From nobody Wed Dec 1 13:46: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 8E9B93A0B79 for ; Wed, 1 Dec 2021 13:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 hl1w9m1aGOoP for ; Wed, 1 Dec 2021 13:46:25 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2110.outbound.protection.outlook.com [40.107.220.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 A3A1A3A0B72 for ; Wed, 1 Dec 2021 13:46:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TWGJ5S09j9id+uYlFAbwIvyYFXQaRcuOUQzEH4yGKs+MHwQbaNcu3fQeAcUTsoVNWoPTCLS1AEGb+jl73/uidRpO6CuwoloOJ6SOd+dazyOWSHi82Np+uqiI76vu+fwL3xP5jCtwPs1dXtuAkHcSu9eJzJJkGrBugfP86u/vtz4rr+vjLY61tpEI6Aie8E6IKrDaZeTD6bmAH0fg5DGC22yIBQGGjfaJ97Og0SuuCDgNf1/x3CyealRfUquPSA+C6XyNBpjwrMAAPtRn1JDwf56PbEsZeZwlH/FEBCdTXSpcTB0xt0EjSHdWY2NHH+GVUehDaSuOLlCN3CD64VaBvw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AHOjnQp53JqGIQ0eZVZOwjNuZyEe0h9SP5JxM8RvWcc=; b=Hx18VPs+tlzyH/cuQ6duHDGcZWscUbBy4Ham4RCMhd0TTjusWolXg1aQc0dtH+zzj1RFDwbsjhBaWfm/PEgf5ls4XfKQXmD1sxK7FZbIKHuYsjgvZfaTYpZAK4J0mz8c/+0gEU73MajR4inO04TxED1GBZlfvF/S2JU4/JrPwchqogcWlHenErxoO1p+1fkX8sT2Cp3ZFvkdKU4wAoQVzxzHvZXMbEpYPlUjoPjudGZuAb3IV62vW7UobSevmPBUUqY5lPKJIK4m3jxR/HgTzecWbzSVQECCE8vpapxOz0iRj4Gdf59I/6JUopn0R8ipr34AejKm01MBGXSb04fCNg== 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=AHOjnQp53JqGIQ0eZVZOwjNuZyEe0h9SP5JxM8RvWcc=; b=HUbASiTfHzmxCQquvjsPHL9Bji8cOT3vrV/x6fXS72UtMhbRFUKQPqatJMpvXf6n5xqszkGmcQOgcQakHWZQAt+8T8eWqz2he9vFDSrdammslRHDxeh5/FlPwG9k0Yb+jB79Pw5bzc3flp0Q1VbDM2FknYych03MzWw8t6UtXWk= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB4987.namprd08.prod.outlook.com (2603:10b6:5:46::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.24; Wed, 1 Dec 2021 21:46:24 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4734.024; Wed, 1 Dec 2021 21:46:24 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-11-30 Thread-Index: Adfm/OHS82gKP0aETQqfDxxJwTChRA== Date: Wed, 1 Dec 2021 21:46:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59d58b62-1a05-477e-91bb-08d9b5140526 x-ms-traffictypediagnostic: DM6PR08MB4987: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ph/vZrsyJHPAiH+MO5h6M6ZLmI6x3v8UDkb0TT41FNNDlITTJGEuDfRdA9x7X7EhiAmabh3VN5ghx+/BA5KG8Q8k8RgKWU+QFMEZSCDIs7qy8qI6YFsRWX+r0Q7cvaoEdHgDNIooDi7wQlS00ZXsyOhZEaoGG4iUviJRKMuy5OjMgBfk1KyF4Fu+dE9vegdreNt524WzeFceqXyDN8jBh1zlAbKcZK4/91i+fVg8ZhSBkbhI32Y2l7f6kLDo4RQVg3Fyr4pW4Sjgu/pHORXUTbdLAgHmP5BRbqKzrIQRFr1/OFDtmm0Ik11q2mFCTbtdaOM2JJFizNmk7WZKA+aJgtT3NwmyBZxKWBkdPlhKFY+M4CdIL24A4uGdwPjzR761M3IiSobxcVjt+dlkWCadI2pRYWwQ6ke91ROC0gHrlc3lRbGRlkwkDzQ/KppMddCsNlJGQu3DN3TwaU95KvAJOf4o8Q14tSlS7MZEbwZHSOoLFlYYwvFwUMQhPfxBcgjDk3URiVuTyLFNFF70p65BI8F+y1rnS0uelGI+tB7JJc9UtEaK5Bfk+Incw/EuYAtF/k8C5lJ9oQZjLl4G1sNizzOefg0ZuPM4ybbrMiP09DAFvXzwgiqwqmCvUC3UkEmn4zLEEenUmsZqcJBUnpHOiT1cJanjxCG7cI52YKMBRzAzIKv3+CFb7kijrlEW9WeuZxkrr3eoXsSieQWWs9fdkUl3gsMeMTw8c/ngdlcpFJVSdmK4jRRk7YMggonuQ76teZ6Qeu1UJgFOZp4fpgZRhmx5WFQtBMw1+6WDs9x9/9g= 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)(366004)(66446008)(66556008)(122000001)(38100700002)(64756008)(66476007)(6506007)(86362001)(82960400001)(71200400001)(76116006)(316002)(9686003)(2906002)(508600001)(166002)(16799955002)(8936002)(6916009)(8676002)(966005)(40140700001)(83380400001)(186003)(55016003)(26005)(52536014)(7696005)(4001150100001)(33656002)(38070700005)(5660300002)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?z/HhSbwSHru4cl8em8BOXMNwweWkH3qDUPyz19TsGgv4jJl79XamwbihicGN?= =?us-ascii?Q?FLvGHD5jwXaHgk6MleNlmv+9/+W0gvLItwSuUJCgFMob8b4KAsAlk0DPFerm?= =?us-ascii?Q?fcIptPM+bCWlzfVZCCmsefRxv5soFvb599p4fAYyYy7P9WXe4RkdptXLSctk?= =?us-ascii?Q?5kxxWk53Q2m1cgsCl5PRstvmPbDKh/vZFsboUaMSu8redWq36Ki+jCDMSaj2?= =?us-ascii?Q?E5ku4vHrtAvhSXoUEhg/ggnPgcSnQ+HLMemecpxO8c4Keu6VvdWc14PqZI2N?= =?us-ascii?Q?2xmIEgmvB9bjIeHP5VmAug6Xj9uTwt/NvjxKPTN6x0qHwgnyIlqKEtN5D4Yr?= =?us-ascii?Q?ftGHDa/+8zgTI+PhnbrI7gyfFosFfFt960WFgFimyXSaYQk/IV681dtkjfL5?= =?us-ascii?Q?fZ3uw6A40dNw82+B9eUwikRgboRxwK3kB1BFP21WOtddLHXaPxP0w6u6SJ1X?= =?us-ascii?Q?CIPCNZVPUhixvEXir7e9i8qGSdE3yCCoJfxGmJm48bePkDcSqh65h4zvqrhD?= =?us-ascii?Q?FgFD9q2zOLkumAtc+72c/s7dm7wTYA4yO6VpgaeN8aC0h5IL+U06epBP6sNV?= =?us-ascii?Q?PgYMR3On42RpK9Cyu1GrnckfYXx5FaSP41XvCYwLXCtNn5DtP79ZVFFxb6LD?= =?us-ascii?Q?X7OUVRKgihRSYtlZCDBxlfhM3ilbASIgScE8Or5pFNQMHEr2i/UxXdBOejBa?= =?us-ascii?Q?pqvVW0g/ZOxoCQWSfKlGNQ9E+/xojHeX+OygL/j/7fyPBKqtI/xlDhxvNj8Q?= =?us-ascii?Q?esOjkEpAgwTASakXAn/5bfLaT+1G5GIUpyru1MbHIS5cSqtJb/aqrxJzE0kT?= =?us-ascii?Q?4gXUUlv23n3wz4oE+byhP+u/zJHzB0M2lJB4ELeYnnijukXamzXeZ2LgDjM8?= =?us-ascii?Q?9xZw6tuKq+BxsEdGPmxacotCLwkI1H3aDMVGhPlVMPh3hqeXp9GgtyRa4Wie?= =?us-ascii?Q?xYesKIdDdPXULRcOoK4LEAsx3E/aoznk9dOKwSZt7rx+uHOjwGpJCHfa85MS?= =?us-ascii?Q?l/pOxI5u0ZCntWm6mB1jeCxvijqC9/gsvs5BLTeS7gBfOpM5gJg0THeWg/yc?= =?us-ascii?Q?U8inMJrLKHBNYkZ/fYHE2WcN6/9R1u845Li06OArawYiBcTrWXm3zXNs0TzM?= =?us-ascii?Q?z1y0dj5FAzuYloJtieaik1/fl3m7ZqSW3icqqg1idEdfLp7l3MKEnOqAjN5B?= =?us-ascii?Q?YX3wOQ/ju/fEnKu8WnHfUqsjILRL46T92bdbpEBF7e82PX2cu7Cdw6scLX7N?= =?us-ascii?Q?XsQk79O/xH9fsBYl34sBL4TRiKd2cYWQJdnvKLmMjmUKUkFrKs7SyuX9m4XI?= =?us-ascii?Q?4E3M+9oZLuXDFCqmJYbE3sTyqmBFPdhRst4qFwWXQLHJ8Gh6JVkYWUNFWCHg?= =?us-ascii?Q?r/M07pGDY9NZe2WLOTlfNRaN7kO/Oe0YtQp4YfMpQ8/bqqm3vtiwI4VvAMSQ?= =?us-ascii?Q?iI2yfuxmW3adiYX4Q0PkxaRVrf32gGIcYtz0HyF+FmSKtbarWgofXnJSG2RZ?= =?us-ascii?Q?FTZ6M+BKadQXqDqutq3R+nkrTmys2J7WgID+kjPAWp5hglZj/hfQQw8Jwjbh?= =?us-ascii?Q?CwYOQJQ6Ml4qxEeMhwto6pu//42xBtBHEA3EWGzJsFdkvtqmB9Yj1qk2u0Uj?= =?us-ascii?Q?wQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084DB0A5691C3ADB79782CC9B689DM6PR08MB5084namp_" 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: 59d58b62-1a05-477e-91bb-08d9b5140526 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2021 21:46:23.9033 (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: jRt0UU+NpfA4TcC5b+XXzD7eazZitowcnOl0Ofn+Msch87voU9XHx/nQUy2XitanWftV0Y5JGfJ0B7dVOVBrhg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4987 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-11-30 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, 01 Dec 2021 21:46:31 -0000 --_000_DM6PR08MB5084DB0A5691C3ADB79782CC9B689DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-11-30 Should we issue a new YANG Semver v06 for the additional text I proposed fo= r issue #84 ? Answer: yes. Joe to issue v-06 of Semver and Jason to sugge= st chairs to go for WG LC in early Jan. Authors have reviewed & think they = are done, and so does the weekly call group. Issue #65: IETF must use Semver for packages, packages for all other orgs s= hould use a revision-label. Balasz to update proposed text. New issue (Bo): use "version" for packages everywhere in the draft, not "re= vision" (but keep "revision" for modules). Note that packages will still u= se a "revision-label" and a "revision-label-scheme". Issue #74: - no need for precedence (conflict resolution for differnet module versions= is already covered) - circular includes in packages is already issue #64 - new subsection in 5.2 that points back to yang semver (for pre-release). = If using YANG semver. Otherwise the scheme should define what to do. Issue #76 - Reshad to refresh on this and we'll discuss in future meetings Topics for next meeting: - More detailed comparison walkthrough for Packages & YANG Library overlap = using current draft and alternative proposal (Jan & Jason) - review any text people have provided to close Packages issues Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 161 096 5630 Meeting password: semver? Occurs every Tuesday effective Tuesday, November 16, 2021 from 9:00 AM to 1= 0:00 AM, (UTC-05:00) Eastern Time (US & Canada) 9:00 AM | (UTC-05:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dme2c6491ebcc37b8127c1244d244d2754 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1610965630## Call-in toll number (US/Canada) --_000_DM6PR08MB5084DB0A5691C3ADB79782CC9B689DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-11-30

 

Should we issue a new YANG Semver v06 for the additi= onal text I proposed for issue #84 ?  Answer: yes.  Joe to issue = v-06 of Semver and Jason to suggest chairs to go for WG LC in early Jan. Au= thors have reviewed & think they are done, and so does the weekly call group.

 

Issue #65: IETF must use Semver for packages, packag= es for all other orgs should use a revision-label.  Balasz to update p= roposed text.

 

New issue (Bo): use "version" for packages= everywhere in the draft, not "revision" (but keep "revision= " for modules).  Note that packages will still use a "revisi= on-label" and a "revision-label-scheme".

 

Issue #74:

- no need for precedence (conflict resolution for di= ffernet module versions is already covered)

- circular includes in packages is already issue #64=

- new subsection in 5.2 that points back to yang sem= ver (for pre-release).  If using YANG semver.  Otherwise the sche= me should define what to do.

 

Issue #76 - Reshad to refresh on this and we'll disc= uss in future meetings

 

Topics for next meeting:

- More detailed comparison walkthrough for Packages = & YANG Library overlap using current draft and alternative proposal (Ja= n & Jason)

- review any text people have provided to close Pack= ages issues

 

Jason

 

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

Weekly webex call details:

 

Meeting number (access code): 161 096 5630

Meeting password: semver?

 

Occurs every Tuesday effective Tuesday, November 16,= 2021 from 9:00 AM to 10:00 AM, (UTC-05:00) Eastern Time (US & Canada)

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

 

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

Tap to join from a mobile device (attendees only)

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

--_000_DM6PR08MB5084DB0A5691C3ADB79782CC9B689DM6PR08MB5084namp_-- From nobody Wed Dec 1 17:05: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 037383A0D63; Wed, 1 Dec 2021 17:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=sandelman.ca 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 kutVBRs1GKLQ; Wed, 1 Dec 2021 17:05:10 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2247F3A0D60; Wed, 1 Dec 2021 17:05:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EAC2E38B16; Wed, 1 Dec 2021 20:08:27 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4G4pxcVElPyh; Wed, 1 Dec 2021 20:08:26 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A8EFF38B15; Wed, 1 Dec 2021 20:08:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1638407306; bh=OENfVDt98kXP2jA+w+Kh6QEX7Ooae0svnG8cCRyVYqg=; h=From:To:CC:Subject:In-Reply-To:References:Date:From; b=It7i1qhHsHwW6ZoDFiHOGCkIs9qEolXgGDCfVv9eBBZxRUg8lyOJz1Z3iI6g8XIk6 sEpxp4z8qBGbwjMrx1+/VFcCDCtWMoN7aSM1wPRQzgdfVXnJKPuBB48UlDLI7zetbB N6IITc3ovkB5wKLUW5khGvXuKcdPUfssGyFPkzmQUMnonSwGkGj5n2zOltPt/bx4/3 dyTMP+W7j7I4QYY2uSFE+ukCKTbwmXWHQpf4XGujw7p4pe8eTjk2/KMjZg0JpODliw cSn3wjimSJ/n/nntlK/H6ugZhX/yYttocYsYlfIcrpfCtodfdytChfoB7k4PWDH0q8 vbtV9jOuR3xmg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0528F2CC; Wed, 1 Dec 2021 20:05:07 -0500 (EST) From: Michael Richardson To: anima@ietf.org CC: netmod@ietf.org In-Reply-To: <163839871300.12623.6948412300953244815@ietfa.amsl.com> References: <163839871300.12623.6948412300953244815@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] New Version Notification for draft-richardson-anima-rfc8366bis-04.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: Thu, 02 Dec 2021 01:05:16 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Name: draft-richardson-anima-rfc8366bis Diff: https://www.ietf.org/rfcdiff?url1=draft-richardson-anima-rfc8366bis-00&url2=draft-richardson-anima-rfc8366bis-04 I uploaded -01, found some yang errors... I did -02/-03 before I figured out how to run the right pyang command myself to determine the source of the error. This version has a new iana-voucher-assertion-type which is intended to be handed to IANA to maintain. I don't think that our IANA Considerations are correct as yet. I think that we need a FAQ somewhere. In the meantime, I would really like some YANG Doctor help here. Toerless: I think that this is the major change. Qiufang Ma did the bulk of the YANG work here, and with the blessing of the WG chairs, I'd like to add her as a co-author. --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Description: Signature =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmGoG8IACgkQgItw+93Q 3WU+rgf+I1QzbjUSEYZr3pyQuMuDy7J8gji7WiZQoYd8ZqcLsnWb5y94XP3Q+B3O P6/GV/YCfEhhjQU9MHkn9XqLND6YawbjFtZTndZWK6LXQU9oSOhmW4h/RUnZ+IS+ NcicGJjdArgrRRsDlTe816Q1cqxVSPQGx458aRlG76sxIPWmJyp8qP56v/PcE856 vIf4JJYEmsb+NgPyrtemrWs29r9oWbv4XkHsBFdd03Fe39jYME1L8g5oAA9K5ywY nSS5pBXcqULcDizxU/jSKyRnaxFW3Przf3nrjv0uXRpbUHqFIcXtc90pVmrZKaO+ EhjOLNW/1kgKRjZmRJETMlV/yeP24A== =9ReJ -----END PGP SIGNATURE----- --==-=-=-- From nobody Fri Dec 3 01:59: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 C12343A1566 for ; Fri, 3 Dec 2021 01:59:21 -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, 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 ik6b267QfK_N for ; Fri, 3 Dec 2021 01:59:19 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B61C63A1564 for ; Fri, 3 Dec 2021 01:59:18 -0800 (PST) Received: from [192.168.1.116] (213-67-237-150-no99.tbcn.telia.com [213.67.237.150]) by mail.tail-f.com (Postfix) with ESMTPSA id 64A6D1B03CF1; Fri, 3 Dec 2021 10:59:12 +0100 (CET) From: Jan Lindblad Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_815646E7-6344-463D-8C9E-F0687A45E110" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 3 Dec 2021 10:59:12 +0100 In-Reply-To: <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> Cc: "Belotti, Sergio (Nokia - IT/Vimercate)" , "netmod@ietf.org" To: Kent Watsen , "maqiufang (A)" References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 03 Dec 2021 09:59:22 -0000 --Apple-Mail=_815646E7-6344-463D-8C9E-F0687A45E110 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kent, Qiufang, all, >>> Offline validation of alone IS required >>> Options: >>> Clients MUST copy/paste any referenced system configuration into = , even though it goes against our objective of avoiding-copy = when possible. >>> Defer work to be a YANG-next effort. >>=20 >> In order to move forward, I would propose working out some more = options in this list. I have suggested a few to the authors that I think = are better than the two above, but I will leave it to the authors make = the call for what they want to bring up for discussion. >=20 > I don=E2=80=99t think the case has been made that *offline* validation = of by itself must be valid. Yes, *online* must be = valid, as must , with the intention of RFC 8342 being that = both are validated in one and the same operation by the server (known = to me as an author of RFC 8342). I understand that implementations may = have assumed offline validation of must be valid, I just = can=E2=80=99t find the RFC reference that demands it be supported, and = without such reference, it falls into an undefined area. Necessitating = offline validation of , if that is what the WG decides, results = in solutions for which none seem nice to me, at least I haven=E2=80=99t = seen any yet. Please share any =E2=80=9Cbetter options=E2=80=9D you = have in mind. =20 Here you are introducing two concepts that the RFCs (6020, 7950, 8342) = are never mentioning: online and offline validation. Then you say that = because the RFCs don't talk about these concepts, the behavior is = undefined. I strongly disagree. The RFCs talk about validation, and = describes the rules for how that happens. These rules always apply, = regardless of online, offline or the phase of the moon. If you think the online and offline validation concepts have merit, I = would like to see proper definitions of them, and how you would like to = modify the existing RFCs with respect to these concepts. It might also = be a good idea to update the proposed draft, which currently does not = mention these concepts. The added value and the core essence of YANG is enabling us to reason = about configurations and compute configuration changes without = necessarily asking the server if a configuration is valid by "trial and = error". This is possible because a YANG model is a detailed and = reasonably complete description of the management interface. Introducing = changes to YANG that breaks this basic premise would be dumbing down = YANG, and I can't see the benefit with this change, or how this would be = compatible with YANG 1.0, or 1.1 rules. I think the ideas behind the system datastore are interesting and in = many use cases useful. We just need to introduce them in a way that = doesn't break existing, agnostic implementations. I made some proposals earlier, both on the interim and privately to the = draft authors, along these lines: Option #1 + We could have a new system datastore that technically is a part of = running. Everything in system would show up in running to clients = unaware of the system datastore. Every time the system datastore changes = for whatever reason, the running datastore transaction ids (if we manage = to get that concept defined), are updated + Clients interested to see pure view of the system datastore without = anything else in running could issue a get-data towards the system = datastore + Clients interested to see a pure view of running without any system = datastore elements could issue a get-data towards running with an extra = flag called 'without-system' + Since all system elements are already part of running, clients have no = need to copy data between the two datastores Option #2 + We could have a system datastore that technically is a part of = operational. Everything in system would show up in operational to = clients unaware of the system datastore. The running datastore always = maintains referential integrity, i.e. cannot reference the system = datastore. + Clients interested to see pure view of the system datastore could = issue a get-data towards the system datastore + Since the system datastore is not part of running, clients can already = see a pure view of running without any system datastore elements using a = simple get-data.=20 + Clients that are aware of the system datastore and are interested to = configure references from running to system elements would issue an = edit-data rpc with the additional flag 'resolve-system-references'. This = will make the server copy any system elements referenced into running = without the client doing so explicitly. + Clients unaware of the system datastore would have to include (copy) = information from the system datastore to running in order to reference = them. > In the meanwhile, can we discuss the issues around a legacy client = failing an offline validation? In this case, a production deployment = must have 1) deployed devices that support , 2) deployed at = least one client that supports , and 3) decided to let clients = start pushing config using . While in the pre-production = testing phase, it would be quickly discovered that all legacy clients = need to be updated. By the time of going to production, the deployment = should have all the clients updated, so it seems that only the forgotten = (relatively insignificant) clients might have an offline validation of = failure. Is this a fair assessment? 1) agreed, without devices that support the system datastore, no problem 2,3) well, a "client" in this case could very well be a CLI operator or = other management interface. Even in highly automated networks, CLI = operators are still common Your description of the operations environment where the operator has = full implementation control of all clients is very different from my = field experience. Not only do I believe the situation with multiple, = independent clients is the most commonly occurring one in the real world = across all server deployments, but I also think the operator usually has = limited insight into as well as control over which specific protocol = features the clients implement. I therefore think your assessment is = fair only for a minority of field situations. Best Regards, /jan= --Apple-Mail=_815646E7-6344-463D-8C9E-F0687A45E110 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Kent, Qiufang, all,

    • Offline validation of <running> alone IS = required
      • Options:
        1. Clients MUST copy/paste = any referenced system configuration into <running>, even = though it goes against our objective of avoiding-copy = when possible.
        2. Defer work to be a = YANG-next effort.

In order to move = forward, I would propose working out some more options in this list. I = have suggested a few to the authors that I think are better than the two = above, but I will leave it to the authors make the call for what they = want to bring up for = discussion.

I don=E2=80=99t think the case has been made that = *offline* validation of <running> by itself must be valid. =  Yes, *online* <running> must be valid, as must = <intended>, with the intention of RFC 8342 being that both are = validated in one and the same operation by the server  (known to me = as an author of RFC 8342).  I understand that implementations may = have assumed offline validation of <running> must be valid, I just = can=E2=80=99t find the RFC reference that demands it be supported, and = without such reference, it falls into an undefined area. =  Necessitating offline validation of <running>, if that is = what the WG decides, results in solutions for which none seem nice to = me, at least I haven=E2=80=99t seen any yet.  Please share any = =E2=80=9Cbetter options=E2=80=9D you have in mind. =  

Here you are introducing two concepts that the = RFCs (6020, 7950, 8342) are never mentioning: online and offline = validation. Then you say that because the RFCs don't talk about these = concepts, the behavior is undefined. I strongly disagree. The RFCs talk = about validation, and describes the rules for how that happens. These = rules always apply, regardless of online, offline or the phase of the = moon.

If you think the online and = offline validation concepts have merit, I would like to see proper = definitions of them, and how you would like to modify the existing RFCs = with respect to these concepts. It might also be a good idea to update = the proposed draft, which currently does not mention these = concepts.

The added value and the = core essence of YANG is enabling us to reason about configurations and = compute configuration changes without necessarily asking the server if a = configuration is valid by "trial and error". This is possible because a = YANG model is a detailed and reasonably complete description of the = management interface. Introducing changes to YANG that breaks this basic = premise would be dumbing down YANG, and I can't see the benefit with = this change, or how this would be compatible with YANG 1.0, or 1.1 = rules.

I think the ideas behind the = system datastore are interesting and in many use cases useful. We just = need to introduce them in a way that doesn't break existing, agnostic = implementations.

I made some = proposals earlier, both on the interim and privately to the draft = authors, along these lines:

Option = #1
+ We could have a new system datastore that technically is = a part of running. Everything in system would show up in running to =  clients unaware of the system datastore. Every time the system = datastore changes for whatever reason, the running datastore transaction = ids (if we manage to get that concept defined), are updated
+ = Clients interested to see pure view of the system datastore without = anything else in running could issue a get-data towards the system = datastore
+ Clients interested to see a pure view of running = without any system datastore elements could issue a get-data towards = running with an extra flag called 'without-system'
+ Since all = system elements are already part of running, clients have no need to = copy data between the two datastores

Option #2
+ We could have a system = datastore that technically is a part of operational. Everything in = system would show up in operational to  clients unaware of the = system datastore. The running datastore always maintains referential = integrity, i.e. cannot reference the system datastore.
+ = Clients interested to see pure view of the system datastore could issue = a get-data towards the system datastore
+ Since the system = datastore is not part of running, clients can already see a pure view of = running without any system datastore elements using a simple = get-data. 
+ Clients that are aware of the system = datastore and are interested to configure references from running to = system elements would issue an edit-data rpc with the additional flag = 'resolve-system-references'. This will make the server copy any system = elements referenced into running without the client doing so = explicitly.
+ Clients unaware of the system datastore = would have to include (copy) information from the system datastore to = running in order to reference them.

In the = meanwhile, can we discuss the issues around a legacy client failing an = offline validation?  In this case, a production deployment must = have 1) deployed devices that support <system>, 2) deployed at = least one client that supports <system>, and 3) decided to let = clients start pushing config using <system>.   While in the = pre-production testing phase, it would be quickly discovered that all = legacy clients need to be updated.  By the time of going to = production, the deployment should have all the clients updated, so it = seems that only the forgotten (relatively insignificant) clients might = have an offline validation of <running> failure.  Is this a = fair assessment?

1) agreed, without devices that support the system = datastore, no problem
2,3) well, a "client" in this case could = very well be a CLI operator or other management interface. Even in = highly automated networks, CLI operators are still common

Your description of the operations environment = where the operator has full implementation control of all clients is = very different from my field experience. Not only do I believe the = situation with multiple, independent clients is the most commonly = occurring one in the real world across all server deployments, but I = also think the operator usually has limited insight into as well as = control over which specific protocol features the clients implement. I = therefore think your assessment is fair only for a minority of field = situations.

Best = Regards,
/jan
= --Apple-Mail=_815646E7-6344-463D-8C9E-F0687A45E110-- From nobody Fri Dec 3 02:26: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 347AE3A03EE for ; Fri, 3 Dec 2021 02:26:24 -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 XxT82Cjb0u0T for ; Fri, 3 Dec 2021 02:26:19 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2053.outbound.protection.outlook.com [40.107.21.53]) (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 4A94E3A03EA for ; Fri, 3 Dec 2021 02:26:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VqGspi1VWgu0miZ6bP5RviEwJY8khCSYA+XJqTxVx7HxARFu3yqu8L/zd9fi/DCPkn6PFHdzdb2I78LVJ9KAZKn2TgZyOeWjMq9Rwi5avAcl636XnxGsbjFIXm1tDSDY+NPpLvXoicFPkLvcRUvTqTP4aO83o2Qdc/0jSv2vUGctDKfmtrqM8ce/Q+A5AiKw72fTcijKJrgPCCSJ5DTQKt5KR7JMH0UOwEP6PmBqUIBKglsbB3P4ryfKTRU459NnZTauwW2idY1FmhqPXdYqJk2Kz8du/GuL9mJ+q/vkgIowDzmb8q9yT8g5MASqE8G/75F8wrs6cB9wE9PFlb6wEA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ds3LDhe+AAU2/5WDEhU9OEFZk39p9z2lTaUtwY6y/2o=; b=UblliCmOmE1ww57p7GWlXLU9BeCrD41QeY5A10eMiaZSIhJ+3qlrT4VuDO32HZpsAHvioAwlZs+XsqbJbvy/3J8JZit80viIYMp2by7QTz+NsUsoFOnv7jMFCtZMxlD4uVPF64FaHPxQIEzzB1VWOOMk3zDaKlzoboNjGonW3XJAEqNOCVZ5Irm4FjWZLCgqgDxY8gKI0kkP/UdcARxp/LpTEG+9t/sN+2GQNdfRGwjUatENI8JdMPD9K+HW0F0ugxrTF/pGw6kYp4gLArek1WbVJHeQCc8+dpf0ZVkLWQ8avYfUU007igVLO6UIBF9zHXqQhldPtorGCc6L/6rSGg== 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=Ds3LDhe+AAU2/5WDEhU9OEFZk39p9z2lTaUtwY6y/2o=; b=iM0Ht04kZomOY8dvMq6b4uDNu28dmTn8kaO84sIQdRKtRBdbch97qZxBmbPMt4deKuDX2TSgyNUnPfEXLx3PnVBSMkqIXhX7S1cz8UFJAoXhETSGZorvYFGDdJEzmUzRZp38+1MWwdhc5tCnem2SHkwKRST5zmueld+v8u2RT5o= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1650.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3b6::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.11; Fri, 3 Dec 2021 10:26:11 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::5cb6:636f:eb2d:d6f2]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::5cb6:636f:eb2d:d6f2%8]) with mapi id 15.20.4755.016; Fri, 3 Dec 2021 10:26:11 +0000 Date: Fri, 3 Dec 2021 11:26:10 +0100 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Jan Lindblad Cc: Kent Watsen , "maqiufang (A)" , "netmod@ietf.org" Message-ID: <20211203102610.6zntrwbemnyxxjnr@anna> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Jan Lindblad , Kent Watsen , "maqiufang (A)" , "netmod@ietf.org" References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AM9P192CA0001.EURP192.PROD.OUTLOOK.COM (2603:10a6:20b:21d::6) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 Received: from localhost (212.201.44.244) by AM9P192CA0001.EURP192.PROD.OUTLOOK.COM (2603:10a6:20b:21d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.23 via Frontend Transport; Fri, 3 Dec 2021 10:26:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 567b48dc-b6ee-40c8-b260-08d9b647538c X-MS-TrafficTypeDiagnostic: AM9P190MB1650: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LxLd23LKE7VCYDyAW7yoksaZxyCcpOk44OG7pCKXbMM71foEqoXCjfbnYiSm+mwwPkmAGUn1+l+tevEhvW5BT/4xbYaeqWUyRKYyhDiP6pwN9CUUi8A+1gLaUfVP+eNj+7Jqo+0U8WFtbWPxsfMSesRox5lj3K7uh3LHfdeVUPxfKW6BiAFaLdhkqnumWjMssMJTdKCpsxWWUMQzgFjiA37cgXAbTwuGzMZzDrwWCLsTysT1cYDu6sU6T4bj3zLT71amwpKqw0QK945DcwXAfPVTrupmzZuEQPJQlCsAsQuWUSyxxLnP3adv7VkODYMzWT+T0yPfEvA6HPu/Wlbs1qBvyVx0MofvGc5IFqtOJQHkKcnv7HMTaoUA5GXowBG6aJ6nvNQ0/hphtbb+mIVXmiNYxI+xWf3li3r0ive7536A9oX3EMTdGfWIUhnSw0axxwJ8udOxr30eNmHKSqkgN9JhGxxw4tPpifjDYlpjjpzlJ5tggR1jhavvHjByJXWFXkY2rtGMhjtumWewmRKwE6i1mEqOeM/zmw3fzGj80DMjqx5ugqpmzMi6CWqKllsYDwG4Kl8gwdSNVhVXBuxLvyjwLXTMCPV2McyNmKYeUaxfhJdwCcwrsW3bc/oo+tC3dZU2OcNDtA6ErArArINKJ3q9nQLt+5ltObEW/63Hd276fUPS0sW8dYAtOR1egRA8j6sFGkb5/4bKsSpQVJa8DrIQ9GUFnaxlZsRZoPZimF3joXyS/pCojYMW6WTuDjwKE5isjqwWBAhAIYz8yHcqSyX6VwNVFC+RPv1yl+Agi+E= 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:(7916004)(366004)(40140700001)(4326008)(6496006)(6916009)(66946007)(54906003)(38100700002)(52116002)(1076003)(5660300002)(85182001)(9686003)(2906002)(786003)(508600001)(8936002)(38350700002)(6486002)(316002)(33716001)(26005)(186003)(66556008)(3450700001)(83380400001)(85202003)(86362001)(956004)(8676002)(66476007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TDI3MWdmaVZMK1BXYXB0dGdoS21vSGVudDloNjdkK0M2bHFZWEVidzhxMU9Q?= =?utf-8?B?VGU5dUZkaUV3YjBhcHkxbmZnV1lleGZqdTNCWUxEYjFrQzNQOVhHazZMTEhj?= =?utf-8?B?VDRmdlVmSGR6MWpZSGJZZFRmaEdqZmFTc1lNeXFXT0toQi82MkhxbTVDQUUr?= =?utf-8?B?bnN3ejJpQ3dJWlZyenA1U2EzNlBNdzM3aHMyZXZ1SGZlWnMyVXdPSytReGVB?= =?utf-8?B?Q2VZNllBYVdWRVp1bUM5aXVDQS83dVdnbTJiNityZzQ0S1pHMWJsZ0QzYVpz?= =?utf-8?B?Wjg3VHNmUncvTlBFUk1rR3Z5WlpmbWhESlRWeFUyVXZnNlVLUUUwdUR1SW9q?= =?utf-8?B?ZDVzc045ck9menQ3cUI3ZUhjT29kUC9nUXVyUVVWR0N4d0FNeEhkT1RRVW9s?= =?utf-8?B?TGVnRXNXZldjL2JRWlZqaHdVb2xBeFBrTTc0OUw2Qno1dlpuWUx4UTNNTlVl?= =?utf-8?B?aEM4QlpSbXFzQXBvYi9GRlFoYTRLMUFMeVlNU3BDWDBxbTJPYlFjTHBDNkNl?= =?utf-8?B?aDhVdXd4Qnc0d3dldW12YjNoWGcrYTJMVy95a1R0RWlJVDBLYmtlRzBWQzBK?= =?utf-8?B?cm9MM2krWk9McDlna0I3S2IwR3pLRFNoTWJHVVY0bGdYRVViMUJOOXEvcnRq?= =?utf-8?B?b1M1OW0xT0Y3UVc0c2h2YnNQbzFTM0FXQUN4T2IrWTJJM3drRU1FbFNZZk12?= =?utf-8?B?SitXZ3R4cmF1WkJDUnBEeUFUcGdYVkdUMTd2eDFBUmxjY01FSkVtQXBiWWJp?= =?utf-8?B?aFlDZkNQQnRwb1pjM1hmWFF3a3RDQWZmOXB2Z1RLd0g0TkYyTHJiV3lCWHFV?= =?utf-8?B?TEc4WC9iRTQ5UWJQUEg0Q0p0RFNzUVZ1bXFPRDNTTmdqcEg5UUZzSjd1UzA4?= =?utf-8?B?Q0xBWTFraVJSYUsxMnNaRjVZQWpwbkNaUlJEZnpuN1Y2M1B1VFZZc2JSRDhO?= =?utf-8?B?RFlLZSttaEYvdk5adVRJaXB4eHUyYy9vc0R1S0FOUkVBaVBTMjNYVHAxNDYy?= =?utf-8?B?b2UzdWRKakJxdkRJWjY4c1BialM4Tys2SUNibDI1K2oyWkllTnc0WCtCa3FM?= =?utf-8?B?OUdDS0N2TTJrQ2JUbGY5K2xETWpQdmJMWXptRlNkNUY5ZzNGWlJsNWJZRnp6?= =?utf-8?B?VmtGK2RjWUIvNE4xTDdteXhoV0F5c0g3dFdldlRjNnRGK2hraGV6SmVFOEcw?= =?utf-8?B?R1hteGZwSWJxbkFVVVQyNnhKOExSL2VUV0RKVVlBU0RXY1Y4dkxkZS9sOExC?= =?utf-8?B?eHNodS9ZVFRjakM5WTEyRWphUmN3V2x2RHFtWmhTa1d0TWhsNDZOQm0ycGQ3?= =?utf-8?B?WVlDdkdWMW02Q2JxK1l2ZVplOXZLNXJtUkRkbmtWUXE4KzBlMGRLRVZZWkk5?= =?utf-8?B?cS91Z0xVY0ZFdVlteFFEOWlvMmM1TlJybEtBK1FzK01xUjM0M3RHTmxzYm11?= =?utf-8?B?MThLaGVoYXhpbU1JeE15OTFIM25BcFV5aVRaU0V6YzB0ZnEvUEZvVHgxT3pp?= =?utf-8?B?ZU9LTE05blUxUHlKUEU5NWQ4ektWNDE4N3YzRWY0UDRDT0dWUWtySnBURnBn?= =?utf-8?B?ZnpTLzBvaEVBWm1PQlE0R0RMd1ZTN2RvSDlvZkJoZVVnWm5sS1Bkc04zQXVB?= =?utf-8?B?STdwc0taMGtTc2ZtS2l2YVIxdUFEejladjc3bGVaYVhDME5EclZuUWFtSHVm?= =?utf-8?B?cmRydHgxRldHdCttampjSnNVODRRaFovZ0M3bVIzMCswUTdILzJkTVFyM0xL?= =?utf-8?B?VXBTVGVhQnRMVmlBNnh5YXk0c21xdHBlcnQ5WWFmOSt4MnUyS1NvNW9PdzVP?= =?utf-8?B?WFlnNTZ4R1gwdXdxdmRjUHBLbmFiNnRiOEl3STlzUjdqb3Fyc2VUaDRaMVV5?= =?utf-8?B?ejRqdVVpaW43MVpickpQb3dRdXNlSUVMbVpoSng2TVVHdkpRQ2tSTHpEM1Rq?= =?utf-8?B?R1Z6Mk9MS1c5UVdCQ0ZoYUU2d2hpSTZNQmFwQUViTS9RL3JwL3lJTmxQcTFU?= =?utf-8?B?VWhSRDlxcHYyQkFkTkd2NWhZOVlJK3ZLNlBMeW9iYVdQaVVuR0M0cEUydEFP?= =?utf-8?B?ZTA2TGcvR3pCbHI5SzdhUHJuZUhmbHlSTUJoaDhnK3UyamJLNnVBV0p2dlBH?= =?utf-8?B?bDUzcjYyZ0dna1lZU1BMSkVFZ2s3YlZpb25XV1BNVGxNQ2QweVF4Z0tSSFdj?= =?utf-8?B?M2Q5RGovSDVpdWU2QWNBZXFIclVGbklPdkl1M04yY0pxMzc3dGR1WEdPd1g5?= =?utf-8?B?aWx0d1RWZHg0NlVtc0hkSUxzdUl3PT0=?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 567b48dc-b6ee-40c8-b260-08d9b647538c X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2021 10:26:11.1752 (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: Oy0bRU0NfFMuaXELmGW3GIgJwqTJSuoshgTg2uvtVn2fskyQ3GIJ1thajpQEjV51SEgv5QFVaOcpNi0M8aiKYdKcNTYjfoAuGUE33fQh4mQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1650 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 03 Dec 2021 10:26:24 -0000 On Fri, Dec 03, 2021 at 10:59:12AM +0100, Jan Lindblad wrote: > I made some proposals earlier, both on the interim and privately to the draft authors, along these lines: > > Option #1 > + We could have a new system datastore that technically is a part of running. Everything in system would show up in running to clients unaware of the system datastore. Every time the system datastore changes for whatever reason, the running datastore transaction ids (if we manage to get that concept defined), are updated > + Clients interested to see pure view of the system datastore without anything else in running could issue a get-data towards the system datastore > + Clients interested to see a pure view of running without any system datastore elements could issue a get-data towards running with an extra flag called 'without-system' > + Since all system elements are already part of running, clients have no need to copy data between the two datastores > > Option #2 > + We could have a system datastore that technically is a part of operational. Everything in system would show up in operational to clients unaware of the system datastore. The running datastore always maintains referential integrity, i.e. cannot reference the system datastore. > + Clients interested to see pure view of the system datastore could issue a get-data towards the system datastore > + Since the system datastore is not part of running, clients can already see a pure view of running without any system datastore elements using a simple get-data. > + Clients that are aware of the system datastore and are interested to configure references from running to system elements would issue an edit-data rpc with the additional flag 'resolve-system-references'. This will make the server copy any system elements referenced into running without the client doing so explicitly. > + Clients unaware of the system datastore would have to include (copy) information from the system datastore to running in order to reference them. > Option #3 There is a client on the system that makes changes to running just like any other remote clients can make changes to running. System generate config that is not editable explicit config in running goes straight into the applied config in operational. This does not require a system datastore (in fact something like a system datastore may exist as the _logic_ of the system client, the good old example we had is allocting an unused uid for an account that, once allocated, is maintained in running). /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 Dec 3 03:01:28 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 9AC823A0777 for ; Fri, 3 Dec 2021 03:01:26 -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.20210112.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 IQktLhUV4v3y for ; Fri, 3 Dec 2021 03:01:21 -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 7BA2F3A077C for ; Fri, 3 Dec 2021 03:01:21 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id u3so5642830lfl.2 for ; Fri, 03 Dec 2021 03:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=J29zht5p2udTLwtz/AyQim3oh1GTaj8lcH9aWM1bbYc=; b=FYVp+4i0MYNRlrCJVcyPRapQ5qPOufFJ+Skg0eVZsUToxfhn9iziHH8RiRFArOp1Mv xzAtPYntWUkoFxhIIqUH7Wbm78SJRQmBCsR3wxUZkrm8dGpE/XBOpfjuwRFuMEwzU5bm qB38anEYA7MDSSm2YihS2VmJSZOXdhOV38vtez1z7rq9+qHDkJHVyjyCxbI//EwvrBYu 4K2Gccvw1Pu0EmZKvqTARfkiI0eltBJx+As3MRthD3/mVNd6m0XMPVEpM7h7G9m+A35p os/uOWXHAfXLZSOU/AfgHDXbk6uE2y+PdHQf3NiokdOTenIlJYIt+1RVJERUZxW+g9gY e5tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=J29zht5p2udTLwtz/AyQim3oh1GTaj8lcH9aWM1bbYc=; b=UhPim4KoqE8T/QiSe3PDn/nmfw7+QpksDWaIZyGYOUnipdV8wzMyOgxG4r/QqmQqoX c6PZfp2MfeY/rl45B/uI3f2KJz3WdDaJKC3pFtmPZNsiYGmTis5fRfXdVk1D2GbnY7OD s+W5spnviqCFPr7q/EwooMMkfaClJKlQBUM8dkeGwN12b57XtOH+HRK/7Zzjifq13mO3 b++i/F2uw0/3R2t1fFakCrshAlIN4pAp+HV9/vR+ik63Ele6VpLFPAGatAhKoAPkvyBi jC601rpQbKhKXWP9GwnOpYebkMxispWyivVb9LDfol9u1cvDqVWUMkYy0dtnV7KDP2Tf cbsw== X-Gm-Message-State: AOAM530g5vzKpN4m58iezBXtydAmqge41j9Auim8DgBIhUR8tVT6fK5Y V5OfNaeBqVVqXQHQuz9ORGJknlMoYmxsXsN4S3omDw== X-Google-Smtp-Source: ABdhPJy3sJV0zWJ20VdLqb17mEGGuzyZfzsLrcgrebTf585RuheswZoP4lFAxkEgRlXFO99lP5xF+WI+q3756avg5Bs= X-Received: by 2002:a05:6512:68c:: with SMTP id t12mr17566145lfe.10.1638529278389; Fri, 03 Dec 2021 03:01:18 -0800 (PST) MIME-Version: 1.0 References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> In-Reply-To: <20211203102610.6zntrwbemnyxxjnr@anna> From: Andy Bierman Date: Fri, 3 Dec 2021 03:01:07 -0800 Message-ID: To: Juergen Schoenwaelder , Jan Lindblad , Kent Watsen , "maqiufang (A)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000097c64405d23bd35c" Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 03 Dec 2021 11:01:27 -0000 --00000000000097c64405d23bd35c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 3, 2021 at 2:26 AM J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Dec 03, 2021 at 10:59:12AM +0100, Jan Lindblad wrote: > > > I made some proposals earlier, both on the interim and privately to the > draft authors, along these lines: > > > > Option #1 > > + We could have a new system datastore that technically is a part of > running. Everything in system would show up in running to clients unawar= e > of the system datastore. Every time the system datastore changes for > whatever reason, the running datastore transaction ids (if we manage to g= et > that concept defined), are updated > > + Clients interested to see pure view of the system datastore without > anything else in running could issue a get-data towards the system datast= ore > > + Clients interested to see a pure view of running without any system > datastore elements could issue a get-data towards running with an extra > flag called 'without-system' > > + Since all system elements are already part of running, clients have n= o > need to copy data between the two datastores > > > > Option #2 > > + We could have a system datastore that technically is a part of > operational. Everything in system would show up in operational to client= s > unaware of the system datastore. The running datastore always maintains > referential integrity, i.e. cannot reference the system datastore. > > + Clients interested to see pure view of the system datastore could > issue a get-data towards the system datastore > > + Since the system datastore is not part of running, clients can alread= y > see a pure view of running without any system datastore elements using a > simple get-data. > > + Clients that are aware of the system datastore and are interested to > configure references from running to system elements would issue an > edit-data rpc with the additional flag 'resolve-system-references'. This > will make the server copy any system elements referenced into running > without the client doing so explicitly. > > + Clients unaware of the system datastore would have to include (copy) > information from the system datastore to running in order to reference th= em. > > > > Option #3 > > There is a client on the system that makes changes to running just > like any other remote clients can make changes to running. System > generate config that is not editable explicit config in running goes > straight into the applied config in operational. This does not require > a system datastore (in fact something like a system datastore may > exist as the _logic_ of the system client, the good old example we had > is allocting an unused uid for an account that, once allocated, is > maintained in running). > > +1 to option 3. Consider an implementation that moves all the "hidden system logic" off-box to a controller, such that the initial config is literally supplied by an external client. I have yet to hear a single use-case for creating a datastore. "The client might want" is not a use-case for standardization. I do not understand the "pure view". Seems like if this was a real problem to solve, then NMDA would have included a system datastore from the start. /js > Andy > > -- > 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 > --00000000000097c64405d23bd35c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 3, 2021 at 2:26 AM J=C3= =BCrgen Sch=C3=B6nw=C3=A4lder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Dec 03, 2021 at = 10:59:12AM +0100, Jan Lindblad wrote:

> I made some proposals earlier, both on the interim and privately to th= e draft authors, along these lines:
>
> Option #1
> + We could have a new system datastore that technically is a part of r= unning. Everything in system would show up in running to=C2=A0 clients unaw= are of the system datastore. Every time the system datastore changes for wh= atever reason, the running datastore transaction ids (if we manage to get t= hat concept defined), are updated
> + Clients interested to see pure view of the system datastore without = anything else in running could issue a get-data towards the system datastor= e
> + Clients interested to see a pure view of running without any system = datastore elements could issue a get-data towards running with an extra fla= g called 'without-system'
> + Since all system elements are already part of running, clients have = no need to copy data between the two datastores
>
> Option #2
> + We could have a system datastore that technically is a part of opera= tional. Everything in system would show up in operational to=C2=A0 clients = unaware of the system datastore. The running datastore always maintains ref= erential integrity, i.e. cannot reference the system datastore.
> + Clients interested to see pure view of the system datastore could is= sue a get-data towards the system datastore
> + Since the system datastore is not part of running, clients can alrea= dy see a pure view of running without any system datastore elements using a= simple get-data.
> + Clients that are aware of the system datastore and are interested to= configure references from running to system elements would issue an edit-d= ata rpc with the additional flag 'resolve-system-references'. This = will make the server copy any system elements referenced into running witho= ut the client doing so explicitly.
> + Clients unaware of the system datastore would have to include (copy)= information from the system datastore to running in order to reference the= m.
>

Option #3

There is a client on the system that makes changes to running just
like any other remote clients can make changes to running. System
generate config that is not editable explicit config in running goes
straight into the applied config in operational. This does not require
a system datastore (in fact something like a system datastore may
exist as the _logic_ of the system client, the good old example we had
is allocting an unused uid for an account that, once allocated, is
maintained in running).



+1 to option 3.
Consider an implementation that moves all the "hidden system logic&= quot; off-box
to a controller, such that the initial config is li= terally supplied by an external client.

I have yet= to hear a single use-case for creating a <system> datastore.
"The client might want" is not a use-case for standardization.=
I do not understand the "pure view". Seems like if thi= s was a real problem to solve,
then NMDA would have included a sy= stem datastore from the start.


/js


Andy
=C2= =A0

--
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
--00000000000097c64405d23bd35c-- From nobody Fri Dec 3 05:37:59 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 D6DC23A0991; Fri, 3 Dec 2021 05:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, SPF_NONE=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 (2048-bit key) header.d=siemens.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 iHTwlv9cDXp5; Fri, 3 Dec 2021 05:37:50 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2061c.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::61c]) (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 8343D3A098F; Fri, 3 Dec 2021 05:37:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mk/Q2WEAvJVtXIHJN3qB8mKzVHWqMg8hDJv8IWED9RF7zjZdtsRGXtthQpGjRed0oe/2lDslP86g6mpdXRtGofVKjUW2iB1RDJZ5ZgN9H87k0wmCOpNYz9q3lLrpnoJznRSd5sTzz3oz3sIh5vOYzsLHg3DURdKN7xb97GBzn3/SsGcdeMz5R94dJgaWLCgV7lDsp7mw5yTmuETbpzefcEO2xx8WUVJ299DB/YoqihaAHNojKMZpxkgRw26uxqZC27+Ioc6vRE7qjb1yewPmP6eb2nXlrQNWOijM9O7ar7C1Yizgx5rL2y+clSa5NGuKzNe7DEPO/XzHqbzw5vEWKQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TdI8G7Zu979JO8MJqDEFcDF8Oufd4opi9T66JOylBBQ=; b=IPahdXheCyT97V43OCdv9ss0gMUF+xDKqzSKt0821V1XrK/NSnAoImdIlZWz5mBwqyvuYRB7xIOs3i1HDhTcruwlyJv3TdgDVecSaRFK7voWATHsX+qpi2PqvcCrBTthgLZwNFfn+1YFWC8cht86B8Wsn93X8VF+y6lsCJamBDZtTV9bMFNwy8i9KqHeKrHwLp+I5xJ5AKpVQtV7Ayfc0Zz0uuiVrQFF58sGoijxJMGRTu38xD4QeT4X/wf1Y37EZrhpPtRCUjE909Gb4hRBXB8ExvykmESj0CvAUy0iPz9jLz5qZ4B8nUrKmkJvAApRGcbaYQ1CieEA5AsEdpZBxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TdI8G7Zu979JO8MJqDEFcDF8Oufd4opi9T66JOylBBQ=; b=cOTSijzo+n4SPmvEvzW2jn3LQv14eQVxhVdsYx7ChsyGIHpkInGzr434drwtmZfGAcwGDzgEb0lvbsAO2K+Y/cuAZ/40yrqFPrCeelpV4BgO99rVfHdex0fax17Ezr5QgP32sIQs/QxXXj2gPC2mlXDW5V3GMY/jCpHhaPrB/LC/ajcmBdKODdfTNRdROs3tFtfslOfe3rKqbnED+fLmR627zmgvUwk2ZEGOO+I1DavJnqK5qxhI713VLlNNL8JNsac5PRJLop6kQWfKgtP3EhyWKqEI3vUwj9SRde0NUvBThynp4cnqOp1LDkBPvtHDD4JQL8ZKAebB8uPRFc3a2g== Received: from DU0PR10MB5196.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:348::20) by DU0PR10MB5310.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:34d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.24; Fri, 3 Dec 2021 13:37:45 +0000 Received: from DU0PR10MB5196.EURPRD10.PROD.OUTLOOK.COM ([fe80::188d:b1dc:19e:19eb]) by DU0PR10MB5196.EURPRD10.PROD.OUTLOOK.COM ([fe80::188d:b1dc:19e:19eb%6]) with mapi id 15.20.4734.024; Fri, 3 Dec 2021 13:37:45 +0000 From: "Fries, Steffen" To: Michael Richardson , "anima@ietf.org" CC: "netmod@ietf.org" Thread-Topic: [Anima] New Version Notification for draft-richardson-anima-rfc8366bis-04.txt Thread-Index: AQHX5xjRanH0QNQ1uEqRNfKY5Pf/rawgxh+A Date: Fri, 3 Dec 2021 13:37:45 +0000 Message-ID: References: <163839871300.12623.6948412300953244815@ietfa.amsl.com> <31289.1638407106@localhost> In-Reply-To: <31289.1638407106@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-12-03T13:37:43Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=41874b6b-1661-46b7-9e19-7cb96540e404; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ed93cb45-cb06-464d-40b6-08d9b66216ca x-ms-traffictypediagnostic: DU0PR10MB5310: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ygTkINswLMs3X4eOfIRtyIURIt0ncoUCr2n26SLeaNbwp/6nEER/HTb4XTbzSUOd6WsnOXsE+ZmgnAONvIdLTrgZnqOZ+fBt0iDe+OBZkO2bkbpbvowHOMJcNuk0C6MEN5p9aps6yvCoxtdL9Vc/maOhUDtAlb7nHib4yK9wAr/CPXIxnAMZ8LdRJriZo1imK96WaaCulIjnG43Dh/wQB6hXtoSFyVNEK4w69Mo5+M//eavggFRsHn6lU4M9cKHHcOrDvscnRyQ8bR7Qn0Z9tTe0ilQGYLc59kS6JhQBVt5n4SQ2ebedPykh4kGDtymnlb77M6WsuWvQkyxDIawdhRjmSsIk9yg2h73fteC5rFex/TeJbih/fcXFKgAlx84sgCQgvTITLi1m3+WLxmbRnX4QCnOFcPrCclIH8Cp9C/VSOM5wQpXnq8xdG61n/cLQ8P9te7iw0qTQ6HuhYmy15YXBKtN2CqSVZGTqV7yg/+DANjj+vQcss1EXWtEGKUu7wPFlYRphvBO2pGjD6bb9B6lx4ls9AhwN368q1f6JvmYQqegL6ByZgNwovxkzY3LmHowZde0Tob8w+SuDi1ubKhzERk3otsIT+HeED3ZHsxfB0M0Qj1IGjtJnTJSx/y6MklzT+2x3x4ZsmonqWgQr/GZpjfAiknvWDZjTpAJm6Y5VLYdXadiKMLme7iAMbMknHXdITgMGkYpxVzItORr7XUA4gTy5LxuUIZ8QJQU3t0qN626faCqe/RUEElAtl80f7IYnj3W2ujuZ8aVwfHpIZxYoObawwaidSYEqYWV/nXdMd88ohHlNuRKor9X+DZYdjlTCAwG/wWTiWUg//2bIvg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0PR10MB5196.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(45080400002)(33656002)(6506007)(82960400001)(38070700005)(8676002)(38100700002)(7696005)(110136005)(966005)(55016003)(122000001)(52536014)(15650500001)(26005)(71200400001)(83380400001)(2906002)(498600001)(76116006)(8936002)(53546011)(9686003)(66446008)(64756008)(186003)(66476007)(66946007)(66556008)(86362001)(4326008)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?HnvvF0Y0VqfbKTwS8sm4H5SuirD5UsvkbpR0ST09gapGQwGg0p+6T/zq8ZUh?= =?us-ascii?Q?4qk4/rLo62WH38RYlUKQDFZ3Ino+hwQ57XkrMqDoVCmNE2ftAXVMEs8eoedV?= =?us-ascii?Q?dNb5g8vFu24nvp1/Y36b2rDt1GOChDkhhdkN/NzoM8X7aHkvl7uFUtJiJOEj?= =?us-ascii?Q?Lx47Buapdqb3Ru/2zEy08EI6VtrUajBP9IxIxs0I+4KZotZYRnjLOnMyJbV0?= =?us-ascii?Q?vI0epcXgCNHMbeE+rQv4iXkI0qF7aFGQNuKgFhuEirxmSHRqvQek6vdjUnO+?= =?us-ascii?Q?3oQjOJQbQxNp4ybww8Lts9qIEf99RueKKsH6juVZtHRqyuJ1tDfVEAl0Bm6V?= =?us-ascii?Q?+Vkqx9Ymo/tE6RqnjganFTm6JRSLQ/a4Zs0AYs8PCS0x3rhXJFb7uLLAQJmv?= =?us-ascii?Q?MxGQFFcI6/zf1ctJYOcs1m2uW61AfgnWCTHrmX13cdI+vRHyx1czTbljfjDi?= =?us-ascii?Q?vWe0iChhASu+RPCd+vkq87XoRwSKxyeloqv16J4nTuR6SdoKyQ/i3WDHc43R?= =?us-ascii?Q?s3u55ngiDSPjhlOaFQOY7Ca4F+gEGjQrwjy9YdranccML9RUMsoVSHRYS7Tm?= =?us-ascii?Q?kOuGSnxt9u1Czu2TnN801xja6aHzWXcYo3ba9qE6ezdId3CeO6nR/5Vi/sNr?= =?us-ascii?Q?igVKUZYL5jHhfabtxQf5kLNFq3P2X4VSSiICasTyjZYE6+JuCXOyvTpMvXzP?= =?us-ascii?Q?7rSS0gmM61OO/wYhUs9ULRr4US/asjGdMxJimZxnunKL+t7+tLojkB7jBBBp?= =?us-ascii?Q?SaypO/q5HCBH2VQDxAIzcKXmHdyol9qgiKjEogNPwV0e7AUFOxIueHvN6xCx?= =?us-ascii?Q?TJWKFl0iPQTlSZMwpAiO/tZe4u5u3TXQ8hOLjg8Fry84glkTJPpMpZBElaFe?= =?us-ascii?Q?iucL2rO22PzMw73EfI+jnET5uOYh0y2/mXWH7AW7p3Y1UF8wE7S/2K9I4bjw?= =?us-ascii?Q?r+zlePTLMjUwa2JZr6aBZdSqyG7GGVJKgr8n1Dlvu4fxcW75uVsiowzbCy85?= =?us-ascii?Q?E3jD/cWROab0Xj1LQ/RwdEbrwqzXFrELz3wcE+C6ZK2IiolOcPkk9l6Ha3F6?= =?us-ascii?Q?YerNaLEUW7p1wSXeRSpQnHOj09h5CQnRJQ01gmCSEBi9nRE1VexrxHSDRUUH?= =?us-ascii?Q?WJ33gNg++vK0Xa0VNCA1iUdChaSPwNHA1ps0VBtZ+UMGnZrdvsBt11JbImsS?= =?us-ascii?Q?sMeaVkj+iLmohM226o/qkO8oBcNhFrHWVbZgxUC0PuSfhhF/EjnAi7cxr7Pu?= =?us-ascii?Q?nvjv5GMpkqBwCMN9CrxU5G1rps+8VtTpjHOd8/J5Kn/IhhX/RkNBirqjZEte?= =?us-ascii?Q?MCjoXAR0PwLwOsQ48e5el7NiEbX6EmiC7C8NdFn6tXqLgNzSdZcyd8hezRLb?= =?us-ascii?Q?GIvK3RqWAYU18JQnsaqA6bUbe6iv/bOvFJhZyteNTIjR/2WVRUFUDkz4HngA?= =?us-ascii?Q?U+nJDMJz6mS/sqWbPOVPtdauUW9Xg2eq+lIvMxY6G1fvqw5NpeK6PYllUWY5?= =?us-ascii?Q?ON62R6bwVetRb8x1XepgiIxozhpDHRx4OBBENvJyWe8OW0GG6taLrL8LLYBE?= =?us-ascii?Q?bClXRrfI+Yv5wx2YRoEDPaVK2tSB07TXJF6HpqZxxquAVa0qK1PW+ZHB6h9x?= =?us-ascii?Q?TkdT8qFI+77ITaHhug9hbcWA7DW522zd2LMeAahHjM3YPeYrfjm9A/N/JQLn?= =?us-ascii?Q?lYe6bw=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU0PR10MB5196.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: ed93cb45-cb06-464d-40b6-08d9b66216ca X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2021 13:37:45.4362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: duSDvR3yrocJN3KOxGnNztCrk3rkytB60ylxesrO80xmwksT4Aj4Zh/8P2wN99JPG6mU9IKZz71PqJzTrJEMakpxxgxju7s7z2qFo1lKfHo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR10MB5310 Archived-At: Subject: Re: [netmod] [Anima] New Version Notification for draft-richardson-anima-rfc8366bis-04.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: Fri, 03 Dec 2021 13:37:56 -0000 Hi Michael, Thank you for the update, I included the updated voucher also in BRSKI-PRM = (working version on github), which should address issue https://github.com/= anima-wg/anima-brski-prm/issues/4. Nevertheless, BRSKI-PRM currently does n= ot contain a YANG module for the voucher itself, only for the voucher-reque= st. To my understanding we do not need an augmentation for the voucher, as = agent-proximity is already included in draft RFC 8366bis. Did I miss something? Best regards Steffen > -----Original Message----- > From: Anima On Behalf Of Michael Richardson > Sent: Donnerstag, 2. Dezember 2021 02:05 > To: anima@ietf.org > Cc: netmod@ietf.org > Subject: Re: [Anima] New Version Notification for draft-richardson-anima- > rfc8366bis-04.txt >=20 >=20 > Name: draft-richardson-anima-rfc8366bis >=20 > Diff: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf > .org%2Frfcdiff%3Furl1%3Ddraft-richardson-anima-rfc8366bis- > 00%26url2%3Ddraft-richardson-anima-rfc8366bis- > 04&data=3D04%7C01%7Csteffen.fries%40siemens.com%7Ce31fb7323d1949 > a349e208d9b52fd8f7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C > 637740039811249891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dy9 > fmZnQrHPXMIwGCM8uZaV4x5Yg2kdy2LoUjUqxIelY%3D&reserved=3D0 >=20 > I uploaded -01, found some yang errors... I did -02/-03 before I figured = out how > to run the right pyang command myself to determine the source of the erro= r. >=20 > This version has a new iana-voucher-assertion-type which is intended to b= e > handed to IANA to maintain. > I don't think that our IANA Considerations are correct as yet. > I think that we need a FAQ somewhere. >=20 > In the meantime, I would really like some YANG Doctor help here. >=20 > Toerless: I think that this is the major change. >=20 > Qiufang Ma did the bulk of the YANG work here, and with the blessing of t= he WG > chairs, I'd like to add her as a co-author. From nobody Fri Dec 3 16:02: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 B3EA23A0BEF; Fri, 3 Dec 2021 16:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=sandelman.ca 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 87Ga24JWVMV8; Fri, 3 Dec 2021 16:01:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6179C3A0120; Fri, 3 Dec 2021 16:01:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0DB6638AAB; Fri, 3 Dec 2021 19:05:19 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vJyycm5MSoXF; Fri, 3 Dec 2021 19:05:16 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4F55138AAA; Fri, 3 Dec 2021 19:05:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1638576316; bh=ECI6BOYd/NniQQyYhehWFViahnBrZUCnOj9Hf7ABJCU=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=qVXge+fuJvQ9kALl7mHjTolCh3dIK8RwpsAxp1vuZqG/QwJqeOp0ppcJNzsiFXJuH +ZPGUAR6rgjdpwHWC4DU2Ptpmwu4JR9UsGu0f5CP/tbQwb48dhkYgB1F+M5Cnqq8LM 4oYxnUDetM2AabHy5FWhF/u29q1tmoQ9Sc33jiQa0lkeF23wgNLHmVyLKg6TbZUaAE Xjw0wFwkkv996+7l9rXziVg8WYAdPdSXToH7tvxJ7H4hMDbVSIuLjHCFCykvBghKBI tuqq62WvgxvtRrC/byrP2JmeTAbTyj5X+ODBWSfuG/19wd3Dw/DUXd6R7lkyPvQip/ 8ue/nhsb6FzPA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4AD4F7EA; Fri, 3 Dec 2021 19:01:49 -0500 (EST) From: Michael Richardson To: "Fries\, Steffen" cc: "anima\@ietf.org" , "netmod\@ietf.org" In-Reply-To: References: <163839871300.12623.6948412300953244815@ietfa.amsl.com> <31289.1638407106@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] [Anima] New Version Notification for draft-richardson-anima-rfc8366bis-04.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: Sat, 04 Dec 2021 00:02:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fries, Steffen wrote: > Thank you for the update, I included the updated voucher also in > BRSKI-PRM (working version on github), which should address issue > https://github.com/anima-wg/anima-brski-prm/issues/4. Nevertheless, > BRSKI-PRM currently does not contain a YANG module for the voucher > itself, only for the voucher-request. To my understanding we do not > need an augmentation for the voucher, as agent-proximity is already > included in draft RFC 8366bis. I think that is correct. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmGqr+0ACgkQgItw+93Q 3WWnEgf+MiQsxubAf1Z39/jkLHcb63r4CLEYgHCNOjACKHjihiytuXZAO5b+XAKd FuG4xkFvC49V0VNqF5Zt6wH7vnMDKbzlL7XKBbPJXR09JRiZHsA23dZgnWVzlaBD SfF7vkbVGFx9Xrx5YGWMsGXROQGwLyPB3n6LgYPgOAKoYfABt0Gf/kg45OVTnoRs 4PLzcnjHWOCLOVt+7kR4geaQ5EbNhqytuVPWRG47QfNGNqx31zWVDuSaDhezICsB uyEGoIwKHpnsotXOFQn487in6csqneaDCOymMokyZVD5FXp/xX3JIpe5hP5Zs+/9 pFovj07NaJ8yKOT7f1chEP8cJwvF2w== =lBz0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 8 01:50: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 2C41F3A0CBF for ; Wed, 8 Dec 2021 01:50:48 -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, SPF_PASS=-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 2MbS8HI3Qy3w for ; Wed, 8 Dec 2021 01:50:46 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2072f.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::72f]) (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 3A6963A0CB0 for ; Wed, 8 Dec 2021 01:50:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+TmkcwwY775OyAo74BUkeEpleQKQC+3j6Dns+ESdL1ycG2YvIcIKuHr2oG/SyQzvKgMYv1Tb5SIIazoYLDzOGmtS4X8swL84yCdMBgk9VHatWvPM6T7jjhmOUWViGXOyAAxraD0ULFIV2RoK9Ie5f0tQ7qmh//6smS+U8O/S8u3QwGfs6plH1HMosG8f53QgKHO5wpx+k/2Hn6DNy/S4/nCCUaiI1NzCgsOooLKJO2QRnisbpWiRQV930YPY7g8Bk5l/liYADvRuNphTO1HYqpoi+NInZoIHO31+Qxw0YG/vqcW4hfKKqMsEfX/osfhKXMrGIW67Sek5C1QO8v7lA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=buHlOgKvlTYn25Ft77bWyvSGw+yK2FsKiTdehd+Qtow=; b=cPtmcEpN58ZN5yTVpp5OfFLV43yc5EbMdFdmlLGvt1DnEUznQ8I/buHv+Msd4mShktymncjEtTe/9uqf67ezrBWx0Hln6Nxq5IR6HXornmHji+BvabQ8MeIjeQaCNwVq4iSI0QQU3Mg48qHG56FKfcnGZGIgw5+6iZ2hOVTpdiOYF8YL/yn8uCw4uBnNuD6rDXBYb2lbHhs/r9z5mLU/igj2OvxJTQVBC/QwkrikvGuw3vJGu0bQeUZxU3Dqj/TEWLQ/r1dB9stJQXshdeXiR+0TtXZVqMefGyLR08zk6CmIo6Vz6pBiX+SJYdpnDBzHp/aMnCbY/VE10axTMxba1A== 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=buHlOgKvlTYn25Ft77bWyvSGw+yK2FsKiTdehd+Qtow=; b=h+7in1tzBiaXLnSTb3jjPryvRhNOlAA+0obkxUQ/kQEL6ATlqnzXateF6qK4JrL1EXrm8fla4YcawMamOmQviF3q3uova3261N8F96A72nueUDoiDo0OUHm3o37hBx8ZFFc6PCTYYriWJLwxI36pfC8vCsT0S7yWV6/Kn8noVhA= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM5PR0701MB2370.eurprd07.prod.outlook.com (2603:10a6:203:11::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.12; Wed, 8 Dec 2021 09:50:37 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::89f3:ef4c:9336:3848]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::89f3:ef4c:9336:3848%3]) with mapi id 15.20.4778.012; Wed, 8 Dec 2021 09:50:37 +0000 From: tom petch To: "netmod@ietf.org" Thread-Topic: RFC7950 s.11 and 9127-bis Thread-Index: AQHX7BauAzogsNTzwEWqsryCq6/74A== Date: Wed, 8 Dec 2021 09:50:37 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: cde8e29b-6fff-db7c-3172-2678ee471054 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 47f22529-9446-4252-adad-08d9ba303026 x-ms-traffictypediagnostic: AM5PR0701MB2370:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QcjtxqMzv3qqqhecrGOJEUB8c6nBqM1KkjJk9ZFJ2ECAOHhRfisVcQM6IsU7KjlCtXXxp4IIuBcjCN6x5pYi1n0z2rAqnqugpekUSK2sSF5MXABASKXZHB31SxMjhmMJoOnSy3zVmVyLyETJooCOqyJ3LLGOUMg3Qwys54Zp7yjmg2BIo7IF3gfV8m6AeICV5/I/stOku0gNBc/yHJw3dPrQXtmrxYo1wHBZzHg7mRpXTQpbtDwp95FOTsjxQIGBMSe6eeX/ow1nyDVwJImBFFBpqSwWvESJetw/9ukCSohxsiLRZp8Q9JmE+1K9qiYAof4swhQdJ5jVa1AvMBudwAwmMaJwBSCIbJzECSmpFzMsV6sKDasWmJb+bG5vQtaPEWOMYYQLBhklLlbAUYvhnQ6NEXywU2aWA4sNcUJ4N/dhpMyHu++FUqE1bAlV1AIawjJ5tP5OvogF4ENkuxb9LwIHc2aTM6AOJq4C7UrUVFE3Rb4g4BZHiFlHk/UZQOxbky0jFrsmDRG7ZnsTWMM15DnkWB3rc8+D+wj/TNlqyOa+dkl2UnF7/nwywGiSBgA/WCCZ4CvNZXyqhAwdLqZaw8BOtRHuV6B4ONh6A6P65V/I3LH6EZajR1Fvh2tsMTu5Pxa+ouHkE8MmG06XTL0btLb0Dc22K/Q1XGv9ZizCKeeWD9IlyMvUJzveUm9R8MdtMBv4NgHcw53UY2Aju8xaMDgIAZc5SQ5jzVKZYEqI9luPrPMrZhav3fZ7IYgLdcTG 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:(4636009)(366004)(9686003)(8676002)(508600001)(71200400001)(2906002)(76116006)(5660300002)(8936002)(316002)(33656002)(38100700002)(66446008)(66476007)(66556008)(64756008)(91956017)(66946007)(6916009)(122000001)(4744005)(52536014)(86362001)(7696005)(38070700005)(6506007)(26005)(186003)(55016003)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?YD2e40lFR/qyHemxlP/YH5nnffOVcqxgLs8phXTb2oNZ5edwMBK0tpQo0X?= =?iso-8859-1?Q?DJNmS7KqLgxp6t+pGbLtql3GOEUFoZvlca0AVo6GDyQgfRaNIN31F+0iRK?= =?iso-8859-1?Q?a7R6R+hMRTBRZB79TDyvjuYcvbF8AdJU7f+KmzK/+icMD3HG6FKAHJpJ6t?= =?iso-8859-1?Q?yHRs3A7KZjDJqqk3aLdnRbTbNDtMbYueI1MoM/ENAmOAJq4vAwolzz8Sja?= =?iso-8859-1?Q?1mGVbsZCQnqSyxGcIlzpJlkgqlXoiCHt4V5LFY4ajnYC9OArPTidF+N7Rt?= =?iso-8859-1?Q?P6mA4BAm6wStrdNmWZIgqVPFx8yHt3ayc2qamTdTiCdwotb8S0GAi3W+Ox?= =?iso-8859-1?Q?mokFtIQs1k/0W/Ixds8RlCHz5BAHr0WkKYZZd3+8FrZ2F0zNZKvY7CHW9H?= =?iso-8859-1?Q?sJajVfsVgjA6OwjtaYFibk8+X75Vzf/XuvFBemu4x8jIm1sbxK5t+ElCdJ?= =?iso-8859-1?Q?itMxIQ6b9yR3dvybWZGOL8ntPlyT59yx4vg9moeE4kct+1vkew6fAHQHf8?= =?iso-8859-1?Q?CIZd6F21mQwyYicOkf8CwIu9mz8WndQhKEJYH0B48UXwHHTx/RlZT8XHUX?= =?iso-8859-1?Q?MtkZ6uEiEsyZMAOQNFqSmtkZgFLD3BTfDuAOLLL1e9yY9lXBHjYH3yJvOo?= =?iso-8859-1?Q?boDP7LYJoCsFMNXltkZedUv95LGa7w3Evk4+gyT6mLo/fG9wc4wxI4ugNL?= =?iso-8859-1?Q?1APBWFYonmaTA0EXmEQNceA2o6Vp5iu/g5iFKKllRZigIBsC+U8uuNg1pp?= =?iso-8859-1?Q?KkEgl2COqbc5yFumbo3/dwK5HIuMpLUAd257D+NREsAEpq2SCGuSYBeC6M?= =?iso-8859-1?Q?lncldmf0aB/2vxVt7FliGSSsbtwNcuILcRZn/FrnQ1I845zzFdPqvVy8ZQ?= =?iso-8859-1?Q?9u5CaBbES1dZm24sawgtkZ8S5BBHf/XMm6u1nbOLpPgxc0d2H/+3qUcptW?= =?iso-8859-1?Q?5XunGQYARKacUm6t8q9+gP/laTnF9vljbYxclrXes0b2rX9pu5qOZeM6Cs?= =?iso-8859-1?Q?IeXI0PC46fJJ1jaFTzmEeypIm1Hr86YLJ1HtLNt5D67kMJq2Xfed9AKYc/?= =?iso-8859-1?Q?ebC24JwMnhwzQ0WFeKEb3+CPMwUgB7SorG8+WoH20Ne6tzN27gZXK1ZKOq?= =?iso-8859-1?Q?4MnYdRnvGeAmMzZSLLFNyLc9Dr4ypxYWlQxU0EP/hJyq+paOE1AoMuCJNP?= =?iso-8859-1?Q?yId92jnLK+Ukj4l5v1Kje2I09nprZ7igICWvebdbFY5T2z9HSZPa2ouLmf?= =?iso-8859-1?Q?L1FgEjpAmpk+oMZElbspHT07s/CDMVGni7HL+3JgR71Y5kVLVg15mopOBm?= =?iso-8859-1?Q?8MEtA96XF4YnaGFok4xiipVbDeP9qXIE2w2hDSXWfZfzewSFl+vQo2y1gE?= =?iso-8859-1?Q?qYmm8wV42p/pBJDP8UoTLu2OfrBVOpBJibEJJtzcCkmqOxtAP2xCObClOB?= =?iso-8859-1?Q?ugtl+w6PqUCGMey+1gnN/dYt9UvqtSs23tIFA6IDf9ENdzHTKkSVA32Yoj?= =?iso-8859-1?Q?PgTEWKT1Wou4rI0LF9beW1BnZxVoFCp3zm2f1fnKCVTcBYDrjBesHFxRgU?= =?iso-8859-1?Q?TOwoz6Txa/NHCYp8otZRKtaNXJslLEWCOQuCepQCnx1LGnMVnOBTXSB+q0?= =?iso-8859-1?Q?NS4numy/hLgJ7pjtLjj2GoXRYiNRwXsXqRAspvCxkNOEjj27OHAQpmkA?= =?iso-8859-1?Q?=3D=3D?= 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: 47f22529-9446-4252-adad-08d9ba303026 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2021 09:50:37.8048 (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: 89cxsSePc1FfxvTtaD35K3YGRatnYhotqqIMp1sXxy/CmmALL97Fsx9E8L/klO14TA3e9py27lGMt/dddUtaSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2370 Archived-At: Subject: [netmod] RFC7950 s.11 and 9127-bis 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, 08 Dec 2021 09:50:48 -0000 The BFD WG are revising RFC9127 to add a new feature =0A= if-feature "client-base-cfg-parms";=0A= and make =0A= uses base-cfg-parms {=0A= conditional thereon in module ietf-bfd-types. Reading and re-reading RFC79= 50, especially about mandatory and top-level, I am not convinced that this = is legal. The module bfd-types is imported by a number of other modules su= ch as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be made ma= ndatory by its usage in another module. I raised this on the BFD list and = the WG Chair tells me that this is a violation of the intent of the RFC, 79= 50, but that it has been reviewed by YANG doctors and is probably the best = fix.=0A= =0A= If YANG Doctors collectively say that this violation is ok, then I think th= at such a statement needs to appear on the Netmod WG list.=0A= =0A= I think that there are a lot of other editorial changes needed to 9127-bis = to make it legal but they can come later. The I-D is in WG Last Call endin= g 20Dec2021=0A= =0A= Tom Petch= From nobody Wed Dec 8 04:38: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 03B643A0781 for ; Wed, 8 Dec 2021 04:38:36 -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 hayJbywRrD_O for ; Wed, 8 Dec 2021 04:38:32 -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 CD5033A078D for ; Wed, 8 Dec 2021 04:38:30 -0800 (PST) Received: from localhost (unknown [IPv6:2a01:5e0:29:ffff:fc73:fa64:57e6:2115]) by mail.nic.cz (Postfix) with ESMTPSA id C6C2D140813; Wed, 8 Dec 2021 13:38:26 +0100 (CET) From: Ladislav Lhotka To: tom petch , "netmod@ietf.org" In-Reply-To: References: Mail-Followup-To: tom petch , "netmod@ietf.org" Date: Wed, 08 Dec 2021 13:38:26 +0100 Message-ID: <87a6hb6zlp.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.102.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] RFC7950 s.11 and 9127-bis 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, 08 Dec 2021 12:38:36 -0000 tom petch writes: > The BFD WG are revising RFC9127 to add a new feature if-feature > "client-base-cfg-parms"; and make uses base-cfg-parms { conditional > thereon in module ietf-bfd-types. Reading and re-reading RFC7950, > especially about mandatory and top-level, I am not convinced that > this is legal. Sorry, I don't get the problem - nothing in the "base-cfg-parms" grouping is mandatory. Why do you think this might be illegal? Lada > The module bfd-types is imported by a number of other modules such > as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be > made mandatory by its usage in another module. I raised this on the > BFD list and the WG Chair tells me that this is a violation of the > intent of the RFC, 7950, but that it has been reviewed by YANG > doctors and is probably the best fix. > > If YANG Doctors collectively say that this violation is ok, then I think that such a statement needs to appear on the Netmod WG list. > > I think that there are a lot of other editorial changes needed to 9127-bis to make it legal but they can come later. The I-D is in WG Last Call ending 20Dec2021 > > Tom Petch > _______________________________________________ > 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 Dec 8 09:27: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 297553A07D1 for ; Wed, 8 Dec 2021 09:27:48 -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 nqJ3jOX7CUso for ; Wed, 8 Dec 2021 09:27:43 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2129.outbound.protection.outlook.com [40.107.21.129]) (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 DC03B3A07D0 for ; Wed, 8 Dec 2021 09:27:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KuTXBgLAvN9vJXKwJHo2TyBAAeHRDVxEjc8vV2+KdEtJqME5q0Id4HsNAzhDi5Q1XxgCNj/aiUuHI5uC7daIafwW+RePUizU8UnFFzfQpGoosfEbnFr51Zvg8RlqgApRTDfhhtC/JsLj2H0fAzXfj8hOsGoQBj+hSeowybm4Paxgh7R4GJdu6/rhbmPYyKdvwoHSjhU8dmHhyhqRG9QBqPGBJN/qZPDE3oskWVH8WkZGggvjH8sa8p22hMThXFcEdDFh0KaaaZ/lxp8vUTm1wzG5hYOjTfs7o7CrwRweIL0L8KSOjB1RYYWZv5L0pBJfUVpgv2yLUGeJ7bR5SRfUOQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IUo+EXWSsndAX9tKDWHa2a8sCopjjJd3UdzesTyU5Rk=; b=N3UcJbpKLfl2ImmDcdcPGpSPviGYf2AuYQDcdRDtzSz8qxX7wyXqsfMVCcMfMM81SMLlTwsyXpJHyg8pyl/pSRWZuIRIh8M1RKvX11ylfblMj5+GAXbsRgmn0h7lDdwkXNLj4wGhqBkoRCNQHqzQxcTAqCr+3bmErnMvrG48/mnGnYM3vHMsupizPNKPD/Ef3hHz3JztHB9DxV8uUILbvOnWx9bkX7oqNhWujgANaeiGKGUvjKMA2TgzQ+j2ETIi9kqOl9JhaxqyK2mZxQqcu4KBAZCX1TMz0Jby/TWlSlZ4V9+BnJUwiOC1TmUuX3+f/aKrQ7ehT7eAzLVGw821oQ== 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=IUo+EXWSsndAX9tKDWHa2a8sCopjjJd3UdzesTyU5Rk=; b=J16Z8a5QG0zpjNz1ygrIkwXDCv8485sReqDCZutHQlO1UBYaBkkXLl7nwUXqflybeY2t2ga1cNcgO7XeqVz9G77rKAgSo8UK/M9Y3M0rAJVJ3/gGsONj5ZOkvWQBcazRp9Vg6gF2arjqwD8cBR31PP6LEIwAR9bpjDT489kj3E4= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB6167.eurprd07.prod.outlook.com (2603:10a6:20b:65::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.7; Wed, 8 Dec 2021 17:27:39 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::89f3:ef4c:9336:3848]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::89f3:ef4c:9336:3848%3]) with mapi id 15.20.4778.012; Wed, 8 Dec 2021 17:27:39 +0000 From: tom petch To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] RFC7950 s.11 and 9127-bis Thread-Index: AQHX7BauAzogsNTzwEWqsryCq6/74KwoiNAAgABPsCY= Date: Wed, 8 Dec 2021 17:27:39 +0000 Message-ID: References: <87a6hb6zlp.fsf@nic.cz> In-Reply-To: <87a6hb6zlp.fsf@nic.cz> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 38c435cb-25ae-4af3-1567-e7ebd5591cb2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 690a36e8-4370-4be2-27dd-08d9ba7008cd x-ms-traffictypediagnostic: AM6PR07MB6167:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aAHJwUEojMt+TxKtIYej9fIkzDv5VoDbwsZnV78ox9lmLHxog2vBOwAaRgnlmakYX18lYDjyeexKwaCdNa6ZQZBhV4G12lz5dMHwnuFLWG5SbWMyGXIB9BQhYOgsovl14tYUYlw0oZiP/GhG8/dMXAeKbH7fWJg0+FacG9uMgmk8e9S3yc+KVfsKCES4FHl7bFdNpSf0KGuVWFKs/vvQAhxRx5thqOqpx2TSMX2EPKfN5BRmQoI2ndRBzcPzEpzbS9W6SLxgJgN+RXG35HazNYr0aL1KqUXD9V1whbV90BxJDiG0Miv9eciirPHJ/HwHCdCOXDIycnVwCIEO0wxDQye6hmesyIXq6sbbl+2HKJcZIGgZmHRLzhzGUo++zsg1XoPZGm4yCGPzgcLuGD+vpNn1tS60vc5wzbq51aib8ZNy6HvFb7pxveccWi/A5jpaw6AIp6VtLYv/E9dN/vJlTBPOn1P4Uq57I++RKFHsxKgaaMsYRBSN8xPqIEWYT3JEmRBAjIv9bu7sh3bV5bzIqYuDDMVIndt0m2tERj4UU1sTin3/L/N0s6iZETFwIgOA178TBpzsXu6CIJOHKFTP3j4zLEicjtlbn+ZOlWfg6ZoCzzRYnJgH3oMbSq6OVSpiREID1Kx0AI7QQK8oO16gvUfY3HGI4IQVA+0NsbF/M3Qg8jOSOTvV05PHfX+iU+odIr3PNN5I2pgDvYgde+cS4R8r8+9jC3dySgRFmCfKIXKfBRecVc/DS+vVDO4qm9N4Gre0O9wElDRYSNd+yI+vmJpvmAMH1B2oQEA9cPQoE+c= 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:(4636009)(366004)(316002)(508600001)(8936002)(110136005)(66946007)(76116006)(66476007)(9686003)(91956017)(66556008)(64756008)(66446008)(2906002)(5660300002)(52536014)(71200400001)(38070700005)(8676002)(26005)(966005)(7696005)(186003)(82960400001)(33656002)(6506007)(38100700002)(86362001)(122000001)(55016003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?AtBLSFhbBNXFgur++MsXuk3oo0sA+9gs+7yqRfd+PJrj39Ra6jLHx4eKli?= =?iso-8859-1?Q?hv1SVYri7J60zGWsbv3X89S+LLA3iC/e0UZF8iWjgQTdxc0v8UZlzLO5Se?= =?iso-8859-1?Q?98ApTapcsJ9mB8IPaIdpYr76lAPU9kyFuBzqyxVs9oJe6kPCXfb1Ub6ZGD?= =?iso-8859-1?Q?DDTrTJSr4VZbOlXMqZDBPZVIbELSDrP/qr+HWLOnbhHXlEF+tgBlluhw1G?= =?iso-8859-1?Q?brosCClDAg7JsKmeKq5nybxGs/YREOPS0n1IlojcJpbSFTm5Ukt/Loy7CL?= =?iso-8859-1?Q?xr+fk0JFlwy5o5uY9yQ8HLZJiX8sJmegEjSMBjq8GUNetkli/eaRpfiQ75?= =?iso-8859-1?Q?+VWarybK6jdReviDBtBAUAqMTdFU5IB7JK7eGLtP79kFLDVjy1sBq4+KLG?= =?iso-8859-1?Q?5YC30ghsZl6UK6ittEPpIGS+SnbrReZqfKdituklLbyxY74JyX0RACYlqd?= =?iso-8859-1?Q?Zhnr0Nwbn7PdNUJ3FIF4sgsN5ZqWeEjw/H+uBJHq9dpL4PF8LUxteyF11g?= =?iso-8859-1?Q?+fY9E0/W05Vkkgq1+ACwl26r9T6/9yglRWvM0+8iTPTyh3sHQANy4VWvGI?= =?iso-8859-1?Q?1RfQG3c8HFy0jBezY/J4zAtFFTC1EFQM1QQ8Gq9s4unAL4ZdB02WAuMlyN?= =?iso-8859-1?Q?z3aX44ABg4A0laa280A4FyO+hiMMPbZcNqWIdZOmGHwznqSM+Dy6VPNBiA?= =?iso-8859-1?Q?HFM2EH0ZuAsX2auvkGmSLv0Nxy89Bg+yKvTjeA/VZ2D6+TCqgfz7Wpdqe0?= =?iso-8859-1?Q?UbriWc7ObYgAkzj7Fuwo80VoOGDinpXiVvsJ6vXGROmPjTY3lZeGtwWdqH?= =?iso-8859-1?Q?VPtDSDRMu+Cy7Zt7grT7UckyDzY6E+zmjQxsnBM8BxjYC23iq0A9LreQCg?= =?iso-8859-1?Q?XBejewTwPyUNMZihRfMkagZ7/M5peIOuLN1WplhsN9GKRwi7RZTxcFCkdT?= =?iso-8859-1?Q?wM9Ur9lZxYsDE+odNAFWkZVr9hIGOgNh98zIQfljxfBKixRcitNFH2rZnZ?= =?iso-8859-1?Q?O3Q4E+zgK+eYPL0ElmLNtVnkxGiMYoLOPaUcW0Vw55efYpOlruv/cY1q4H?= =?iso-8859-1?Q?cKfpeeVVa1DA6XdLw+OmBYqoZ5rRNTSSK2iSBaLwl8eW0AGCOLQy8kAw3O?= =?iso-8859-1?Q?jY9GlltmItH/y8WefF9WAOU4YPjH/M6T+K45CYYDsqTn3ZBxdzn/0JunIg?= =?iso-8859-1?Q?YfKm9arPzHNg6eXuTesA1m2P75UmM+E9P3aWsZQdYjL9XkFj+vfmH/mPOs?= =?iso-8859-1?Q?k2OlJWE39SiF7E1D+512E/5cmLDXFDvFvZ1G9ggsL0BzKfo1R2n/Plaudg?= =?iso-8859-1?Q?E5o+ryVSHQ/Wg3jvCutOG8y9X5aYNDTStIGMi1WitUVoOHXCSkhxeq/tQ8?= =?iso-8859-1?Q?yZMg/WNy2Wg5FXs9oKjGljc+zS+zkaC0Ct32tLc9qw+evoZOD9Z6P418eN?= =?iso-8859-1?Q?zyplyzs9pTudLru0P4krRYNbh3BbxNpSCbh+1gTOaKSYXZWXjNSJKLbpDX?= =?iso-8859-1?Q?KvJBpfm50U7NpOMUHNR7jpJqHm7VZkoANMfSd/22MC00B+D8ddvJ1ub96n?= =?iso-8859-1?Q?Ia2/Gl8H2BytRs+kUWuFnnM6QorDnM0QxetY5q6XiBkaD+cvbZ1pcnq8q5?= =?iso-8859-1?Q?zBlifZdG43CDkrwrzuZRVdXAWlm3hA5rgeLHyPmZxgwKkCX0UhYJek6A?= =?iso-8859-1?Q?=3D=3D?= 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: 690a36e8-4370-4be2-27dd-08d9ba7008cd X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2021 17:27:39.4996 (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: iYlqV85YVvoB4aF8ji7vGnZ3DZqM+bj97LYfoWfZiVtoYRzzTaIChr0bOgD6E5a0pPGZT+L4NAhFxSpdSkEqNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6167 Archived-At: Subject: Re: [netmod] RFC7950 s.11 and 9127-bis 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, 08 Dec 2021 17:27:48 -0000 From: Ladislav Lhotka =0A= Sent: 08 December 2021 12:38=0A= =0A= tom petch writes:=0A= =0A= > The BFD WG are revising RFC9127 to add a new feature if-feature=0A= > "client-base-cfg-parms"; and make uses base-cfg-parms { conditional=0A= > thereon in module ietf-bfd-types. Reading and re-reading RFC7950,=0A= > especially about mandatory and top-level, I am not convinced that=0A= > this is legal.=0A= =0A= Sorry, I don't get the problem - nothing in the "base-cfg-parms" grouping i= s mandatory. Why do you think this might be illegal?=0A= =0A= =0A= Reading that section I find parts less than clear, especially about top lev= el and mandatory. Could a PIM eg module importing that grouping make it to= p level or mandatory even if it is not so in the BFD module?=0A= =0A= I realise that such as NACM can always make part of the tree invisible so s= oftware has to be prepared for something to be missing but I am not confide= nt of my interpretation.=0A= =0A= Tom Petch=0A= Lada=0A= =0A= > The module bfd-types is imported by a number of other modules such=0A= > as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be=0A= > made mandatory by its usage in another module. I raised this on the=0A= > BFD list and the WG Chair tells me that this is a violation of the=0A= > intent of the RFC, 7950, but that it has been reviewed by YANG=0A= > doctors and is probably the best fix.=0A= >=0A= > If YANG Doctors collectively say that this violation is ok, then I think = that such a statement needs to appear on the Netmod WG list.=0A= >=0A= > I think that there are a lot of other editorial changes needed to 9127-bi= s to make it legal but they can come later. The I-D is in WG Last Call end= ing 20Dec2021=0A= >=0A= > Tom Petch=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= From nobody Wed Dec 8 09:58: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 414E23A088A for ; Wed, 8 Dec 2021 09:58:29 -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.20210112.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 rc689pdJZtzf for ; Wed, 8 Dec 2021 09:58:24 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 AB8683A089C for ; Wed, 8 Dec 2021 09:58:24 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id u17so5503030wrt.3 for ; Wed, 08 Dec 2021 09:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sxYcWbKST0EdmwyBma0tRokG7UcMlTVDaHkCN9w+oaQ=; b=OJNSgXUWLTX19qM6sxmXXCNVtSufdDkRPhGMkRuGx99wOCzkBHvipHUY1w75V39R6R HACsfH+56R61/h9/nUaZ3lf8PMMiRu2Mhv0Hl1dmT/e+eg4DxbhMsFcB07oy5MX5VJ8h CxduT/guhafggR44ts8Uvf2riUOxZM20JqAu5aGhZ9T4o+dsgxNbYtzfHpXpoUurnnxK oy89R/fqGYHL0MNyi8tmHN7zCFxf2Q5VlOBvwtiFCuCAWXdFWuTwQd/ziZVO5s2CGSnW qE8NFGRIDZsn5wz5/WrOlALc4qqSSmZXxuYJhQ07PHtI4NU/cODLKFSK2GkHsTvr0LXR 5EkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sxYcWbKST0EdmwyBma0tRokG7UcMlTVDaHkCN9w+oaQ=; b=CxpnU7EpFlUK8QQDaeWvh771MgM55KdV42wzuhLW/jbnIjFjr7bO7/Sw/PIOW/NVZW vXbJKvUAyRYieyhsw/pXWuFyeQAm1FqDpIQI9P7oYy2clwhvEK5hUxTnLw5dlz/h5C0u UvV1EcJP5kiTaVWFI+DHAzSJIUiVGBrNQ05QmYxs2YMAIWJnNY2JrZurG8fyhGkul1IO qV0D44XKjhxV7h9UxboUIDOFfxcgo74/+p71OGWNi84FTw83IZjPq17oJU3lhlOMbzfP 3TCQlgRsDp67rtoJvpwev4Gay9dFLB4FkbrVqT/CryMoSOQ2o/pKJKItN+K89idnbDNk H67A== X-Gm-Message-State: AOAM533wahnXfxOmmNcO6s8yrCmD5k8e+aX1iHLxC9cRzSOxemlC4igJ 7nUqhwTyNhvDQdsM9R1IyshfLGvbagLuhMHRHMCwMQ== X-Google-Smtp-Source: ABdhPJyAxSk702S1x7sLIEgQCMrbvUb8OzY/fKpLm5ElsWM8gK/RCyzQPpYodkLTq0c9jcPE4Dcz2M+KbqsuCNIxMKc= X-Received: by 2002:adf:e8c9:: with SMTP id k9mr174795wrn.603.1638986301949; Wed, 08 Dec 2021 09:58:21 -0800 (PST) MIME-Version: 1.0 References: <87a6hb6zlp.fsf@nic.cz> In-Reply-To: From: Andy Bierman Date: Wed, 8 Dec 2021 09:58:11 -0800 Message-ID: To: tom petch Cc: Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000051dfe505d2a63ccd" Archived-At: Subject: Re: [netmod] RFC7950 s.11 and 9127-bis 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, 08 Dec 2021 17:58:29 -0000 --00000000000051dfe505d2a63ccd Content-Type: text/plain; charset="UTF-8" On Wed, Dec 8, 2021 at 9:27 AM tom petch wrote: > From: Ladislav Lhotka > Sent: 08 December 2021 12:38 > > tom petch writes: > > > The BFD WG are revising RFC9127 to add a new feature if-feature > > "client-base-cfg-parms"; and make uses base-cfg-parms { conditional > > thereon in module ietf-bfd-types. Reading and re-reading RFC7950, > > especially about mandatory and top-level, I am not convinced that > > this is legal. > > Sorry, I don't get the problem - nothing in the "base-cfg-parms" grouping > is mandatory. Why do you think this might be illegal? > > > Reading that section I find parts less than clear, especially about top > level and mandatory. Could a PIM eg module importing that grouping make it > top level or mandatory even if it is not so in the BFD module? > > Yes. The refine-stmt can add or change a mandatory-stmt. https://datatracker.ietf.org/doc/html/rfc7950#section-7.13.2 This only affects the specific "uses" of the grouping, never the grouping itself. Andy I realise that such as NACM can always make part of the tree invisible so > software has to be prepared for something to be missing but I am not > confident of my interpretation. > > Tom Petch > Lada > > > The module bfd-types is imported by a number of other modules such > > as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be > > made mandatory by its usage in another module. I raised this on the > > BFD list and the WG Chair tells me that this is a violation of the > > intent of the RFC, 7950, but that it has been reviewed by YANG > > doctors and is probably the best fix. > > > > If YANG Doctors collectively say that this violation is ok, then I think > that such a statement needs to appear on the Netmod WG list. > > > > I think that there are a lot of other editorial changes needed to > 9127-bis to make it legal but they can come later. The I-D is in WG Last > Call ending 20Dec2021 > > > > Tom Petch > > _______________________________________________ > > 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 > --00000000000051dfe505d2a63ccd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 8, 2021 at 9:27 AM tom pe= tch <ietfc@btconnect.com> = wrote:
From: Lad= islav Lhotka <ladislav.lhotka@nic.cz>
Sent: 08 December 2021 12:38

tom petch <ietf= c@btconnect.com> writes:

> The BFD WG are revising RFC9127 to add a new feature if-feature
> "client-base-cfg-parms"; and make uses base-cfg-parms { cond= itional
> thereon in module ietf-bfd-types.=C2=A0 Reading and re-reading RFC7950= ,
> especially about mandatory and top-level, I am not convinced that
> this is legal.

Sorry, I don't get the problem - nothing in the "base-cfg-parms&qu= ot; grouping is mandatory. Why do you think this might be illegal?

<tp>
Reading that section I find parts less than clear, especially about top lev= el and mandatory.=C2=A0 Could a PIM eg module importing that grouping make = it top level or mandatory even if it is not so in the BFD module?



Yes. The refine-stmt ca= n add or change a mandatory-stmt.

This only af= fects the specific "uses" of the grouping, never the grouping its= elf.

Andy


=
I realise that such as NACM can always make part of the tree invisible so s= oftware has to be prepared for something to be missing but I am not confide= nt of my interpretation.

Tom Petch
Lada

> The module bfd-types is imported by a number of other modules such
> as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be
> made mandatory by its usage in another module.=C2=A0 I raised this on = the
> BFD list and the WG Chair tells me that this is a violation of the
> intent of the RFC, 7950, but that it has been reviewed by YANG
> doctors and is probably the best fix.
>
> If YANG Doctors collectively say that this violation is ok, then I thi= nk that such a statement needs to appear on the Netmod WG list.
>
> I think that there are a lot of other editorial changes needed to 9127= -bis to make it legal but they can come later.=C2=A0 The I-D is in WG Last = Call ending 20Dec2021
>
> Tom Petch
> _______________________________________________
> 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
--00000000000051dfe505d2a63ccd-- From nobody Wed Dec 8 14:31: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 957AC3A079A for ; Wed, 8 Dec 2021 14:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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=unavailable 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 i63_MQx8xTsP for ; Wed, 8 Dec 2021 14:31:34 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2111.outbound.protection.outlook.com [40.107.244.111]) (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 2BB823A0791 for ; Wed, 8 Dec 2021 14:31:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UAU8wyRtybjo37VGnF8naqZWIR+gLCN2jR4+S354x7DPoCujcQLy72450zhuRQoM9NY+FVHzpNCr3oCirHmW5NEqcLNnwB4s8jNFmV6na2qumk599aPB0cF3ThGorCq06wAsYl05m/mN5Cw6bzkvYNRCuPVT7VJ+c1nqj1TW8zrwPdP5YL2yYl/6GLEp4neO64iGnNOZDH6eopLzpJ+VPnL6kn7S2FkhxS1sQqrkgCYuxV0HnU4rmW3v7XzG8uYF7dveLOsqSI9rVF8CM7kwmhu/YczflANUmQGKoLg/xSJGsVQhg4CnZ7b5+FlINeTeu8T+PbU/tzBFfXKIFBN7Uw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=w1BbwleFP7kRWXnsYmVC1EigqaUlI56vI4roT5AMYXg=; b=RrAxFG67z3Wwt4WTdtTzqTDbmWckiFTfgShFKv7fizUJS8FtFbiNb7XXSZPqUnmYeSh3me+iCEhHvUnY5RUfED57lZeJ4WWGBSEKtFdkehMHOH7/NHRhuL5ehAVvLdRxVYpVD4h5+VwFSXckveBlhEtO2gkvyWUZOOplZurPqxnWmZCg7kGqYV9eWzJiD+neGCWLOQsECHhHMw9z37SN4JssZZK1G4Av2SougRYrj++JpVR/bDDThykfeNs6nTc7fZA00pzXIVamKs9ftNVv3rHqXQlQlZQf5Ggpn18IcXQqpoDunVsD4H20DcWQEwbDnAe3eNKjDIbBeo7//ky28g== 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=w1BbwleFP7kRWXnsYmVC1EigqaUlI56vI4roT5AMYXg=; b=D7PtLf30uPH5RQ7lJvgciP4lah5iWkpnluf142T+9F0GQo6txJdkFKQ0LQhf3Z9hAJT8U4ph4NtHiUAQS5LsPZIdlN1CrPL4FD4GiLs3/luvJ2IBGs9Yy/Y6BocniU4wxQZRKEZmcqyIU+HV9rnJqiwS0KKQ0JE0VsUQYnIjcFo= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5963.namprd08.prod.outlook.com (2603:10b6:5:153::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.20; Wed, 8 Dec 2021 22:31:31 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.022; Wed, 8 Dec 2021 22:31:31 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Andy Bierman , Juergen Schoenwaelder , Jan Lindblad , Kent Watsen , "maqiufang (A)" , "netmod@ietf.org" Thread-Topic: [netmod] Must offline-validation of alone be valid? Thread-Index: AQHX6DUp5BZXcFhAE0+IivjOGbmtWawpL+ew Date: Wed, 8 Dec 2021 22:31:30 +0000 Message-ID: References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62ab9ab3-2edf-4e09-59ef-08d9ba9a7b97 x-ms-traffictypediagnostic: DM6PR08MB5963:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eKiTWdFXhC1xddpI/EQDq15vQrYfhSBHrYA4V8uIYSUSabBNlEckLNEiBMaoKO91qBTk6ahRn3VEvxp7yeaOFiQbQHt9Mmh5uFXPd8fw3pAEqZVWUJtkW1Cih6wuwF4B3sEyRBYBCqIA8jOFxlh//qEjHkQM5/h2ry4EmxJ3TUh3J17aaUdyFcr/sWqwEVp8jwK8+0ijU2qVr4iI1/RBDA2Cm6nYsUImIWdsGnnc6+NikhTXYfN14KdhDdLhDxCDk9JLYjZcD1fp4rWSasq9ROCZ6Oc5Hp6WUle+qq+7fXnn4PQTwU06eMhP97OxX9FW509CPPgL+WHt4onXGfw2AaRokXC6xcqiTV2pI9dQUNgqk5KXOA+9ldGexRo1nPe9SI7Ofi0ElFvtC6AElC6PbjxkI/lK84reClMQCL+6UvbDxUGAZVadjTDYOG4hWafkgs2DzY3w/CRnoZ+c3YDkdK0LpPVYqUXSl7Jm+AVfoY86+NJaukA9TCcolqXcZcev7EHb+mp2U150RLagRVvKLopl1SQDkwOycPedkhKw8gjBtFQR+GTUJELBuwaDbk6ccUNnl2UCQrtNAU09vPEQG08gS9wGDJPA+1qAEGPlIWCBeIQF5sdcCX7QSqLevI1wkPSbIQOmX7dq77N0MNPm2vt7fDJ/9qOOpdhXB/oYfQUUxCF4e8OMinJdP1SYHr01StvB04WE2GozDXD/aTVBQslBudHkxkD++AvvxSES7xq+8MJHeFcMeX+HRpNwySRoLfL+pjOe/PugZZpOaeSbVYupXnPaUAqlr2rU8WMJCI0= 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)(366004)(83380400001)(186003)(66946007)(110136005)(66446008)(86362001)(66574015)(64756008)(166002)(55016003)(52536014)(8676002)(76116006)(71200400001)(66556008)(66476007)(38100700002)(122000001)(966005)(8936002)(40140700001)(9686003)(38070700005)(5660300002)(316002)(33656002)(508600001)(82960400001)(26005)(7696005)(53546011)(2906002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZG5QMklJeGQvK3hwcFoxSEZRSlQyUkE4S1o5bTVBUElFRkFTMGhPV2hmWlNB?= =?utf-8?B?WlBWVG1jaUJjM2kxUU1tQ1lIOGgvcnNNUjdad0JQT2tFYjZ4bzJkNHFoV1Vn?= =?utf-8?B?QkxzczgrY0Vjb0c5WVFIb3hvb1JrSXl5T2luQ2ZSUWx5ZDBQcDFHcEJlUWZt?= =?utf-8?B?Smtya2orTlBIZjRjSEhlRjFPSkJlenMyOGF6NnlGMmJDN09SVnBwbjA4dDhj?= =?utf-8?B?OXYxeHIxbXF1dUIzNUxTL1lsVU9QY0srR2Zyb1g1TWNIcjh4cEIweW05cm1M?= =?utf-8?B?bjk5ck55T2Rpbi8zcDYya0RVU0duWFVucUx5bHpmdWdkVXRnMVUvc0tLMDRs?= =?utf-8?B?a3JtUTdqaUtrQjd3c1NXOEFXWDBGYjNXWlVaMXVxQ1RlQTQ5RmpXK3Z1eFBB?= =?utf-8?B?UGJEZlBKdUJHcC85Nllqc09EZ25vZXNZWXpyeEV5QnpoOG5JTFVMTUNINnJp?= =?utf-8?B?SGdnZmpEL3NmR1ZtZ2V2N2RrN2hOYVh4bHl0Qk9qRXV3Y2RjN2xVR0ZYVkY0?= =?utf-8?B?ZFUyNm83Nm1zeWtkbFF0YXNaQUdnVmdvQWdPWkxEUjFnKzZzSVdpSVVuZmRO?= =?utf-8?B?MnJRUWl3RTFEUlI0MXZsN056USszWW83R0d1RWcydndmY1Yxb0MyS2JpUmgx?= =?utf-8?B?WHVld1NPeWlqTEMzbEM4dXJSYXZJaWNKc2lNWlU1WVhMbW5FWSthZkNOTTF0?= =?utf-8?B?SHJaRDNsd3IyYitNOGtIaWRuSWpUVmR2eTlBanJqdmN3RENVUmZxeE0yOWNo?= =?utf-8?B?OEhMbWplTXNlWExNSWo4QUdBZEUzM1FGNG5JZk1IZGFYTTh5b01VcFA3U0Qr?= =?utf-8?B?VERzYUxlOEx5Zko0NE5EYUhjamZMZmJWOEFjRS9Ta2JuTlhLbi90b0YyWmpm?= =?utf-8?B?NXhManoxVjVKVllWOU9vSXZoZ1hFR1Z1NGJSTWxZbEI0NUtzek43VUpWSHlJ?= =?utf-8?B?anM3Zm9ucUxxNTV4UXFuN2lMUks0alNyQStIeXZnQllSZFFoSjVQdkFEVnJa?= =?utf-8?B?ZXlpcTJ4cGhQeFlCa25KZldCbXJxUWJxU3dLaXRGL201L0UxWHN5LzBXRjBY?= =?utf-8?B?YjZwQVZYQVVwYjd4SUtFYVFjeiswbk5wRmcwVlhXQXBvNlMvdUpTb2h6TGpw?= =?utf-8?B?ZTNxOXpDN0VoVjIzaGVXOU5lSVM4dmg5YlFQam4rbGR0MnpOWTNVUURlczNM?= =?utf-8?B?NWVmNXNpVUZ2c3RPYXgyb2REQjF6MDNIYW8rdFFkUEo1a3Y3QzhOMFIxWjBI?= =?utf-8?B?R0VZZkE4U2ZMck1nZHNhRjFjRlFBK3Y4V3FXTGRaM2NmKzVTeVYwNTFmWGRn?= =?utf-8?B?RDM3dDlKMkMzMVRRKzgwK3FwbDFGUm0raXZLWThjZksrZURmdXdoOXlnT3lq?= =?utf-8?B?TGNsTFJJc2xuY3ZMOHkxV3FMQ0tqZFJSN1FXMGRHVVlwZ1FEMHZrK0JhUGI4?= =?utf-8?B?UGROUm9SZ3VYM3k2cFMvdUluTFpETHRNM1BaUFRRY1ZQdEl5VnQxTW1VVmli?= =?utf-8?B?ZlpGNVJOcnBYdDJJVGxFTS9mZ2gzWFllK0JJbCs3VzNZTlR1bm9VbW5yanEw?= =?utf-8?B?NGdqakdFNmVXWXVCeENiVCtMdGJjOFpSLzd6cHhHMExIUk82RWNhLzdYSkRN?= =?utf-8?B?ckg3VXI5cmVrWnd0dCtOa2pibzdvdnh1YzJlQ1dwTDdIeklGRXl2UzFqeXpr?= =?utf-8?B?VHlCZk8rbzBobTJXY2Z4bmtSZVNrZ0lTQXJzVkI5cStXMTkwbXpzeERlKzJJ?= =?utf-8?B?aG1mbGxlYW1jUStVYzI3VlAxeXZHanN3QTZwYzk2ZklYRDVpOE9nNnpIa0VD?= =?utf-8?B?N2prc3Y1SmdjaVVGdGlaNDg0MFN0eHRaM1dPUSs3Mk9OZ2Z4V3BMU21yRkZU?= =?utf-8?B?RkFwKy9VaXBLV29QK1ZLaG52b2lZN1RZOWFMSElkSjVNOXQ3MFR0RHRKb0xW?= =?utf-8?B?Z3R2ZDh3WW80U292aWk0aVFWTCtacUlDTGU5U3JOdS9jSnNwbER1OHBXcThi?= =?utf-8?B?U3VWVkZpRERvK2xNajI5MnFBekRIRFpDVnNhU2YwWVhYbGVTS3Fia3R6Smc0?= =?utf-8?B?QnVLS2RvUHdjeElrY0dVSzhKVmdiQU85MUhDVmREc0xBcXlIRTczS3Y5Z0VM?= =?utf-8?B?OVhqTkRrVHJVZ20vZHN4eGNaZEF6aCtyajNBeFRhUDVpUVBjWWdGTVZoVmxa?= =?utf-8?B?YUE9PQ==?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB50844DB8F2F7D2D11A6CB0879B6F9DM6PR08MB5084namp_" 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: 62ab9ab3-2edf-4e09-59ef-08d9ba9a7b97 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2021 22:31:30.9543 (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: i3BxVxVOObmzcgIf1JT3li/K0X27gy387w3foWgSKkkjSkLtFIX2W/LsiQdWjKtkAx9bOMZmUFXNCvE6Sl4rww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5963 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 08 Dec 2021 22:31:43 -0000 --_000_DM6PR08MB50844DB8F2F7D2D11A6CB0879B6F9DM6PR08MB5084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZ3V5cywNCg0KQW5keSAtIGFib3V0IHVzZSBjYXNlcy4gIEhlcmUgaXMgYSBwcm9ibGVtIHdl J3JlIHRyeWluZyB0byBhZGRyZXNzOg0KDQpUaGVyZSBhcmUgYXQgbGVhc3Qgc2V2ZXJhbCBtYWpv ciByb3V0ZXIgaW1wbGVtZW50YXRpb25zIHRoYXQgaGF2ZSB0aGlzIGNvbmNlcHQgb2YgImhpZGRl biBjb25maWciIChpLmUuIGxpc3QgZW50cmllcyB0aGF0IGNhbiBiZSByZWZlcmVuY2VkIGluIGEg bGVhZnJlZiBieSBleHBsaWNpdCB1c2VyIGNvbmZpZywgYnV0IHRob3NlIGxpc3QgZW50cmllcyBh cmUgbm90IHJldHVybmVkIGluIGEgPGdldC1jb25maWc+KS4NCg0KVGhlIHNlcnZlciBhY2NlcHRz IHRoZXNlIGNvbmZpZ3VyYXRpb25zIChpLmUuIGEgdmFsaWRhdGUgb3IgY29tbWl0IHN1Y2NlZWRz KSwgYnV0IGlmIHlvdSBhY3R1YWxseSB2YWxpZGF0ZSAoZS5nLiB3aXRoIHlhbmdMaW50KSB0aGUg cnVubmluZyBkYXRhc3RvcmUgY29udGVudHMgKGUuZy4gZmV0Y2hlZCB1c2luZyA8Z2V0LWNvbmZp Zz4pIHRvIHRoZSBZQU5HIG1vZGVsIGl0IGlzIG5vdCB2YWxpZC4gVGhhdCBpcyBhZ2FpbnN0IHNl dmVyYWwgUkZDcyByZWZlcmVuY2VkIGluIHRoZSBkaXNjdXNzaW9ucyBiZWxvdy4NCg0KSU1PIHRo ZXJlIGlzbid0IGFueSAib2ZmbGluZSIgdnMiIG9ubGluZSIgdmFsaWRhdGlvbiB0aGF0IGlzIGRp ZmZlcmVudC4gVGhlIGNvbnRlbnRzIG9mIHRoZSBydW5uaW5nIG11c3QgYmUgdmFsaWQgYWdhaW5z dCB0aGUgWUFORyBtb2RlbC4gIEEgPGdldC1jb25maWc+IHJldHVybnMgdGhlIGNvbnRlbnRzIG9m IHRoZSBydW5uaW5nLiAgVGhlIHNlcnZlciBjYW4gdmFsaWRhdGUgaXQsIG9yIHNvbWUgb3RoZXIg ZW50aXR5IGNhbiB2YWxpZGF0ZSBpdCwgYnV0IGl0IG11c3QgYmUgdmFsaWQuDQoNCkluIEphbidz IG9wdGlvbiAjMSB0aGUgcnVubmluZyBjb25maWcgY291bGQgYmUgcG9sbHV0ZWQgd2l0aCAxMDBz IG9yIDEwMDBzIG9mIGxpbmVzIG9mIHVucmVmZXJlbmNlZC91bnVzZWQgY29uZmlnLiBBIDxnZXQt Y29uZmlnPiBvZiBhIHN5c3RlbSB3aXRob3V0IG11Y2ggY29uZmlnIHdvdWxkIGluc3RlYWQgcmV0 dXJuIDEwMHMvMTAwMHMgb2YgbGluZXMuIEkgdGhpbmsgdGhhdCB3b3VsZCBiZSB2ZXJ5IGFubm95 aW5nIGZyb20gYSB1c2FiaWxpdHkgcGVyc3BlY3RpdmUuDQoNCkknbSBpbiBmYXZvciBvZiB0aGlz IGFzcGVjdCBvZiBKYW4ncyBvcHRpb24gIzI6ICAiICsgQ2xpZW50cyB1bmF3YXJlIG9mIHRoZSBz eXN0ZW0gZGF0YXN0b3JlIHdvdWxkIGhhdmUgdG8gaW5jbHVkZSAoY29weSkgaW5mb3JtYXRpb24g ZnJvbSB0aGUgc3lzdGVtIGRhdGFzdG9yZSB0byBydW5uaW5nIGluIG9yZGVyIHRvIHJlZmVyZW5j ZSB0aGVtLiINCg0KLT4gT25seSB0aGUgbGlzdCBrZXlzIG9mIHJlZmVyZW5jZWQgc3lzdGVtIG9i amVjdHMgd291bGQgaGF2ZSB0byBiZSBjb3BpZWQgKGNvbmZpZ3VyZWQpIGludG8gdGhlIHJ1bm5p bmcgRFMgKHRvIHJlc29sdmUgbGVhZnJlZnMpLiAgV2Ugd291bGRuJ3QgbmVlZCB0byBjb3B5IGFs bCB0aGUgZGVzY2VuZGFudCBlbGVtZW50cyBpbnNpZGUgdGhlIHJlZmVyZW5jZWQgb2JqZWN0Lg0K LT4gVGhpcyBjb3B5aW5nIHdvdWxkIG9ubHkgbmVlZCB0byBiZSBkb25lIGJ5IG9wZXJhdG9ycyB3 aXRoIGEgd29ya2Zsb3cgdGhhdCByZXF1aXJlcyBvZmZsaW5lIHZhbGlkYXRpb24NCg0KU29tZSBv ZiB0aGlzIGFwcHJvYWNoIGlzIGFscmVhZHkgZGVzY3JpYmVkIGluIGRyYWZ0LW1hLW5ldG1vZC13 aXRoLXN5c3RlbS0wMToNCg0KIiAgIEluIGFsbCBjYXNlcywgdGhlIGNsaWVudHMgc2hvdWxkIGhh dmUgY29udHJvbCBvdmVyIHRoZSBjb25maWd1cmF0aW9ucw0KICAgLGkuZS4sIHJlYWQtYmFjayBv ZiA8cnVubmluZz4gc2hvdWxkIGNvbnRhaW4gb25seSB3aGF0IHdhcyBleHBsaWNpdGx5DQogICBz ZXQgYnkgY2xpZW50cy4iDQoNCg0KIjQuMy4gIEV4cGxpY2l0IGRlY2xhcmF0aW9uIG9mIHN5c3Rl bSBjb25maWd1cmF0aW9uDQoNCiAgIEluIGFkZGl0aW9uIHRvIG1vZGlmeWluZyBzeXN0ZW0gY29u ZmlndXJhdGlvbiwgYW5kIGFkZGluZyBub2RlcyB0bw0KICAgbGlzdHMgaW4gc3lzdGVtIGNvbmZp Z3VyYXRpb24gYXMgZGVzY3JpYmVkIGFib3ZlLCBhIGNsaWVudCBjYW4gYWxzbw0KICAgZXhwbGlj aXRseSBkZWNsYXJlIHN5c3RlbSBjb25maWd1cmF0aW9uIG5vZGVzIGluIDxydW5uaW5nPiB3aXRo IHRoZQ0KICAgc2FtZSB2YWx1ZXMgYXMgaW4gPHN5c3RlbT4uICBXaGVuIGEgY2xpZW50IGNvbmZp Z3VyZXMgYSBub2RlIChsaXN0DQogICBlbnRyeSwgbGVhZiwgZXRjKSBpbiA8cnVubmluZz4gdGhh dCBtYXRjaGVzIHRoZSBzYW1lIG5vZGUgJiB2YWx1ZSBpbg0KICAgPHN5c3RlbT4sIHRoZW4gdGhh dCBub2RlIGJlY29tZXMgcGFydCBvZiA8cnVubmluZz4uICBBIHJlYWQgb2YNCiAgIDxydW5uaW5n PiByZXR1cm5zIHRob3NlIGV4cGxpY2l0bHkgY29uZmlndXJlZCBub2Rlcy4NCg0KICAgVGhpcyBl eHBsaWNpdCBjb25maWd1cmF0aW9uIG9mIHN5c3RlbSBjb25maWd1cmF0aW9uIGluIDxydW5uaW5n PiBjYW4NCiAgIGJlIHVzZWZ1bCwgZm9yIGV4YW1wbGUsIHdoZW4gYW4gb3BlcmF0b3IncyB3b3Jr ZmxvdyByZXF1aXJlcyBhIGNsaWVudA0KICAgb3Igb2ZmbGluZSB0b29sIHRvIHNlZSB0aGUgPHJ1 bm5pbmc+IGNvbmZpZ3VyYXRpb24gYXMgdmFsaWQuICBUaGUNCiAgIGNsaWVudCBjYW4gZXhwbGlj aXRseSBkZWNsYXJlIChpLmUuICBjb25maWd1cmUgaW4gPHJ1bm5pbmc+KSB0aGUgbGlzdA0KICAg ZW50cmllcyAod2l0aCBhdCBsZWFzdCB0aGUga2V5cykgZm9yIGFueSBzeXN0ZW0gY29uZmlndXJh dGlvbiBsaXN0DQogICBlbnRyaWVzIHRoYXQgYXJlIHJlZmVyZW5jZWQgZWxzZXdoZXJlIGluIDxy dW5uaW5nPi4gIFRoZSBjbGllbnQgZG9lcw0KICAgbm90IG5lY2Vzc2FyaWx5IG5lZWQgdG8gZGVj bGFyZSBhbGwgdGhlIGNvbnRlbnRzIG9mIHRoZSBsaXN0IGVudHJ5DQogICAoaS5lLiB0aGUgZGVz Y2VuZGFudCBub2RlcykgLSBvbmx5IHRoZSBwYXJ0cyB0aGF0IGFyZSByZXF1aXJlZCB0bw0KICAg bWFrZSB0aGUgPHJ1bm5pbmc+IGFwcGVhciB2YWxpZCBvZmZsaW5lLiAgIg0KDQpJJ20gbm90IGEg ZmFuIG9mIG9wdGlvbiAjMy4gSXQgZG9lc24ndCBhbGxvdyBhIG1vZGUgb2Ygb3BlcmF0aW5nIHdo ZXJlIGEgY2xpZW50L09TUyBoYXMgZnVsbCBjb250cm9sIG92ZXIgdGhlIGNvbnRlbnRzIG9mIHRo ZSA8cnVubmluZz4uICBTb21lIG9wZXJhdG9ycyB3aWxsIHdhbnQgdGhlIG1hc3RlciBjb25maWcg dG8gYmUgb3duZWQgdXAgaW4gdGhlaXIgY2xpZW50L09TUyBhbmQgcHVzaCBpdCBkb3duLiBUaGUg c2VydmVyIHNob3VsZCBqdXN0IGFjY2VwdCBpdCBhbmQgdGhlIGNsaWVudCBzaG91bGQgYmUgYWJs ZSB0byBkbyBhICJyZWFkLWJhY2siIGFuZCBzZWUgZXhhY3RseSB3aGF0IHdhcyBzZW50IHByZXZp b3VzbHkuDQoNCkkgdGhpbmsgd2UgaGF2ZSBhIHBvdGVudGlhbCBzb2x1dGlvbiBmb3IgdGhpcyBz eXN0ZW0gY29uZmlnIHRoYXQga2VlcHMgdGhlIHJ1bm5pbmcgdmFsaWQuIEJ1dCBJJ20gZmFyIG1v cmUgd29ycmllZCBhYm91dCBjb25maWd1cmF0aW9uIHRlbXBsYXRlcy4gSSBkb24ndCBzZWUgaG93 IHdlIGNhbiBwb3NzaWJseSBrZWVwIDxydW5uaW5nPiB2YWxpZCB3aXRoIGNvbmZpZyB0ZW1wbGF0 ZXMuIFRoYXQgc2VlbXMgbGlrZSBhIG1ham9yIHByb2JsZW0gdG8gbWUuIEJ1dCBpZiB3ZSBldmVy IGRlY2xhcmUgdGhhdCA8cnVubmluZz4gZG9lc24ndCBoYXZlIHRvIGJlIHZhbGlkLCBhbmQgb25s eSA8aW50ZW5kZWQ+IGhhcyB0byBiZSB2YWxpZCwgdGhlbiBvZmZsaW5lIHRvb2xzIGNhbiBuZXZl ciB2YWxpZGF0ZSAoYWhlYWQgb2YgdGltZSkgdGhlIGNvbmZpZyB0aGV5IGFjdHVhbGx5IGRvd25s b2FkIHRvIHRoZSBzZXJ2ZXIuDQoNCkphc29uDQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogRnJpZGF5LCBE ZWNlbWJlciAzLCAyMDIxIDY6MDEgQU0NClRvOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT47IEphbiBMaW5kYmxhZCA8amFubEB0YWls LWYuY29tPjsgS2VudCBXYXRzZW4gPGtlbnRAd2F0c2VuLm5ldD47IG1hcWl1ZmFuZyAoQSkgPG1h cWl1ZmFuZzE9NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnPjsgbmV0bW9kQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW25ldG1vZF0gTXVzdCBvZmZsaW5lLXZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+ IGFsb25lIGJlIHZhbGlkPw0KDQoNCg0KT24gRnJpLCBEZWMgMywgMjAyMSBhdCAyOjI2IEFNIErD vHJnZW4gU2Now7Zud8OkbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl PG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCk9u IEZyaSwgRGVjIDAzLCAyMDIxIGF0IDEwOjU5OjEyQU0gKzAxMDAsIEphbiBMaW5kYmxhZCB3cm90 ZToNCg0KPiBJIG1hZGUgc29tZSBwcm9wb3NhbHMgZWFybGllciwgYm90aCBvbiB0aGUgaW50ZXJp bSBhbmQgcHJpdmF0ZWx5IHRvIHRoZSBkcmFmdCBhdXRob3JzLCBhbG9uZyB0aGVzZSBsaW5lczoN Cj4NCj4gT3B0aW9uICMxDQo+ICsgV2UgY291bGQgaGF2ZSBhIG5ldyBzeXN0ZW0gZGF0YXN0b3Jl IHRoYXQgdGVjaG5pY2FsbHkgaXMgYSBwYXJ0IG9mIHJ1bm5pbmcuIEV2ZXJ5dGhpbmcgaW4gc3lz dGVtIHdvdWxkIHNob3cgdXAgaW4gcnVubmluZyB0byAgY2xpZW50cyB1bmF3YXJlIG9mIHRoZSBz eXN0ZW0gZGF0YXN0b3JlLiBFdmVyeSB0aW1lIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIGNoYW5nZXMg Zm9yIHdoYXRldmVyIHJlYXNvbiwgdGhlIHJ1bm5pbmcgZGF0YXN0b3JlIHRyYW5zYWN0aW9uIGlk cyAoaWYgd2UgbWFuYWdlIHRvIGdldCB0aGF0IGNvbmNlcHQgZGVmaW5lZCksIGFyZSB1cGRhdGVk DQo+ICsgQ2xpZW50cyBpbnRlcmVzdGVkIHRvIHNlZSBwdXJlIHZpZXcgb2YgdGhlIHN5c3RlbSBk YXRhc3RvcmUgd2l0aG91dCBhbnl0aGluZyBlbHNlIGluIHJ1bm5pbmcgY291bGQgaXNzdWUgYSBn ZXQtZGF0YSB0b3dhcmRzIHRoZSBzeXN0ZW0gZGF0YXN0b3JlDQo+ICsgQ2xpZW50cyBpbnRlcmVz dGVkIHRvIHNlZSBhIHB1cmUgdmlldyBvZiBydW5uaW5nIHdpdGhvdXQgYW55IHN5c3RlbSBkYXRh c3RvcmUgZWxlbWVudHMgY291bGQgaXNzdWUgYSBnZXQtZGF0YSB0b3dhcmRzIHJ1bm5pbmcgd2l0 aCBhbiBleHRyYSBmbGFnIGNhbGxlZCAnd2l0aG91dC1zeXN0ZW0nDQo+ICsgU2luY2UgYWxsIHN5 c3RlbSBlbGVtZW50cyBhcmUgYWxyZWFkeSBwYXJ0IG9mIHJ1bm5pbmcsIGNsaWVudHMgaGF2ZSBu byBuZWVkIHRvIGNvcHkgZGF0YSBiZXR3ZWVuIHRoZSB0d28gZGF0YXN0b3Jlcw0KPg0KPiBPcHRp b24gIzINCj4gKyBXZSBjb3VsZCBoYXZlIGEgc3lzdGVtIGRhdGFzdG9yZSB0aGF0IHRlY2huaWNh bGx5IGlzIGEgcGFydCBvZiBvcGVyYXRpb25hbC4gRXZlcnl0aGluZyBpbiBzeXN0ZW0gd291bGQg c2hvdyB1cCBpbiBvcGVyYXRpb25hbCB0byAgY2xpZW50cyB1bmF3YXJlIG9mIHRoZSBzeXN0ZW0g ZGF0YXN0b3JlLiBUaGUgcnVubmluZyBkYXRhc3RvcmUgYWx3YXlzIG1haW50YWlucyByZWZlcmVu dGlhbCBpbnRlZ3JpdHksIGkuZS4gY2Fubm90IHJlZmVyZW5jZSB0aGUgc3lzdGVtIGRhdGFzdG9y ZS4NCj4gKyBDbGllbnRzIGludGVyZXN0ZWQgdG8gc2VlIHB1cmUgdmlldyBvZiB0aGUgc3lzdGVt IGRhdGFzdG9yZSBjb3VsZCBpc3N1ZSBhIGdldC1kYXRhIHRvd2FyZHMgdGhlIHN5c3RlbSBkYXRh c3RvcmUNCj4gKyBTaW5jZSB0aGUgc3lzdGVtIGRhdGFzdG9yZSBpcyBub3QgcGFydCBvZiBydW5u aW5nLCBjbGllbnRzIGNhbiBhbHJlYWR5IHNlZSBhIHB1cmUgdmlldyBvZiBydW5uaW5nIHdpdGhv dXQgYW55IHN5c3RlbSBkYXRhc3RvcmUgZWxlbWVudHMgdXNpbmcgYSBzaW1wbGUgZ2V0LWRhdGEu DQo+ICsgQ2xpZW50cyB0aGF0IGFyZSBhd2FyZSBvZiB0aGUgc3lzdGVtIGRhdGFzdG9yZSBhbmQg YXJlIGludGVyZXN0ZWQgdG8gY29uZmlndXJlIHJlZmVyZW5jZXMgZnJvbSBydW5uaW5nIHRvIHN5 c3RlbSBlbGVtZW50cyB3b3VsZCBpc3N1ZSBhbiBlZGl0LWRhdGEgcnBjIHdpdGggdGhlIGFkZGl0 aW9uYWwgZmxhZyAncmVzb2x2ZS1zeXN0ZW0tcmVmZXJlbmNlcycuIFRoaXMgd2lsbCBtYWtlIHRo ZSBzZXJ2ZXIgY29weSBhbnkgc3lzdGVtIGVsZW1lbnRzIHJlZmVyZW5jZWQgaW50byBydW5uaW5n IHdpdGhvdXQgdGhlIGNsaWVudCBkb2luZyBzbyBleHBsaWNpdGx5Lg0KPiArIENsaWVudHMgdW5h d2FyZSBvZiB0aGUgc3lzdGVtIGRhdGFzdG9yZSB3b3VsZCBoYXZlIHRvIGluY2x1ZGUgKGNvcHkp IGluZm9ybWF0aW9uIGZyb20gdGhlIHN5c3RlbSBkYXRhc3RvcmUgdG8gcnVubmluZyBpbiBvcmRl ciB0byByZWZlcmVuY2UgdGhlbS4NCj4NCg0KT3B0aW9uICMzDQoNClRoZXJlIGlzIGEgY2xpZW50 IG9uIHRoZSBzeXN0ZW0gdGhhdCBtYWtlcyBjaGFuZ2VzIHRvIHJ1bm5pbmcganVzdA0KbGlrZSBh bnkgb3RoZXIgcmVtb3RlIGNsaWVudHMgY2FuIG1ha2UgY2hhbmdlcyB0byBydW5uaW5nLiBTeXN0 ZW0NCmdlbmVyYXRlIGNvbmZpZyB0aGF0IGlzIG5vdCBlZGl0YWJsZSBleHBsaWNpdCBjb25maWcg aW4gcnVubmluZyBnb2VzDQpzdHJhaWdodCBpbnRvIHRoZSBhcHBsaWVkIGNvbmZpZyBpbiBvcGVy YXRpb25hbC4gVGhpcyBkb2VzIG5vdCByZXF1aXJlDQphIHN5c3RlbSBkYXRhc3RvcmUgKGluIGZh Y3Qgc29tZXRoaW5nIGxpa2UgYSBzeXN0ZW0gZGF0YXN0b3JlIG1heQ0KZXhpc3QgYXMgdGhlIF9s b2dpY18gb2YgdGhlIHN5c3RlbSBjbGllbnQsIHRoZSBnb29kIG9sZCBleGFtcGxlIHdlIGhhZA0K aXMgYWxsb2N0aW5nIGFuIHVudXNlZCB1aWQgZm9yIGFuIGFjY291bnQgdGhhdCwgb25jZSBhbGxv Y2F0ZWQsIGlzDQptYWludGFpbmVkIGluIHJ1bm5pbmcpLg0KDQoNCisxIHRvIG9wdGlvbiAzLg0K Q29uc2lkZXIgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBtb3ZlcyBhbGwgdGhlICJoaWRkZW4gc3lz dGVtIGxvZ2ljIiBvZmYtYm94DQp0byBhIGNvbnRyb2xsZXIsIHN1Y2ggdGhhdCB0aGUgaW5pdGlh bCBjb25maWcgaXMgbGl0ZXJhbGx5IHN1cHBsaWVkIGJ5IGFuIGV4dGVybmFsIGNsaWVudC4NCg0K SSBoYXZlIHlldCB0byBoZWFyIGEgc2luZ2xlIHVzZS1jYXNlIGZvciBjcmVhdGluZyBhIDxzeXN0 ZW0+IGRhdGFzdG9yZS4NCiJUaGUgY2xpZW50IG1pZ2h0IHdhbnQiIGlzIG5vdCBhIHVzZS1jYXNl IGZvciBzdGFuZGFyZGl6YXRpb24uDQpJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSAicHVyZSB2aWV3 Ii4gU2VlbXMgbGlrZSBpZiB0aGlzIHdhcyBhIHJlYWwgcHJvYmxlbSB0byBzb2x2ZSwNCnRoZW4g Tk1EQSB3b3VsZCBoYXZlIGluY2x1ZGVkIGEgc3lzdGVtIGRhdGFzdG9yZSBmcm9tIHRoZSBzdGFy dC4NCg0KDQovanMNCg0KDQpBbmR5DQoNCg0KLS0NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAg ICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAg MzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6 ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0 eS5kZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --_000_DM6PR08MB50844DB8F2F7D2D11A6CB0879B6F9DM6PR08MB5084namp_ 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 OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIGd1 eXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkFuZHkgLSBhYm91dCB1c2UgY2FzZXMuJm5ic3A7IEhlcmUgaXMgYSBwcm9ibGVt IHdlJ3JlIHRyeWluZyB0byBhZGRyZXNzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5UaGVyZSBhcmUgYXQgbGVhc3Qgc2V2ZXJhbCBtYWpvciByb3V0ZXIgaW1wbGVtZW50YXRpb25z IHRoYXQgaGF2ZSB0aGlzIGNvbmNlcHQgb2YgJnF1b3Q7aGlkZGVuIGNvbmZpZyZxdW90OyAoaS5l LiBsaXN0IGVudHJpZXMgdGhhdCBjYW4gYmUgcmVmZXJlbmNlZCBpbiBhIGxlYWZyZWYgYnkgZXhw bGljaXQgdXNlcg0KIGNvbmZpZywgYnV0IHRob3NlIGxpc3QgZW50cmllcyBhcmUgbm90IHJldHVy bmVkIGluIGEgJmx0O2dldC1jb25maWcmZ3Q7KS4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBzZXJ2ZXIg YWNjZXB0cyB0aGVzZSBjb25maWd1cmF0aW9ucyAoaS5lLiBhIHZhbGlkYXRlIG9yIGNvbW1pdCBz dWNjZWVkcyksIGJ1dCBpZiB5b3UgYWN0dWFsbHkgdmFsaWRhdGUgKGUuZy4gd2l0aCB5YW5nTGlu dCkgdGhlIHJ1bm5pbmcgZGF0YXN0b3JlIGNvbnRlbnRzIChlLmcuIGZldGNoZWQNCiB1c2luZyAm bHQ7Z2V0LWNvbmZpZyZndDspIHRvIHRoZSBZQU5HIG1vZGVsIGl0IGlzIG5vdCB2YWxpZC4gVGhh dCBpcyBhZ2FpbnN0IHNldmVyYWwgUkZDcyByZWZlcmVuY2VkIGluIHRoZSBkaXNjdXNzaW9ucyBi ZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SU1PIHRoZXJlIGlzbid0IGFueSAmcXVvdDtvZmZsaW5lJnF1b3Q7IHZzJnF1 b3Q7IG9ubGluZSZxdW90OyB2YWxpZGF0aW9uIHRoYXQgaXMgZGlmZmVyZW50LiBUaGUgY29udGVu dHMgb2YgdGhlIHJ1bm5pbmcgbXVzdCBiZSB2YWxpZCBhZ2FpbnN0IHRoZSBZQU5HIG1vZGVsLiZu YnNwOyBBICZsdDtnZXQtY29uZmlnJmd0OyByZXR1cm5zIHRoZSBjb250ZW50cyBvZiB0aGUgcnVu bmluZy4mbmJzcDsgVGhlDQogc2VydmVyIGNhbiB2YWxpZGF0ZSBpdCwgb3Igc29tZSBvdGhlciBl bnRpdHkgY2FuIHZhbGlkYXRlIGl0LCBidXQgaXQgbXVzdCBiZSB2YWxpZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW4gSmFu J3Mgb3B0aW9uICMxIHRoZSBydW5uaW5nIGNvbmZpZyBjb3VsZCBiZSBwb2xsdXRlZCB3aXRoIDEw MHMgb3IgMTAwMHMgb2YgbGluZXMgb2YgdW5yZWZlcmVuY2VkL3VudXNlZCBjb25maWcuIEEgJmx0 O2dldC1jb25maWcmZ3Q7IG9mIGEgc3lzdGVtIHdpdGhvdXQgbXVjaCBjb25maWcgd291bGQgaW5z dGVhZCByZXR1cm4gMTAwcy8xMDAwcyBvZg0KIGxpbmVzLiBJIHRoaW5rIHRoYXQgd291bGQgYmUg dmVyeSBhbm5veWluZyBmcm9tIGEgdXNhYmlsaXR5IHBlcnNwZWN0aXZlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JJ20gaW4g ZmF2b3Igb2YgdGhpcyBhc3BlY3Qgb2YgSmFuJ3Mgb3B0aW9uICMyOiZuYnNwOyAmcXVvdDsgKyBD bGllbnRzIHVuYXdhcmUgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUgd291bGQgaGF2ZSB0byBpbmNs dWRlIChjb3B5KSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIHRvIHJ1bm5p bmcgaW4gb3JkZXIgdG8gcmVmZXJlbmNlIHRoZW0uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0mZ3Q7IE9ubHkgdGhl IGxpc3Qga2V5cyBvZiByZWZlcmVuY2VkIHN5c3RlbSBvYmplY3RzIHdvdWxkIGhhdmUgdG8gYmUg Y29waWVkIChjb25maWd1cmVkKSBpbnRvIHRoZSBydW5uaW5nIERTICh0byByZXNvbHZlIGxlYWZy ZWZzKS4mbmJzcDsgV2Ugd291bGRuJ3QgbmVlZCB0byBjb3B5IGFsbCB0aGUgZGVzY2VuZGFudCBl bGVtZW50cyBpbnNpZGUgdGhlDQogcmVmZXJlbmNlZCBvYmplY3QuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4tJmd0OyBUaGlzIGNvcHlpbmcgd291bGQgb25seSBuZWVkIHRvIGJlIGRvbmUg Ynkgb3BlcmF0b3JzIHdpdGggYSB3b3JrZmxvdyB0aGF0IHJlcXVpcmVzIG9mZmxpbmUgdmFsaWRh dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5Tb21lIG9mIHRoaXMgYXBwcm9hY2ggaXMgYWxyZWFkeSBkZXNjcmliZWQgaW4g ZHJhZnQtbWEtbmV0bW9kLXdpdGgtc3lzdGVtLTAxOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mcXVvdDsmbmJzcDsmbmJzcDsg SW4gYWxsIGNhc2VzLCB0aGUgY2xpZW50cyBzaG91bGQgaGF2ZSBjb250cm9sIG92ZXIgdGhlIGNv bmZpZ3VyYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgLGku ZS4sIHJlYWQtYmFjayBvZiAmbHQ7cnVubmluZyZndDsgc2hvdWxkIGNvbnRhaW4gb25seSB3aGF0 IHdhcyBleHBsaWNpdGx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsg c2V0IGJ5IGNsaWVudHMuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+JnF1b3Q7NC4zLiZuYnNwOyBFeHBsaWNpdCBkZWNsYXJhdGlvbiBvZiBzeXN0ZW0gY29u ZmlndXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgSW4gYWRkaXRpb24gdG8gbW9kaWZ5aW5nIHN5 c3RlbSBjb25maWd1cmF0aW9uLCBhbmQgYWRkaW5nIG5vZGVzIHRvPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgbGlzdHMgaW4gc3lzdGVtIGNvbmZpZ3VyYXRpb24gYXMg ZGVzY3JpYmVkIGFib3ZlLCBhIGNsaWVudCBjYW4gYWxzbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+Jm5ic3A7Jm5ic3A7IGV4cGxpY2l0bHkgZGVjbGFyZSBzeXN0ZW0gY29uZmlndXJhdGlv biBub2RlcyBpbiAmbHQ7cnVubmluZyZndDsgd2l0aCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPiZuYnNwOyZuYnNwOyBzYW1lIHZhbHVlcyBhcyBpbiAmbHQ7c3lzdGVtJmd0Oy4mbmJz cDsgV2hlbiBhIGNsaWVudCBjb25maWd1cmVzIGEgbm9kZSAobGlzdDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7IGVudHJ5LCBsZWFmLCBldGMpIGluICZsdDtydW5uaW5n Jmd0OyB0aGF0IG1hdGNoZXMgdGhlIHNhbWUgbm9kZSAmYW1wOyB2YWx1ZSBpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZsdDtzeXN0ZW0mZ3Q7LCB0aGVuIHRoYXQg bm9kZSBiZWNvbWVzIHBhcnQgb2YgJmx0O3J1bm5pbmcmZ3Q7LiZuYnNwOyBBIHJlYWQgb2Y8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyAmbHQ7cnVubmluZyZndDsgcmV0 dXJucyB0aG9zZSBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgbm9kZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNw OyBUaGlzIGV4cGxpY2l0IGNvbmZpZ3VyYXRpb24gb2Ygc3lzdGVtIGNvbmZpZ3VyYXRpb24gaW4g Jmx0O3J1bm5pbmcmZ3Q7IGNhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5i c3A7IGJlIHVzZWZ1bCwgZm9yIGV4YW1wbGUsIHdoZW4gYW4gb3BlcmF0b3IncyB3b3JrZmxvdyBy ZXF1aXJlcyBhIGNsaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7 IG9yIG9mZmxpbmUgdG9vbCB0byBzZWUgdGhlICZsdDtydW5uaW5nJmd0OyBjb25maWd1cmF0aW9u IGFzIHZhbGlkLiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZu YnNwOyBjbGllbnQgY2FuIGV4cGxpY2l0bHkgZGVjbGFyZSAoaS5lLiZuYnNwOyBjb25maWd1cmUg aW4gJmx0O3J1bm5pbmcmZ3Q7KSB0aGUgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Jm5ic3A7Jm5ic3A7IGVudHJpZXMgKHdpdGggYXQgbGVhc3QgdGhlIGtleXMpIGZvciBhbnkgc3lz dGVtIGNvbmZpZ3VyYXRpb24gbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7 Jm5ic3A7IGVudHJpZXMgdGhhdCBhcmUgcmVmZXJlbmNlZCBlbHNld2hlcmUgaW4gJmx0O3J1bm5p bmcmZ3Q7LiZuYnNwOyBUaGUgY2xpZW50IGRvZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PiZuYnNwOyZuYnNwOyBub3QgbmVjZXNzYXJpbHkgbmVlZCB0byBkZWNsYXJlIGFsbCB0aGUgY29u dGVudHMgb2YgdGhlIGxpc3QgZW50cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNw OyZuYnNwOyAoaS5lLiB0aGUgZGVzY2VuZGFudCBub2RlcykgLSBvbmx5IHRoZSBwYXJ0cyB0aGF0 IGFyZSByZXF1aXJlZCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7 IG1ha2UgdGhlICZsdDtydW5uaW5nJmd0OyBhcHBlYXIgdmFsaWQgb2ZmbGluZS4mbmJzcDsgJnF1 b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkknbSBub3QgYSBmYW4gb2Ygb3B0aW9uICMzLiBJdCBkb2Vzbid0IGFsbG93IGEg bW9kZSBvZiBvcGVyYXRpbmcgd2hlcmUgYSBjbGllbnQvT1NTIGhhcyBmdWxsIGNvbnRyb2wgb3Zl ciB0aGUgY29udGVudHMgb2YgdGhlICZsdDtydW5uaW5nJmd0Oy4gJm5ic3A7U29tZSBvcGVyYXRv cnMgd2lsbCB3YW50IHRoZSBtYXN0ZXIgY29uZmlnIHRvIGJlIG93bmVkIHVwDQogaW4gdGhlaXIg Y2xpZW50L09TUyBhbmQgcHVzaCBpdCBkb3duLiBUaGUgc2VydmVyIHNob3VsZCBqdXN0IGFjY2Vw dCBpdCBhbmQgdGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byBkbyBhICZxdW90O3JlYWQtYmFj ayZxdW90OyBhbmQgc2VlIGV4YWN0bHkgd2hhdCB3YXMgc2VudCBwcmV2aW91c2x5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5J IHRoaW5rIHdlIGhhdmUgYSBwb3RlbnRpYWwgc29sdXRpb24gZm9yIHRoaXMgc3lzdGVtIGNvbmZp ZyB0aGF0IGtlZXBzIHRoZSBydW5uaW5nIHZhbGlkLiBCdXQgSSdtIGZhciBtb3JlIHdvcnJpZWQg YWJvdXQgY29uZmlndXJhdGlvbiB0ZW1wbGF0ZXMuIEkgZG9uJ3Qgc2VlIGhvdyB3ZSBjYW4gcG9z c2libHkga2VlcCAmbHQ7cnVubmluZyZndDsgdmFsaWQNCiB3aXRoIGNvbmZpZyB0ZW1wbGF0ZXMu IFRoYXQgc2VlbXMgbGlrZSBhIG1ham9yIHByb2JsZW0gdG8gbWUuIEJ1dCBpZiB3ZSBldmVyIGRl Y2xhcmUgdGhhdCAmbHQ7cnVubmluZyZndDsgZG9lc24ndCBoYXZlIHRvIGJlIHZhbGlkLCBhbmQg b25seSAmbHQ7aW50ZW5kZWQmZ3Q7IGhhcyB0byBiZSB2YWxpZCwgdGhlbiBvZmZsaW5lIHRvb2xz IGNhbiBuZXZlciB2YWxpZGF0ZSAoYWhlYWQgb2YgdGltZSkgdGhlIGNvbmZpZyB0aGV5IGFjdHVh bGx5IGRvd25sb2FkIHRvIHRoZQ0KIHNlcnZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SmFzb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbmV0bW9kICZsdDtu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVy bWFuPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRGVjZW1iZXIgMywgMjAyMSA2OjAxIEFNPGJy Pg0KPGI+VG86PC9iPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZSZndDs7IEphbiBMaW5kYmxhZCAmbHQ7amFubEB0YWlsLWYuY29t Jmd0OzsgS2VudCBXYXRzZW4gJmx0O2tlbnRAd2F0c2VuLm5ldCZndDs7IG1hcWl1ZmFuZyAoQSkg Jmx0O21hcWl1ZmFuZzE9NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnJmd0OzsgbmV0bW9kQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBNdXN0IG9mZmxpbmUtdmFs aWRhdGlvbiBvZiAmbHQ7cnVubmluZyZndDsgYWxvbmUgYmUgdmFsaWQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgRGVjIDMs IDIwMjEgYXQgMjoyNiBBTSBKw7xyZ2VuIFNjaMO2bnfDpGxkZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiPmouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5PbiBGcmksIERlYyAwMywgMjAyMSBhdCAxMDo1OToxMkFNICswMTAwLCBKYW4gTGlu ZGJsYWQgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBJIG1hZGUgc29tZSBwcm9wb3NhbHMgZWFybGll ciwgYm90aCBvbiB0aGUgaW50ZXJpbSBhbmQgcHJpdmF0ZWx5IHRvIHRoZSBkcmFmdCBhdXRob3Jz LCBhbG9uZyB0aGVzZSBsaW5lczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgT3B0aW9uICMxPGJyPg0K Jmd0OyArIFdlIGNvdWxkIGhhdmUgYSBuZXcgc3lzdGVtIGRhdGFzdG9yZSB0aGF0IHRlY2huaWNh bGx5IGlzIGEgcGFydCBvZiBydW5uaW5nLiBFdmVyeXRoaW5nIGluIHN5c3RlbSB3b3VsZCBzaG93 IHVwIGluIHJ1bm5pbmcgdG8mbmJzcDsgY2xpZW50cyB1bmF3YXJlIG9mIHRoZSBzeXN0ZW0gZGF0 YXN0b3JlLiBFdmVyeSB0aW1lIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIGNoYW5nZXMgZm9yIHdoYXRl dmVyIHJlYXNvbiwgdGhlIHJ1bm5pbmcgZGF0YXN0b3JlIHRyYW5zYWN0aW9uDQogaWRzIChpZiB3 ZSBtYW5hZ2UgdG8gZ2V0IHRoYXQgY29uY2VwdCBkZWZpbmVkKSwgYXJlIHVwZGF0ZWQ8YnI+DQom Z3Q7ICsgQ2xpZW50cyBpbnRlcmVzdGVkIHRvIHNlZSBwdXJlIHZpZXcgb2YgdGhlIHN5c3RlbSBk YXRhc3RvcmUgd2l0aG91dCBhbnl0aGluZyBlbHNlIGluIHJ1bm5pbmcgY291bGQgaXNzdWUgYSBn ZXQtZGF0YSB0b3dhcmRzIHRoZSBzeXN0ZW0gZGF0YXN0b3JlPGJyPg0KJmd0OyArIENsaWVudHMg aW50ZXJlc3RlZCB0byBzZWUgYSBwdXJlIHZpZXcgb2YgcnVubmluZyB3aXRob3V0IGFueSBzeXN0 ZW0gZGF0YXN0b3JlIGVsZW1lbnRzIGNvdWxkIGlzc3VlIGEgZ2V0LWRhdGEgdG93YXJkcyBydW5u aW5nIHdpdGggYW4gZXh0cmEgZmxhZyBjYWxsZWQgJ3dpdGhvdXQtc3lzdGVtJzxicj4NCiZndDsg KyBTaW5jZSBhbGwgc3lzdGVtIGVsZW1lbnRzIGFyZSBhbHJlYWR5IHBhcnQgb2YgcnVubmluZywg Y2xpZW50cyBoYXZlIG5vIG5lZWQgdG8gY29weSBkYXRhIGJldHdlZW4gdGhlIHR3byBkYXRhc3Rv cmVzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9wdGlvbiAjMjxicj4NCiZndDsgKyBXZSBjb3VsZCBo YXZlIGEgc3lzdGVtIGRhdGFzdG9yZSB0aGF0IHRlY2huaWNhbGx5IGlzIGEgcGFydCBvZiBvcGVy YXRpb25hbC4gRXZlcnl0aGluZyBpbiBzeXN0ZW0gd291bGQgc2hvdyB1cCBpbiBvcGVyYXRpb25h bCB0byZuYnNwOyBjbGllbnRzIHVuYXdhcmUgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUuIFRoZSBy dW5uaW5nIGRhdGFzdG9yZSBhbHdheXMgbWFpbnRhaW5zIHJlZmVyZW50aWFsIGludGVncml0eSwg aS5lLiBjYW5ub3QgcmVmZXJlbmNlDQogdGhlIHN5c3RlbSBkYXRhc3RvcmUuPGJyPg0KJmd0OyAr IENsaWVudHMgaW50ZXJlc3RlZCB0byBzZWUgcHVyZSB2aWV3IG9mIHRoZSBzeXN0ZW0gZGF0YXN0 b3JlIGNvdWxkIGlzc3VlIGEgZ2V0LWRhdGEgdG93YXJkcyB0aGUgc3lzdGVtIGRhdGFzdG9yZTxi cj4NCiZndDsgKyBTaW5jZSB0aGUgc3lzdGVtIGRhdGFzdG9yZSBpcyBub3QgcGFydCBvZiBydW5u aW5nLCBjbGllbnRzIGNhbiBhbHJlYWR5IHNlZSBhIHB1cmUgdmlldyBvZiBydW5uaW5nIHdpdGhv dXQgYW55IHN5c3RlbSBkYXRhc3RvcmUgZWxlbWVudHMgdXNpbmcgYSBzaW1wbGUgZ2V0LWRhdGEu DQo8YnI+DQomZ3Q7ICsgQ2xpZW50cyB0aGF0IGFyZSBhd2FyZSBvZiB0aGUgc3lzdGVtIGRhdGFz dG9yZSBhbmQgYXJlIGludGVyZXN0ZWQgdG8gY29uZmlndXJlIHJlZmVyZW5jZXMgZnJvbSBydW5u aW5nIHRvIHN5c3RlbSBlbGVtZW50cyB3b3VsZCBpc3N1ZSBhbiBlZGl0LWRhdGEgcnBjIHdpdGgg dGhlIGFkZGl0aW9uYWwgZmxhZyAncmVzb2x2ZS1zeXN0ZW0tcmVmZXJlbmNlcycuIFRoaXMgd2ls bCBtYWtlIHRoZSBzZXJ2ZXIgY29weSBhbnkgc3lzdGVtIGVsZW1lbnRzDQogcmVmZXJlbmNlZCBp bnRvIHJ1bm5pbmcgd2l0aG91dCB0aGUgY2xpZW50IGRvaW5nIHNvIGV4cGxpY2l0bHkuPGJyPg0K Jmd0OyArIENsaWVudHMgdW5hd2FyZSBvZiB0aGUgc3lzdGVtIGRhdGFzdG9yZSB3b3VsZCBoYXZl IHRvIGluY2x1ZGUgKGNvcHkpIGluZm9ybWF0aW9uIGZyb20gdGhlIHN5c3RlbSBkYXRhc3RvcmUg dG8gcnVubmluZyBpbiBvcmRlciB0byByZWZlcmVuY2UgdGhlbS48YnI+DQomZ3Q7PGJyPg0KPGJy Pg0KT3B0aW9uICMzPGJyPg0KPGJyPg0KVGhlcmUgaXMgYSBjbGllbnQgb24gdGhlIHN5c3RlbSB0 aGF0IG1ha2VzIGNoYW5nZXMgdG8gcnVubmluZyBqdXN0PGJyPg0KbGlrZSBhbnkgb3RoZXIgcmVt b3RlIGNsaWVudHMgY2FuIG1ha2UgY2hhbmdlcyB0byBydW5uaW5nLiBTeXN0ZW08YnI+DQpnZW5l cmF0ZSBjb25maWcgdGhhdCBpcyBub3QgZWRpdGFibGUgZXhwbGljaXQgY29uZmlnIGluIHJ1bm5p bmcgZ29lczxicj4NCnN0cmFpZ2h0IGludG8gdGhlIGFwcGxpZWQgY29uZmlnIGluIG9wZXJhdGlv bmFsLiBUaGlzIGRvZXMgbm90IHJlcXVpcmU8YnI+DQphIHN5c3RlbSBkYXRhc3RvcmUgKGluIGZh Y3Qgc29tZXRoaW5nIGxpa2UgYSBzeXN0ZW0gZGF0YXN0b3JlIG1heTxicj4NCmV4aXN0IGFzIHRo ZSBfbG9naWNfIG9mIHRoZSBzeXN0ZW0gY2xpZW50LCB0aGUgZ29vZCBvbGQgZXhhbXBsZSB3ZSBo YWQ8YnI+DQppcyBhbGxvY3RpbmcgYW4gdW51c2VkIHVpZCBmb3IgYW4gYWNjb3VudCB0aGF0LCBv bmNlIGFsbG9jYXRlZCwgaXM8YnI+DQptYWludGFpbmVkIGluIHJ1bm5pbmcpLjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4rMSB0 byBvcHRpb24gMy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkNvbnNpZGVyIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgbW92ZXMgYWxsIHRoZSAmcXVv dDtoaWRkZW4gc3lzdGVtIGxvZ2ljJnF1b3Q7IG9mZi1ib3g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIGEgY29udHJvbGxlciwgc3VjaCB0aGF0 IHRoZSBpbml0aWFsIGNvbmZpZyBpcyBsaXRlcmFsbHkgc3VwcGxpZWQgYnkgYW4gZXh0ZXJuYWwg Y2xpZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGhhdmUgeWV0IHRvIGhlYXIgYSBzaW5nbGUgdXNlLWNhc2UgZm9yIGNyZWF0aW5nIGEg Jmx0O3N5c3RlbSZndDsgZGF0YXN0b3JlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7VGhlIGNsaWVudCBtaWdodCB3YW50JnF1b3Q7IGlz IG5vdCBhIHVzZS1jYXNlIGZvciBzdGFuZGFyZGl6YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSAm cXVvdDtwdXJlIHZpZXcmcXVvdDsuIFNlZW1zIGxpa2UgaWYgdGhpcyB3YXMgYSByZWFsIHByb2Js ZW0gdG8gc29sdmUsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj50aGVuIE5NREEgd291bGQgaGF2ZSBpbmNsdWRlZCBhIHN5c3RlbSBkYXRhc3RvcmUg ZnJvbSB0aGUgc3RhcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+L2pzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0gPGJyPg0KSnVl cmdlbiBTY2hvZW53YWVsZGVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+DQpQaG9uZTogKzQ5IDQyMSAyMDAg MzU4NyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDYW1wdXMgUmluZyAxIHwgMjg3 NTkgQnJlbWVuIHwgR2VybWFueTxicj4NCkZheDombmJzcDsgJm5ic3A7KzQ5IDQyMSAyMDAgMzEw MyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93 d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuamFj b2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9k QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR08MB50844DB8F2F7D2D11A6CB0879B6F9DM6PR08MB5084namp_-- From nobody Wed Dec 8 14:34: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 B0BC03A07A2 for ; Wed, 8 Dec 2021 14:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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=unavailable 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 AIddv4aJgEg7 for ; Wed, 8 Dec 2021 14:34:36 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2104.outbound.protection.outlook.com [40.107.244.104]) (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 4211E3A079D for ; Wed, 8 Dec 2021 14:34:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NGBR37RuF3QdcDMncHuWUEST3/vLBLdk5l3/sw0PyzTp7+aiIOHQF7eXCRqMEU2PF3YtkR4961OtKMVDZt6bRqPVk+04ute7AmtQIqgl8rg+KVscZxmLD/NXjZ3/rxd+fwxbwKVdGqlXvmuMoWL0Tn2rVdZXePBVvgSgiZEMuoIsL9jX6yb77ewJuVPIsbK4DOqMOcyG/kKMBMCdJgZOZJktrdh0wPpQnziDrAPM7TkACYpknKdZgCjF6TrFpYTIR0hXpS8SqsmcllidFB9ZZ604MfddnpJzrDoQjSzoAhQ6PdZuzykD8h9BBo45xMBWTvgBygG5YJyP6WdI+pQXjA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hiaJCDxQwMrfv9JCG2OrRX+9tcHwxq8kNxwpT8mHKeY=; b=SVvkGJZIncgp7hceXo4N9YjFceAYGrVPUqjU9wUMyzWARmE1g3c7CIexffvMD8EpDppraWGAKZUznjvPQn7QhiSDvrQyj6snuKqFICfg0sJY/7Xlt1xHbkdSQ3xylEX+uHgZznBCoWJrcRfwkEu3RQ3KgNf+2+mTVPvzSOFFAE5sDw7nKCh7RIz+r7sXGgcngjB1Jbo57R5rXdYSHbEm9i8LM4Pgde0MIt7PzBDRS8+e+4GcjE1FcxytIQclj1SrucDr34XxPRoqfpAbXAYWhLImOj3FWw/T1A4BAPOdWOG9ofVanibT26RX4BDpCFTEjjNk1Ujm1eVJKjc7SnSa9w== 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=hiaJCDxQwMrfv9JCG2OrRX+9tcHwxq8kNxwpT8mHKeY=; b=NQt6fTjoH6qOr5zAFwg5JAdcF5qvC9zBDjuzqfLC//+OXPVAV2DGd2uNbroOdNJb1bd8xFCyB38bYvAJ0/3GbRvLDkW8DOjh5TSL/CjPHwCkgIPmGvw9/Z7y7wp3/Dt8EU3kemP2J4IbZXIGDjw3t8JEzdXEmyM0mcjN1TbLByw= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5963.namprd08.prod.outlook.com (2603:10b6:5:153::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.20; Wed, 8 Dec 2021 22:34:31 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.022; Wed, 8 Dec 2021 22:34:31 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Kent Watsen , Jan Lindblad CC: "maqiufang (A)" , "netmod@ietf.org" Thread-Topic: [netmod] Must offline-validation of alone be valid? Thread-Index: AQHX7IPD5BZXcFhAE0+IivjOGbmtWQ== Date: Wed, 8 Dec 2021 22:34:31 +0000 Message-ID: References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> In-Reply-To: <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f56f0d85-41a0-4e59-9e16-08d9ba9ae6f1 x-ms-traffictypediagnostic: DM6PR08MB5963:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o31EUrdkfFb8JRoBs5PdkGdHGXDc4lI6CMiv/pO0wFVkXUPVj0coTx8Wv23bNtVmHW78gWoAlj6gAbUjoZqvBckwdMt291nTpBh80kmJMDnySxy+Ayzxl6FayzZ4ikQ7R4gB01BLhoNIiWjOl90qDH7tQDCej5zY3ywZ5im7xPTKVnUx5xo/6KlS9oe+hGkT8Zv0Ckh+jZHT0HboJ0YC0THOWB5sHyKm3ASUu23vGctkij82lXhR0UKfQrTBMi8dIjhjNHsxLQ7xBfbeLh7L0sSFZLYMhwhevG/GDIqp96ZiSMMEyHNxqGsm/IM1zvYh6JV22kH2ibhGKdKaw6d24C9M7V2Im32TcZz/SJHl4KMWg1qs9J3CYESs294tlOJeWi5MsYEFQNIt+wvPJw6lOLbWuCZiT5mDGvM80si+liUGblhQtvCG/fnH9Y1+jTdGVVweukh6XpQv62dL97EX7MYMOY0RninDOdBUufhP5Zn4qd3K5AdeGHy+/tuxgpA9q//Nug3fE7EGhpzxkiV2YpB/n5pBn2oOV/dx/odhjn0IuhW0xaTVFBAqJV+Au+GQSF5/a65M/eJ6FmreHmL1pUlZ2vIATV5vw6zDxYC0ZhLqpoBqUHimfXYfM3DWtGeMDHPFb64AR1a0+l/DphshbQ9ZzQSl96DTefRdRQlcnQ8HE+gPN1E+UllUL6M69uVbyJdNBIPuwHpLi/ce7cbutdHZrMu2J/Ersq6EM93wwEKnYyhCg6/u0UwGEqorUQ3rHnnG9fELRke238TB23cH+Cv2RRs7R441HeqWxKCeHyIgRNsNxVhrWaRNeR3/Y8pbmO2yBu6vcQ9P3HPIDFu7fA== 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)(366004)(83380400001)(186003)(54906003)(66946007)(110136005)(9326002)(66446008)(86362001)(64756008)(166002)(55016003)(52536014)(8676002)(4326008)(76116006)(71200400001)(66556008)(66476007)(38100700002)(122000001)(8936002)(9686003)(38070700005)(5660300002)(316002)(33656002)(508600001)(82960400001)(26005)(7696005)(53546011)(2906002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?N0JMTjJvelNCQmh4cGFGbnVQMHBvWFRMUWhGcGxOMXJXTFAxQSt3djRWbGd1?= =?utf-8?B?V2REL3NjdFl4OWhzTHhpT3cwRGZoT2lhTzVtVkRJRDhETUxSbk50Ujc0QTdO?= =?utf-8?B?RU1BTGY5cjMzQVpGSTJvbE1LRWltQU5OZXdnWmVLQmM3NjZVTng1bi9Qb0tM?= =?utf-8?B?VXRvRjlQRU1jSlNUMmlIcFkrbnc1QjQwVEFKbTJKVnBrVGJnOURxeGU4dlIz?= =?utf-8?B?UTFpYkpWZFRIRWRRckVDN1Y2THJzVU5TeHBNTS83SjdiRVAxaWRHSVdtM2NQ?= =?utf-8?B?K3BWb2c4bjZPWFVKaDNCc2ZIWGt3NEltbjdpODlJV2ZhNWp0NmFHcTZlOGd0?= =?utf-8?B?U3FpSHlPNDdNWWtQLzRGYlBVanNOOUNzZ05uTlJYTmkrNHpsalBVKzV3Z01E?= =?utf-8?B?ZS8xbU8raVBpWHY1enlpYW9yeXR6aFZGT2hlOXptdkt5OVF0N3kvUzN2UkEy?= =?utf-8?B?ZEtra3dEQklEamxHRmJ6RmoyRXR0QzQvTDBhQWt2Rkw5akQ2WmMzTVVlSVFF?= =?utf-8?B?VGZpR0h4ZFBzVVJHN0pyUkdoYzhRRTZNNFo2ZHAxeEJzWm4wMWJKZUFlYlNh?= =?utf-8?B?R2lhM3V6dS9FUG1vMTdyc3lvczVFOVpmWUpVcUQ1b1htZGNMY0szQ0M1bkdh?= =?utf-8?B?dno0TmdNYUpvSFJYUUwrTWU3Q2hKdDNnMVFYeGhhOUtkSkw2dWZhYnhmeERX?= =?utf-8?B?OGtHV3FUcUI4NWhhQjhNTkZCNTdpVzY1OTgvVXFFY0ZlcjExUHB2V05zWUE3?= =?utf-8?B?bGRUZEpMSzYxWVZHM1hBTEZaNWtyUFZPNzVzY3FmOW0wVUtGUGxFUVdoaURo?= =?utf-8?B?QjNTOVh4dW52cUxyQlI3ZjkvU2V4SEZDT0N3OGtCY2pjekVjb3pSVVhmM1Ry?= =?utf-8?B?VG1QbXRYTVluR2tJZmtPc2lHbk1oZmNqQzFIeUc3c3ZIV2pkS3JkZm5ZbFBL?= =?utf-8?B?T0Y4eDYrcWkyaXhxaTZTRnNLNDFVU0ZuWk5JbWRBTlRDeXBmQXVoTTZWZVBC?= =?utf-8?B?a1ZLZlRXSiszSjNvSU5xVVhaeEM1NUJYZi9md0dMZGJXamQ3NFF2dVg2QUwx?= =?utf-8?B?WkpoTHAzbkNOKzRsSXRyaXgzWGx5cUpVajlrL211OEJMQ2JwaS9oSGpmZlNx?= =?utf-8?B?OEFrMExLMktObnZISklRTVNIc1VXa2xjSmZQcDlxZC9qN1orY0R6UmZtbXNW?= =?utf-8?B?UjJxVk5SYUI0aDh3M01ON1RGQUlmdllBckxRUnNORWY1QVhwa1UyWWd2WFRG?= =?utf-8?B?L2g1aU91Z0luUVVHakh6NEdhZUVuL3pmVzVZb3B4eURvcVlkVXVOLzlVTWVS?= =?utf-8?B?S3ZDNHprNkxYUmJVQmFoMlZheDBrQzdJSzZ5UUpQemF3bnJHOUlOSTZNSGMz?= =?utf-8?B?Rko0Ums4MGdzNkl6R0lqaFkrSHZSTXhxTG5pQnI2aDd1eEJENTRmWGU0UEpz?= =?utf-8?B?akpBM3dIT0RONnZ3TGtnTEdaV2ZFZWtmRFYzU253M3B4cDkxTjN3bU0xVUpB?= =?utf-8?B?NDladkJLRXJpNnZyNWdzUENmYnlJUGdSejFTN0ZWMlN1ZUVyZk5mQWxKcUxK?= =?utf-8?B?dnJRcWpVSlhBei82RFFwYWVFQ2kvVjJYQW5DSCtEMHdwMXdEVVpPYmhnbjg2?= =?utf-8?B?S09SMnhZZXRaazJENDRSTjJXYllidmgrc3lIUHVrbGo4VnUvdEN1TDZtZlE5?= =?utf-8?B?MU1URkI4SjZNYUJLTWxKdGdSbHQvRGlFRXA4b3Rvc3hvMkIvU3JRaDgveWFv?= =?utf-8?B?UVEyQ0RlVVVRaTI3TGVLaHlyTnRDdjZXQTA5MDF2SDlmZmdvZlpZa2czMkhC?= =?utf-8?B?Z00wOCtKdVl4TnRlM1VReGdiVTRYTk5ZaXVvdXo5WkF1SDFyU05wYnVYNTRl?= =?utf-8?B?dnJ2cWpCdUwrc2RXMzZFOWJmNEI0QVp4d1ptZDRoS1plRTZabXJiTyt6VDBz?= =?utf-8?B?RTNLZkZqdDlTUjhQaDA0QzVPeWROYWs0WERMYUpHejNhdmxoRFBTYkU3SHFa?= =?utf-8?B?WUtNODlBOUVnTmFlQlMreDhtL3pydTVTN1J5T044VUx1cGNsZ3hKR3EyZVcx?= =?utf-8?B?OU1XcmswM0hzRldpZXJER0dVZ1JpYjFsUmJkeW1vUzlZaGZ0QXF6SGNNV29l?= =?utf-8?B?cnBjaWg2Wk1kSWFCSnFrbTV3Y1NnOEdqM2wrNVZqTFFKYUNDNUtrdkh1OGpQ?= =?utf-8?B?RlE9PQ==?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084739CE43B26EF9CAD40EB9B6F9DM6PR08MB5084namp_" 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: f56f0d85-41a0-4e59-9e16-08d9ba9ae6f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2021 22:34:31.0690 (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: KRsyaPctjLUORHKLG/Q/t6YpfFgsWGk3HRr8Jz0CJZzjmhuVW/+BaaykJGqpQDQnwN0RdQRe5XvRx1RPa6HhHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5963 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 08 Dec 2021 22:34:42 -0000 --_000_DM6PR08MB5084739CE43B26EF9CAD40EB9B6F9DM6PR08MB5084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KSSdtIG5vdCBmb2xsb3dpbmcgeW91ciAiSW4gdGhlIG1lYW53aGlsZSIgdGhv dWdodHMuDQoNCkxlZ2FjeSBjbGllbnRzIGFyZSBmYWlsaW5nIG9mZmxpbmUgdmFsaWRhdGlvbiB0 b2RheS4gSWYgcnVubmluZyBjb25maWcgaGFzIGEgbGVhZnJlZiB0byBzeXN0ZW0gY29uZmlnLCBh bmQgPGdldC1jb25maWc+IGRvZXNuJ3QgcmV0dXJuIHRoYXQgc3lzdGVtIGNvbmZpZyAod2hpY2gg aXQgZG9lc24ndCBpbiBzb21lIGltcGxlbWVudGF0aW9ucyksIHRoZW4gdGhlIGluc3RhbmNlIGRh dGEgcmV0dXJuZWQgdG8gdGhlIGNsaWVudCBkb2Vzbid0IHZhbGlkYXRlIGFnYWluc3QgdGhlIFlB TkcgbW9kZWwuICBUaGVzZSBpbXBsZW1lbnRhdGlvbnMgZG9uJ3QgaGF2ZSBhbiBleHBsaWNpdCA8 c3lzdGVtPiBkYXRhc3RvcmUgdG9kYXkgKGJ1dCB0aGV5IGRvIGhhdmUgdGhlc2UgaW50ZXJuYWwg c2VtaS1oaWRkZW4gcmVmZXJlbmNlYWJsZSBsaXN0IGVudHJpZXMpLg0KDQpKYXNvbg0KDQpGcm9t OiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgS2VudCBXYXRz ZW4NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjksIDIwMjEgNTowOSBQTQ0KVG86IEphbiBMaW5k YmxhZCA8amFubEB0YWlsLWYuY29tPg0KQ2M6IG1hcWl1ZmFuZyAoQSkgPG1hcWl1ZmFuZzE9NDBo dWF3ZWkuY29tQGRtYXJjLmlldGYub3JnPjsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W25ldG1vZF0gTXVzdCBvZmZsaW5lLXZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+IGFsb25lIGJlIHZh bGlkPw0KDQoNCg0KSGkgSmFuLA0KDQoNCk9uIE5vdiAyMywgMjAyMSwgYXQgMTI6NTYgUE0sIEph biBMaW5kYmxhZCA8amFubEB0YWlsLWYuY29tPG1haWx0bzpqYW5sQHRhaWwtZi5jb20+PiB3cm90 ZToNCg0KU2VyZ2lvLCBRaXVmYW5nLA0KDQpIaSBKYW4sDQpZb3UgY29ycmVjdGx5IHdyb3RlOg0K DQpUaGVuIHRoZSBjaG9pY2VzIGJlY29tZToNCg0KICAgICAqICAgT2ZmbGluZSB2YWxpZGF0aW9u IG9mIDxydW5uaW5nPiBhbG9uZSBpcyBOT1QgcmVxdWlyZWQNCg0KICAgICAgICAqICAgU2VydmVy cyBpbnRlcm5hbGx5IHZhbGlkYXRlIDxydW5uaW5nPiB2aWEgdmFsaWRhdGluZyA8aW50ZW5kZWQ+ DQogICAgICAgICoNClNCPiBidXQgaW4gZmFjdCB0aGlzIGlzIHdoYXQgZGVjbGFyZWQsIGZvciBt eSB1bmRlcnN0YW5kaW5nLCBpbiBSRkMgODM0MiwgZm9yIHdoaWNoIOKAnHZhbGlkYXRpb27igJ0g aXMgZG9uZSBvbiDigJxpbnRlbmRlZOKAnSBieSB0aGUgc2VydmVyICwgYXMgYWxzbyBzaG93biBp biBmaWd1cmUgMiBvZiB0aGUgUkZDLiBJcyBpdCBuZWVkZWQgdG8gY2hhbmdlIGFsc28gUkZDPw0K DQpBY2NvcmRpbmcgdG8gUkZDIDgzNDIsICpib3RoKiBydW5uaW5nIGFuZCBpbnRlbmRlZCBoYXZl IHRvIGJlIHZhbGlkIGF0IGFsbCB0aW1lcy4gU2VjdGlvbiA1LjEuMyBzYXlzOg0KDQoNCjUuMS4z PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODM0MiNzZWN0aW9uLTUu MS4zPi4gIFRoZSBSdW5uaW5nIENvbmZpZ3VyYXRpb24gRGF0YXN0b3JlICg8cnVubmluZz4pDQoN Ci4uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBIb3dldmVyLA0KDQogICA8cnVubmluZz4gTVVTVCBhbHdheXMgYmUgYSB2YWxpZCBj b25maWd1cmF0aW9uIGRhdGEgdHJlZSwgYXMgZGVmaW5lZA0KDQogICBpbiBTZWN0aW9uIDguMSBv ZiBbUkZDNzk1MF08aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM3OTUw I3NlY3Rpb24tOC4xPi4NCg0KU2VjdGlvbiA4LjEgb2YgUkZDIDc5NTAgd2FzIHRoZSBzZWN0aW9u IEkgcmVmZXJyZWQgdG8gaW4gbXkgcHJldmlvdXMgY29tbWVudC4gU2VjdGlvbiA1LjEuNCBzYXlz Og0KDQoNCjUuMS40PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODM0 MiNzZWN0aW9uLTUuMS40Pi4gIFRoZSBJbnRlbmRlZCBDb25maWd1cmF0aW9uIERhdGFzdG9yZSAo PGludGVuZGVkPikNCg0KLi4uDQoNCiAgIDxpbnRlbmRlZD4gaXMgdGlnaHRseSBjb3VwbGVkIHRv IDxydW5uaW5nPi4gIFdoZW5ldmVyIGRhdGEgaXMgd3JpdHRlbg0KDQogICB0byA8cnVubmluZz4s IHRoZSBzZXJ2ZXIgTVVTVCBhbHNvIGltbWVkaWF0ZWx5IHVwZGF0ZSBhbmQgdmFsaWRhdGUNCg0K ICAgPGludGVuZGVkPi4NCg0KSW4gbXkganVkZ2VtZW50LCBjaGFuZ2luZyB0aGUgZnVuZGFtZW50 cyBvZiBSRkMgNzk1MCBhbmQgODM0MiBpcyBub3QgZ29pbmcgdG8gaGFwcGVuIGFueSB0aW1lIHNv b24gKGZvciBnb29kIHJlYXNvbiksIGFuZCB0aGVyZSBhcmUgb3RoZXIgKGJldHRlcikgb3B0aW9u cy4NCg0KDQogICAgICogICBPZmZsaW5lIHZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+IGFsb25lIElT IHJlcXVpcmVkDQoNCiAgICAgICAgKiAgIE9wdGlvbnM6DQoNCiAgICAgICAgICAgKiAgIENsaWVu dHMgTVVTVCBjb3B5L3Bhc3RlIGFueSByZWZlcmVuY2VkIHN5c3RlbSBjb25maWd1cmF0aW9uIGlu dG8gPHJ1bm5pbmc+LCBldmVuIHRob3VnaCBpdCBnb2VzIGFnYWluc3Qgb3VyIG9iamVjdGl2ZSBv ZiBhdm9pZGluZy1jb3B5IHdoZW4gcG9zc2libGUuDQogICAgICAgICAgICogICBEZWZlciB3b3Jr IHRvIGJlIGEgWUFORy1uZXh0IGVmZm9ydC4NCg0KSW4gb3JkZXIgdG8gbW92ZSBmb3J3YXJkLCBJ IHdvdWxkIHByb3Bvc2Ugd29ya2luZyBvdXQgc29tZSBtb3JlIG9wdGlvbnMgaW4gdGhpcyBsaXN0 LiBJIGhhdmUgc3VnZ2VzdGVkIGEgZmV3IHRvIHRoZSBhdXRob3JzIHRoYXQgSSB0aGluayBhcmUg YmV0dGVyIHRoYW4gdGhlIHR3byBhYm92ZSwgYnV0IEkgd2lsbCBsZWF2ZSBpdCB0byB0aGUgYXV0 aG9ycyBtYWtlIHRoZSBjYWxsIGZvciB3aGF0IHRoZXkgd2FudCB0byBicmluZyB1cCBmb3IgZGlz Y3Vzc2lvbi4NCg0KDQoNCkkgZG9u4oCZdCB0aGluayB0aGUgY2FzZSBoYXMgYmVlbiBtYWRlIHRo YXQgKm9mZmxpbmUqIHZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+IGJ5IGl0c2VsZiBtdXN0IGJlIHZh bGlkLiAgWWVzLCAqb25saW5lKiA8cnVubmluZz4gbXVzdCBiZSB2YWxpZCwgYXMgbXVzdCA8aW50 ZW5kZWQ+LCB3aXRoIHRoZSBpbnRlbnRpb24gb2YgUkZDIDgzNDIgYmVpbmcgdGhhdCBib3RoIGFy ZSB2YWxpZGF0ZWQgaW4gb25lIGFuZCB0aGUgc2FtZSBvcGVyYXRpb24gYnkgdGhlIHNlcnZlciAg KGtub3duIHRvIG1lIGFzIGFuIGF1dGhvciBvZiBSRkMgODM0MikuICBJIHVuZGVyc3RhbmQgdGhh dCBpbXBsZW1lbnRhdGlvbnMgbWF5IGhhdmUgYXNzdW1lZCBvZmZsaW5lIHZhbGlkYXRpb24gb2Yg PHJ1bm5pbmc+IG11c3QgYmUgdmFsaWQsIEkganVzdCBjYW7igJl0IGZpbmQgdGhlIFJGQyByZWZl cmVuY2UgdGhhdCBkZW1hbmRzIGl0IGJlIHN1cHBvcnRlZCwgYW5kIHdpdGhvdXQgc3VjaCByZWZl cmVuY2UsIGl0IGZhbGxzIGludG8gYW4gdW5kZWZpbmVkIGFyZWEuICBOZWNlc3NpdGF0aW5nIG9m ZmxpbmUgdmFsaWRhdGlvbiBvZiA8cnVubmluZz4sIGlmIHRoYXQgaXMgd2hhdCB0aGUgV0cgZGVj aWRlcywgcmVzdWx0cyBpbiBzb2x1dGlvbnMgZm9yIHdoaWNoIG5vbmUgc2VlbSBuaWNlIHRvIG1l LCBhdCBsZWFzdCBJIGhhdmVu4oCZdCBzZWVuIGFueSB5ZXQuICBQbGVhc2Ugc2hhcmUgYW55IOKA nGJldHRlciBvcHRpb25z4oCdIHlvdSBoYXZlIGluIG1pbmQuDQoNCkluIHRoZSBtZWFud2hpbGUs IGNhbiB3ZSBkaXNjdXNzIHRoZSBpc3N1ZXMgYXJvdW5kIGEgbGVnYWN5IGNsaWVudCBmYWlsaW5n IGFuIG9mZmxpbmUgdmFsaWRhdGlvbj8gIEluIHRoaXMgY2FzZSwgYSBwcm9kdWN0aW9uIGRlcGxv eW1lbnQgbXVzdCBoYXZlIDEpIGRlcGxveWVkIGRldmljZXMgdGhhdCBzdXBwb3J0IDxzeXN0ZW0+ LCAyKSBkZXBsb3llZCBhdCBsZWFzdCBvbmUgY2xpZW50IHRoYXQgc3VwcG9ydHMgPHN5c3RlbT4s IGFuZCAzKSBkZWNpZGVkIHRvIGxldCBjbGllbnRzIHN0YXJ0IHB1c2hpbmcgY29uZmlnIHVzaW5n IDxzeXN0ZW0+LiAgIFdoaWxlIGluIHRoZSBwcmUtcHJvZHVjdGlvbiB0ZXN0aW5nIHBoYXNlLCBp dCB3b3VsZCBiZSBxdWlja2x5IGRpc2NvdmVyZWQgdGhhdCBhbGwgbGVnYWN5IGNsaWVudHMgbmVl ZCB0byBiZSB1cGRhdGVkLiAgQnkgdGhlIHRpbWUgb2YgZ29pbmcgdG8gcHJvZHVjdGlvbiwgdGhl IGRlcGxveW1lbnQgc2hvdWxkIGhhdmUgYWxsIHRoZSBjbGllbnRzIHVwZGF0ZWQsIHNvIGl0IHNl ZW1zIHRoYXQgb25seSB0aGUgZm9yZ290dGVuIChyZWxhdGl2ZWx5IGluc2lnbmlmaWNhbnQpIGNs aWVudHMgbWlnaHQgaGF2ZSBhbiBvZmZsaW5lIHZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+IGZhaWx1 cmUuICBJcyB0aGlzIGEgZmFpciBhc3Nlc3NtZW50Pw0KDQpLZW50IC8vIGFzIGEgY29udHJpYnV0 b3INCg0KDQo= --_000_DM6PR08MB5084739CE43B26EF9CAD40EB9B6F9DM6PR08MB5084namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uaDQNCgl7bXNvLXN0eWxlLW5hbWU6aDQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6NTMwMDczNTkxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NzI1OTM2Nzg7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxp c3QtaWQ6MTM1MDUyNzQxOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTUxNzY5MjIwNDt9DQpA bGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEtlbnQsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkknbSBub3QgZm9s bG93aW5nIHlvdXIgJnF1b3Q7SW4gdGhlIG1lYW53aGlsZSZxdW90OyB0aG91Z2h0cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ TGVnYWN5IGNsaWVudHMgYXJlIGZhaWxpbmcgb2ZmbGluZSB2YWxpZGF0aW9uIHRvZGF5LiBJZiBy dW5uaW5nIGNvbmZpZyBoYXMgYSBsZWFmcmVmIHRvIHN5c3RlbSBjb25maWcsIGFuZCAmbHQ7Z2V0 LWNvbmZpZyZndDsgZG9lc24ndCByZXR1cm4gdGhhdCBzeXN0ZW0gY29uZmlnICh3aGljaCBpdCBk b2Vzbid0IGluIHNvbWUgaW1wbGVtZW50YXRpb25zKSwNCiB0aGVuIHRoZSBpbnN0YW5jZSBkYXRh IHJldHVybmVkIHRvIHRoZSBjbGllbnQgZG9lc24ndCB2YWxpZGF0ZSBhZ2FpbnN0IHRoZSBZQU5H IG1vZGVsLiZuYnNwOyBUaGVzZSBpbXBsZW1lbnRhdGlvbnMgZG9uJ3QgaGF2ZSBhbiBleHBsaWNp dCAmbHQ7c3lzdGVtJmd0OyBkYXRhc3RvcmUgdG9kYXkgKGJ1dCB0aGV5IGRvIGhhdmUgdGhlc2Ug aW50ZXJuYWwgc2VtaS1oaWRkZW4gcmVmZXJlbmNlYWJsZSBsaXN0IGVudHJpZXMpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5K YXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbmV0bW9kICZsdDtuZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+S2VudCBXYXRzZW48YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAyOSwgMjAyMSA1OjA5IFBNPGJyPg0KPGI+VG86PC9iPiBK YW4gTGluZGJsYWQgJmx0O2phbmxAdGFpbC1mLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG1hcWl1 ZmFuZyAoQSkgJmx0O21hcWl1ZmFuZzE9NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnJmd0Ozsg bmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBNdXN0IG9m ZmxpbmUtdmFsaWRhdGlvbiBvZiAmbHQ7cnVubmluZyZndDsgYWxvbmUgYmUgdmFsaWQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBK YW4sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAyMywgMjAyMSwgYXQgMTI6NTYgUE0sIEphbiBMaW5k YmxhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbmxAdGFpbC1mLmNvbSI+amFubEB0YWlsLWYuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TZXJnaW8sJm5ic3A7UWl1ZmFuZyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEphbiw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBjb3JyZWN0bHkgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+VGhlbiB0aGUgY2hvaWNlcyBiZWNvbWU6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjx1 bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMiBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi Pk9mZmxpbmUgdmFsaWRhdGlvbiBvZiAmbHQ7cnVubmluZyZndDsgYWxvbmUgaXMgTk9UIHJlcXVp cmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjx1bCBzdHlsZT0ibWFyZ2lu LXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0i Y2lyY2xlIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9InNxdWFyZSI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMyBsZm8xIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPlNlcnZlcnMgaW50ZXJuYWxseSB2YWxpZGF0ZSAmbHQ7cnVubmluZyZndDsg dmlhIHZhbGlkYXRpbmcgJmx0O2ludGVuZGVkJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDMgbGZvMSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0K PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlNC Jmd0OyBidXQgaW4gZmFjdCB0aGlzIGlzIHdoYXQgZGVjbGFyZWQsIGZvciBteSB1bmRlcnN0YW5k aW5nLCBpbiBSRkMgODM0MiwgZm9yIHdoaWNoIOKAnHZhbGlkYXRpb27igJ0gaXMgZG9uZSBvbiDi gJxpbnRlbmRlZOKAnSBieSB0aGUgc2VydmVyICwgYXMgYWxzbyBzaG93biBpbiBmaWd1cmUgMiBv ZiB0aGUgUkZDLg0KIElzIGl0IG5lZWRlZCB0byBjaGFuZ2UgYWxzbyBSRkM/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFjY29yZGluZyB0byBSRkMgODM0MiwgKmJvdGgqIHJ1bm5pbmcgYW5k IGludGVuZGVkIGhhdmUgdG8gYmUgdmFsaWQgYXQgYWxsIHRpbWVzLiBTZWN0aW9uIDUuMS4zIHNh eXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJl Zm9yZTogcGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7b3JwaGFuczogMjt3aWRv d3M6IDI7dGV4dC1kZWNvcmF0aW9uLXRoaWNrbmVzczogaW5pdGlhbCI+PHNwYW4gY2xhc3M9Img0 Ij48Yj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzgz NDIjc2VjdGlvbi01LjEuMyI+NS4xLjM8L2E+LiZuYnNwOyBUaGUgUnVubmluZyBDb25maWd1cmF0 aW9uIERhdGFzdG9yZSAoJmx0O3J1bm5pbmcmZ3Q7KTwvYj48L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJoNCI+PGI+Li4u PC9iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBz dHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtv cnBoYW5zOiAyO3dpZG93czogMjt0ZXh0LWRlY29yYXRpb24tdGhpY2tuZXNzOiBpbml0aWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSG93ZXZl ciw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgJmx0O3J1bm5pbmcmZ3Q7IE1V U1QgYWx3YXlzIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBkYXRhIHRyZWUsIGFzIGRlZmluZWQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW4gPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM3OTUwI3NlY3Rpb24tOC4xIj5TZWN0aW9u Jm5ic3A7OC4xIG9mIFtSRkM3OTUwXTwvYT4uPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gOC4xIG9mIFJGQyA3OTUwIHdhcyB0aGUgc2VjdGlv biBJIHJlZmVycmVkIHRvIGluIG15IHByZXZpb3VzIGNvbW1lbnQuIFNlY3Rpb24gNS4xLjQgc2F5 czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVm b3JlOiBwYWdlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtvcnBoYW5zOiAyO3dpZG93 czogMjt0ZXh0LWRlY29yYXRpb24tdGhpY2tuZXNzOiBpbml0aWFsIj48c3BhbiBjbGFzcz0iaDQi PjxiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODM0 MiNzZWN0aW9uLTUuMS40Ij41LjEuNDwvYT4uJm5ic3A7IFRoZSBJbnRlbmRlZCBDb25maWd1cmF0 aW9uIERhdGFzdG9yZSAoJmx0O2ludGVuZGVkJmd0Oyk8L2I+PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJo NCI+PGI+Li4uPC9iPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUg c3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7 b3JwaGFuczogMjt3aWRvd3M6IDI7dGV4dC1kZWNvcmF0aW9uLXRoaWNrbmVzczogaW5pdGlhbCI+ Jm5ic3A7Jm5ic3A7ICZsdDtpbnRlbmRlZCZndDsgaXMgdGlnaHRseSBjb3VwbGVkIHRvICZsdDty dW5uaW5nJmd0Oy4mbmJzcDsgV2hlbmV2ZXIgZGF0YSBpcyB3cml0dGVuPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRvICZsdDtydW5uaW5nJmd0OywgdGhlIHNlcnZlciBNVVNU IGFsc28gaW1tZWRpYXRlbHkgdXBkYXRlIGFuZCB2YWxpZGF0ZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyAmbHQ7aW50ZW5kZWQmZ3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIG15IGp1ZGdlbWVudCwgY2hhbmdpbmcgdGhlIGZ1bmRhbWVudHMgb2YgUkZDIDc5NTAg YW5kIDgzNDIgaXMgbm90IGdvaW5nIHRvIGhhcHBlbiBhbnkgdGltZSBzb29uIChmb3IgZ29vZCBy ZWFzb24pLCBhbmQgdGhlcmUgYXJlIG90aGVyIChiZXR0ZXIpIG9wdGlvbnMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj5PZmZsaW5lIHZhbGlkYXRpb24gb2YgJmx0O3J1bm5pbmcmZ3Q7IGFsb25lIElTIHJlcXVp cmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjx1bCBzdHlsZT0ibWFyZ2lu LXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0i Y2lyY2xlIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9InNxdWFyZSI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMyBsZm8yIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPk9wdGlvbnM6PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4N CjwvdWw+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjx1bCBzdHls ZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImNpcmNsZSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGNtIiB0eXBlPSJzcXVhcmUiPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9IjEi IHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZl bDQgbGZvMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5DbGllbnRzIE1VU1QgY29weS9wYXN0ZSBhbnkg cmVmZXJlbmNlZCBzeXN0ZW0gY29uZmlndXJhdGlvbiBpbnRvJm5ic3A7Jmx0O3J1bm5pbmcmZ3Q7 LCBldmVuIHRob3VnaCBpdCBnb2VzIGFnYWluc3Qgb3VyIG9iamVjdGl2ZSBvZiBhdm9pZGluZy1j b3B5IHdoZW4mbmJzcDtwb3NzaWJsZS48L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWw0IGxmbzIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+RGVmZXIgd29yayB0byBiZSBhIFlBTkctbmV4dCBlZmZvcnQuPC9zcGFuPjxvOnA+PC9v OnA+PC9saT48L29sPg0KPC91bD4NCjwvdWw+DQo8L3VsPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gb3JkZXIgdG8gbW92ZSBmb3J3YXJkLCBJIHdvdWxk IHByb3Bvc2Ugd29ya2luZyBvdXQgc29tZSBtb3JlIG9wdGlvbnMgaW4gdGhpcyBsaXN0LiBJIGhh dmUgc3VnZ2VzdGVkIGEgZmV3IHRvIHRoZSBhdXRob3JzIHRoYXQgSSB0aGluayBhcmUgYmV0dGVy IHRoYW4gdGhlIHR3byBhYm92ZSwgYnV0IEkgd2lsbCBsZWF2ZSBpdCB0byB0aGUgYXV0aG9ycyBt YWtlIHRoZSBjYWxsIGZvciB3aGF0IHRoZXkgd2FudA0KIHRvIGJyaW5nIHVwIGZvciBkaXNjdXNz aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBkb27igJl0IHRoaW5rIHRoZSBjYXNlIGhh cyBiZWVuIG1hZGUgdGhhdCAqb2ZmbGluZSogdmFsaWRhdGlvbiBvZiAmbHQ7cnVubmluZyZndDsg YnkgaXRzZWxmIG11c3QgYmUgdmFsaWQuICZuYnNwO1llcywgKm9ubGluZSogJmx0O3J1bm5pbmcm Z3Q7IG11c3QgYmUgdmFsaWQsIGFzIG11c3QgJmx0O2ludGVuZGVkJmd0Oywgd2l0aCB0aGUgaW50 ZW50aW9uIG9mIFJGQyA4MzQyIGJlaW5nIHRoYXQgYm90aCBhcmUNCiB2YWxpZGF0ZWQgaW4gb25l IGFuZCB0aGUgc2FtZSBvcGVyYXRpb24gYnkgdGhlIHNlcnZlciAmbmJzcDsoa25vd24gdG8gbWUg YXMgYW4gYXV0aG9yIG9mIFJGQyA4MzQyKS4gJm5ic3A7SSB1bmRlcnN0YW5kIHRoYXQgaW1wbGVt ZW50YXRpb25zIG1heSBoYXZlIGFzc3VtZWQgb2ZmbGluZSB2YWxpZGF0aW9uIG9mICZsdDtydW5u aW5nJmd0OyBtdXN0IGJlIHZhbGlkLCBJIGp1c3QgY2Fu4oCZdCBmaW5kIHRoZSBSRkMgcmVmZXJl bmNlIHRoYXQgZGVtYW5kcyBpdCBiZSBzdXBwb3J0ZWQsDQogYW5kIHdpdGhvdXQgc3VjaCByZWZl cmVuY2UsIGl0IGZhbGxzIGludG8gYW4gdW5kZWZpbmVkIGFyZWEuICZuYnNwO05lY2Vzc2l0YXRp bmcgb2ZmbGluZSB2YWxpZGF0aW9uIG9mICZsdDtydW5uaW5nJmd0OywgaWYgdGhhdCBpcyB3aGF0 IHRoZSBXRyBkZWNpZGVzLCByZXN1bHRzIGluIHNvbHV0aW9ucyBmb3Igd2hpY2ggbm9uZSBzZWVt IG5pY2UgdG8gbWUsIGF0IGxlYXN0IEkgaGF2ZW7igJl0IHNlZW4gYW55IHlldC4gJm5ic3A7UGxl YXNlIHNoYXJlIGFueSDigJxiZXR0ZXIgb3B0aW9uc+KAnQ0KIHlvdSBoYXZlIGluIG1pbmQuICZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5JbiB0aGUgbWVhbndoaWxlLCBjYW4gd2UgZGlzY3VzcyB0aGUgaXNzdWVzIGFy b3VuZCBhIGxlZ2FjeSBjbGllbnQgZmFpbGluZyBhbiBvZmZsaW5lIHZhbGlkYXRpb24/ICZuYnNw O0luIHRoaXMgY2FzZSwgYSBwcm9kdWN0aW9uIGRlcGxveW1lbnQgbXVzdCBoYXZlIDEpIGRlcGxv eWVkIGRldmljZXMgdGhhdCBzdXBwb3J0ICZsdDtzeXN0ZW0mZ3Q7LCAyKSBkZXBsb3llZCBhdCBs ZWFzdA0KIG9uZSBjbGllbnQgdGhhdCBzdXBwb3J0cyAmbHQ7c3lzdGVtJmd0OywgYW5kIDMpIGRl Y2lkZWQgdG8gbGV0IGNsaWVudHMgc3RhcnQgcHVzaGluZyBjb25maWcgdXNpbmcgJmx0O3N5c3Rl bSZndDsuICZuYnNwOyBXaGlsZSBpbiB0aGUgcHJlLXByb2R1Y3Rpb24gdGVzdGluZyBwaGFzZSwg aXQgd291bGQgYmUgcXVpY2tseSBkaXNjb3ZlcmVkIHRoYXQgYWxsIGxlZ2FjeSBjbGllbnRzIG5l ZWQgdG8gYmUgdXBkYXRlZC4gJm5ic3A7QnkgdGhlIHRpbWUgb2YgZ29pbmcgdG8gcHJvZHVjdGlv biwNCiB0aGUgZGVwbG95bWVudCBzaG91bGQgaGF2ZSBhbGwgdGhlIGNsaWVudHMgdXBkYXRlZCwg c28gaXQgc2VlbXMgdGhhdCBvbmx5IHRoZSBmb3Jnb3R0ZW4gKHJlbGF0aXZlbHkgaW5zaWduaWZp Y2FudCkgY2xpZW50cyBtaWdodCBoYXZlIGFuIG9mZmxpbmUgdmFsaWRhdGlvbiBvZiAmbHQ7cnVu bmluZyZndDsgZmFpbHVyZS4gJm5ic3A7SXMgdGhpcyBhIGZhaXIgYXNzZXNzbWVudD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ S2VudCAvLyBhcyBhIGNvbnRyaWJ1dG9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_DM6PR08MB5084739CE43B26EF9CAD40EB9B6F9DM6PR08MB5084namp_-- From nobody Wed Dec 8 14:42: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 5F49B3A07B5 for ; Wed, 8 Dec 2021 14:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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=unavailable 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 P0j22G2gxPE3 for ; Wed, 8 Dec 2021 14:42:28 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2120.outbound.protection.outlook.com [40.107.223.120]) (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 06EB13A07B6 for ; Wed, 8 Dec 2021 14:42:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AYK3uA2wX07/yMjh7E0IIeobR87hnnQ4aOF+swhCttfItNQVMviVkr0Qt29YR85VkkTk9wH6mVWFRD3XQ1GnfawMh/Yx8+kADRbRdVU4Dk8c/bczBrTNSMNEb9F+LG2CUh3lwcTTiVDsmnm93N9rYOygQdtzP4H8QzVLlnbeOcahnScQRg9ToKWhC9L1d9VpO4BDyM1KxGJKUT7SnZHR+/MjLAagv8CwwPOu00+jB29OFA6opQzvtMAO+VKp2XlTH/xXQI4RXACCPBD6InfRAiPDY/fYDwwXJkm5Epmh/ie7mpklYIbc3ZPU10k1cghhkrpA7ViqgVTJcop1G9NfZw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tC6k5U+gNv2ugqTQBjkiIgebITpW07Ns2lBmCgJj5Bk=; b=gs2ACGGpdSz0a5zAU4TpX1bT/qZjkWKvFgvJ9iDcQ6JPzoTkVgtY/ifkBYKSKW1MXayGYTiENN5MxLlmQ4msaqvaPvYT9vhqbc555a21WuoDm6bkjQCOGV3yS02XUnjqR0iJxbRCM0dbeV2WRWLwUxEVbz6Jkhfb53md6eZPAkFLa+kbOyx5/eZkmbE5T2oiRPeSuxNYiK8CasXlRZKh/yZQKJC3bqkK/F8qllWqqu6o/yF3oTYMq0dNP3bGFXajnirbxc2Tjbf5JiBEEesY8sFZiwkob//6WiVNJAqkErkL9s33neBkQrFHaU4D3pPPYYsRIecrEMqadfzdk8qvUw== 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=tC6k5U+gNv2ugqTQBjkiIgebITpW07Ns2lBmCgJj5Bk=; b=KixXZGFao1wDy3NavPGYVDP57HSFGT0xWiEaEE1gq/6sucI/AV5NF0oIfmeNgFiV3Nv8IR8U9hP1oZk6Nbo/pXcSuVxjUUEaZVPdI/O6+kudgL6S7e7pP6CAQVJprqGCVtU/wSrqIrm5Qf0bmN/AmBWVchuhXscPBFgCueBuVMw= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB2858.namprd08.prod.outlook.com (2603:10b6:3:145::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Wed, 8 Dec 2021 22:42:25 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.022; Wed, 8 Dec 2021 22:42:25 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "maqiufang (A)" , "netmod@ietf.org" Thread-Topic: [netmod] "immutable" flag Thread-Index: AdffmIO2eQWZH1bVQgKuM6kNhPhaAAM61mjg Date: Wed, 8 Dec 2021 22:42:25 +0000 Message-ID: References: <79459f02f6ea4a87bea56edc9772daa6@huawei.com> In-Reply-To: <79459f02f6ea4a87bea56edc9772daa6@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6bbb0498-166d-4afc-3070-08d9ba9c0195 x-ms-traffictypediagnostic: DM5PR08MB2858:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8+MUKk8rwbXYI59BT37LoRtJ5+yY//ajIFAk/8JLWZ931UNDCnJOuokhkCcAs/6lxJeYjUb0og8xj7r6UGzyci+V6cUR6AfR0a9y6WFckUvjOkP6Zr180aRv7ghJ2oddvk+2PwvXosiEJfXZKG/IzvSXzHAsUnVaQtzF9LOcSHHJEYyQubZQE6hC1a4TD7WQihUpyV6t1vgaeIkTp3cvbGrBBMNlnMEWFG00ruh7yEoEEZk3VT+NpMw4S6H3PtyA60PD1+LMitZT5j4wiBhQndCXG7T26+2FOoLn2EYlljZj4gP/cmVl/6rfXSReVYk+KKz/5qHPh9n/ni3NpMRG54dTGCt29OUZlOCdRfgjLvzwZfprZrccpPwn7k6PFWlQR0qOtD35IIgVvnjxaHB5Aj98GxjYnR/B/g+N6PRoOJItRnZ/gxaCzht4ol3m+/p+0vccIseRe3GLjVBQqapb4k5WyshAKPq18G1AxwcUHsNX74KpoVXC/o5QI0MP7IOQnNEsdxsvqOV11rhZySTGlBWFAcA+BWcRvUZMPgQjShLp9aoirWvbp2p3NtTP+vPF+UQXu+ESSwZ2qDcwFJztyEvNsFJzpjeqKkz/yeydSrfhvEV6jo5Ws6jlO7rsxmAX47iB8Xq9C9aTXtBfXuoeCanZJnnj0llIR7G/jmA0Lfdh8SorafdWLG0+LxO4CNUs0iXk7vxjURt6tW4hHojwqQ== 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)(366004)(9326002)(66446008)(86362001)(64756008)(76116006)(71200400001)(66476007)(66946007)(186003)(8676002)(52536014)(66556008)(8936002)(33656002)(38100700002)(82960400001)(55016003)(316002)(110136005)(508600001)(122000001)(2906002)(26005)(7696005)(6506007)(53546011)(9686003)(38070700005)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?6tWoSj48o1YJ09KAyx8rDpHQS+mCZiYtovVnZGktomIb5nu3Al7pMLJKwRNR?= =?us-ascii?Q?FZEjyiA1d+8n9Ozvwh0ZruBegRCMiWJDMqS3Ld6k64Z48DI6lzwSuUx41/ZM?= =?us-ascii?Q?A6SgD2UR6K8sB9kLZol7nh09PqinhFVLjOkp/R3IgaKeYuL4gphRmx8t1HOX?= =?us-ascii?Q?m90leF6z5n6bqTE5bC0iYqnWkoS0OpL2aSdYvVoZyx3SsIv3DyKHjdC2So1q?= =?us-ascii?Q?MX7EODB1T079LjrCKZR1owzbS/I/xr2cummtRJO5MqGmR40kbxIAAFHD40og?= =?us-ascii?Q?po2idOJcFYl3hoiRSNlaSxDNC3HxXdySWbkXcvaiZU8TPBFBlWs4gmjMApwR?= =?us-ascii?Q?J/n4ueNTx+WY/aJf0MEleHsi7Efxo3WglWDjkdT9OcpFGTAuhXAymvP7l0/5?= =?us-ascii?Q?4h9Y9AyfA6STx72762aZEyctV+B7GGbQL774IG4oTd2wAICLEQTYs6XgHTDI?= =?us-ascii?Q?doF3hBAbx/gYjA97QbCIYDzhjUgSWqWpmEe0s7CG5nnzIX/kuZzhc325frrd?= =?us-ascii?Q?wME3ZsvFw3734AnfIUXpjAna6OpdHIZqXNLWrWyxNmrmFKphAiM7U8Sg31S2?= =?us-ascii?Q?0L0wWx3mRdtZ+SwXvreAWApw+oQAKnf5RJQozpzTxidQrj9P11ZhT9j+VYyn?= =?us-ascii?Q?60+VwIkyoN8e9c9bQKbbZIunzt/gHSNrwgoORhicwrJoBoQhzpfUC0JsJmxQ?= =?us-ascii?Q?drvSdcU49dHUl2nB5JUwnHdiwURYHZqiSpumTsC6RstYjEedBENJC/pJycec?= =?us-ascii?Q?aIWePvL3jgBjaxqfWjX9qSAtfXSGHLUiUlPPxK7sg/CUj27KPnX9DdH4HviM?= =?us-ascii?Q?uLKz5xqKCRNCqEIp5p1Kpr89Ji/W600gQEN4+WTvaAWK2u5rkBplo1VUCAOm?= =?us-ascii?Q?wJvX9+ehuJWZ3qhVA80k6camt+Yr847rQc1R1U3j7dl3Orrz3zAZ7qAXCznh?= =?us-ascii?Q?CMHJtzG7MzrTRYcGSrux21JeRfvHqIVrJPMtMBZED4D46VtlwgFJXRGZfA3s?= =?us-ascii?Q?kSBrfohq1imwhEi+lIcerKvxsmd2Q/Js095/PiWtGpTWrj7N1EjgV/OT6mv/?= =?us-ascii?Q?BiFO17Kc1mjAC4toaULsf8lkEpfNNNCLb1cWO9LT8tx5Hv7SdpWXkQMu4e9L?= =?us-ascii?Q?8UyEZWsL70pB8N+lJm/T1NhqnlNouE/LVPwdY7FeYeP6FKtMxDbUsULrI7XN?= =?us-ascii?Q?Jr3u6cBd6XrKFoOoRPQOLpwCPkn6ELEFZwBUn53fN2KF4Wm4YaYnFIX3fghe?= =?us-ascii?Q?clivFljF2pL1Y17D1N2MMmrdVBWnZwTkhI28defQcnrnMrYVNEU50tmQGGuk?= =?us-ascii?Q?diTYFFPXBBlPu3n34YlqxM5s0TJCY8K6w/2sMYSbeeJ8acMVIOiO878TNuBz?= =?us-ascii?Q?6UX3rRWEp+comthvq2d50z1dcySTxV7nQI+elB+oQJp8RCTDHWDrn07in1oD?= =?us-ascii?Q?kIthFB9YzcQeHvqfCZueVEjLpK3JsATQ7r9kf+02BAeJI2bdZnbWBAp/kAqA?= =?us-ascii?Q?MEVdgBDby1RyAOoAWnmXJiyV38oJXhWxVlx0FHGVXkfGLOl1XQpUVBgBsZ8i?= =?us-ascii?Q?NwQ1ivPt2hOaiDirReA3seFhfur4r8IE/W762w1NyqNinrPJlFEF/HjNVURs?= =?us-ascii?Q?tQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084D10522345B3249822F529B6F9DM6PR08MB5084namp_" 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: 6bbb0498-166d-4afc-3070-08d9ba9c0195 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2021 22:42:25.3215 (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: jfXDbv54aTg+g3efYirjOD8R/nPR/fsroAd0beGCQTRE/Sb2RpA142OiJFWNCbwQOLG8g/o6CkZ0LKpjxMVdyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2858 Archived-At: Subject: Re: [netmod] "immutable" flag 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, 08 Dec 2021 22:42:32 -0000 --_000_DM6PR08MB5084D10522345B3249822F529B6F9DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qiufang, I think there are use-cases for "immutable" even outside of system config s= o we may not want to restrict it to system config. I'm not sure it would be as simple as erroring when a write is attempted to= that value. Are you talking about an error at edit time, or at commit/validation time ?= What if the value configured is the same as the current value ? It is prob= ably best if this is a validation/commit time check. If the immutable leaf is inside a list entry, then it should probably be ac= ceptable for the server to allow a change to the leaf by destroying and re-= creating the list entry under the hood. i.e. allow a change to the immutab= le item (which is in line with configurations being "declarative" - just ge= t me there if possible). Jason From: netmod On Behalf Of maqiufang (A) Sent: Monday, November 22, 2021 7:12 AM To: netmod@ietf.org Subject: [netmod] "immutable" flag Hi, all There are some system configuration which may not be modifiable for clients= (e.g., interface "name" and "type"). Should we define an "immutable" flag t= o indicate to the clients which system configuration is read-only or which = is not? The server will return an error if the clients attempt to configure a value= for a system defined data node with an "immutable" flag. My assumption is that this annotation should be carried only when the clien= ts retrieve with "with-system" parameter to get a merged view. Suggestions, comments and concerns about this issue? Best Regards, Qiufang Ma --_000_DM6PR08MB5084D10522345B3249822F529B6F9DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qiufan= g,

&nbs= p;

I think t= here are use-cases for "immutable" even outside of system config = so we may not want to restrict it to system config.

&nbs= p;

I'm not s= ure it would be as simple as erroring when a write is attempted to that val= ue. 

&nbs= p;

Are you t= alking about an error at edit time, or at commit/validation time ? What if = the value configured is the same as the current value ? It is probably best= if this is a validation/commit time check.

&nbs= p;

If the im= mutable leaf is inside a list entry, then it should probably be acceptable = for the server to allow a change to the leaf by destroying and re-creating = the list entry under the hood.  i.e. allow a change to the immutable item (which is in line with configurations= being "declarative" - just get me there if possible).=

&nbs= p;

Jason

&nbs= p;

From: netmod <netmod-bounces@ietf.org> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:12 AM
To: netmod@ietf.org
Subject: [netmod] "immutable" flag

 

Hi, all

 

There are some system configurati= on which may not be modifiable for clients(e.g., interface “name̶= 1; and “type”). Should we define an “immutable” fla= g to indicate to the clients which system configuration is read-only or which is not?

 

The server will return an error i= f the clients attempt to configure a value for a system defined data node w= ith an “immutable” flag.

 

My assumption is that this annota= tion should be carried only when the clients retrieve <running> with = “with-system” parameter to get  a merged view.<= /span>

 

Suggestions, comments and concern= s about this issue?

 

 

Best Regards,

Qiufang Ma

--_000_DM6PR08MB5084D10522345B3249822F529B6F9DM6PR08MB5084namp_-- From nobody Wed Dec 8 14:50: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 D57AB3A07DA for ; Wed, 8 Dec 2021 14:50:26 -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.20210112.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 jmZW8FAQD9Ka for ; Wed, 8 Dec 2021 14:50:22 -0800 (PST) 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 A792E3A07D6 for ; Wed, 8 Dec 2021 14:50:21 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id p8so6211365ljo.5 for ; Wed, 08 Dec 2021 14:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6cPSY2Qmd2yrGoZt2gJM3ZSlYnlPkeg6N8bWa8J9GbA=; b=QOZd6wEOrxiMqTcZ13kKcjTVwESeAKEz4+ZF3bXPlVtNMU3vTUuEwUfm6wA00AOZC+ RV0P0+QArSVJLA1zmjc/k/J/ytx4x5v8OTA4HDvXAM+t7QivQmcCVZZ5S4v86wQHUfwz Qqf7UdJ1WD+RRcAYyV2aazQAG3OZNsTPfyD7abMqB/UiZIN9fJRv7Ro8pBDEFIZYwomP 9LonhO/CCt00rHi4diPeqz0OR+gFJfh5jdnt9xxFMKa+Eml2hZSR5tZSEpgUzMuXteno Z2rA7UhzS8s7hCdzbsDQBynsEKwIhunEqn2npRa47Yic2cIBmxjAJw8Vhz1gw4FLiIed FNmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6cPSY2Qmd2yrGoZt2gJM3ZSlYnlPkeg6N8bWa8J9GbA=; b=MNIBIp7AT5CnkC4hjjNUNAhgXYc27NBFO4Cdy1wTqYTl+nf5Ur4AqjhGc5MWFF1JSg e3oI/m2mtxzusMLiza61wdYO1FfzQsQ1A9N95d3kMkNpNxpSXJZIQS0oqQAP1GW2Y+vm J8msoy9/BZjlrEuK/l4opLjsaXH/K2k6mGNviBbSCB1O2P3HdMFstOqZj4qbu7r7Ioms EWNWaiNS8hOApTJY3hKwseN9RIEPhQSaZThZTILFQyFjMV1IcGXe+yNnvK5wABDJvbyj lh+zfuEZxG/TKilsWGod2N/jhAL0s3R6z09pU/Vm020pMNH0nb9NW316eQk4EF1d6T9x q+Vw== X-Gm-Message-State: AOAM5302vrkUNAWxYgeHQOWUFVNfTFVcIo9FeN1xaamMkrzI14Sq+XIK KEv0agrHFExNlY2zjpX/0ekzLGg9O6IP1pCMGhmtuw== X-Google-Smtp-Source: ABdhPJw4qdCUXknG6WkTUeCjjMWvbUQvStD97mpwo2Yb1pO1pzXSarYK8VyCJBT00zeQjZPDQtEy81b/LmdJ3mFp86w= X-Received: by 2002:a2e:904b:: with SMTP id n11mr2338562ljg.120.1639003818389; Wed, 08 Dec 2021 14:50:18 -0800 (PST) MIME-Version: 1.0 References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> In-Reply-To: From: Andy Bierman Date: Wed, 8 Dec 2021 14:50:07 -0800 Message-ID: To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: Juergen Schoenwaelder , Jan Lindblad , Kent Watsen , "maqiufang (A)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006186be05d2aa504c" Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 08 Dec 2021 22:50:27 -0000 --0000000000006186be05d2aa504c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 8, 2021 at 2:31 PM Sterne, Jason (Nokia - CA/Ottawa) < jason.sterne@nokia.com> wrote: > Hi guys, > > > > Andy - about use cases. Here is a problem we're trying to address: > > > > There are at least several major router implementations that have this > concept of "hidden config" (i.e. list entries that can be referenced in a > leafref by explicit user config, but those list entries are not returned = in > a ). > > > Clearly not in compliance with RFC 7950. IMO the "enable flag" approach to the general problem, presented by Kent a couple years ago, is a much simpler and better solution than a new datastore. The full set of nodes is in . A generalized "enable" mechanism causes the resource to be used or not, where it shows up in and if enabled=3Dtrue. IMO this fits the original intent of NMDA and does so in a way that require= s the least disruption to current compliant implementations. Andy > The server accepts these configurations (i.e. a validate or commit > succeeds), but if you actually validate (e.g. with yangLint) the running > datastore contents (e.g. fetched using ) to the YANG model it > is not valid. That is against several RFCs referenced in the discussions > below. > > > > IMO there isn't any "offline" vs" online" validation that is different. > The contents of the running must be valid against the YANG model. A > returns the contents of the running. The server can validat= e > it, or some other entity can validate it, but it must be valid. > > > > In Jan's option #1 the running config could be polluted with 100s or 1000= s > of lines of unreferenced/unused config. A of a system withou= t > much config would instead return 100s/1000s of lines. I think that would = be > very annoying from a usability perspective. > > > > I'm in favor of this aspect of Jan's option #2: " + Clients unaware of > the system datastore would have to include (copy) information from the > system datastore to running in order to reference them." > > > > -> Only the list keys of referenced system objects would have to be copie= d > (configured) into the running DS (to resolve leafrefs). We wouldn't need > to copy all the descendant elements inside the referenced object. > > -> This copying would only need to be done by operators with a workflow > that requires offline validation > > > > Some of this approach is already described in > draft-ma-netmod-with-system-01: > > > > " In all cases, the clients should have control over the configurations > > ,i.e., read-back of should contain only what was explicitly > > set by clients." > > > > > > "4.3. Explicit declaration of system configuration > > > > In addition to modifying system configuration, and adding nodes to > > lists in system configuration as described above, a client can also > > explicitly declare system configuration nodes in with the > > same values as in . When a client configures a node (list > > entry, leaf, etc) in that matches the same node & value in > > , then that node becomes part of . A read of > > returns those explicitly configured nodes. > > > > This explicit configuration of system configuration in can > > be useful, for example, when an operator's workflow requires a client > > or offline tool to see the configuration as valid. The > > client can explicitly declare (i.e. configure in ) the list > > entries (with at least the keys) for any system configuration list > > entries that are referenced elsewhere in . The client does > > not necessarily need to declare all the contents of the list entry > > (i.e. the descendant nodes) - only the parts that are required to > > make the appear valid offline. " > > > > I'm not a fan of option #3. It doesn't allow a mode of operating where a > client/OSS has full control over the contents of the . Some > operators will want the master config to be owned up in their client/OSS > and push it down. The server should just accept it and the client should = be > able to do a "read-back" and see exactly what was sent previously. > > > > I think we have a potential solution for this system config that keeps th= e > running valid. But I'm far more worried about configuration templates. I > don't see how we can possibly keep valid with config templates. > That seems like a major problem to me. But if we ever declare that > doesn't have to be valid, and only has to be valid, > then offline tools can never validate (ahead of time) the config they > actually download to the server. > > > > Jason > > > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Friday, December 3, 2021 6:01 AM > *To:* Juergen Schoenwaelder ; Jan > Lindblad ; Kent Watsen ; maqiufang (A) > ; netmod@ietf.org > *Subject:* Re: [netmod] Must offline-validation of alone be > valid? > > > > > > > > On Fri, Dec 3, 2021 at 2:26 AM J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Fri, Dec 03, 2021 at 10:59:12AM +0100, Jan Lindblad wrote: > > > I made some proposals earlier, both on the interim and privately to the > draft authors, along these lines: > > > > Option #1 > > + We could have a new system datastore that technically is a part of > running. Everything in system would show up in running to clients unawar= e > of the system datastore. Every time the system datastore changes for > whatever reason, the running datastore transaction ids (if we manage to g= et > that concept defined), are updated > > + Clients interested to see pure view of the system datastore without > anything else in running could issue a get-data towards the system datast= ore > > + Clients interested to see a pure view of running without any system > datastore elements could issue a get-data towards running with an extra > flag called 'without-system' > > + Since all system elements are already part of running, clients have n= o > need to copy data between the two datastores > > > > Option #2 > > + We could have a system datastore that technically is a part of > operational. Everything in system would show up in operational to client= s > unaware of the system datastore. The running datastore always maintains > referential integrity, i.e. cannot reference the system datastore. > > + Clients interested to see pure view of the system datastore could > issue a get-data towards the system datastore > > + Since the system datastore is not part of running, clients can alread= y > see a pure view of running without any system datastore elements using a > simple get-data. > > + Clients that are aware of the system datastore and are interested to > configure references from running to system elements would issue an > edit-data rpc with the additional flag 'resolve-system-references'. This > will make the server copy any system elements referenced into running > without the client doing so explicitly. > > + Clients unaware of the system datastore would have to include (copy) > information from the system datastore to running in order to reference th= em. > > > > Option #3 > > There is a client on the system that makes changes to running just > like any other remote clients can make changes to running. System > generate config that is not editable explicit config in running goes > straight into the applied config in operational. This does not require > a system datastore (in fact something like a system datastore may > exist as the _logic_ of the system client, the good old example we had > is allocting an unused uid for an account that, once allocated, is > maintained in running). > > > > > > +1 to option 3. > > Consider an implementation that moves all the "hidden system logic" off-b= ox > > to a controller, such that the initial config is literally supplied by an > external client. > > > > I have yet to hear a single use-case for creating a datastore. > > "The client might want" is not a use-case for standardization. > > I do not understand the "pure view". Seems like if this was a real proble= m > to solve, > > then NMDA would have included a system datastore from the start. > > > > > > /js > > > > > > Andy > > > > > -- > 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 > > --0000000000006186be05d2aa504c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 8, 2021 at 2:31 PM Sterne= , Jason (Nokia - CA/Ottawa) <j= ason.sterne@nokia.com> wrote:

Hi guys,

=C2=A0

Andy - about use cases.=C2=A0 Here is a proble= m we're trying to address:

=C2=A0

There are at least = several major router implementations that have this concept of "hidden= config" (i.e. list entries that can be referenced in a leafref by exp= licit user config, but those list entries are not returned in a <get-config>).= =C2=A0=C2=A0

=C2=A0



Clearly no= t in compliance with RFC 7950.

IMO the "enabl= e flag" approach to the general problem, presented by Kent a couple ye= ars ago,
is a much simpler and better solution than a new <sys= tem> datastore.
The full set of nodes is in <running>.
A generalized "enable" mechanism causes the resource to = be used or not,
where it shows up in <intended> and <ope= rational> if enabled=3Dtrue.

IMO this fits the = original intent of NMDA and does so in a way that requires
the le= ast disruption to current compliant implementations.

Andy

=C2=A0

The server accepts = these configurations (i.e. a validate or commit succeeds), but if you actua= lly validate (e.g. with yangLint) the running datastore contents (e.g. fetc= hed using <get-config>) to the YANG model it is not valid. That is again= st several RFCs referenced in the discussions below.

=C2=A0

IMO there isn't any "offline" vs= " online" validation that is different. The contents of the runni= ng must be valid against the YANG model.=C2=A0 A <get-config> returns= the contents of the running.=C2=A0 The server can validate it, or some other entity can validate it, but it must = be valid.

=C2=A0

In Jan's option #1 the running config coul= d be polluted with 100s or 1000s of lines of unreferenced/unused config. A = <get-config> of a system without much config would instead return 100= s/1000s of lines. I think that would be very annoying from a usability perspective.

=C2=A0

I'm in favor of this aspect of Jan's o= ption #2:=C2=A0 " + Clients unaware of the system datastore would have= to include (copy) information from the system datastore to running in orde= r to reference them."

=C2=A0

-> Only the list keys of referenced system = objects would have to be copied (configured) into the running DS (to resolv= e leafrefs).=C2=A0 We wouldn't need to copy all the descendant elements= inside the referenced object.

-> This copying would only need to be done = by operators with a workflow that requires offline validation=

=C2=A0

Some of this approach is already described in = draft-ma-netmod-with-system-01:

=C2=A0

"=C2=A0=C2=A0 In all cases, the clients s= hould have control over the configurations

=C2=A0=C2=A0 ,i.e., read-back of <running&g= t; should contain only what was explicitly

=C2=A0=C2=A0 set by clients."

=C2=A0

=C2=A0

"4.3.=C2=A0 Explicit declaration of syste= m configuration

=C2=A0

=C2=A0=C2=A0 In addition to modifying system c= onfiguration, and adding nodes to

=C2=A0=C2=A0 lists in system configuration as = described above, a client can also

=C2=A0=C2=A0 explicitly declare system configu= ration nodes in <running> with the

=C2=A0=C2=A0 same values as in <system>.= =C2=A0 When a client configures a node (list

=C2=A0=C2=A0 entry, leaf, etc) in <running&= gt; that matches the same node & value in

=C2=A0=C2=A0 <system>, then that node be= comes part of <running>.=C2=A0 A read of

=C2=A0=C2=A0 <running> returns those exp= licitly configured nodes.

=C2=A0

=C2=A0=C2=A0 This explicit configuration of sy= stem configuration in <running> can

=C2=A0=C2=A0 be useful, for example, when an o= perator's workflow requires a client

=C2=A0=C2=A0 or offline tool to see the <ru= nning> configuration as valid.=C2=A0 The

=C2=A0=C2=A0 client can explicitly declare (i.= e.=C2=A0 configure in <running>) the list

=C2=A0=C2=A0 entries (with at least the keys) = for any system configuration list

=C2=A0=C2=A0 entries that are referenced elsew= here in <running>.=C2=A0 The client does

=C2=A0=C2=A0 not necessarily need to declare a= ll the contents of the list entry

=C2=A0=C2=A0 (i.e. the descendant nodes) - onl= y the parts that are required to

=C2=A0=C2=A0 make the <running> appear v= alid offline.=C2=A0 "

=C2=A0

I'm not a fan of option #3. It doesn't= allow a mode of operating where a client/OSS has full control over the con= tents of the <running>.=C2=A0 Some operators will want the master con= fig to be owned up in their client/OSS and push it down. The server should just accept it and= the client should be able to do a "read-back" and see exactly wh= at was sent previously.

=C2=A0

I think we have a potential solution for this = system config that keeps the running valid. But I'm far more worried ab= out configuration templates. I don't see how we can possibly keep <r= unning> valid with config templates. That seems like a major problem to me. But if we ev= er declare that <running> doesn't have to be valid, and only <= intended> has to be valid, then offline tools can never validate (ahead = of time) the config they actually download to the server.

=C2=A0

Jason

=C2=A0

=C2=A0

From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Friday, December 3, 2021 6:01 AM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Jan Lindblad <janl@tail-f.com>; Kent Watsen <kent@watsen.net>; maqiufang (A) <maqiufang1= =3D40huawe= i.com@dmarc.ietf.org>; netmod@ietf.org
Subject: Re: [netmod] Must offline-validation of <running> alo= ne be valid?

=C2=A0

=C2=A0

=C2=A0

On Fri, Dec 3, 2021 at 2:26 AM J=C3=BCrgen Sch=C3=B6= nw=C3=A4lder <j.schoenwaelder@jacobs-university.de> wrote:<= u>

On Fri, Dec 03, 2021 at= 10:59:12AM +0100, Jan Lindblad wrote:

> I made some proposals earlier, both on the interim and privately to th= e draft authors, along these lines:
>
> Option #1
> + We could have a new system datastore that technically is a part of r= unning. Everything in system would show up in running to=C2=A0 clients unaw= are of the system datastore. Every time the system datastore changes for wh= atever reason, the running datastore transaction ids (if we manage to get that concept defined), are updated
> + Clients interested to see pure view of the system datastore without = anything else in running could issue a get-data towards the system datastor= e
> + Clients interested to see a pure view of running without any system = datastore elements could issue a get-data towards running with an extra fla= g called 'without-system'
> + Since all system elements are already part of running, clients have = no need to copy data between the two datastores
>
> Option #2
> + We could have a system datastore that technically is a part of opera= tional. Everything in system would show up in operational to=C2=A0 clients = unaware of the system datastore. The running datastore always maintains ref= erential integrity, i.e. cannot reference the system datastore.
> + Clients interested to see pure view of the system datastore could is= sue a get-data towards the system datastore
> + Since the system datastore is not part of running, clients can alrea= dy see a pure view of running without any system datastore elements using a= simple get-data.
> + Clients that are aware of the system datastore and are interested to= configure references from running to system elements would issue an edit-d= ata rpc with the additional flag 'resolve-system-references'. This = will make the server copy any system elements referenced into running without the client doing so explicitly.
> + Clients unaware of the system datastore would have to include (copy)= information from the system datastore to running in order to reference the= m.
>

Option #3

There is a client on the system that makes changes to running just
like any other remote clients can make changes to running. System
generate config that is not editable explicit config in running goes
straight into the applied config in operational. This does not require
a system datastore (in fact something like a system datastore may
exist as the _logic_ of the system client, the good old example we had
is allocting an unused uid for an account that, once allocated, is
maintained in running).

=C2=A0

=C2=A0

+1 to option 3.

Consider an implementation that moves all the "= hidden system logic" off-box

to a controller, such that the initial config is lit= erally supplied by an external client.

=C2=A0

I have yet to hear a single use-case for creating a = <system> datastore.

"The client might want" is not a use-case = for standardization.

I do not understand the "pure view". Seems= like if this was a real problem to solve,

then NMDA would have included a system datastore fro= m the start.

=C2=A0

=C2=A0

/js

=C2=A0

=C2=A0

Andy

=C2=A0


--
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

--0000000000006186be05d2aa504c-- From nobody Wed Dec 8 14:51: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 5694A3A0808 for ; Wed, 8 Dec 2021 14:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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=unavailable 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 1GsbltjgjtzS for ; Wed, 8 Dec 2021 14:50:52 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2096.outbound.protection.outlook.com [40.107.244.96]) (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 89DB53A07F5 for ; Wed, 8 Dec 2021 14:50:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BPMPCdKWugOanSwL3iqpJMdyCiivgDeGOwu8E9G/yJSvzXz/KiXpqR/ac3BkhcYnTqD1GlHCkkSpXq0tVmarbQFgdoRUF5I6zsfGHaJR7TxTlcFjqi1A4jIS+9dyYkgguIgrjyQO8XY7QUtH2+HSVNEBWHszQFXn8pc/VQ1VnfM/Ptb4xof/cfFNGW7tWUVkRifKr7GtDFiQkEMJKGn/9l0KORLccl+eqWGWNmRO/tlsjDrffZcA1QLVPyHM8atxeYxnTNFi6XVadx1ZIjnnovnpr6slebH1TY5W/AcoMKbRR/SE9mZxr/zRw3Zqr7szAXSvIk51v2lzdFnYXR0esA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rHv9l8N5ytSLk1azsbuBADXbl0Z3rXDFmDd291rhplQ=; b=TkZUnlO/Pthj+ehNDd9YCmGpcNk+9kT6P/qKpEtuo5A/7dfd0Y/ldV+1dgojl0k6VajKzfuIj/uatyNwXM1UTYr+nOCCggNhdY627V3cso8WZxQjcnhiSA0HFJx/L2bXRVu6ZN3fvv51wJWn35EL2wAg9Q4GIkW+6TGKTwFqTwp8cbUNdff+Wx7vktKspI/PMZ2cqjK4lf2MtfL7oFWcSMhfXuoEJrNiXc+NuNc3oyEVCVqoThpaol2e9Ci+xeSBs/NzjIEJxMSSP3rpI3EG7XSaZaokcb7J2csYGT8nWjrXWMQ+sJEEF20j4xXutkM1j74xEkoawz788qv2hDQjFQ== 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=rHv9l8N5ytSLk1azsbuBADXbl0Z3rXDFmDd291rhplQ=; b=qKTD8YKfqlrTLfTMKHnao9fiQMXyWPpGiMeEP71jl7NrHnS/fZ/9MWDqShqno/hYuQhbYOreLgelAcBcUdb3Xa3Wv6R63Zr1AqwkLbAiHFu1e0Vk6w02/yPpiVGybdm8VLI2M8I/td7HrkYwsT59GOxoQHcV5ZfslZSmuluedBI= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6060.namprd08.prod.outlook.com (2603:10b6:5:107::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.11; Wed, 8 Dec 2021 22:50:49 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.022; Wed, 8 Dec 2021 22:50:49 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "maqiufang (A)" , "netmod@ietf.org" Thread-Topic: [netmod] Should the "with-origin" parameter be supported for ? Thread-Index: AdffkIzQgrflx2pfQFG03vlrV2MIPQM9JcDg Date: Wed, 8 Dec 2021 22:50:49 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7e06717d-15e1-42fa-f83b-08d9ba9d2deb x-ms-traffictypediagnostic: DM6PR08MB6060:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W1sIj5zHU7PeW3vpDU5OCZ37cc1zuvA11CCQuop+Pzzs5BL0tbUl3kPEDdGOSJVQCGs77cXZMxMyTjQcmixzqFYvXFyDcDtd1RPnBfqFlUg5MBDVNqoPVIzalqfCuINBSLaYu3F6MFeeqAX1O1NpR03vPfUDeUUujhXEJ4hZZdThRJZRs40rgxvqlBEQHi+lq0c9gtVXyi4VMSnlPbbh9NgX0YrlX4a4M90nByrLfh4sU3G6bKQ8MW3HTtN4upIvfTd+tkWaVromjk+e28Ic0owT1RUNSGjZf0x5lQb87L1KqWXH5XRPAMdToabFkao24oKXu25UBE3LGO1toDtDZEZEUpbWSHBFj5eX4t4P5h8On2MpHerL9a+PpEmzKpQG9mIFC8FNuZKUZ3s74wODccj3r64/SciW12v6Ql6jvj3SgmB2argflm3NsBuZsmxpuaICBUXbq+vRp4IpUe4rwxRBdk5CrzmCjme8UqxQgZhiMus58jywkIGb2EbXoZcZF0ekNG91q9OuzO8qLq+L2VPupJw8Gx9+F8btCnrvPVjy8Ql6pif14dhBwKN5hOtlnFm7yYUYxS5y3l2miZjmo1NFO/gwAS8dD6Uf2Zvlrn7cygDeOMByEwaKVAZuFaG20wpN/NQo7dtbsfJrWz0B+MOmzws1xao4IDP4UpVV5OOR4jzN3gQ1/zzTEhxpwfcwMACxBLjinpkjB3TW3nq3vg== 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)(366004)(26005)(8676002)(186003)(508600001)(8936002)(7696005)(9326002)(110136005)(2906002)(52536014)(53546011)(316002)(6506007)(71200400001)(66556008)(38070700005)(122000001)(38100700002)(86362001)(82960400001)(33656002)(5660300002)(64756008)(76116006)(66476007)(66946007)(66446008)(55016003)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?vnp5DbUo0cdUPkN9Yfa1cwX7qM+ju5UD6M4zTubRpsa9jGUekZ7fYK+NY5XA?= =?us-ascii?Q?lSSjt5FTW2USE+tg7f2biatAbNSKwOkq6j9PIiNDnXCk7tOsVVWJdOV0G0qu?= =?us-ascii?Q?FcE+1EBzxZGFk7YJyeu4Ua/YSw9D7aveQtEMrSQB5JEDzpDh7jo8AfLTN5K9?= =?us-ascii?Q?XDrylqlHslBCrA/0HsGRN5ryDauXvrcjtbZBCn0sHv5i7C+LwSwQiJZOq86u?= =?us-ascii?Q?wfqzdJayAn0q6u3m8VyY3g0UQsl0Dwb/jYrLk3YL4byjL2/QOP+9R1bKEU50?= =?us-ascii?Q?q+ew8OkYISeTQ9FJ3+JWfPXYLhG2g3oDmlTcA2jB5MHGN1fma9flUJ+9Xzgw?= =?us-ascii?Q?qug136uOmBxZE4vlhJAAlgFBDLBVHXUEROCbX+JrS+nWA+oxVu6JFaNXWhYL?= =?us-ascii?Q?vNeVYjJ5kvFbCCCI0G7nuLBRJkGRRau1OVpQsLLZB+xnII4joTizn2ufo/K4?= =?us-ascii?Q?OL1cmNTK7JScG+c7MoSW595Xa9cP4jec6OZy4YhoaTnIXQjNV2UP54zimn9c?= =?us-ascii?Q?EO2xgLTHs7N/trATa2QaLGK0e1m5wf8b+ZsuRxwRDbvlb2AAMDMJ5IardfMy?= =?us-ascii?Q?0rqD5jO6dL8qlZgMzpANKo+zZY4sCX4qNpJsATQkBywvitRqhFEuoxVjAnwP?= =?us-ascii?Q?PO4q2/2vLteipanQy7kiq6WPhq/CLM9fa1ltt9E0zqoT024hVRBPNq4OBy9P?= =?us-ascii?Q?Pmwhmz7nSbQrh89f0hTdgxF8nH5U0ProRnpHOZMHv0slTSoTHlUQSiHMo2Sr?= =?us-ascii?Q?wU3PBC5CvM1XzScyQKwyFNcHVGLUJEsMEVJR0bMVqobiL0ukzYutIqWj2vJf?= =?us-ascii?Q?RIB+353/7YEVtDwGAztQw2pxbgWDImtUhvp44pQC3VhjWk+iiKf14z5QmGmo?= =?us-ascii?Q?P087++8g5TGyMX8mx+fV1BEkRp3gPqrPu3DTP2N5bVli6QPikHq28gckG9XM?= =?us-ascii?Q?CroULcmjBn24IMUEmtqLbrci9lv++bx7xoNbgRzG9xuw+rURrSeD3wdWbUBZ?= =?us-ascii?Q?W+qplUKxI1RXqVaqzWxvz83Cl06VbZSByUUL43lrxLvFM1W33wSQv3Oz917G?= =?us-ascii?Q?vrTwVpVV02DKIf5fw2Xj8xYt6GEZqHxCs9joMNMiwabRh0BlME/piqFXDUz4?= =?us-ascii?Q?Qifoc6IePgB9bK7k+F82RSNIKVZCb2Lj8l9E+8vgUaF16XjKLpKfjRB7iXIR?= =?us-ascii?Q?fDR+K4vzZLuyHxqnbiTGh+CzN4CWujX7Ngo1EsBCr5jW04+n1966g+qkbh2s?= =?us-ascii?Q?WiS6vF7Fh78RqjIwXcK9u4z2nPqPGzJqkuzQ/xUJbjEOu8Kn+gMrctX4P7O6?= =?us-ascii?Q?VUPj9JDZq+RtHOOegbnreaMezpY7ao1LFelg992PrP2c6CKU/Bqt0PSqE0Zp?= =?us-ascii?Q?yV5luNDBtzEbNj1oa/DK8/LzLGgBepNsM8lijCTzDn+1O5WaMUQKI8y7XiaG?= =?us-ascii?Q?sxWopac3bB1wdQlsA52C8VekaaAWuqxpaRHwTkaVZqX3mJagRJ2EsuMPkVkh?= =?us-ascii?Q?myeh38SPbWAC0whQAoQcCOyULHaIl5UGIjVKBHy5ap5K1cH38QqDF+p/jWIy?= =?us-ascii?Q?hmavpvY2OPYlKHGYbt94m2pWCXpxf4/odAP7uo1mwgQECiL+OoJ/npYDc7a1?= =?us-ascii?Q?jg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084FAEF703823D65DC3AED79B6F9DM6PR08MB5084namp_" 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: 7e06717d-15e1-42fa-f83b-08d9ba9d2deb X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2021 22:50:49.1647 (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: HFA4L+PBFzQhyIL7TO9zuEtENDmfhArBjUdbrgTm6xWpGNqMg7eDTRJt5m6k0DhMCeDPf17CnIoNk3MkXA9stQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6060 Archived-At: Subject: Re: [netmod] Should the "with-origin" parameter be supported for ? 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, 08 Dec 2021 22:51:02 -0000 --_000_DM6PR08MB5084FAEF703823D65DC3AED79B6F9DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qiufang, In your first option, did you mean "understand a certain data node is from = or from " ? It is an interesting question about whether the origin annotation could/sho= uld be available in a read from , and what values that origin cou= ld take. We should consider other transformations between and (= besides the merging of ): - active/inactive config - configuration templates Inactive config would simply be stripped and not appear in at al= l. So nothing to discuss for that. But would elements provided from within config templates have an 'origin' t= hat indicates what template it came from ? I suppose the same question could apply to 'origin' in the DS= . Having origin purely available in the operational DS may not be complete en= ough. Some config nodes may not be present in operational because they are = not "applied". So you wouldn't necessarily be able to get the full picture = of the origin of all intended config by just checking the origin in the DS. Maybe that's an argument to have an origin in ? Jason From: netmod On Behalf Of maqiufang (A) Sent: Monday, November 22, 2021 7:11 AM To: netmod@ietf.org Subject: [netmod] Should the "with-origin" parameter be supported for ? Hi, all In the "system-defined configuration(draft-ma-netmod-with-system)" work, an= optional datastore named "system" is introduced to hold non-deletable syst= em configurations. We define that if a server implements , MUST be merged i= nto . So there is the cases that the clients can fetch and contains merged . The question is should we extend the "with-origin" parameter to support ? The possible considerations for following two choices: * "with-origin" parameter should be supported for * It may be helpful for a client to fetch to understan= d a certain data node is from or from * There is no need for to support "with-origin" * We already have to provide the origin for a parti= cular data node Any thoughts on this? Best Regards, Qiufang Ma --_000_DM6PR08MB5084FAEF703823D65DC3AED79B6F9DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qiufan= g,

&nbs= p;

In your f= irst option, did you mean "understand a certain data node is from <= running> or from <system>" ?

&nbs= p;

It is an = interesting question about whether the origin annotation could/should be av= ailable in a read from <intended>, and what values that origin could = take.

&nbs= p;

We should= consider other transformations between <running> and <intended>= ; (besides the merging of <system>):

- active/= inactive config

- configu= ration templates

&nbs= p;

Inactive = config would simply be stripped and not appear in <intended> at all. = So nothing to discuss for that.

&nbs= p;

But would= elements provided from within config templates have an 'origin' that indic= ates what template it came from ?

&nbs= p;

I suppose= the same question could apply to 'origin' in the <operational> DS.

&nbs= p;

Having or= igin purely available in the operational DS may not be complete enough. Som= e config nodes may not be present in operational because they are not "= ;applied". So you wouldn't necessarily be able to get the full picture of the origin of all intended config by just = checking the origin in the <operational> DS. Maybe that's an argument= to have an origin in <intended> ?

&nbs= p;

Jason

&nbs= p;

From: netmod <netmod-bounces@ietf.org> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:11 AM
To: netmod@ietf.org
Subject: [netmod] Should the "with-origin" parameter be su= pported for <intended>?

 

Hi, all

 

In the “system-defined conf= iguration(draft-ma-netmod-with-system)” work, an optional datastore n= amed “system” is introduced to hold non-deletable system config= urations.

We define that if a server implem= ents <intended>, <system> MUST be merged into <intended>.=   So there is the cases that the clients can fetch <intended> an= d <intended> contains merged <system>.

The question is should we extend = the “with-origin” parameter to support <intended>? The po= ssible considerations for following two choices:

    • “with-origin” parameter should be supported = for <intended>
      • It may be helpful for a client to fetch <intended>= to understand a certain data node is from <running> or from <inte= nded>
    • There is no need for <intended> to support “= with-origin”
      • We already have <operational> to provide the origi= n for a particular data node

Any thoughts on this?<= /span>

 

 

Best Regards,

Qiufang Ma

 

--_000_DM6PR08MB5084FAEF703823D65DC3AED79B6F9DM6PR08MB5084namp_-- From nobody Thu Dec 9 02:51:26 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 2426E3A0994 for ; Thu, 9 Dec 2021 02:51:24 -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 cmymRFRZdbvX for ; Thu, 9 Dec 2021 02:51:19 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2092.outbound.protection.outlook.com [40.107.20.92]) (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 702CD3A0991 for ; Thu, 9 Dec 2021 02:51:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=erhoN15BMb0Kz8I81bCa1BzJoATDI8gact+aTJKkqrGMZfX7gBaA/hx/BdaHHLZuWYugg2eqDD9sQcnuv6wOmPO8g5rUEqavlIWXKWatHg83eXKLObA8iDU3ahed/25khqfQY9uc7wBA+0IRj7L7W5L2ujd0xkbb2HURKxROY0eRzHwcEApwGKUi6e1pFOmOHqBDv9QeS02y0oDdwwPFpWDMdP4dlSsiap5YABIgGurIHJx1EHxPPOuHFr7UiGto+FqeSAhZuHCoRqTYw/VzFAj6/GGFA1CcqtROsHcRkhlzFaX5JkIzszI4EASgf3TPpV1BnADsc7uP5GmOY2P0Ww== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gAbRg75UvFF3jMPhKt7s0AKYDWWnN/soXdNmLUu8fTA=; b=VtuT1s3sqDMabIidK1BVvCEqntVDxYnTVfEB9Jz044/vXpHsuls6p/igKTy2MiMHrmwjATA0lU+AtnXQyDqAAZsh52Iwj2l0YjmE0/+epfyfKG3XaHu/bGmJdCKi7sbgMQuy3flNxkU5RXaJIAnKp56d0ga4K/3RQCzrQhoXNrR1N1KFzaFlRRhtYpCJb4uGFpQ+5XvlaoZydnHniLn9zDf6ZyStwaY7M3GoRglYrfXJ8ZE0ArxkqGzktgfwYhOMo1kRHH/UT+wzUElNQL4cDbR6PvYEVXjT4TnykXeXDYDs2lGYt2pLH59BeRJncUYQHEp48aA4+vAQZpfN4wT8aA== 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=gAbRg75UvFF3jMPhKt7s0AKYDWWnN/soXdNmLUu8fTA=; b=oihGW+Z1A0ZZZ37XZdl2G8HaQYzqfucbCy73b9bAMXeNphEr10vXMUd+2/LyDiAXL0Ql3qai4wtVlUghaCAhSX1NZ4E5SYAqVyvGc3WLoY5Kd5RNpXTtmUzvkPQHlxOPplOFitnwvSvLkRjjw7ifcMKQqhhBEDpYsDpC+xE5I8c= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB4678.eurprd07.prod.outlook.com (2603:10a6:20b:1c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.11; Thu, 9 Dec 2021 10:51:16 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::89f3:ef4c:9336:3848]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::89f3:ef4c:9336:3848%3]) with mapi id 15.20.4778.013; Thu, 9 Dec 2021 10:51:16 +0000 From: tom petch To: Andy Bierman CC: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] RFC7950 s.11 and 9127-bis Thread-Index: AQHX7BauAzogsNTzwEWqsryCq6/74KwoiNAAgABPsCaAAAmmgIABGRNw Date: Thu, 9 Dec 2021 10:51:16 +0000 Message-ID: References: <87a6hb6zlp.fsf@nic.cz> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: db95434c-5767-aa96-3223-17f99a9d4ac1 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a14e038-b05d-4917-9f38-08d9bb01d38d x-ms-traffictypediagnostic: AM6PR07MB4678:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oilt+78buXq5oH1Y1eaqp8Px1tovung1UkwwbwOSTz2kj+jppKqJ+FjUDKp0yyroEoCG1KFHDbwx0gjyPLs98mUB14R5rsRBgBTazwyeSh0d8/68TeZawo2Wwj8Cr8SctmvuT6ymTHPCTAtpBfJTTC9BOJQrzbzY6LjaoCsT7A8mVILpYWVubL49KPPYialDDkkeLr0nRNquaEfLYZO2eMdyFZ6IGl7qno+HUmQSqQPjUiOyo9J/7vKDMseTxGRYR62ULzdYGPiEFmidcnKNBPdJV8Egn5Tr/fvbWYRN5DwMERED5A7TxmDTuZIaXCYOQKPPRt7A1Wvwck5FXQOvj24R5Y5oO0xUnw31rOu4a+3iBmczr2Y6iVywXDxoSpTms3xoUse6tMtBNcnRBg2/Dr7qlRpC4wz2O52E6Zi6TUb7guZ/yKO0sdoyl9kF0rH0k3j1x4f0wdAKPc1Jcdn4KEAdfra+jiVNDYU2dXf6BKZgWEtlw0H7MQt3hAVWzN70r+3bo+vQSQ7nHJeQwk2t2l10ZIk+N+p+ye2V7D/oK8+Ay1+ZmYc6eTaSdW/b4RZRZamVN7LDSHmFsWgYni4YAOync5D0s2zImn9Q2p/WMzeAi1iVdZaECAAqAqcqfnag0szSK/vr0ruxqZB64XameZP6p60ZjwPw7dIZm7MxxC/Wfxy3Sl3BepXa9Ec+C0l877eHHC4OWQufOO0xHRvmwaTNo1SUpPCw6zRKcBut3uSczQ6HA9c5LC+gz3tB8jxYos/NqwVF5BAQPZcmzQ1WFTbMFgFkukLOTu8YD6EE9eNle+zqPqyOWqnKWrxm8KrOzUYIBm6PRQ/wlSY8N2XaBc9RipvNTZNteQIg+IuvSDxjqb48QEAQaEBSI6MrLWEBgP6n9qzQiXE0e969KYewuQ== 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:(4636009)(366004)(33656002)(64756008)(66476007)(66446008)(186003)(66556008)(4326008)(91956017)(55016003)(2906002)(52536014)(71200400001)(9686003)(26005)(8676002)(8936002)(966005)(38070700005)(66946007)(76116006)(508600001)(316002)(38100700002)(82960400001)(122000001)(86362001)(5660300002)(6506007)(6916009)(53546011)(7696005)(54906003)(586874003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?+551niNIYEFz6wwyKMhnelGsnV6QSlwlpHoP38vI3HK4pambhPtXApAPA1?= =?iso-8859-1?Q?0t3w+eu6+xmH4+CxAeAa4o6Wdv03vhgwlae4j0k6mRm5t0PM/lkhy3qCZA?= =?iso-8859-1?Q?2ZNR5y4rQhABk4JNOSW19BM9rB1f+Pd22wvsPJw1CQt/2rlCxX29h6pLEh?= =?iso-8859-1?Q?ecUj+KDqEHJ3pa6q918THdS8eWGiVClaLY+D4EwMCUuGPzJb+TUUO749UM?= =?iso-8859-1?Q?ql6eGRtdnkrQPDy0fJwKr1JR3/7jrHGBpkwWxVOaHasm81ew0BxxcmliJQ?= =?iso-8859-1?Q?VpaLvI46Lhgo7FIYqT9lZOIvPPQ3kLj5J2HbdQ1SbKpzBC9iDD89NvFx/P?= =?iso-8859-1?Q?AVmQvu6pKZWIYfqqH6y4gippEm/9WKY/8ZhQWfkM1789CRPM0+BVLlNLvS?= =?iso-8859-1?Q?P+6JOelSPnCPqvGnxkzli6oT6fAC6zAaVXMxbpd+holmXyjHH/3qhib3Oq?= =?iso-8859-1?Q?q/+6WZHCOuT4+ukqouYKwQKQW2mkMUiI7Ek6nB2VzJdaSoytx4Y3DAIX5V?= =?iso-8859-1?Q?SE1XK6JrF5NONzvVH6sUAy3cBjsvvEMdm9ye1Pg3Md49qPclMnQ09n05er?= =?iso-8859-1?Q?48UhypaSdJOKJyn/YSe8NcSI+pOQTEdpoyCaWg47naV3zfImEUCym9Y9w2?= =?iso-8859-1?Q?1rf65a8pa48BYwaAG+U9SX/sn0SCHa9CfqWQwikeFTD8XjIln2OIjZgQSC?= =?iso-8859-1?Q?G3mCrJf5SqENOGdccU7+QZqMmG+UCQTrLE/IDHWtfbO6e/7OeustW4zmiy?= =?iso-8859-1?Q?nVqrTvDhxHTXe6oE5MDty9wPGO2RwlvDzxRuq1zCW6cQDffx9A5R7lIsGQ?= =?iso-8859-1?Q?Q4RtRR4FDqsA5SZ31oVFvGZ0hvdjrF4QlumoGXu2B1BejSRWByuD0CeRNN?= =?iso-8859-1?Q?kqBGz7kqI9yV9cst2jLOX/OR1tS6kpMRfttWYIXSr9oigbWchljKhLhj5E?= =?iso-8859-1?Q?5QEPOF+gcLCj1xwQxKaPrpL9foYGIyxevJ5KCJgQ/Gd7obzpKa3FBRgXE0?= =?iso-8859-1?Q?32uLOIgojXGalwuF20/t9bAlFack9moR0t7hYAPCLbUS345D/t7ARyzQ4G?= =?iso-8859-1?Q?AKzAed6e07qcFoEEt4rFhPq5KsYQaLAk5/rinxi3OZ/4rntPPwqQKIsLbH?= =?iso-8859-1?Q?XT1GJkXf7RY3fntRT31ak8xn5c5C9JD5epK2smG8Ej+WJknniwj6IcJXGd?= =?iso-8859-1?Q?FziJabQ1ZCkQr11esroMZimejbjylWHDmrGZzXFKMk8eS7RZeP9ecgnvDa?= =?iso-8859-1?Q?xjL8eEwizsAzyNsMaUK8CL4CqUWd035hW/JlfUJ3GlheUd4wrImG5Z/Xns?= =?iso-8859-1?Q?v/oHFfNg57Bb8Xovy1L5P06ryp/f2BKJyeYZvw/6K/byrFsysD+Mb3QoMi?= =?iso-8859-1?Q?dZzx6HOsUj1FpqTSnbR7MWErAbpPawnPkIW1YzIhK4AwOxs8GYxooHv+kB?= =?iso-8859-1?Q?cur74++82+31GSOSZ7dZqdx4BwbFM4qQ44eDwZ12i1SbK1SanptRyTldtN?= =?iso-8859-1?Q?uku5MC4+fVgPcLh+hTtrEWJCRRfMHY4gE6EKBxV6W4xY0oMOqzsLvcV+wA?= =?iso-8859-1?Q?FgN9/0snu3EM/NSGJrYLPSbd9mO5XwWZdYAu1nZT7eXYCppOjZVGCsyaz3?= =?iso-8859-1?Q?4+4DyMzBBdahLjiyJaG0OuRVmUcHTTSl0uc5a19coubWwSD1SMiE//qg?= =?iso-8859-1?Q?=3D=3D?= 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: 2a14e038-b05d-4917-9f38-08d9bb01d38d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 10:51:16.7165 (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: 8xn58w5v+DnLzGEfLmwQD1WH1kEm7PbUnoQ4t8TpyTxx+n/4250wtmIEHYY7IFnWk/gNtAH+JbMa6iCQpXZwuQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4678 Archived-At: Subject: Re: [netmod] RFC7950 s.11 and 9127-bis 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, 09 Dec 2021 10:51:24 -0000 =0A= =0A= ________________________________________=0A= From: Andy Bierman =0A= Sent: 08 December 2021 17:58=0A= =0A= =0A= =0A= On Wed, Dec 8, 2021 at 9:27 AM tom petch > wrote:=0A= From: Ladislav Lhotka >=0A= Sent: 08 December 2021 12:38=0A= =0A= tom petch > writes:=0A= =0A= > The BFD WG are revising RFC9127 to add a new feature if-feature=0A= > "client-base-cfg-parms"; and make uses base-cfg-parms { conditional=0A= > thereon in module ietf-bfd-types. Reading and re-reading RFC7950,=0A= > especially about mandatory and top-level, I am not convinced that=0A= > this is legal.=0A= =0A= Sorry, I don't get the problem - nothing in the "base-cfg-parms" grouping i= s mandatory. Why do you think this might be illegal?=0A= =0A= =0A= Reading that section I find parts less than clear, especially about top lev= el and mandatory. Could a PIM eg module importing that grouping make it to= p level or mandatory even if it is not so in the BFD module?=0A= =0A= =0A= =0A= Yes. The refine-stmt can add or change a mandatory-stmt.=0A= https://datatracker.ietf.org/doc/html/rfc7950#section-7.13.2=0A= =0A= This only affects the specific "uses" of the grouping, never the grouping i= tself.=0A= =0A= =0A= =0A= Andy, Lada,=0A= =0A= Thanks for the responses. Perhaps I should stop worrying. None of the imp= orting modules - PIM, OSPF. BGP, RIP - use refines for bfd-types but even i= f they did, then the conditional in new bfd-types would still be valid.=0A= =0A= Tom Petch=0A= Andy=0A= =0A= =0A= =0A= I realise that such as NACM can always make part of the tree invisible so s= oftware has to be prepared for something to be missing but I am not confide= nt of my interpretation.=0A= =0A= Tom Petch=0A= Lada=0A= =0A= > The module bfd-types is imported by a number of other modules such=0A= > as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be=0A= > made mandatory by its usage in another module. I raised this on the=0A= > BFD list and the WG Chair tells me that this is a violation of the=0A= > intent of the RFC, 7950, but that it has been reviewed by YANG=0A= > doctors and is probably the best fix.=0A= >=0A= > If YANG Doctors collectively say that this violation is ok, then I think = that such a statement needs to appear on the Netmod WG list.=0A= >=0A= > I think that there are a lot of other editorial changes needed to 9127-bi= s to make it legal but they can come later. The I-D is in WG Last Call end= ing 20Dec2021=0A= >=0A= > Tom Petch=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= From nobody Thu Dec 9 04:44: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 EC2973A0AF9 for ; Thu, 9 Dec 2021 04:44:30 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 Ftplg2OpyjGn for ; Thu, 9 Dec 2021 04:44:26 -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 8431E3A0AF7 for ; Thu, 9 Dec 2021 04:44:26 -0800 (PST) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4J8tsj06qTz689Hq; Thu, 9 Dec 2021 20:40:09 +0800 (CST) Received: from kwepemm000020.china.huawei.com (7.193.23.93) 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.2308.20; Thu, 9 Dec 2021 13:44:23 +0100 Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm000020.china.huawei.com (7.193.23.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 9 Dec 2021 20:44:21 +0800 Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2308.020; Thu, 9 Dec 2021 20:44:21 +0800 From: "maqiufang (A)" To: "Sterne, Jason (Nokia - CA/Ottawa)" CC: "netmod@ietf.org" Thread-Topic: [netmod] Should the "with-origin" parameter be supported for ? Thread-Index: AdffkIzQgrflx2pfQFG03vlrV2MIPQM9JcDgABNIqyA= Date: Thu, 9 Dec 2021 12:44:21 +0000 Message-ID: <5948edacb10345aa8a65933609081a92@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.87] Content-Type: multipart/alternative; boundary="_000_5948edacb10345aa8a65933609081a92huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Should the "with-origin" parameter be supported for ? 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, 09 Dec 2021 12:44:31 -0000 --_000_5948edacb10345aa8a65933609081a92huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Jason Thanks for kicking off some discussion around this question. Please see my reply inline. From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:jason.sterne@nokia.com] Sent: Thursday, December 9, 2021 6:51 AM To: maqiufang (A) ; netmod@ietf.org Subject: RE: [netmod] Should the "with-origin" parameter be supported for <= intended>? Hi Qiufang, In your first option, did you mean "understand a certain data node is from = or from " ? [Qiufang Ma] Yes, you're correct. We already define that a data node which = is present in and not overwritten by will appear in with "origin=3Dsystem" as always when applied successfully. So th= e server needs to remember whether a particular data node in is = from or from . The question is should the server expose t= his source information to the client. It is an interesting question about whether the origin annotation could/sho= uld be available in a read from , and what values that origin cou= ld take. We should consider other transformations between and (= besides the merging of ): - active/inactive config - configuration templates Inactive config would simply be stripped and not appear in at al= l. So nothing to discuss for that. But would elements provided from within config templates have an 'origin' t= hat indicates what template it came from ? [Qiufang Ma] I am not quite sure what do you mean by "what template it came= from". But for the client-defined template in , elements provided= from within the config template will exist in and finally have = an origin=3D"intended" when present in . I believe that this i= s already well defined in NMDA work. I suppose the same question could apply to 'origin' in the DS= . Having origin purely available in the operational DS may not be complete en= ough. Some config nodes may not be present in operational because they are = not "applied". So you wouldn't necessarily be able to get the full picture = of the origin of all intended config by just checking the origin in the DS. Maybe that's an argument to have an origin in ? [Qiufang Ma] That is a good point. only contains those are ac= tually used by the system. It might be useful if a client can fetch can understand the origin of some data nodes which is after configurati= on transformation(e.g., client-defined/system-defined templates expansion) = but may not be successfully applied by the device. Best Regards, Qiufang Ma Jason From: netmod > On B= ehalf Of maqiufang (A) Sent: Monday, November 22, 2021 7:11 AM To: netmod@ietf.org Subject: [netmod] Should the "with-origin" parameter be supported for ? Hi, all In the "system-defined configuration(draft-ma-netmod-with-system)" work, an= optional datastore named "system" is introduced to hold non-deletable syst= em configurations. We define that if a server implements , MUST be merged i= nto . So there is the cases that the clients can fetch and contains merged . The question is should we extend the "with-origin" parameter to support ? The possible considerations for following two choices: o "with-origin" parameter should be supported for ? It may be helpful for a client to fetch to understand a certa= in data node is from or from o There is no need for to support "with-origin" ? We already have to provide the origin for a particular dat= a node Any thoughts on this? Best Regards, Qiufang Ma --_000_5948edacb10345aa8a65933609081a92huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Jason

Thanks for kicking off= some discussion around this question.

Please see my reply in= line.

 

From: Sterne, Ja= son (Nokia - CA/Ottawa) [mailto:jason.sterne@nokia.com]
Sent: Thursday, December 9, 2021 6:51 AM
To: maqiufang (A) <maqiufang1@huawei.com>; netmod@ietf.org
Subject: RE: [netmod] Should the "with-origin" parameter b= e supported for <intended>?

 

Hi Qiufang,

 

In your first option, did you mean "= ;understand a certain data node is from <running> or from <system&= gt;" ?

[Qiufang Ma] Yes, you’re correct. We alread= y define that a data node which is present in <system> and not overwr= itten by <running> will appear in <operational> with “origin=3Dsystem” as always when applied successfully. So the = server needs to remember whether a particular data node in <intended>= is from <running> or from <system>. The question is should the= server expose this source information to the client.

 

It is an interesting question about whet= her the origin annotation could/should be available in a read from <inte= nded>, and what values that origin could take.

 

We should consider other transformations= between <running> and <intended> (besides the merging of <s= ystem>):

- active/inactive config

- configuration templates

 

Inactive config would simply be stripped= and not appear in <intended> at all. So nothing to discuss for that.=

 

But would elements provided from within = config templates have an 'origin' that indicates what template it came from= ?

[Qiufang Ma] I am not quite sure what do you mean= by “what template it came from”. But for the client-defined te= mplate in <running>, elements provided from within the config template will exist in <intended> and finally have an ori= gin=3D”intended” when present in <operational>. I believe= that this is already well defined in NMDA work.<= /p>

 

I suppose the same question could apply = to 'origin' in the <operational> DS.

 

Having origin purely available in the op= erational DS may not be complete enough. Some config nodes may not be prese= nt in operational because they are not "applied". So you wouldn't necessarily be able to get the full picture of the origin = of all intended config by just checking the origin in the <operational&g= t; DS. Maybe that's an argument to have an origin in <intended> ?

[Qiufang Ma] That is a good point. <operationa= l> only contains those are actually used by the system. It might be usef= ul if a client can fetch <intended> can understand the origin of some data nodes which is after configuration transformation(= e.g., client-defined/system-defined templates expansion) but may not be suc= cessfully applied by the device.

 

Best Regards,

Qiufang Ma

 

Jason

 

From: netmod <= ;netmod-bounces@ietf.org> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:11 AM
To: netmod@ietf.org
Subject: [netmod] Should the "with-origin" parameter be su= pported for <intended>?

 

Hi, all<= /span>

 

In the “syste= m-defined configuration(draft-ma-netmod-with-system)” work, an option= al datastore named “system” is introduced to hold non-deletable system configurations.

We define that if a= server implements <intended>, <system> MUST be merged into <= ;intended>.  So there is the cases that the clients can fetch <i= ntended> and <intended> contains merged <system>.

The question is sho= uld we extend the “with-origin” parameter to support <intend= ed>? The possible considerations for following two choices:

o  “with-origin” parameter shou= ld be supported for <intended>

§  It may be helpful for a client to fetch = <intended> to understand a certain data node is from <running> = or from <intended>

o  There is no need for <intended> to= support “with-origin”

§  We already have <operational> to p= rovide the origin for a particular data node

Any thoughts on thi= s?

 

 

Best Regards,<= /o:p>

Qiufang Ma

 

--_000_5948edacb10345aa8a65933609081a92huaweicom_-- From nobody Thu Dec 9 04:57: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 014843A0B15 for ; Thu, 9 Dec 2021 04:57:29 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 9T2Nbx6vvV7N for ; Thu, 9 Dec 2021 04:57:24 -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 E0B443A0B0E for ; Thu, 9 Dec 2021 04:57:23 -0800 (PST) Received: from fraeml706-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4J8vD75QC3z67MYc; Thu, 9 Dec 2021 20:56:07 +0800 (CST) Received: from kwepemm000019.china.huawei.com (7.193.23.135) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Thu, 9 Dec 2021 13:57:19 +0100 Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm000019.china.huawei.com (7.193.23.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 9 Dec 2021 20:57:17 +0800 Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2308.020; Thu, 9 Dec 2021 20:57:17 +0800 From: "maqiufang (A)" To: "Sterne, Jason (Nokia - CA/Ottawa)" CC: "netmod@ietf.org" Thread-Topic: [netmod] "immutable" flag Thread-Index: AdffmIO2eQWZH1bVQgKuM6kNhPhaAAM61mjgABANFhA= Date: Thu, 9 Dec 2021 12:57:17 +0000 Message-ID: <178f7cabbf0141b4815349dad3555bb4@huawei.com> References: <79459f02f6ea4a87bea56edc9772daa6@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.87] Content-Type: multipart/alternative; boundary="_000_178f7cabbf0141b4815349dad3555bb4huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] "immutable" flag 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, 09 Dec 2021 12:57:29 -0000 --_000_178f7cabbf0141b4815349dad3555bb4huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Jason, Thanks for your comments, please see my reply inline. From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:jason.sterne@nokia.com] Sent: Thursday, December 9, 2021 6:42 AM To: maqiufang (A) ; netmod@ietf.org Subject: RE: [netmod] "immutable" flag Hi Qiufang, I think there are use-cases for "immutable" even outside of system config s= o we may not want to restrict it to system config. [Qiufang Ma] Agree that we can just define such an "immutable" flag without= restricting it to decorating system configuration. In that way, maybe we c= an discuss whether we should define this annotation in an independent I-D. Regarding this "immutable" flag there may be a question to answer: what if= legacy clients receive some annotations they do not understand? Should the= y just ignore it silently? I'm not sure it would be as simple as erroring when a write is attempted to= that value. Are you talking about an error at edit time, or at commit/validation time ? [Qiufang Ma] My assumption is an error at edit time, static checks are suff= icient for the server to detect the problem. But I think it's also okay to = report an error at commit/validation time. What if the value configured is the same as the current value ? [Qiufang Ma] I have the same question. Some implementations do allow the cl= ient to configure a same value(e.g., for the purpose of offline validation = of ). But I feel that it may depend on the discussion of another t= hread "should the origin=3D'system' be required for system configurations c= opied/pasted into '" which I posted to the WG. If the origin=3D"in= tended" , it actually means overwrite. It is probably best if this is a validation/commit time check. If the immutable leaf is inside a list entry, then it should probably be ac= ceptable for the server to allow a change to the leaf by destroying and re-= creating the list entry under the hood. i.e. allow a change to the immutab= le item (which is in line with configurations being "declarative" - just ge= t me there if possible). [Qiufang Ma] Are you suggesting a server should allow a client to delete/cr= eate the "immutable" data item in ? Wouldn't that be a little stra= nge if a client can delete a particular data item but has no right to chang= e its value? Theoretically, the deletable is modifiable. Best Regards, Qiufang Ma Jason From: netmod > On B= ehalf Of maqiufang (A) Sent: Monday, November 22, 2021 7:12 AM To: netmod@ietf.org Subject: [netmod] "immutable" flag Hi, all There are some system configuration which may not be modifiable for clients= (e.g., interface "name" and "type"). Should we define an "immutable" flag t= o indicate to the clients which system configuration is read-only or which = is not? The server will return an error if the clients attempt to configure a value= for a system defined data node with an "immutable" flag. My assumption is that this annotation should be carried only when the clien= ts retrieve with "with-system" parameter to get a merged view. Suggestions, comments and concerns about this issue? Best Regards, Qiufang Ma --_000_178f7cabbf0141b4815349dad3555bb4huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Jason,<= /span>

 

Thanks for your commen= ts, please see my reply inline.

 

From: Sterne, Ja= son (Nokia - CA/Ottawa) [mailto:jason.sterne@nokia.com]
Sent: Thursday, December 9, 2021 6:42 AM
To: maqiufang (A) <maqiufang1@huawei.com>; netmod@ietf.org
Subject: RE: [netmod] "immutable" flag

 

Hi Qiufang,

 

I think there are use-cases for "im= mutable" even outside of system config so we may not want to restrict = it to system config.

[Qiufang Ma] Agree that we can just define such a= n “immutable” flag without restricting it to decorating system = configuration. In that way, maybe we can discuss whether we should define this annotation in an independent I-D.<= /i>

Regarding this “immutable” flag  = ;there may be a question to answer: what if legacy clients receive some ann= otations they do not understand? Should they just ignore it silently?

 

I'm not sure it would be as simple as er= roring when a write is attempted to that value. 

 

Are you talking about an error at edit t= ime, or at commit/validation time ?

[Qiufang Ma] My assumption is an error at edit ti= me, static checks are sufficient for the server to detect the problem. But = I think it’s also okay to report an error at commit/validation time.

What if the value configured is the same= as the current value ?

[Qiufang Ma] I have the same question. Some imple= mentations do allow the client to configure a same value(e.g., for the purp= ose of offline validation of <running>). But I feel that it may depend on the discussion of another thread “s= hould the origin=3D’system’ be required for system configuratio= ns copied/pasted into <running>’” which I posted to the W= G. If the origin=3D“intended” , it actually means overwrite.

 

It is probably best if this is a validat= ion/commit time check.

 

If the immutable leaf is inside a list e= ntry, then it should probably be acceptable for the server to allow a chang= e to the leaf by destroying and re-creating the list entry under the hood.  i.e. allow a change to the immutable = item (which is in line with configurations being "declarative" - = just get me there if possible).

[Qiufang Ma] Are you suggesting a server should a= llow a client to delete/create the “immutable” data item in <= ;running>? Wouldn't that be a little strange if a client can delete a particular data item but has no right to change its value? &n= bsp;Theoretically, the deletable is modifiable.

 

Best Regards,

Qiufang Ma

 

Jason

 

From: netmod <= ;netmod-bounces@ietf.org> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:12 AM
To: netmod@ietf.org
Subject: [netmod] "immutable" flag

 

Hi, all<= /span>

 

There are some syst= em configuration which may not be modifiable for clients(e.g., interface &#= 8220;name” and “type”). Should we define an “immuta= ble” flag to indicate to the clients which system configuration is read-only or= which is not?

 

The server will ret= urn an error if the clients attempt to configure a value for a system defin= ed data node with an “immutable” flag.

 

My assumption is th= at this annotation should be carried only when the clients retrieve <run= ning> with “with-system” parameter to get  a merged view.

 

Suggestions, commen= ts and concerns about this issue?

 

 

Best Regards,<= /o:p>

Qiufang Ma

--_000_178f7cabbf0141b4815349dad3555bb4huaweicom_-- From nobody Thu Dec 9 05:07: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 111623A0B42 for ; Thu, 9 Dec 2021 05:07:21 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 jUIH7jK_3G-a for ; Thu, 9 Dec 2021 05:07:16 -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 BAE303A0B3F for ; Thu, 9 Dec 2021 05:07:15 -0800 (PST) Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4J8vN06NWfz67kNP; Thu, 9 Dec 2021 21:02:56 +0800 (CST) Received: from kwepemm000020.china.huawei.com (7.193.23.93) 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.2308.20; Thu, 9 Dec 2021 14:07:11 +0100 Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm000020.china.huawei.com (7.193.23.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 9 Dec 2021 21:07:09 +0800 Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2308.020; Thu, 9 Dec 2021 21:07:09 +0800 From: "maqiufang (A)" To: Andy Bierman , "Sterne, Jason (Nokia - CA/Ottawa)" CC: Juergen Schoenwaelder , Jan Lindblad , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] Must offline-validation of alone be valid? Thread-Index: AdffkR5mw0pyFtGVS9uFCu3u8tPNZAAfJr4AAAKFEoAADiYHAAE2j/QAAK+uFwAAAPEZAAABOHuAARORhgAAAKZygAAuWrDQ Date: Thu, 9 Dec 2021 13:07:09 +0000 Message-ID: <4010d6892a4b42249a5d3fda5d511788@huawei.com> References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.87] Content-Type: multipart/alternative; boundary="_000_4010d6892a4b42249a5d3fda5d511788huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 09 Dec 2021 13:07:21 -0000 --_000_4010d6892a4b42249a5d3fda5d511788huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbA0KDQpJIGFncmVlIHRoYXQgb3B0aW9uICMxIHdpbGwgb3ZlcndoZWxtIGEgY2xpZW50 IHNldmVyZWx5Lg0KDQpBdm9pZC1jb3B5aW5nIGFuZCBjbGllbnQtY29udHJvbCBvdmVyIDxydW5u aW5nPiB3cml0dGVuIGluIHRoZSBpbnRyb2R1Y3Rpb24gb2YgZHJhZnQtbWEtbmV0bW9kLXdpdGgt c3lzdGVtLTAwIGFyZSBhY3R1YWxseSB0d28gY29tcGV0aW5nIG9iamVjdGl2ZXMsIGlmIHRoZSBX RyB0aGlua3Mgb2ZmbGluZS12YWxpZGF0aW9uIG9mIDxydW5uaW5nPiBhbG9uZSBJUyByZXF1aXJl ZCwNCkkgdGhpbmsgd2UgbmVlZCB0byBtYWtlIGEgY29tcHJvbWlzZS4gT3B0aW9uICMyIG1heSBw cm92aWRlIGEgZ29vZCBzdGFydGluZyBwb2ludC4NCg0KUmVnYXJkaW5nIG9wZW4gIzMsIGl0IGlz IG5hdHVyYWwgZm9yIHRoZSBjbGllbnRzIHRvIGJlbGlldmUgdGhhdCB3aGF0IHRoZXkgcmVhZCBi YWNrIGZyb20gdGhlIHNlcnZlciBpcyBleGFjdGx5IHdoYXQgdGhleSBzZW50IHRvIHRoZSBzZXJ2 ZXIuDQpJZiB0aGVyZSBpcyBhICJzeXN0ZW0gY2xpZW50IiBwbGF5aW5nIGEgcm9sZSwgdGhpcyB3 b3VsZCByZXF1aXJlIHNvbWUgZXh0cmEgaGFuZGxpbmcgZm9yIHRoZSBvdGhlciByZW1vdGUgY2xp ZW50cyBhbmQgYnJpbmcgdGhlbSBzdXJwcmlzZSBhbmQgaW5jb252ZW5pZW5jZS4NCg0KQmVzdCBS ZWdhcmRzLA0KUWl1ZmFuZyBNYQ0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1 bWF3b3Jrcy5jb21dDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgOSwgMjAyMSA2OjUwIEFNDQpU bzogU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2EpIDxqYXNvbi5zdGVybmVAbm9raWEu Y29tPg0KQ2M6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPjsgSmFuIExpbmRibGFkIDxqYW5sQHRhaWwtZi5jb20+OyBLZW50IFdhdHNl biA8a2VudEB3YXRzZW4ubmV0PjsgbWFxaXVmYW5nIChBKSA8bWFxaXVmYW5nMUBodWF3ZWkuY29t PjsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gTXVzdCBvZmZsaW5lLXZh bGlkYXRpb24gb2YgPHJ1bm5pbmc+IGFsb25lIGJlIHZhbGlkPw0KDQoNCg0KT24gV2VkLCBEZWMg OCwgMjAyMSBhdCAyOjMxIFBNIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EvT3R0YXdhKSA8amFz b24uc3Rlcm5lQG5va2lhLmNvbTxtYWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNvbT4+IHdyb3Rl Og0KSGkgZ3V5cywNCg0KQW5keSAtIGFib3V0IHVzZSBjYXNlcy4gIEhlcmUgaXMgYSBwcm9ibGVt IHdlJ3JlIHRyeWluZyB0byBhZGRyZXNzOg0KDQpUaGVyZSBhcmUgYXQgbGVhc3Qgc2V2ZXJhbCBt YWpvciByb3V0ZXIgaW1wbGVtZW50YXRpb25zIHRoYXQgaGF2ZSB0aGlzIGNvbmNlcHQgb2YgImhp ZGRlbiBjb25maWciIChpLmUuIGxpc3QgZW50cmllcyB0aGF0IGNhbiBiZSByZWZlcmVuY2VkIGlu IGEgbGVhZnJlZiBieSBleHBsaWNpdCB1c2VyIGNvbmZpZywgYnV0IHRob3NlIGxpc3QgZW50cmll cyBhcmUgbm90IHJldHVybmVkIGluIGEgPGdldC1jb25maWc+KS4NCg0KDQoNCkNsZWFybHkgbm90 IGluIGNvbXBsaWFuY2Ugd2l0aCBSRkMgNzk1MC4NCg0KSU1PIHRoZSAiZW5hYmxlIGZsYWciIGFw cHJvYWNoIHRvIHRoZSBnZW5lcmFsIHByb2JsZW0sIHByZXNlbnRlZCBieSBLZW50IGEgY291cGxl IHllYXJzIGFnbywNCmlzIGEgbXVjaCBzaW1wbGVyIGFuZCBiZXR0ZXIgc29sdXRpb24gdGhhbiBh IG5ldyA8c3lzdGVtPiBkYXRhc3RvcmUuDQpUaGUgZnVsbCBzZXQgb2Ygbm9kZXMgaXMgaW4gPHJ1 bm5pbmc+Lg0KQSBnZW5lcmFsaXplZCAiZW5hYmxlIiBtZWNoYW5pc20gY2F1c2VzIHRoZSByZXNv dXJjZSB0byBiZSB1c2VkIG9yIG5vdCwNCndoZXJlIGl0IHNob3dzIHVwIGluIDxpbnRlbmRlZD4g YW5kIDxvcGVyYXRpb25hbD4gaWYgZW5hYmxlZD10cnVlLg0KDQpJTU8gdGhpcyBmaXRzIHRoZSBv cmlnaW5hbCBpbnRlbnQgb2YgTk1EQSBhbmQgZG9lcyBzbyBpbiBhIHdheSB0aGF0IHJlcXVpcmVz DQp0aGUgbGVhc3QgZGlzcnVwdGlvbiB0byBjdXJyZW50IGNvbXBsaWFudCBpbXBsZW1lbnRhdGlv bnMuDQoNCkFuZHkNCg0KDQpUaGUgc2VydmVyIGFjY2VwdHMgdGhlc2UgY29uZmlndXJhdGlvbnMg KGkuZS4gYSB2YWxpZGF0ZSBvciBjb21taXQgc3VjY2VlZHMpLCBidXQgaWYgeW91IGFjdHVhbGx5 IHZhbGlkYXRlIChlLmcuIHdpdGggeWFuZ0xpbnQpIHRoZSBydW5uaW5nIGRhdGFzdG9yZSBjb250 ZW50cyAoZS5nLiBmZXRjaGVkIHVzaW5nIDxnZXQtY29uZmlnPikgdG8gdGhlIFlBTkcgbW9kZWwg aXQgaXMgbm90IHZhbGlkLiBUaGF0IGlzIGFnYWluc3Qgc2V2ZXJhbCBSRkNzIHJlZmVyZW5jZWQg aW4gdGhlIGRpc2N1c3Npb25zIGJlbG93Lg0KDQpJTU8gdGhlcmUgaXNuJ3QgYW55ICJvZmZsaW5l IiB2cyIgb25saW5lIiB2YWxpZGF0aW9uIHRoYXQgaXMgZGlmZmVyZW50LiBUaGUgY29udGVudHMg b2YgdGhlIHJ1bm5pbmcgbXVzdCBiZSB2YWxpZCBhZ2FpbnN0IHRoZSBZQU5HIG1vZGVsLiAgQSA8 Z2V0LWNvbmZpZz4gcmV0dXJucyB0aGUgY29udGVudHMgb2YgdGhlIHJ1bm5pbmcuICBUaGUgc2Vy dmVyIGNhbiB2YWxpZGF0ZSBpdCwgb3Igc29tZSBvdGhlciBlbnRpdHkgY2FuIHZhbGlkYXRlIGl0 LCBidXQgaXQgbXVzdCBiZSB2YWxpZC4NCg0KSW4gSmFuJ3Mgb3B0aW9uICMxIHRoZSBydW5uaW5n IGNvbmZpZyBjb3VsZCBiZSBwb2xsdXRlZCB3aXRoIDEwMHMgb3IgMTAwMHMgb2YgbGluZXMgb2Yg dW5yZWZlcmVuY2VkL3VudXNlZCBjb25maWcuIEEgPGdldC1jb25maWc+IG9mIGEgc3lzdGVtIHdp dGhvdXQgbXVjaCBjb25maWcgd291bGQgaW5zdGVhZCByZXR1cm4gMTAwcy8xMDAwcyBvZiBsaW5l cy4gSSB0aGluayB0aGF0IHdvdWxkIGJlIHZlcnkgYW5ub3lpbmcgZnJvbSBhIHVzYWJpbGl0eSBw ZXJzcGVjdGl2ZS4NCg0KSSdtIGluIGZhdm9yIG9mIHRoaXMgYXNwZWN0IG9mIEphbidzIG9wdGlv biAjMjogICIgKyBDbGllbnRzIHVuYXdhcmUgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUgd291bGQg aGF2ZSB0byBpbmNsdWRlIChjb3B5KSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBzeXN0ZW0gZGF0YXN0 b3JlIHRvIHJ1bm5pbmcgaW4gb3JkZXIgdG8gcmVmZXJlbmNlIHRoZW0uIg0KDQotPiBPbmx5IHRo ZSBsaXN0IGtleXMgb2YgcmVmZXJlbmNlZCBzeXN0ZW0gb2JqZWN0cyB3b3VsZCBoYXZlIHRvIGJl IGNvcGllZCAoY29uZmlndXJlZCkgaW50byB0aGUgcnVubmluZyBEUyAodG8gcmVzb2x2ZSBsZWFm cmVmcykuICBXZSB3b3VsZG4ndCBuZWVkIHRvIGNvcHkgYWxsIHRoZSBkZXNjZW5kYW50IGVsZW1l bnRzIGluc2lkZSB0aGUgcmVmZXJlbmNlZCBvYmplY3QuDQotPiBUaGlzIGNvcHlpbmcgd291bGQg b25seSBuZWVkIHRvIGJlIGRvbmUgYnkgb3BlcmF0b3JzIHdpdGggYSB3b3JrZmxvdyB0aGF0IHJl cXVpcmVzIG9mZmxpbmUgdmFsaWRhdGlvbg0KDQpTb21lIG9mIHRoaXMgYXBwcm9hY2ggaXMgYWxy ZWFkeSBkZXNjcmliZWQgaW4gZHJhZnQtbWEtbmV0bW9kLXdpdGgtc3lzdGVtLTAxOg0KDQoiICAg SW4gYWxsIGNhc2VzLCB0aGUgY2xpZW50cyBzaG91bGQgaGF2ZSBjb250cm9sIG92ZXIgdGhlIGNv bmZpZ3VyYXRpb25zDQogICAsaS5lLiwgcmVhZC1iYWNrIG9mIDxydW5uaW5nPiBzaG91bGQgY29u dGFpbiBvbmx5IHdoYXQgd2FzIGV4cGxpY2l0bHkNCiAgIHNldCBieSBjbGllbnRzLiINCg0KDQoi NC4zLiAgRXhwbGljaXQgZGVjbGFyYXRpb24gb2Ygc3lzdGVtIGNvbmZpZ3VyYXRpb24NCg0KICAg SW4gYWRkaXRpb24gdG8gbW9kaWZ5aW5nIHN5c3RlbSBjb25maWd1cmF0aW9uLCBhbmQgYWRkaW5n IG5vZGVzIHRvDQogICBsaXN0cyBpbiBzeXN0ZW0gY29uZmlndXJhdGlvbiBhcyBkZXNjcmliZWQg YWJvdmUsIGEgY2xpZW50IGNhbiBhbHNvDQogICBleHBsaWNpdGx5IGRlY2xhcmUgc3lzdGVtIGNv bmZpZ3VyYXRpb24gbm9kZXMgaW4gPHJ1bm5pbmc+IHdpdGggdGhlDQogICBzYW1lIHZhbHVlcyBh cyBpbiA8c3lzdGVtPi4gIFdoZW4gYSBjbGllbnQgY29uZmlndXJlcyBhIG5vZGUgKGxpc3QNCiAg IGVudHJ5LCBsZWFmLCBldGMpIGluIDxydW5uaW5nPiB0aGF0IG1hdGNoZXMgdGhlIHNhbWUgbm9k ZSAmIHZhbHVlIGluDQogICA8c3lzdGVtPiwgdGhlbiB0aGF0IG5vZGUgYmVjb21lcyBwYXJ0IG9m IDxydW5uaW5nPi4gIEEgcmVhZCBvZg0KICAgPHJ1bm5pbmc+IHJldHVybnMgdGhvc2UgZXhwbGlj aXRseSBjb25maWd1cmVkIG5vZGVzLg0KDQogICBUaGlzIGV4cGxpY2l0IGNvbmZpZ3VyYXRpb24g b2Ygc3lzdGVtIGNvbmZpZ3VyYXRpb24gaW4gPHJ1bm5pbmc+IGNhbg0KICAgYmUgdXNlZnVsLCBm b3IgZXhhbXBsZSwgd2hlbiBhbiBvcGVyYXRvcidzIHdvcmtmbG93IHJlcXVpcmVzIGEgY2xpZW50 DQogICBvciBvZmZsaW5lIHRvb2wgdG8gc2VlIHRoZSA8cnVubmluZz4gY29uZmlndXJhdGlvbiBh cyB2YWxpZC4gIFRoZQ0KICAgY2xpZW50IGNhbiBleHBsaWNpdGx5IGRlY2xhcmUgKGkuZS4gIGNv bmZpZ3VyZSBpbiA8cnVubmluZz4pIHRoZSBsaXN0DQogICBlbnRyaWVzICh3aXRoIGF0IGxlYXN0 IHRoZSBrZXlzKSBmb3IgYW55IHN5c3RlbSBjb25maWd1cmF0aW9uIGxpc3QNCiAgIGVudHJpZXMg dGhhdCBhcmUgcmVmZXJlbmNlZCBlbHNld2hlcmUgaW4gPHJ1bm5pbmc+LiAgVGhlIGNsaWVudCBk b2VzDQogICBub3QgbmVjZXNzYXJpbHkgbmVlZCB0byBkZWNsYXJlIGFsbCB0aGUgY29udGVudHMg b2YgdGhlIGxpc3QgZW50cnkNCiAgIChpLmUuIHRoZSBkZXNjZW5kYW50IG5vZGVzKSAtIG9ubHkg dGhlIHBhcnRzIHRoYXQgYXJlIHJlcXVpcmVkIHRvDQogICBtYWtlIHRoZSA8cnVubmluZz4gYXBw ZWFyIHZhbGlkIG9mZmxpbmUuICAiDQoNCkknbSBub3QgYSBmYW4gb2Ygb3B0aW9uICMzLiBJdCBk b2Vzbid0IGFsbG93IGEgbW9kZSBvZiBvcGVyYXRpbmcgd2hlcmUgYSBjbGllbnQvT1NTIGhhcyBm dWxsIGNvbnRyb2wgb3ZlciB0aGUgY29udGVudHMgb2YgdGhlIDxydW5uaW5nPi4gIFNvbWUgb3Bl cmF0b3JzIHdpbGwgd2FudCB0aGUgbWFzdGVyIGNvbmZpZyB0byBiZSBvd25lZCB1cCBpbiB0aGVp ciBjbGllbnQvT1NTIGFuZCBwdXNoIGl0IGRvd24uIFRoZSBzZXJ2ZXIgc2hvdWxkIGp1c3QgYWNj ZXB0IGl0IGFuZCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIGRvIGEgInJlYWQtYmFjayIg YW5kIHNlZSBleGFjdGx5IHdoYXQgd2FzIHNlbnQgcHJldmlvdXNseS4NCg0KSSB0aGluayB3ZSBo YXZlIGEgcG90ZW50aWFsIHNvbHV0aW9uIGZvciB0aGlzIHN5c3RlbSBjb25maWcgdGhhdCBrZWVw cyB0aGUgcnVubmluZyB2YWxpZC4gQnV0IEknbSBmYXIgbW9yZSB3b3JyaWVkIGFib3V0IGNvbmZp Z3VyYXRpb24gdGVtcGxhdGVzLiBJIGRvbid0IHNlZSBob3cgd2UgY2FuIHBvc3NpYmx5IGtlZXAg PHJ1bm5pbmc+IHZhbGlkIHdpdGggY29uZmlnIHRlbXBsYXRlcy4gVGhhdCBzZWVtcyBsaWtlIGEg bWFqb3IgcHJvYmxlbSB0byBtZS4gQnV0IGlmIHdlIGV2ZXIgZGVjbGFyZSB0aGF0IDxydW5uaW5n PiBkb2Vzbid0IGhhdmUgdG8gYmUgdmFsaWQsIGFuZCBvbmx5IDxpbnRlbmRlZD4gaGFzIHRvIGJl IHZhbGlkLCB0aGVuIG9mZmxpbmUgdG9vbHMgY2FuIG5ldmVyIHZhbGlkYXRlIChhaGVhZCBvZiB0 aW1lKSB0aGUgY29uZmlnIHRoZXkgYWN0dWFsbHkgZG93bmxvYWQgdG8gdGhlIHNlcnZlci4NCg0K SmFzb24NCg0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6 IEZyaWRheSwgRGVjZW1iZXIgMywgMjAyMSA2OjAxIEFNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVs ZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+OyBKYW4gTGluZGJsYWQgPGphbmxAdGFpbC1m LmNvbTxtYWlsdG86amFubEB0YWlsLWYuY29tPj47IEtlbnQgV2F0c2VuIDxrZW50QHdhdHNlbi5u ZXQ8bWFpbHRvOmtlbnRAd2F0c2VuLm5ldD4+OyBtYXFpdWZhbmcgKEEpIDxtYXFpdWZhbmcxPTQw aHVhd2VpLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBodWF3ZWkuY29tQGRtYXJjLmlldGYu b3JnPj47IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtuZXRtb2RdIE11c3Qgb2ZmbGluZS12YWxpZGF0aW9uIG9mIDxydW5uaW5nPiBhbG9uZSBi ZSB2YWxpZD8NCg0KDQoNCk9uIEZyaSwgRGVjIDMsIDIwMjEgYXQgMjoyNiBBTSBKw7xyZ2VuIFNj aMO2bnfDpGxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQpPbiBGcmksIERl YyAwMywgMjAyMSBhdCAxMDo1OToxMkFNICswMTAwLCBKYW4gTGluZGJsYWQgd3JvdGU6DQoNCj4g SSBtYWRlIHNvbWUgcHJvcG9zYWxzIGVhcmxpZXIsIGJvdGggb24gdGhlIGludGVyaW0gYW5kIHBy aXZhdGVseSB0byB0aGUgZHJhZnQgYXV0aG9ycywgYWxvbmcgdGhlc2UgbGluZXM6DQo+DQo+IE9w dGlvbiAjMQ0KPiArIFdlIGNvdWxkIGhhdmUgYSBuZXcgc3lzdGVtIGRhdGFzdG9yZSB0aGF0IHRl Y2huaWNhbGx5IGlzIGEgcGFydCBvZiBydW5uaW5nLiBFdmVyeXRoaW5nIGluIHN5c3RlbSB3b3Vs ZCBzaG93IHVwIGluIHJ1bm5pbmcgdG8gIGNsaWVudHMgdW5hd2FyZSBvZiB0aGUgc3lzdGVtIGRh dGFzdG9yZS4gRXZlcnkgdGltZSB0aGUgc3lzdGVtIGRhdGFzdG9yZSBjaGFuZ2VzIGZvciB3aGF0 ZXZlciByZWFzb24sIHRoZSBydW5uaW5nIGRhdGFzdG9yZSB0cmFuc2FjdGlvbiBpZHMgKGlmIHdl IG1hbmFnZSB0byBnZXQgdGhhdCBjb25jZXB0IGRlZmluZWQpLCBhcmUgdXBkYXRlZA0KPiArIENs aWVudHMgaW50ZXJlc3RlZCB0byBzZWUgcHVyZSB2aWV3IG9mIHRoZSBzeXN0ZW0gZGF0YXN0b3Jl IHdpdGhvdXQgYW55dGhpbmcgZWxzZSBpbiBydW5uaW5nIGNvdWxkIGlzc3VlIGEgZ2V0LWRhdGEg dG93YXJkcyB0aGUgc3lzdGVtIGRhdGFzdG9yZQ0KPiArIENsaWVudHMgaW50ZXJlc3RlZCB0byBz ZWUgYSBwdXJlIHZpZXcgb2YgcnVubmluZyB3aXRob3V0IGFueSBzeXN0ZW0gZGF0YXN0b3JlIGVs ZW1lbnRzIGNvdWxkIGlzc3VlIGEgZ2V0LWRhdGEgdG93YXJkcyBydW5uaW5nIHdpdGggYW4gZXh0 cmEgZmxhZyBjYWxsZWQgJ3dpdGhvdXQtc3lzdGVtJw0KPiArIFNpbmNlIGFsbCBzeXN0ZW0gZWxl bWVudHMgYXJlIGFscmVhZHkgcGFydCBvZiBydW5uaW5nLCBjbGllbnRzIGhhdmUgbm8gbmVlZCB0 byBjb3B5IGRhdGEgYmV0d2VlbiB0aGUgdHdvIGRhdGFzdG9yZXMNCj4NCj4gT3B0aW9uICMyDQo+ ICsgV2UgY291bGQgaGF2ZSBhIHN5c3RlbSBkYXRhc3RvcmUgdGhhdCB0ZWNobmljYWxseSBpcyBh IHBhcnQgb2Ygb3BlcmF0aW9uYWwuIEV2ZXJ5dGhpbmcgaW4gc3lzdGVtIHdvdWxkIHNob3cgdXAg aW4gb3BlcmF0aW9uYWwgdG8gIGNsaWVudHMgdW5hd2FyZSBvZiB0aGUgc3lzdGVtIGRhdGFzdG9y ZS4gVGhlIHJ1bm5pbmcgZGF0YXN0b3JlIGFsd2F5cyBtYWludGFpbnMgcmVmZXJlbnRpYWwgaW50 ZWdyaXR5LCBpLmUuIGNhbm5vdCByZWZlcmVuY2UgdGhlIHN5c3RlbSBkYXRhc3RvcmUuDQo+ICsg Q2xpZW50cyBpbnRlcmVzdGVkIHRvIHNlZSBwdXJlIHZpZXcgb2YgdGhlIHN5c3RlbSBkYXRhc3Rv cmUgY291bGQgaXNzdWUgYSBnZXQtZGF0YSB0b3dhcmRzIHRoZSBzeXN0ZW0gZGF0YXN0b3JlDQo+ ICsgU2luY2UgdGhlIHN5c3RlbSBkYXRhc3RvcmUgaXMgbm90IHBhcnQgb2YgcnVubmluZywgY2xp ZW50cyBjYW4gYWxyZWFkeSBzZWUgYSBwdXJlIHZpZXcgb2YgcnVubmluZyB3aXRob3V0IGFueSBz eXN0ZW0gZGF0YXN0b3JlIGVsZW1lbnRzIHVzaW5nIGEgc2ltcGxlIGdldC1kYXRhLg0KPiArIENs aWVudHMgdGhhdCBhcmUgYXdhcmUgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUgYW5kIGFyZSBpbnRl cmVzdGVkIHRvIGNvbmZpZ3VyZSByZWZlcmVuY2VzIGZyb20gcnVubmluZyB0byBzeXN0ZW0gZWxl bWVudHMgd291bGQgaXNzdWUgYW4gZWRpdC1kYXRhIHJwYyB3aXRoIHRoZSBhZGRpdGlvbmFsIGZs YWcgJ3Jlc29sdmUtc3lzdGVtLXJlZmVyZW5jZXMnLiBUaGlzIHdpbGwgbWFrZSB0aGUgc2VydmVy IGNvcHkgYW55IHN5c3RlbSBlbGVtZW50cyByZWZlcmVuY2VkIGludG8gcnVubmluZyB3aXRob3V0 IHRoZSBjbGllbnQgZG9pbmcgc28gZXhwbGljaXRseS4NCj4gKyBDbGllbnRzIHVuYXdhcmUgb2Yg dGhlIHN5c3RlbSBkYXRhc3RvcmUgd291bGQgaGF2ZSB0byBpbmNsdWRlIChjb3B5KSBpbmZvcm1h dGlvbiBmcm9tIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIHRvIHJ1bm5pbmcgaW4gb3JkZXIgdG8gcmVm ZXJlbmNlIHRoZW0uDQo+DQoNCk9wdGlvbiAjMw0KDQpUaGVyZSBpcyBhIGNsaWVudCBvbiB0aGUg c3lzdGVtIHRoYXQgbWFrZXMgY2hhbmdlcyB0byBydW5uaW5nIGp1c3QNCmxpa2UgYW55IG90aGVy IHJlbW90ZSBjbGllbnRzIGNhbiBtYWtlIGNoYW5nZXMgdG8gcnVubmluZy4gU3lzdGVtDQpnZW5l cmF0ZSBjb25maWcgdGhhdCBpcyBub3QgZWRpdGFibGUgZXhwbGljaXQgY29uZmlnIGluIHJ1bm5p bmcgZ29lcw0Kc3RyYWlnaHQgaW50byB0aGUgYXBwbGllZCBjb25maWcgaW4gb3BlcmF0aW9uYWwu IFRoaXMgZG9lcyBub3QgcmVxdWlyZQ0KYSBzeXN0ZW0gZGF0YXN0b3JlIChpbiBmYWN0IHNvbWV0 aGluZyBsaWtlIGEgc3lzdGVtIGRhdGFzdG9yZSBtYXkNCmV4aXN0IGFzIHRoZSBfbG9naWNfIG9m IHRoZSBzeXN0ZW0gY2xpZW50LCB0aGUgZ29vZCBvbGQgZXhhbXBsZSB3ZSBoYWQNCmlzIGFsbG9j dGluZyBhbiB1bnVzZWQgdWlkIGZvciBhbiBhY2NvdW50IHRoYXQsIG9uY2UgYWxsb2NhdGVkLCBp cw0KbWFpbnRhaW5lZCBpbiBydW5uaW5nKS4NCg0KDQorMSB0byBvcHRpb24gMy4NCkNvbnNpZGVy IGFuIGltcGxlbWVudGF0aW9uIHRoYXQgbW92ZXMgYWxsIHRoZSAiaGlkZGVuIHN5c3RlbSBsb2dp YyIgb2ZmLWJveA0KdG8gYSBjb250cm9sbGVyLCBzdWNoIHRoYXQgdGhlIGluaXRpYWwgY29uZmln IGlzIGxpdGVyYWxseSBzdXBwbGllZCBieSBhbiBleHRlcm5hbCBjbGllbnQuDQoNCkkgaGF2ZSB5 ZXQgdG8gaGVhciBhIHNpbmdsZSB1c2UtY2FzZSBmb3IgY3JlYXRpbmcgYSA8c3lzdGVtPiBkYXRh c3RvcmUuDQoiVGhlIGNsaWVudCBtaWdodCB3YW50IiBpcyBub3QgYSB1c2UtY2FzZSBmb3Igc3Rh bmRhcmRpemF0aW9uLg0KSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgInB1cmUgdmlldyIuIFNlZW1z IGxpa2UgaWYgdGhpcyB3YXMgYSByZWFsIHByb2JsZW0gdG8gc29sdmUsDQp0aGVuIE5NREEgd291 bGQgaGF2ZSBpbmNsdWRlZCBhIHN5c3RlbSBkYXRhc3RvcmUgZnJvbSB0aGUgc3RhcnQuDQoNCg0K L2pzDQoNCg0KQW5keQ0KDQoNCi0tDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAg ICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0 MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9k IG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K --_000_4010d6892a4b42249a5d3fda5d511788huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSwgYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVl IHRoYXQgb3B0aW9uICMxIHdpbGwgb3ZlcndoZWxtIGEgY2xpZW50IHNldmVyZWx5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXZvaWQtY29weWluZyBhbmQgY2xp ZW50LWNvbnRyb2wgb3ZlciAmbHQ7cnVubmluZyZndDsgd3JpdHRlbiBpbiB0aGUgaW50cm9kdWN0 aW9uIG9mIGRyYWZ0LW1hLW5ldG1vZC13aXRoLXN5c3RlbS0wMCBhcmUgYWN0dWFsbHkgdHdvIGNv bXBldGluZyBvYmplY3RpdmVzLCBpZiB0aGUgV0cNCiB0aGlua3Mgb2ZmbGluZS12YWxpZGF0aW9u IG9mICZsdDtydW5uaW5nJmd0OyBhbG9uZSBJUyByZXF1aXJlZCwgPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkkgdGhpbmsgd2UgbmVlZCB0byBtYWtlIGEgY29tcHJvbWlzZS4gT3B0aW9uICMyIG1heSBwcm92 aWRlIGEgZ29vZCBzdGFydGluZyBwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlJlZ2FyZGluZyBvcGVuICMzLCBpdCBpcyBuYXR1cmFsIGZvciB0aGUgY2xp ZW50cyB0byBiZWxpZXZlIHRoYXQgd2hhdCB0aGV5IHJlYWQgYmFjayBmcm9tIHRoZSBzZXJ2ZXIg aXMgZXhhY3RseSB3aGF0IHRoZXkgc2VudCB0byB0aGUgc2VydmVyLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPklmIHRoZXJlIGlzIGEgJnF1b3Q7c3lzdGVtIGNsaWVudCZxdW90OyBwbGF5aW5nIGEgcm9s ZSwgdGhpcyB3b3VsZCByZXF1aXJlIHNvbWUgZXh0cmEgaGFuZGxpbmcgZm9yIHRoZSBvdGhlciBy ZW1vdGUgY2xpZW50cyBhbmQgYnJpbmcgdGhlbSBzdXJwcmlzZSBhbmQgaW5jb252ZW5pZW5jZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+UWl1ZmFuZyBNYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDksIDIwMjEgNjo1MCBBTTxicj4NCjxiPlRv OjwvYj4gU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2EpICZsdDtqYXNvbi5zdGVybmVA bm9raWEuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7OyBKYW4gTGluZGJsYWQgJmx0 O2phbmxAdGFpbC1mLmNvbSZndDs7IEtlbnQgV2F0c2VuICZsdDtrZW50QHdhdHNlbi5uZXQmZ3Q7 OyBtYXFpdWZhbmcgKEEpICZsdDttYXFpdWZhbmcxQGh1YXdlaS5jb20mZ3Q7OyBuZXRtb2RAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIE11c3Qgb2ZmbGluZS12YWxp ZGF0aW9uIG9mICZsdDtydW5uaW5nJmd0OyBhbG9uZSBiZSB2YWxpZD88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBXZWQsIERlYyA4LCAyMDIxIGF0IDI6MzEgUE0gU3Rlcm5l LCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2EpICZsdDs8YSBocmVmPSJtYWlsdG86amFzb24uc3Rl cm5lQG5va2lhLmNvbSI+amFzb24uc3Rlcm5lQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj5IaSBn dXlzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4g bGFuZz0iRU4tQ0EiPkFuZHkgLSBhYm91dCB1c2UgY2FzZXMuJm5ic3A7IEhlcmUgaXMgYSBwcm9i bGVtIHdlJ3JlIHRyeWluZyB0byBhZGRyZXNzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0Ei PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPlRoZXJlIGFyZSBhdCBsZWFzdCBz ZXZlcmFsIG1ham9yIHJvdXRlciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBoYXZlIHRoaXMgY29uY2Vw dCBvZiAmcXVvdDtoaWRkZW4gY29uZmlnJnF1b3Q7IChpLmUuIGxpc3QgZW50cmllcyB0aGF0IGNh biBiZSByZWZlcmVuY2VkIGluIGEgbGVhZnJlZiBieSBleHBsaWNpdCB1c2VyIGNvbmZpZywgYnV0 IHRob3NlIGxpc3QgZW50cmllcyBhcmUgbm90IHJldHVybmVkIGluIGEgJmx0O2dldC1jb25maWcm Z3Q7KS4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkNsZWFy bHkgbm90IGluIGNvbXBsaWFuY2Ugd2l0aCBSRkMgNzk1MC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SU1PIHRoZSAmcXVvdDtlbmFibGUgZmxhZyZx dW90OyBhcHByb2FjaCB0byB0aGUgZ2VuZXJhbCBwcm9ibGVtLCBwcmVzZW50ZWQgYnkgS2VudCBh IGNvdXBsZSB5ZWFycyBhZ28sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5pcyBhIG11Y2ggc2ltcGxl ciBhbmQgYmV0dGVyIHNvbHV0aW9uIHRoYW4gYSBuZXcgJmx0O3N5c3RlbSZndDsgZGF0YXN0b3Jl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIGZ1bGwgc2V0IG9mIG5vZGVzIGlzIGluICZsdDty dW5uaW5nJmd0Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkEgZ2VuZXJhbGl6ZWQgJnF1b3Q7ZW5h YmxlJnF1b3Q7IG1lY2hhbmlzbSBjYXVzZXMgdGhlIHJlc291cmNlIHRvIGJlIHVzZWQgb3Igbm90 LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+d2hlcmUgaXQgc2hvd3MgdXAgaW4gJmx0O2ludGVuZGVk Jmd0OyBhbmQgJmx0O29wZXJhdGlvbmFsJmd0OyBpZiBlbmFibGVkPXRydWUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPklNTyB0aGlzIGZpdHMgdGhl IG9yaWdpbmFsIGludGVudCBvZiBOTURBIGFuZCBkb2VzIHNvIGluIGEgd2F5IHRoYXQgcmVxdWly ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnRoZSBsZWFzdCBkaXNydXB0aW9uIHRvIGN1cnJlbnQg Y29tcGxpYW50IGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Ojcy LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+VGhlIHNlcnZlciBhY2NlcHRzIHRoZXNlIGNvbmZp Z3VyYXRpb25zIChpLmUuIGEgdmFsaWRhdGUgb3IgY29tbWl0IHN1Y2NlZWRzKSwgYnV0IGlmIHlv dSBhY3R1YWxseSB2YWxpZGF0ZSAoZS5nLiB3aXRoIHlhbmdMaW50KSB0aGUgcnVubmluZyBkYXRh c3RvcmUgY29udGVudHMgKGUuZy4gZmV0Y2hlZCB1c2luZyAmbHQ7Z2V0LWNvbmZpZyZndDspIHRv IHRoZSBZQU5HIG1vZGVsIGl0IGlzIG5vdCB2YWxpZC4gVGhhdCBpcyBhZ2FpbnN0DQogc2V2ZXJh bCBSRkNzIHJlZmVyZW5jZWQgaW4gdGhlIGRpc2N1c3Npb25zIGJlbG93LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNw YW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPklNTyB0 aGVyZSBpc24ndCBhbnkgJnF1b3Q7b2ZmbGluZSZxdW90OyB2cyZxdW90OyBvbmxpbmUmcXVvdDsg dmFsaWRhdGlvbiB0aGF0IGlzIGRpZmZlcmVudC4gVGhlIGNvbnRlbnRzIG9mIHRoZSBydW5uaW5n IG11c3QgYmUgdmFsaWQgYWdhaW5zdCB0aGUgWUFORyBtb2RlbC4mbmJzcDsgQSAmbHQ7Z2V0LWNv bmZpZyZndDsgcmV0dXJucyB0aGUgY29udGVudHMgb2YgdGhlIHJ1bm5pbmcuJm5ic3A7IFRoZSBz ZXJ2ZXIgY2FuIHZhbGlkYXRlIGl0LCBvciBzb21lIG90aGVyIGVudGl0eQ0KIGNhbiB2YWxpZGF0 ZSBpdCwgYnV0IGl0IG11c3QgYmUgdmFsaWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+SW4gSmFuJ3Mgb3B0aW9uICMxIHRo ZSBydW5uaW5nIGNvbmZpZyBjb3VsZCBiZSBwb2xsdXRlZCB3aXRoIDEwMHMgb3IgMTAwMHMgb2Yg bGluZXMgb2YgdW5yZWZlcmVuY2VkL3VudXNlZCBjb25maWcuIEEgJmx0O2dldC1jb25maWcmZ3Q7 IG9mIGEgc3lzdGVtIHdpdGhvdXQgbXVjaCBjb25maWcgd291bGQgaW5zdGVhZCByZXR1cm4gMTAw cy8xMDAwcyBvZiBsaW5lcy4gSSB0aGluayB0aGF0IHdvdWxkIGJlIHZlcnkgYW5ub3lpbmcNCiBm cm9tIGEgdXNhYmlsaXR5IHBlcnNwZWN0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0Ei PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPkknbSBpbiBmYXZvciBvZiB0aGlz IGFzcGVjdCBvZiBKYW4ncyBvcHRpb24gIzI6Jm5ic3A7ICZxdW90OyAmIzQzOyBDbGllbnRzIHVu YXdhcmUgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUgd291bGQgaGF2ZSB0byBpbmNsdWRlIChjb3B5 KSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIHRvIHJ1bm5pbmcgaW4gb3Jk ZXIgdG8gcmVmZXJlbmNlIHRoZW0uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+LSZndDsgT25seSB0aGUgbGlzdCBr ZXlzIG9mIHJlZmVyZW5jZWQgc3lzdGVtIG9iamVjdHMgd291bGQgaGF2ZSB0byBiZSBjb3BpZWQg KGNvbmZpZ3VyZWQpIGludG8gdGhlIHJ1bm5pbmcgRFMgKHRvIHJlc29sdmUgbGVhZnJlZnMpLiZu YnNwOyBXZSB3b3VsZG4ndCBuZWVkIHRvIGNvcHkgYWxsIHRoZSBkZXNjZW5kYW50IGVsZW1lbnRz IGluc2lkZSB0aGUgcmVmZXJlbmNlZCBvYmplY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1D QSI+LSZndDsgVGhpcyBjb3B5aW5nIHdvdWxkIG9ubHkgbmVlZCB0byBiZSBkb25lIGJ5IG9wZXJh dG9ycyB3aXRoIGEgd29ya2Zsb3cgdGhhdCByZXF1aXJlcyBvZmZsaW5lIHZhbGlkYXRpb248bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu MHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVO LUNBIj5Tb21lIG9mIHRoaXMgYXBwcm9hY2ggaXMgYWxyZWFkeSBkZXNjcmliZWQgaW4gZHJhZnQt bWEtbmV0bW9kLXdpdGgtc3lzdGVtLTAxOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZxdW90OyZuYnNwOyZuYnNwOyBJbiBh bGwgY2FzZXMsIHRoZSBjbGllbnRzIHNob3VsZCBoYXZlIGNvbnRyb2wgb3ZlciB0aGUgY29uZmln dXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJzcDsgLGkuZS4s IHJlYWQtYmFjayBvZiAmbHQ7cnVubmluZyZndDsgc2hvdWxkIGNvbnRhaW4gb25seSB3aGF0IHdh cyBleHBsaWNpdGx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7Jm5ic3A7IHNl dCBieSBjbGllbnRzLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0i RU4tQ0EiPiZxdW90OzQuMy4mbmJzcDsgRXhwbGljaXQgZGVjbGFyYXRpb24gb2Ygc3lzdGVtIGNv bmZpZ3VyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N CjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJzcDsgSW4gYWRkaXRpb24gdG8gbW9kaWZ5aW5n IHN5c3RlbSBjb25maWd1cmF0aW9uLCBhbmQgYWRkaW5nIG5vZGVzIHRvPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3Bh biBsYW5nPSJFTi1DQSI+Jm5ic3A7Jm5ic3A7IGxpc3RzIGluIHN5c3RlbSBjb25maWd1cmF0aW9u IGFzIGRlc2NyaWJlZCBhYm92ZSwgYSBjbGllbnQgY2FuIGFsc288bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLUNBIj4mbmJzcDsmbmJzcDsgZXhwbGljaXRseSBkZWNsYXJlIHN5c3RlbSBjb25maWd1 cmF0aW9uIG5vZGVzIGluICZsdDtydW5uaW5nJmd0OyB3aXRoIHRoZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4g bGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyBzYW1lIHZhbHVlcyBhcyBpbiAmbHQ7c3lzdGVtJmd0 Oy4mbmJzcDsgV2hlbiBhIGNsaWVudCBjb25maWd1cmVzIGEgbm9kZSAobGlzdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0K PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyBlbnRyeSwgbGVhZiwgZXRjKSBpbiAmbHQ7 cnVubmluZyZndDsgdGhhdCBtYXRjaGVzIHRoZSBzYW1lIG5vZGUgJmFtcDsgdmFsdWUgaW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu MHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsmbmJzcDsgJmx0O3N5c3RlbSZndDssIHRo ZW4gdGhhdCBub2RlIGJlY29tZXMgcGFydCBvZiAmbHQ7cnVubmluZyZndDsuJm5ic3A7IEEgcmVh ZCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyAmbHQ7cnVubmlu ZyZndDsgcmV0dXJucyB0aG9zZSBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgbm9kZXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+ Jm5ic3A7Jm5ic3A7IFRoaXMgZXhwbGljaXQgY29uZmlndXJhdGlvbiBvZiBzeXN0ZW0gY29uZmln dXJhdGlvbiBpbiAmbHQ7cnVubmluZyZndDsgY2FuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1D QSI+Jm5ic3A7Jm5ic3A7IGJlIHVzZWZ1bCwgZm9yIGV4YW1wbGUsIHdoZW4gYW4gb3BlcmF0b3In cyB3b3JrZmxvdyByZXF1aXJlcyBhIGNsaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0Ei PiZuYnNwOyZuYnNwOyBvciBvZmZsaW5lIHRvb2wgdG8gc2VlIHRoZSAmbHQ7cnVubmluZyZndDsg Y29uZmlndXJhdGlvbiBhcyB2YWxpZC4mbmJzcDsgVGhlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1DQSI+Jm5ic3A7Jm5ic3A7IGNsaWVudCBjYW4gZXhwbGljaXRseSBkZWNsYXJlIChpLmUuJm5i c3A7IGNvbmZpZ3VyZSBpbiAmbHQ7cnVubmluZyZndDspIHRoZSBsaXN0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3Bh biBsYW5nPSJFTi1DQSI+Jm5ic3A7Jm5ic3A7IGVudHJpZXMgKHdpdGggYXQgbGVhc3QgdGhlIGtl eXMpIGZvciBhbnkgc3lzdGVtIGNvbmZpZ3VyYXRpb24gbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFu Zz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyBlbnRyaWVzIHRoYXQgYXJlIHJlZmVyZW5jZWQgZWxzZXdo ZXJlIGluICZsdDtydW5uaW5nJmd0Oy4mbmJzcDsgVGhlIGNsaWVudCBkb2VzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8 c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7Jm5ic3A7IG5vdCBuZWNlc3NhcmlseSBuZWVkIHRvIGRl Y2xhcmUgYWxsIHRoZSBjb250ZW50cyBvZiB0aGUgbGlzdCBlbnRyeTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4g bGFuZz0iRU4tQ0EiPiZuYnNwOyZuYnNwOyAoaS5lLiB0aGUgZGVzY2VuZGFudCBub2RlcykgLSBv bmx5IHRoZSBwYXJ0cyB0aGF0IGFyZSByZXF1aXJlZCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0i RU4tQ0EiPiZuYnNwOyZuYnNwOyBtYWtlIHRoZSAmbHQ7cnVubmluZyZndDsgYXBwZWFyIHZhbGlk IG9mZmxpbmUuJm5ic3A7ICZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPkknbSBub3QgYSBmYW4gb2Ygb3B0aW9uICMz LiBJdCBkb2Vzbid0IGFsbG93IGEgbW9kZSBvZiBvcGVyYXRpbmcgd2hlcmUgYSBjbGllbnQvT1NT IGhhcyBmdWxsIGNvbnRyb2wgb3ZlciB0aGUgY29udGVudHMgb2YgdGhlICZsdDtydW5uaW5nJmd0 Oy4mbmJzcDsgU29tZSBvcGVyYXRvcnMgd2lsbCB3YW50IHRoZSBtYXN0ZXIgY29uZmlnIHRvIGJl IG93bmVkIHVwIGluIHRoZWlyIGNsaWVudC9PU1MgYW5kIHB1c2ggaXQgZG93bi4gVGhlDQogc2Vy dmVyIHNob3VsZCBqdXN0IGFjY2VwdCBpdCBhbmQgdGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0 byBkbyBhICZxdW90O3JlYWQtYmFjayZxdW90OyBhbmQgc2VlIGV4YWN0bHkgd2hhdCB3YXMgc2Vu dCBwcmV2aW91c2x5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4tQ0EiPkkgdGhpbmsgd2UgaGF2ZSBhIHBvdGVudGlhbCBzb2x1dGlv biBmb3IgdGhpcyBzeXN0ZW0gY29uZmlnIHRoYXQga2VlcHMgdGhlIHJ1bm5pbmcgdmFsaWQuIEJ1 dCBJJ20gZmFyIG1vcmUgd29ycmllZCBhYm91dCBjb25maWd1cmF0aW9uIHRlbXBsYXRlcy4gSSBk b24ndCBzZWUgaG93IHdlIGNhbiBwb3NzaWJseSBrZWVwICZsdDtydW5uaW5nJmd0OyB2YWxpZCB3 aXRoIGNvbmZpZyB0ZW1wbGF0ZXMuIFRoYXQgc2VlbXMgbGlrZQ0KIGEgbWFqb3IgcHJvYmxlbSB0 byBtZS4gQnV0IGlmIHdlIGV2ZXIgZGVjbGFyZSB0aGF0ICZsdDtydW5uaW5nJmd0OyBkb2Vzbid0 IGhhdmUgdG8gYmUgdmFsaWQsIGFuZCBvbmx5ICZsdDtpbnRlbmRlZCZndDsgaGFzIHRvIGJlIHZh bGlkLCB0aGVuIG9mZmxpbmUgdG9vbHMgY2FuIG5ldmVyIHZhbGlkYXRlIChhaGVhZCBvZiB0aW1l KSB0aGUgY29uZmlnIHRoZXkgYWN0dWFsbHkgZG93bmxvYWQgdG8gdGhlIHNlcnZlci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNB Ij5KYXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNw YW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8Yj5Gcm9tOjwvYj4gbmV0bW9kICZs dDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFu ZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDMsIDIwMjEgNjow MSBBTTxicj4NCjxiPlRvOjwvYj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJt YWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFu ayI+ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPiZndDs7IEphbiBMaW5k YmxhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbmxAdGFpbC1mLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmphbmxAdGFpbC1mLmNvbTwvYT4mZ3Q7OyBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmtlbnRAd2F0c2VuLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmtlbnRAd2F0c2VuLm5ldDwvYT4mZ3Q7 Ow0KIG1hcWl1ZmFuZyAoQSkgJmx0O21hcWl1ZmFuZzE9PGEgaHJlZj0ibWFpbHRvOjQwaHVhd2Vp LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwaHVhd2VpLmNvbUBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtu ZXRtb2RdIE11c3Qgb2ZmbGluZS12YWxpZGF0aW9uIG9mICZsdDtydW5uaW5nJmd0OyBhbG9uZSBi ZSB2YWxpZD88c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNw YW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5n PSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPk9uIEZyaSwgRGVj IDMsIDIwMjEgYXQgMjoyNiBBTSBKw7xyZ2VuIFNjaMO2bnfDpGxkZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiIHRhcmdldD0iX2JsYW5r Ij5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8c3BhbiBsYW5nPSJFTi1DQSI+T24gRnJpLCBEZWMgMDMsIDIwMjEgYXQgMTA6NTk6MTJBTSAm IzQzOzAxMDAsIEphbiBMaW5kYmxhZCB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEkgbWFkZSBzb21l IHByb3Bvc2FscyBlYXJsaWVyLCBib3RoIG9uIHRoZSBpbnRlcmltIGFuZCBwcml2YXRlbHkgdG8g dGhlIGRyYWZ0IGF1dGhvcnMsIGFsb25nIHRoZXNlIGxpbmVzOjxicj4NCiZndDsgPGJyPg0KJmd0 OyBPcHRpb24gIzE8YnI+DQomZ3Q7ICYjNDM7IFdlIGNvdWxkIGhhdmUgYSBuZXcgc3lzdGVtIGRh dGFzdG9yZSB0aGF0IHRlY2huaWNhbGx5IGlzIGEgcGFydCBvZiBydW5uaW5nLiBFdmVyeXRoaW5n IGluIHN5c3RlbSB3b3VsZCBzaG93IHVwIGluIHJ1bm5pbmcgdG8mbmJzcDsgY2xpZW50cyB1bmF3 YXJlIG9mIHRoZSBzeXN0ZW0gZGF0YXN0b3JlLiBFdmVyeSB0aW1lIHRoZSBzeXN0ZW0gZGF0YXN0 b3JlIGNoYW5nZXMgZm9yIHdoYXRldmVyIHJlYXNvbiwgdGhlIHJ1bm5pbmcgZGF0YXN0b3JlIHRy YW5zYWN0aW9uDQogaWRzIChpZiB3ZSBtYW5hZ2UgdG8gZ2V0IHRoYXQgY29uY2VwdCBkZWZpbmVk KSwgYXJlIHVwZGF0ZWQ8YnI+DQomZ3Q7ICYjNDM7IENsaWVudHMgaW50ZXJlc3RlZCB0byBzZWUg cHVyZSB2aWV3IG9mIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIHdpdGhvdXQgYW55dGhpbmcgZWxzZSBp biBydW5uaW5nIGNvdWxkIGlzc3VlIGEgZ2V0LWRhdGEgdG93YXJkcyB0aGUgc3lzdGVtIGRhdGFz dG9yZTxicj4NCiZndDsgJiM0MzsgQ2xpZW50cyBpbnRlcmVzdGVkIHRvIHNlZSBhIHB1cmUgdmll dyBvZiBydW5uaW5nIHdpdGhvdXQgYW55IHN5c3RlbSBkYXRhc3RvcmUgZWxlbWVudHMgY291bGQg aXNzdWUgYSBnZXQtZGF0YSB0b3dhcmRzIHJ1bm5pbmcgd2l0aCBhbiBleHRyYSBmbGFnIGNhbGxl ZCAnd2l0aG91dC1zeXN0ZW0nPGJyPg0KJmd0OyAmIzQzOyBTaW5jZSBhbGwgc3lzdGVtIGVsZW1l bnRzIGFyZSBhbHJlYWR5IHBhcnQgb2YgcnVubmluZywgY2xpZW50cyBoYXZlIG5vIG5lZWQgdG8g Y29weSBkYXRhIGJldHdlZW4gdGhlIHR3byBkYXRhc3RvcmVzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IE9wdGlvbiAjMjxicj4NCiZndDsgJiM0MzsgV2UgY291bGQgaGF2ZSBhIHN5c3RlbSBkYXRhc3Rv cmUgdGhhdCB0ZWNobmljYWxseSBpcyBhIHBhcnQgb2Ygb3BlcmF0aW9uYWwuIEV2ZXJ5dGhpbmcg aW4gc3lzdGVtIHdvdWxkIHNob3cgdXAgaW4gb3BlcmF0aW9uYWwgdG8mbmJzcDsgY2xpZW50cyB1 bmF3YXJlIG9mIHRoZSBzeXN0ZW0gZGF0YXN0b3JlLiBUaGUgcnVubmluZyBkYXRhc3RvcmUgYWx3 YXlzIG1haW50YWlucyByZWZlcmVudGlhbCBpbnRlZ3JpdHksIGkuZS4gY2Fubm90IHJlZmVyZW5j ZQ0KIHRoZSBzeXN0ZW0gZGF0YXN0b3JlLjxicj4NCiZndDsgJiM0MzsgQ2xpZW50cyBpbnRlcmVz dGVkIHRvIHNlZSBwdXJlIHZpZXcgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUgY291bGQgaXNzdWUg YSBnZXQtZGF0YSB0b3dhcmRzIHRoZSBzeXN0ZW0gZGF0YXN0b3JlPGJyPg0KJmd0OyAmIzQzOyBT aW5jZSB0aGUgc3lzdGVtIGRhdGFzdG9yZSBpcyBub3QgcGFydCBvZiBydW5uaW5nLCBjbGllbnRz IGNhbiBhbHJlYWR5IHNlZSBhIHB1cmUgdmlldyBvZiBydW5uaW5nIHdpdGhvdXQgYW55IHN5c3Rl bSBkYXRhc3RvcmUgZWxlbWVudHMgdXNpbmcgYSBzaW1wbGUgZ2V0LWRhdGEuDQo8YnI+DQomZ3Q7 ICYjNDM7IENsaWVudHMgdGhhdCBhcmUgYXdhcmUgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUgYW5k IGFyZSBpbnRlcmVzdGVkIHRvIGNvbmZpZ3VyZSByZWZlcmVuY2VzIGZyb20gcnVubmluZyB0byBz eXN0ZW0gZWxlbWVudHMgd291bGQgaXNzdWUgYW4gZWRpdC1kYXRhIHJwYyB3aXRoIHRoZSBhZGRp dGlvbmFsIGZsYWcgJ3Jlc29sdmUtc3lzdGVtLXJlZmVyZW5jZXMnLiBUaGlzIHdpbGwgbWFrZSB0 aGUgc2VydmVyIGNvcHkgYW55IHN5c3RlbSBlbGVtZW50cw0KIHJlZmVyZW5jZWQgaW50byBydW5u aW5nIHdpdGhvdXQgdGhlIGNsaWVudCBkb2luZyBzbyBleHBsaWNpdGx5Ljxicj4NCiZndDsgJiM0 MzsgQ2xpZW50cyB1bmF3YXJlIG9mIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIHdvdWxkIGhhdmUgdG8g aW5jbHVkZSAoY29weSkgaW5mb3JtYXRpb24gZnJvbSB0aGUgc3lzdGVtIGRhdGFzdG9yZSB0byBy dW5uaW5nIGluIG9yZGVyIHRvIHJlZmVyZW5jZSB0aGVtLjxicj4NCiZndDs8YnI+DQo8YnI+DQpP cHRpb24gIzM8YnI+DQo8YnI+DQpUaGVyZSBpcyBhIGNsaWVudCBvbiB0aGUgc3lzdGVtIHRoYXQg bWFrZXMgY2hhbmdlcyB0byBydW5uaW5nIGp1c3Q8YnI+DQpsaWtlIGFueSBvdGhlciByZW1vdGUg Y2xpZW50cyBjYW4gbWFrZSBjaGFuZ2VzIHRvIHJ1bm5pbmcuIFN5c3RlbTxicj4NCmdlbmVyYXRl IGNvbmZpZyB0aGF0IGlzIG5vdCBlZGl0YWJsZSBleHBsaWNpdCBjb25maWcgaW4gcnVubmluZyBn b2VzPGJyPg0Kc3RyYWlnaHQgaW50byB0aGUgYXBwbGllZCBjb25maWcgaW4gb3BlcmF0aW9uYWwu IFRoaXMgZG9lcyBub3QgcmVxdWlyZTxicj4NCmEgc3lzdGVtIGRhdGFzdG9yZSAoaW4gZmFjdCBz b21ldGhpbmcgbGlrZSBhIHN5c3RlbSBkYXRhc3RvcmUgbWF5PGJyPg0KZXhpc3QgYXMgdGhlIF9s b2dpY18gb2YgdGhlIHN5c3RlbSBjbGllbnQsIHRoZSBnb29kIG9sZCBleGFtcGxlIHdlIGhhZDxi cj4NCmlzIGFsbG9jdGluZyBhbiB1bnVzZWQgdWlkIGZvciBhbiBhY2NvdW50IHRoYXQsIG9uY2Ug YWxsb2NhdGVkLCBpczxicj4NCm1haW50YWluZWQgaW4gcnVubmluZykuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4w cHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiYjNDM7MSB0byBvcHRpb24gMy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj5Db25zaWRlciBhbiBpbXBsZW1lbnRhdGlv biB0aGF0IG1vdmVzIGFsbCB0aGUgJnF1b3Q7aGlkZGVuIHN5c3RlbSBsb2dpYyZxdW90OyBvZmYt Ym94PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+dG8gYSBjb250 cm9sbGVyLCBzdWNoIHRoYXQgdGhlIGluaXRpYWwgY29uZmlnIGlzIGxpdGVyYWxseSBzdXBwbGll ZCBieSBhbiBleHRlcm5hbCBjbGllbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1DQSI+SSBoYXZlIHlldCB0byBoZWFyIGEgc2luZ2xlIHVzZS1jYXNlIGZvciBjcmVhdGluZyBh ICZsdDtzeXN0ZW0mZ3Q7IGRhdGFzdG9yZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFu IGxhbmc9IkVOLUNBIj4mcXVvdDtUaGUgY2xpZW50IG1pZ2h0IHdhbnQmcXVvdDsgaXMgbm90IGEg dXNlLWNhc2UgZm9yIHN0YW5kYXJkaXphdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLUNBIj5JIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSAmcXVvdDtwdXJlIHZpZXcm cXVvdDsuIFNlZW1zIGxpa2UgaWYgdGhpcyB3YXMgYSByZWFsIHByb2JsZW0gdG8gc29sdmUsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+dGhlbiBOTURBIHdvdWxk IGhhdmUgaW5jbHVkZWQgYSBzeXN0ZW0gZGF0YXN0b3JlIGZyb20gdGhlIHN0YXJ0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxh bmc9IkVOLUNBIj4vanM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5n PSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1D QSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+QW5k eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu MHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQotLSA8YnI+DQpKdWVyZ2VuIFNjaG9lbndh ZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4NClBob25lOiAmIzQzOzQ5IDQyMSAyMDAgMzU4NyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVu IHwgR2VybWFueTxicj4NCkZheDombmJzcDsgJm5ic3A7JiM0Mzs0OSA0MjEgMjAwIDMxMDMmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmph Y29icy11bml2ZXJzaXR5LmRlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmphY29icy11 bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4010d6892a4b42249a5d3fda5d511788huaweicom_-- From nobody Thu Dec 9 05: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 886763A0B75 for ; Thu, 9 Dec 2021 05:46:28 -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=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 3yV1YQozw_UE for ; Thu, 9 Dec 2021 05:46:24 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60069.outbound.protection.outlook.com [40.107.6.69]) (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 CD9353A0C50 for ; Thu, 9 Dec 2021 05:46:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E92t0uQO3I2SVM1E630Dck/uSUOoyeWIPqnM9TX5DQCoKv8CUcKuVS33QPc30gOhil66mQW8WJhIQGE3Vf+I9FpN/rvIpHGBJxzW3iIWJq1ugNadtiSkVVkoIJhwd/q8PtwolR7dTW5SOy10TOsLzKBE/tGFOKt3op+8IexcOTJXrNjUonwIP58ntHGR8tuX3NlONjfwmYG9z1v8mMfiOPA1AZRC6YLCj1gmnwxd4cjjowjcX5NhGUOauIHvBL30h6vEubrTw0EpbPprAhXXHFitP0GyPLY/OGjUbkkDut2dgd4tLkEHl5yBX6adb6jhi7PzCF6P1IMDIiWFbxKC9w== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hDjt1mNe79G/4fBg0ODF8tmvNTApyR+85I58LtOIbE0=; b=VsDlzkq/cQ9w7wilccJt06iEPSKNlgbac/grd4qqRvKFaqjEROaRHfcuHGTjEHRV2+RBEJ8RabZ9ib1GAC2EPB599NlA9oa2eUV/prtKxU6OhJwWaz0+u9V4GVknYUrE3/9ubUwh4Dhqx8JW5r8xS8a5WHjMRJJyxVogESzNH3I2w+1EUI2EuP+WT+Dpoxv5UErcaYkBsZ2LyWUULqbwzBxVA8TKBD2WbwyvBXXLiZmAjdCoXXhNjK7QYkSvaK5lYhhfGVotpSHdQo9+GpLCclQNZ+aHuz5e1mZd57dlHLXg6Xf2ogX9rXW4unCaw+OVDly7wvyUvzEyrzttbRb+8Q== 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=hDjt1mNe79G/4fBg0ODF8tmvNTApyR+85I58LtOIbE0=; b=t/LbxEbR6XLvwG14xxDqMIucnYTUzfACzH//TURu22lzVKnyM0xfYYNAphT9+FcMNQLuOXEY1iIbEnBoDnKWVAHydeJ3AXS5P4JBEPttTWSRt+dy6nqxTmbyDrEnL9hP3b/BjPYPOdKD0yrD10ZxoE8gPmCb8EbsVp58Fj0BZJs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1540.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3e4::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.14; Thu, 9 Dec 2021 13:46:20 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8%3]) with mapi id 15.20.4778.013; Thu, 9 Dec 2021 13:46:20 +0000 Date: Thu, 9 Dec 2021 14:46:19 +0100 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: "maqiufang (A)" Cc: Andy Bierman , "Sterne, Jason (Nokia - CA/Ottawa)" , Jan Lindblad , Kent Watsen , "netmod@ietf.org" Message-ID: <20211209134619.uspscxpn3kk2hycf@anna> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "maqiufang (A)" , Andy Bierman , "Sterne, Jason (Nokia - CA/Ottawa)" , Jan Lindblad , Kent Watsen , "netmod@ietf.org" References: <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <4010d6892a4b42249a5d3fda5d511788@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4010d6892a4b42249a5d3fda5d511788@huawei.com> X-ClientProxiedBy: AM0PR02CA0153.eurprd02.prod.outlook.com (2603:10a6:20b:28d::20) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: eec242fb-6207-4baa-8b2e-08d9bb1a4851 X-MS-TrafficTypeDiagnostic: AM9P190MB1540:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: B2EyaEE1JaVfhL8x4CEfBvMzQyaXTpHE1Wyg7ZIFWd9ZzkHvxsfohhnpUAR2pNoAXz7TM1lc6TEF0sy2wu+4fflTn0N4uoiRg/WoYTOWI7fWg81dKIm45bo47xf98m6F9mcz5qZcWVShKFnwBwychbXY1gUwzgK7Q1XUvwQ+Ckk8O2Y7hBvduMu1WuhD9xz158OXIVGEpN8kSSBXfEi1kUh3P8NDydqxBCuRmzG1osyQKHmq+GTFdnvCHsR6nUZz3mvEa1e8C0VE4Ut9YPdBtqGwQHsZKPfDiF1zbwhg7UNllqJ2Xo4wwiT+cqQ0G4ulRf/DFmBAoBGyZLOE680jKaMM3ZkcdFRN4VjxXQGJHlCtUcAJyf58w0J1DQY/eO97yMTCIRQK5gLbHaTNme0gv++L9twPu8bqARN9vFZYZDm8+PybLeeL6nwdOEk+L1uDlrLqSSl2SE5nmpP6CJl8OwiGADmnR440/sXSbFbgDGQNQHuuw99WeJ7es0d6uDyhyAtxe+SifyJAxDfb7QLGRpXd/cz8+BM3C7e7cdiNajZzqNcNoik4ier3cMR5DjouaS62JZQe/olxz5qFUQ+Zs2dZ5sZmFhIewnP+wFKJRS6UTSsFRXkeFdT6cgO+rVcbUy2YWcypflJJM2q2GFjaIHKbi3TNcTxYEnyjk3m4hXNFQ/m5KHlqwB5y7By9tGdEDFufRJ2MASl+/OmtRcJTAcR5c47PK5x+9ppW4go+d/FGPhXIYr+5Tv+8UOnCcKYEOWlH/AjdY7OrKKetZx+kokEa1fa6IOBnQsYogdgYVwY= 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:(7916004)(366004)(6486002)(786003)(316002)(5660300002)(6916009)(54906003)(66946007)(6512007)(85182001)(38100700002)(66556008)(86362001)(33716001)(38350700002)(2906002)(66476007)(3450700001)(9686003)(40140700001)(8676002)(4744005)(52116002)(6506007)(26005)(186003)(508600001)(8936002)(1076003)(85202003)(4326008); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UWJoZWdBbjE4VSs0bXJvb1FSTlhkUUNucFlYQXNYMTRqTHlvSWxpTU4zWXhZ?= =?utf-8?B?VitWeThCRGYzdXFZZUlBSzN6aUxPNzQ3TmRqTHpEd21YL2hBWUlCU0xrVlZ6?= =?utf-8?B?S3lEQUhiSnloVEFHOUFmVElEU01Tc2tJdVU0U2FLYkZuaVdncWhmZ0I2UWtK?= =?utf-8?B?N0RLemdHZ0c1dmgyWTJlc1JBOVpwSEJmZ1RSdDIxUThpdXFiMWJ5WGFpakxG?= =?utf-8?B?ZWxlNDR2TytmN1lqQlFIVElrZkF3YUUyYkZhZzBka3Y2cXdjR2hvRnU5bUEr?= =?utf-8?B?aElrQmx6SElCRE1DQnFIMUJNWFJCNGgvQmo5SWNsRDBYK1BiaTlqRVRLaVQr?= =?utf-8?B?R0VLaUdvSXpRdHQ2R1l5cW5TcUJlK3Y5OE1IVmhMdEs3VXlaamo0VkE0ZDhO?= =?utf-8?B?emNCckFPYVBMZ2krLzRSL1lCOGNjU1FxUi91dlA5T1ljL0NmSW1KY2FPd1NN?= =?utf-8?B?SE5hclRKOWNURlhrQ0FBK1QvNCt2bnRHQUk4QVczYUpya0U3OGpEQnJJV3JW?= =?utf-8?B?YTY5QnRQVGhNUTg5SW1aVFo0RFBwbW4zZnhEZjhjQ2JqYndpVmJzRFdVcm9t?= =?utf-8?B?RVFOVGlyc0Jjb1RmaytzNUxkbzFYOXB1c0VtNE9GMHFBVC9TV28vQkFXcUln?= =?utf-8?B?K1FBT051ckZwS0JySkpKRERsRGVOVEliRUhCbDFMNzc1RXMzWDgzQkRNSWor?= =?utf-8?B?ektjektWbFhWKzQrQXJpT1ZwTjJqV0hEYTl3d3VaK01BbFY0QmJhS1hMTXhl?= =?utf-8?B?WGpQeEtydDZMVUppUG9ZbDV3VnFzSmlVSG5mQ1JUK0paSFFxeVJLZHFhdFRp?= =?utf-8?B?YWNFSWVyL3MyaStCUzdmaXRNU1lra3lUUVFHSURoWC9sTHBkU3JJbStaTkd4?= =?utf-8?B?VHRXcktiMFdIeGs1eStnaXd6NTl1TnVQcWc1VTUzRU1laDdrSXFzRmRwY2Vi?= =?utf-8?B?ZTB1TittU3FvSTVKVzZUR05Ma2pvMktRcTIxWHVuUHUxV2tQU3JYQ2JlUUlV?= =?utf-8?B?d2JsZm1BK3BEZUgxaTdaZUNmSjdVWWwxYldiL2FVUnBvTnNvMUxXTER2WlVW?= =?utf-8?B?UUZwN3ZkSmwweURic3NsTVA4a3hLSFJjQ0swek1iU0RNWS8ycTRvQUwzcE5U?= =?utf-8?B?ZDdKT2RaQUlyRmFxS3A4Skhaa1FxL0NUSitNZVZJM2srUTE3RzBkc3dOckpz?= =?utf-8?B?YzVCUFV6TTJsOHBzSXZRaUIzYnJVUnBXUllRaEdnSW1WWnpLVHRTc1Rsenky?= =?utf-8?B?MVJPREtlYzlrc1V5eWg5S2xOMDBMTUk0RjMyT1d5R0RiY0JkdDY4TUdTZWZ0?= =?utf-8?B?Z0RzcmVkUEp3YURpUXNXQWlOYUJxOEp3RllpRERyM3BZZzQ3S0hxbnRwcy9a?= =?utf-8?B?RjlRc1dvN1MzUjZLYzVZYmk2MlEwWXVWa3E2MEJFRlpPKzlkQUJ1c1RQejNQ?= =?utf-8?B?SzZBaHIvbmM3aXI4TVk2bGlQdWNZTmFnQnpobHRGcmNjeUpnbWhXdXZOK29Y?= =?utf-8?B?SEFoTnJISlpOTll5MkRSUWRDdWNlR0cwTmtXS2NLQTlBM0w2QUUveHEwdnp3?= =?utf-8?B?eVB4RW5tZkc1Y1FJR0tqVmt0Uk8rMjZxbXpOb0R1ZmpVN2hxZ1BWUTdMS0s4?= =?utf-8?B?TzNiYWN2ampMOStIcjNyYTVuaXRIM2UxcGpCN25OSlIzbXFFSmZ1dURpM1dH?= =?utf-8?B?bFJyS0VzOWtLUjRtYk1RUTVvODlvenJhbm1OWXJxUktTU1NybVdpMjNyWkkv?= =?utf-8?B?NnBhL1hhQy9oVENFNk5LaHVRaWZ0RVdHYUtZT2orUUVoYnNFV0hQb2dLekVK?= =?utf-8?B?L1hUMFgwWm14UEpMRXFqdXNiU2lvV1VJTWdoWDl0SHAzcU1LQmFENjZvR1lp?= =?utf-8?B?bWg5TlpKTHBRbnV4Z3UzSUJJWU94SDdQYTFtRjJHUUR6ZkF1WHVYWVpXQjEx?= =?utf-8?B?U2pGT29CamFvU2pPRHZ1VG5tRWVXZ1J4S2x2NkxnTWZrWGszUEFsRW9ta3Nk?= =?utf-8?B?T1JhRkQyZkVUbDVRd3JWUjhVWlMrZkNIZThiVVBNSTlUeEtzR3R4NWVqeWdT?= =?utf-8?B?dE1KQzV0REJHVEZ3SUpwYlZrMmRlTVIzRUJTTEYvakhWdTkyNDNJQWNqd252?= =?utf-8?B?dXpXWG9PMW94K202dVQ3V0p6QWdxd0VvQnpVWTRlUFNndm91ZDNRZUNsTmx5?= =?utf-8?B?TGY4dXVLZnRBYWlvU2VsYm9HdjdOL1gzdmRZbHhzUmZVcE9lZ3p2MEdZRStH?= =?utf-8?B?S3FNZFYyRWJNaW11UW15eWs3WE5BPT0=?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: eec242fb-6207-4baa-8b2e-08d9bb1a4851 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2021 13:46:20.7889 (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: Nsc0FruY+C/wAV3Bqb2ZgOyD8+ZdT9rhv7uGGe4DxZuek3Ux3F/HX/bcTJzms8v8twu/EusCkSl7ny2wNEyhQKrpdKInpqYb246FaUMIELs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1540 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 09 Dec 2021 13:46:29 -0000 On Thu, Dec 09, 2021 at 01:07:09PM +0000, maqiufang (A) wrote: > > Regarding open #3, it is natural for the clients to believe that what they read back from the server is exactly what they sent to the server. > If there is a "system client" playing a role, this would require some extra handling for the other remote clients and bring them surprise and inconvenience. > A server accepting and returning non-valid config is also a surprise and inconvenience. /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 Thu Dec 9 06:31:41 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 975663A0E07 for ; Thu, 9 Dec 2021 06:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 65FxDL_fKEGA for ; Thu, 9 Dec 2021 06:31:30 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2130.outbound.protection.outlook.com [40.107.243.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 F2FC73A0D41 for ; Thu, 9 Dec 2021 06:31:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nBMZQZhAmzwWYK9lc+jZlYhtvpPCWCZhxc+4aUaImwwHRWdpkKYWqEkGcS0yi8HJLflhYqHb09pSWC0J3q1cTpoTBNa11Nz08cJV12vMyXXy8/ICMfkSSwEVQUGfO7HLUudPCmg48hLqQ0pPv5y7jAhQMA3u43/ax83GxwUvwX5KL6lD8c9nboejoMsFRFSyrsfUhnL+ism+ndFXy08JXEMO6s1LJwn6JYjVzm6Y7/an7yPgPc1F/RH/xwfdAVHmCF1Os9mWyo1rz0VB74vyHsVrXl3Q7pevy5j3UT/UZTmU02RGeygZnLFyxPNaaMcVEJf223WCpOheiO3fhK9rrQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f1OSkt5Oaa2VWZVETmFDesrWEr3nGLWthBhalIKJXuM=; b=VxceRV931Jv3oTwVwyN/wkzC4UQ6LgAz61DKG3v2hxhBw+2M0IQPnQvkPJMl2Qa7j9FF6iNYZLhlgjxgWwR5WMDWhix2N9gvghIPPD+XD+sjzakxzNF+1tssjAHgCRWPCLJW3vPEyHKxwvcMXcb+rojnjfj8BacIsmwl6uyVEgd0UNkrXqlezHFT3UTrjpThkaCRdO7qJviwosXe7j78/ugWY9w0NgcJ5xTmr9ziyfnH8EJQiMmrZh8OoSO+ffW3Mg0SP1NjBM6d/s7ktxpU1g6q5gDNvOWxg37bGYTOnGDMwnRv5GxS6Yis8IpOBPaW+qae0EK2FuXf5a806fz7lQ== 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=f1OSkt5Oaa2VWZVETmFDesrWEr3nGLWthBhalIKJXuM=; b=k/yAqj7chSQhSr/lQDGs5BoA18VhqF4PkXqTlD9tF1pmpI/OKt0dZnttULWzRm9oSfhA7IrjTG1R2jJrVoH3cp0t0YpXddUBY1PuGyG2zhCz7+ZGDNlG13iiaiWUvPgvw61k/rWUZw5HMjLw9eZZuEhzIt/O5Ut6vvQ13Xz2p6Q= 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.4755.21; Thu, 9 Dec 2021 14:31:18 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 14:31:18 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "Sterne, Jason (Nokia - CA/Ottawa)" , "maqiufang (A)" , "netmod@ietf.org" Thread-Topic: [netmod] Should the "with-origin" parameter be supported for ? Thread-Index: AdffkIzQgrflx2pfQFG03vlrV2MIPQM9JcDgACEKSaA= Date: Thu, 9 Dec 2021 14:31:18 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c7481d21-b0bb-49b4-ef3e-08d9bb209037 x-ms-traffictypediagnostic: DM6PR08MB4155:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MbnlAL3cd0QDbBMRadbVgOPNN5/9TiMYOWXq2NCgqRNjDNwmvRoAX0sWOBhci+YXhIYA/0boLQRePiWvwpUv9XRxqNtxv8Hemf8KzhtB7w+qCZPXGezONyH7REeXrdrrKdUvDcwjZwKnbIZU13KLIeiDOCTtMAQ5eld9E8PcAW8e1tT9BqT7ptkBWOhSvraWwkcbYae8FO7WcH3zO9V4Hqlx3SbykH1D1viKcMQ3ZS7z+Pi0yM5Ek36uM9bli7qnntHLpvZm529H2ANI9tJsOAS6xJy6539pu7C9GaHEMTjT6ZXyoJp3LvYSdZB9DxVSAVkam5WDt0tZ+kwAkMZZgfofQTfm9jn2v5n9KWjqhQU+VvIRBhmSrYSUND9BWT6RnrJ4C1CcbjzuDMW14ygoD66D0qBLpXVL1AOvdOrDpNdg9BrpI1wsdPP2XugJZDiogSfAoRmBix80y2MfdjCAbAaVSO9w4X+44AndsffrtKuehYXEa9TOJShtEZdZ8k51b8FeGv+WDpdXHonvUoNP2V+sFAiVMgVdVVXZal1xY26JQ8xH+UtbRkAlq/BvEjj+PJDOl+kDLfQ4yWokqYGWomvRnH6Ff7VaBwXf4Xrx0QJQkc8qfmXVximX9221vpByssrZ/qYm4aPRAM6DQnF2e4qH6cT9u+zxcDMRdFxD+G6jwNppUeD1NLRk90G01OATx35Ui3eKcNObeUr7+FDetw== 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)(366004)(9686003)(7696005)(66946007)(26005)(316002)(66446008)(52536014)(38100700002)(5660300002)(186003)(55016003)(53546011)(122000001)(38070700005)(110136005)(83380400001)(71200400001)(86362001)(8676002)(2906002)(82960400001)(76116006)(33656002)(66476007)(66556008)(508600001)(64756008)(8936002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/t8KAB/ttCFCTGFM+4YwMYSod1OtELk2an4V9xE/VBG+W0FGgSjMNHEnD6MP?= =?us-ascii?Q?+I3gSstAsRwPwa2JFrAuAKIw4eNwWRbNWHTyef1+MZ2d+Ym9p2f9EGJL8Tgc?= =?us-ascii?Q?tTar/PuCYYIhdP9b9syzQn5OclSrJyzhjU3S6DDwt6DbbEdo49yTHeJcSuEi?= =?us-ascii?Q?BVMBteeW9O84jmhvCz2vekaP80yMf0Exfo5IobkVVzS/ArqZyYjNHlRQr7WM?= =?us-ascii?Q?MrdsctzQGtE5e68T0AtttadBLpRxxIP0H+VtxDzE7J3/HjwK8ifHTuBDFXPB?= =?us-ascii?Q?exajeatlHkGOKhg34EtybhtY3ePmEYq5FwanlrAX+q3DSeV8QyqnF/TAVSit?= =?us-ascii?Q?LOky6cxoJozwF2ItF7K8oGR7L6S3h+k99AU0hXcKN41x+3oSDDRxpcSLRBH6?= =?us-ascii?Q?uzjQwka9CfG9Jk9UlYGyhlDIxGn0EQa8DZuSeD0tYi0ebBV/+P1msG6AdZm4?= =?us-ascii?Q?M5BF1N07ckZIEA8WLjYHkbJdFaBU1adhMfzB8g4OoKuld1Ek3Om41HWpcGYr?= =?us-ascii?Q?ubbEXx/vD+MKHpVvjV460iiCDniA7h1TLwtplZh17kSOSD49zuHodkEq+wci?= =?us-ascii?Q?RgeLT4nf1lJSJjEdVZIK4qCOjt+7TRKij+R675IOgiOEHdWO2efrL/o6fMjk?= =?us-ascii?Q?GqdYXxe51Wamz570mdUVQL5JZqXvEcPLPeg1v10cV5QVPQOKfZoKuH+O/CR/?= =?us-ascii?Q?gRbOSBI4D2ul9BtVMEHDYWrAtIDub1Dfg+z3wnZ42O1GLfyYwaDVqSEgtg/7?= =?us-ascii?Q?OuThVcsXDJy9ut6TtRAGJXRJlaeVAa37r7H4UnRk48ygCFk78TgIKN6Vnp4+?= =?us-ascii?Q?B3wj/PREsqbPSz1SdDY4y8I5IE5KFNDC78xdkzSALBcEfti8U/WTWn0SliQq?= =?us-ascii?Q?ZjdMiexfgaPXpeO6eoWvA7KZQlZZrn4MyNPCvgD074KJo+dkk02NX/3EXZ6O?= =?us-ascii?Q?5v3CP6JcZtfRUtRwnPd5TOttTPkizaXF+N6q2VpKdLP18/scnpaRbEzFSS3W?= =?us-ascii?Q?wJFE1yHMlhTZU2DPOBKicqCbzB74Uar8vksG//oMeA/EdPkggx2GxK3Zbdcn?= =?us-ascii?Q?9GYsM3WBB8oIsrq5PLUbCcaTyupxu9LDOUorRRp5zctS23js429pM+LSj0Fx?= =?us-ascii?Q?VuoxWOJ+phPhrxvpVX1YSZ2UP5M4vnVq7qTLs/63PH1Modle0LHDAoev+rHy?= =?us-ascii?Q?nH+bx3wPNmqXfMqk1nqx7hYNOTD7CEOHOTMSTGm7cs2Oz9L6Mtg7M+Tpexk+?= =?us-ascii?Q?60b6wuaksPIltYglR3P0Ts17fMAkUxZJOmlYpluPCvqRT1hpcrLs69POZx6+?= =?us-ascii?Q?pUxVaV1zOAix8GVvkcZYRTEFZR+XdZZpTKDwOh0M8mr1QlUk3SK/uI6k9Ow+?= =?us-ascii?Q?DU3EiTcSrqPqOoP6xh7vrxq4KxedOyQR+WWxmYoU/cmV9EUSIyYAm/h3yGYS?= =?us-ascii?Q?YoB5qpb7ifrmQSSa2yxBiUAAaPkzFXOzeDxut3n0+mS2LASZBSLDZ+CSqbfR?= =?us-ascii?Q?U0S01qyXDqdlx86vGeGkmHjkdic+CaysfiNTNR4AU+iAkyXySUSRW5WVRsmT?= =?us-ascii?Q?b+JzxgFsazR4sgnhWag0c24/msAHhRJTzkonjrrwM6uJlbAlGH1dVcEt3j4p?= =?us-ascii?Q?3w=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084B53C6E07A853D74E439F9B709DM6PR08MB5084namp_" 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: c7481d21-b0bb-49b4-ef3e-08d9bb209037 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 14:31:18.1019 (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: rP7+UxvwbNsdsq7hpftSGS7x/KdsLRDo2E0Zjy1IGhdLu1XL5fEVfNKW2Jw5O9w7Y484shyGkIXjU+eoOs04PQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4155 Archived-At: Subject: Re: [netmod] Should the "with-origin" parameter be supported for ? 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, 09 Dec 2021 14:31:40 -0000 --_000_DM6PR08MB5084B53C6E07A853D74E439F9B709DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry all - I just noticed that my email client didn't thread all the respo= nses to this topic in with the original post. It looks like this has been h= eavily discussed and I'll look through those emails. From: netmod On Behalf Of Sterne, Jason (Nokia - = CA/Ottawa) Sent: Wednesday, December 8, 2021 5:51 PM To: maqiufang (A) ; netmod@ietf.o= rg Subject: Re: [netmod] Should the "with-origin" parameter be supported for <= intended>? Hi Qiufang, In your first option, did you mean "understand a certain data node is from = or from " ? It is an interesting question about whether the origin annotation could/sho= uld be available in a read from , and what values that origin cou= ld take. We should consider other transformations between and (= besides the merging of ): - active/inactive config - configuration templates Inactive config would simply be stripped and not appear in at al= l. So nothing to discuss for that. But would elements provided from within config templates have an 'origin' t= hat indicates what template it came from ? I suppose the same question could apply to 'origin' in the DS= . Having origin purely available in the operational DS may not be complete en= ough. Some config nodes may not be present in operational because they are = not "applied". So you wouldn't necessarily be able to get the full picture = of the origin of all intended config by just checking the origin in the DS. Maybe that's an argument to have an origin in ? Jason From: netmod > On B= ehalf Of maqiufang (A) Sent: Monday, November 22, 2021 7:11 AM To: netmod@ietf.org Subject: [netmod] Should the "with-origin" parameter be supported for ? Hi, all In the "system-defined configuration(draft-ma-netmod-with-system)" work, an= optional datastore named "system" is introduced to hold non-deletable syst= em configurations. We define that if a server implements , MUST be merged i= nto . So there is the cases that the clients can fetch and contains merged . The question is should we extend the "with-origin" parameter to support ? The possible considerations for following two choices: * "with-origin" parameter should be supported for * It may be helpful for a client to fetch to understan= d a certain data node is from or from * There is no need for to support "with-origin" * We already have to provide the origin for a parti= cular data node Any thoughts on this? Best Regards, Qiufang Ma --_000_DM6PR08MB5084B53C6E07A853D74E439F9B709DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry all= - I just noticed that my email client didn't thread all the responses to t= his topic in with the original post. It looks like this has been heavily di= scussed and I'll look through those emails.

&nbs= p;

From: netmod <netmod-bounces@ietf.org> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: Wednesday, December 8, 2021 5:51 PM
To: maqiufang (A) <maqiufang1=3D40huawei.com@dmarc.ietf.org>; = netmod@ietf.org
Subject: Re: [netmod] Should the "with-origin" parameter b= e supported for <intended>?

 

Hi Qiufan= g,

&nbs= p;

In your f= irst option, did you mean "understand a certain data node is from <= running> or from <system>" ?

&nbs= p;

It is an = interesting question about whether the origin annotation could/should be av= ailable in a read from <intended>, and what values that origin could = take.

&nbs= p;

We should= consider other transformations between <running> and <intended>= ; (besides the merging of <system>):

- active/= inactive config

- configu= ration templates

&nbs= p;

Inactive = config would simply be stripped and not appear in <intended> at all. = So nothing to discuss for that.

&nbs= p;

But would= elements provided from within config templates have an 'origin' that indic= ates what template it came from ?

&nbs= p;

I suppose= the same question could apply to 'origin' in the <operational> DS.

&nbs= p;

Having or= igin purely available in the operational DS may not be complete enough. Som= e config nodes may not be present in operational because they are not "= ;applied". So you wouldn't necessarily be able to get the full picture of the origin of all intended config by just = checking the origin in the <operational> DS. Maybe that's an argument= to have an origin in <intended> ?

&nbs= p;

Jason

&nbs= p;

From: netmod <netmod-bo= unces@ietf.org> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:11 AM
To: netmod@ietf.org
Subject: [netmod] Should the "with-origin" parameter be su= pported for <intended>?

 

Hi, all

 

In the “system-defined conf= iguration(draft-ma-netmod-with-system)” work, an optional datastore n= amed “system” is introduced to hold non-deletable system config= urations.

We define that if a server implem= ents <intended>, <system> MUST be merged into <intended>.=   So there is the cases that the clients can fetch <intended> an= d <intended> contains merged <system>.

The question is should we extend = the “with-origin” parameter to support <intended>? The po= ssible considerations for following two choices:

    • “with-origin” parameter should be supported = for <intended>
      • It may be helpful for a client to fetch <intended>= to understand a certain data node is from <running> or from <inte= nded>
    • There is no need for <intended> to support “= with-origin”
      • We already have <operational> to provide the origi= n for a particular data node

Any thoughts on this?<= /span>

 

 

Best Regards,

Qiufang Ma

 

--_000_DM6PR08MB5084B53C6E07A853D74E439F9B709DM6PR08MB5084namp_-- From nobody Thu Dec 9 07:10: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 074AC3A0D52 for ; Thu, 9 Dec 2021 07:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 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=-1.852, 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=mg-soft.si 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 k4K0drMRynQV for ; Thu, 9 Dec 2021 07:10:30 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id B5A553A0D4C for ; Thu, 9 Dec 2021 07:10:29 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id BC8FAC41D7DB; Thu, 9 Dec 2021 16:10:24 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 galileo.mg-soft.si BC8FAC41D7DB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1639062624; bh=Yvbe3Hi01xH+Fyx0gd4kUEZjKy+iKJjAV8KHpsrvT04=; h=Date:Subject:To:References:From:In-Reply-To:From; b=StXJ/pA1pq7tY+xKDQmnlEuaXijhmBi5xS8UjuNVy+e1c6B1KmOCFT83WvtDrqTaz AbwJ2Bwm/amSTVbz/G/YZvv0Jvi+CNcPZU9/HfFS4tpMAPg5ePxKatR93YoOdbJM5T m2YWLSz/vIGiSj4+Uf+GfgcWFVudoGG0Z7lXSLRkH3ViJPnjFsJ3BVA0mTWJjgsSea 01f5kA52MIO0Hiw+ClGyszrQakmgUdEsEgoaJOTcm/52VC6FFmr9nV1sBnlK4nvkZE LmidnObkG1PIi6srEFZ4cGUzgyFujrUKHLyqnLRdJcvwW+nIYyP/KuJdCKWir85Brz G1/so9smRK8rA== Message-ID: Date: Thu, 9 Dec 2021 16:10:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: tom petch , "netmod@ietf.org" References: <87a6hb6zlp.fsf@nic.cz> From: Jernej Tuljak In-Reply-To: <87a6hb6zlp.fsf@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] RFC7950 s.11 and 9127-bis 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, 09 Dec 2021 15:10:36 -0000 On 08/12/2021 13:38, Ladislav Lhotka wrote: > tom petch writes: > >> The BFD WG are revising RFC9127 to add a new feature if-feature >> "client-base-cfg-parms"; and make uses base-cfg-parms { conditional >> thereon in module ietf-bfd-types. Reading and re-reading RFC7950, >> especially about mandatory and top-level, I am not convinced that >> this is legal. > Sorry, I don't get the problem - nothing in the "base-cfg-parms" grouping is mandatory. Why do you think this might be illegal? RFC7950, Section 11 (Updating a Module). A change like this does not fall under any of the allowed revisions of definitions in a published module, therefore:    Otherwise, if the semantics of any previous definition are changed    (i.e., if a non-editorial change is made to any definition other than    those specifically allowed above), then this MUST be achieved by a    new definition with a new identifier. The semantics of the original "uses" (the one Tom mentioned) change if an "if-feature" is added to it. You start with a reusable set of data definition nodes and end up with a reusable set of data definition nodes that are constrained by some condition. Jernej > > Lada > >> The module bfd-types is imported by a number of other modules such >> as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be >> made mandatory by its usage in another module. I raised this on the >> BFD list and the WG Chair tells me that this is a violation of the >> intent of the RFC, 7950, but that it has been reviewed by YANG >> doctors and is probably the best fix. >> >> If YANG Doctors collectively say that this violation is ok, then I think that such a statement needs to appear on the Netmod WG list. >> >> I think that there are a lot of other editorial changes needed to 9127-bis to make it legal but they can come later. The I-D is in WG Last Call ending 20Dec2021 >> >> Tom Petch >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Dec 9 07:15: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 747583A0D50 for ; Thu, 9 Dec 2021 07:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 00t4V3XuQMkA for ; Thu, 9 Dec 2021 07:15:28 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2092.outbound.protection.outlook.com [40.107.94.92]) (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 445953A0D46 for ; Thu, 9 Dec 2021 07:15:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k5i9kTJc+K2L9igQtJDsa2Y8suD7QuSFTrMvVBgguNGSQRNKYqthxm7h6YQzLPyYKnuXo+P2dGkFl9x8SMSjVDK2/xa+rODaZVjqXaS24ovhlYb+YN6IGwDNjvahu244c12ywChM5ntGtVXNv1519z03ZATGFg9u75GCfy7bPImwYoAC4brt/1k0iwh/NtMyxr/P//id/xYYdBcFJhb+ulv6JWYreXpKUc3s/3eDlCY/Pnkpzeg/tZyjygmuziJljnT5moT2Lc0IGx7dw+FLpqDzBKISX/RpP7Ehl9BeQ7uVpul5Y8nQppvUGOksXkyU3kkek7O0JE4au+y5l5kIrw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0mwFPul+xghM5sJhDKdZE38ZYj+48C/aa9Y2asoRcyY=; b=H46+HQcl4qFaaA2s5KWT9VHs4yG747u6iJi5WZKt3euhn10FTVNCYPq+d9oQ7SuKuMBAAiM2cZLn34heoD+4crLb3NxnrAnv5xJm96xouyAA02uUiP0n/8x9QIf2mYB/NQrFFxXeqMlNFkSfMpFSYNXxdkEmQZUABeWx3jsQH4Cv2t9FvQu2IFedG9j+isYxhMDnoWj9tySutKIIxlIRX9rLrCZYE6h+TfIBSOzgsHb/G+x38y0NT/LHLXwbWHYrsNVwKelWzQQBBbu+XoWswXzPlrR1BRvvoPOElvID9dvMvcrT2PjzRhPHj7D5i7C+MgiCEdwTZ691Wk0MPxmTKg== 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=0mwFPul+xghM5sJhDKdZE38ZYj+48C/aa9Y2asoRcyY=; b=xDA96LfJeZYK4eTBddKFcPd75yAUloMA4bArwJPgeV+qq6cvj7PAFuEoEp1+BFNBFWAYANBOJMlc/YQCK2GLwRlF9PjbUV+NyR3Q5myXgbJvFHvpW003X+8t8qy4Vgc0dRcWUgx97RXFdiN8Pc+c310fk4ofiZSa2oxpSVi+Uyk= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB3514.namprd08.prod.outlook.com (2603:10b6:4:64::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.24; Thu, 9 Dec 2021 15:15:25 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 15:15:25 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Juergen Schoenwaelder , "maqiufang (A)" CC: Andy Bierman , Jan Lindblad , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] Must offline-validation of alone be valid? Thread-Index: AQHX6DUp5BZXcFhAE0+IivjOGbmtWawpL+ewgAALk4CAAO90gIAACvGAgAAXKdA= Date: Thu, 9 Dec 2021 15:15:24 +0000 Message-ID: References: <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <4010d6892a4b42249a5d3fda5d511788@huawei.com> <20211209134619.uspscxpn3kk2hycf@anna> In-Reply-To: <20211209134619.uspscxpn3kk2hycf@anna> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: efb5acd5-1807-43f3-7364-08d9bb26b9d7 x-ms-traffictypediagnostic: DM5PR08MB3514:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dcKPTttcbbo6Jz337VlGkh40s3Mi7aSt8/uca2yl2MDHzUv+KXQ3D6ZWNYlCGfA72R9p2+1KfR7JqUSlsBGIoXcoLCu5fgy9zq41q3x8rFWIfqmNCicwvQnKVvEWlFHc0fu37W0y574+l4Lt18lP+sMK2zyTXAdGIwImmKWSLgGDbpErWBCrwWrIynS5oQ/i0zCBWLF9KtxZ0ZoWhxWOZqXppUQZe4sgNa8PNqrgz93V0YbirJgVvsVwIRM7qLucvWYP3E/s24t2WAv9HYsA0duj/J6QzuDefW92fC2h0miWZswpidplxFRRaVwyaZT8BF9YQbNsKbjmI+LheNH0vEQQwcplAPCGFYSVPvs3JSb5vWO1MVteErghylXs56Gwtca5qGeYgNPTtohczwro1CgIkQj7h0MogBrMDK2tfhB1xObmh5XeVRiD7Di+bwUDi0pGFOBmhjMxB+bhVtgM++z0hPY1k1AmykA2Yg5kbMAHQyKPwmvsViz0i5Ah5OEJpfRH7CYveUjApoXct487kn4aW8sQGv7axEq9XmMGi+AGv6yGt19Z6O5iHgNJoJYQMbnkAxEpBBOH7i+R68MqaN1001gIzV/MpnZQLpegm9X+pLuDDj3N5deaj51JubW1pVKqCaBKdGYnmX9cXEyJ3NG0qr8zWJcE0Zzx2S3i++IpRaEGxlPJ8XFg0Rvt/0CbqBfkL6/q2C9h1ddtj5o4XRcRujgjfVsBdiRzvEodRVorvuXBNU1L0HWmNZoq5mrvQXyhD4T2zNozWTdJfjVTSD/jKVKvP6V5vQnbrdtOKl8= 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)(366004)(38100700002)(122000001)(8676002)(8936002)(2906002)(186003)(7696005)(40140700001)(66574015)(5660300002)(26005)(83380400001)(53546011)(6506007)(66556008)(76116006)(66446008)(66476007)(66946007)(64756008)(71200400001)(86362001)(82960400001)(9686003)(508600001)(38070700005)(33656002)(316002)(52536014)(55016003)(110136005)(4326008)(54906003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OGFwdFpoVzh4ZXlabzBnSDdDM2ZGZmd2TGpCeDRsQkVTNE9qVnRESTlqa09M?= =?utf-8?B?dnpHTTJ5ZTdYOVFLaUFUZDhSZFNzYWpYdlVhWUUxMk9SMWUxTU92S0VHTU1l?= =?utf-8?B?RFhQOEc4ekNGbjlzSTBaOUJ4L1o0aFNQQy9yeXVkYnNLVnhIaTEvU21OWGJX?= =?utf-8?B?NlB1Qmw3bTk5VXdqNkI3Vlk2YzdKeHRoTFRwTkdEU1lzMjNjQm85bjJzWlVR?= =?utf-8?B?N3l2VDdLUko1WEN0SVRlLy95bE0relNjZDBzWjdJNGEycXlzQVpyaDRMTmRs?= =?utf-8?B?Ni9PMk9QYU9PcW5xT3FhVzNPNGJybERnVHhoK3J0SmZKbzVFT3p5ei9xZnpn?= =?utf-8?B?QlRndnpYL2N0L09lK1VQNk9LUnlpRjFPS0FTU2VlQ2kzQWVWSklXYmtoRUlC?= =?utf-8?B?SzNSRjk1eGJqYzU3aGUzRFJ1QmJ6bHF2SDF2SW45cE9SZTEwQWJoMHZ0T3pS?= =?utf-8?B?eFVJZ3l1bGlGWUVVdUVZQVI1dlJBTVV4NGliK2VlQWx2RURIbnNsV2xuRW1z?= =?utf-8?B?RnlMU0RRSGJ0VXhPTE8yS2hvUEo1YzRwai85OUJwMlhrWmZVU2NJRnBiYmF4?= =?utf-8?B?NUlGVTQvVno0SXBCbFFsTndYbjFTMjdKaEY2NTB3azEzaHpzTTE4UlorOU9T?= =?utf-8?B?VHpWaUVaeHVDUmJRS2RHY0NFUW1xRHdscE90eGRXT0lyUU0xL3FNRVBwaGFS?= =?utf-8?B?cVJZbjg4Vkl6T1ZjWE45aWtUcC9iVUc3UDdtVVRQTllWQ3dsQUNlUFA5VThh?= =?utf-8?B?cVhSVExXYWdld1hlRnNtMW1sczRPR2FRTDlqN3JiZGFMQk5ZRGM2YUEwTFVX?= =?utf-8?B?YzR3MFZMd0VoQmJJTElBZkRYYUxwa1dnWWlqTkxQd2xtRnZEZmk1MlBuTVZz?= =?utf-8?B?Y3l0cHU2V3U1NEVRUTEvZ2xCbEtrSXVjVHRkWUl0Q2lFUE9BTTFzcXhPRi9O?= =?utf-8?B?bG9LQmJ3OFhBNmRPaGdNWDM0eXZUL0ZDK1JhellwYzFrai9CRXU1TlVkWWo0?= =?utf-8?B?WG9aMURscWc2TWJ3U1VhOTJxbGdNNzBzRnc3YmpBZ2dIakE3d0lYNDFNbCtR?= =?utf-8?B?YjhJby8rZGxVUi9pY1VUbVlWeENJZ0pwQ0w1Vlg4QnBveThQc3hJN0QycWxo?= =?utf-8?B?dXFjanVqcjJmUzdGRGNBK3A5ZnhIZUpOcXo5MG1lTkdIYkN0R3FTZG9SL0ZM?= =?utf-8?B?d01BbXJFTDhwZkVGMys1OXpFcWJuRFlDYXZmUnZOUG51QVhyOU5HbnpuL0I4?= =?utf-8?B?T2MvdG12WWh0OWNYUWN6bE5Fc2d2MGlzWXRPNzVsWURqNkVoK0hCVjlSL0tW?= =?utf-8?B?c2JUVEw3UW5nZXBvNkh1VDFrbGxHL3pDTzRsMFhTNG5LaXRNeGZKMXBpUlRB?= =?utf-8?B?Z05lQkpER0dUM2NYNTZ3d2NRbHMvY3UvV3RaT0cwMGoyczY0S0dKNy9WdnZH?= =?utf-8?B?ekl6QUROMXp4cjlPQytZbGZpeVdiYUlhdmxZbXJLaS9OOVFueEN1bHY1MXNK?= =?utf-8?B?VlZZaDBrbEtPRUlXeTZ1dzdrOGxMVExJbFFUUjFzaytnUU0rYmp3a25HanF4?= =?utf-8?B?Y0ZTcVM4WHpLNExQNGh6RUpCUENibVllaWxTVUNiQkh2eDVzRWpOdmVNUHk4?= =?utf-8?B?elZTcm9XSFhjeE1zdmFWaUhrQ2syRFJKeXpQdEZOdkFxUnN1RkRZNThleFQ0?= =?utf-8?B?ZlgvbWlkZHpJUytYckQ3M2VqQThWdm9xNmRsVVFvbEtBMHNMajFLV0tuZDRy?= =?utf-8?B?Yy9laEpocGMyQzQxWk00a3QreWtrbGQ5bHpSR091Y0FMdmlIQWN3Mjl5bjB2?= =?utf-8?B?Nk80NmwwNnNJWmxPTmRsamRUTkp5MXNBald4RitYaUxwby93dXpqZXFubE1D?= =?utf-8?B?cXNFY3Z6Q0pudmNEM1RyRk5XemlSdEdUQkJkZExDQ3NPZUJRekovaC9BWkdG?= =?utf-8?B?bTNzQVJQcGMvdnhpa1pPamFxd3gxRnhNYlRkU09yRWhjVHl4QkdIOEd2QWdQ?= =?utf-8?B?c214SWoxOWhmdjlUSjNscFRNL3NQN2dTSDkyRlYwanJmS3JwNm5LOU5VUWJR?= =?utf-8?B?eFJpdlFzcWwxTXo0Q0Z0L01LbFVlc29DdU1Dc1EzZUd0T1gxTUs2VEw2bmZx?= =?utf-8?B?SnlkYWNOSTBPZllBQk1pMXlCRXluYVMyem9FL0YvcENPWkI5ZC9ER3pIKzRO?= =?utf-8?B?NWc9PQ==?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: efb5acd5-1807-43f3-7364-08d9bb26b9d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 15:15:25.0132 (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: atkGZ0q5NR4NUGNqpBLRTWHXKQf50UiKIPbKBT26Ghzj8fH6shdLOgRwhPpux4cu8zk1OX0dXBRk5SqkyJlKyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB3514 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 09 Dec 2021 15:15:34 -0000 PiBBIHNlcnZlciBhY2NlcHRpbmcgYW5kIHJldHVybmluZyBub24tdmFsaWQgY29uZmlnIGlzIGFs c28gYSBzdXJwcmlzZQ0KPiBhbmQgaW5jb252ZW5pZW5jZS4NCg0KQW5keSBtYWRlIGEgc2ltaWxh ciBwb2ludCBpbiBoaXMgcmVwbHkgYnV0IGl0IGlzIGN1cnJlbnRseSBpbXBsZW1lbnRlZCB0b2Rh eSBhbmQgdGhlcmUgYXJlIHNvbWUgZGVzaXJhYmxlIGFzcGVjdHMgb2YgdGhhdCBmdW5jdGlvbmFs aXR5LiBNYW55IG1ham9yIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgKGF0IGxlYXN0IGluIHRoZSBy b3V0ZXIgc3BhY2UpIGhhdmUgdGhpcyBjb25jZXB0IG9mIGhpZGRlbiBjb25maWcgdGhhdCBjYW4g YmUgcmVmZXJlbmNlZCwgYW5kIHN1cHBvcnQgY29uZmlndXJhdGlvbiB0ZW1wbGF0ZXMuICBCb3Ro IG9mIHRob3NlIG1lYW4gdGhlIHNlcnZlciBpcyBhY2NlcHRpbmcgYW5kIHJldHVybmluZyAibm9u LXZhbGlkIGNvbmZpZyIuDQoNCihxdW90ZXMgYXJvdW5kICJub24tdmFsaWQgY29uZmlnIiBiZWNh dXNlIHdlJ3JlIGRlYmF0aW5nIHdoYXQgaXQgbWVhbnMgdG8gaGF2ZSB2YWxpZCBjb25maWcgaW4g dGhpcyBkaXNjdXNzaW9uIC0+IGkuZS4gaXMgaXQgb2sgdGhhdCBydW5uaW5nIGlzIGludmFsaWQs IGFzIGxvbmcgYXMgaW50ZW5kZWQgaXMgdmFsaWQgPykNCg0KSmFzb24NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKw7xyZ2VuIFNjaMO2bnfDpGxkZXIgPGouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVy IDksIDIwMjEgODo0NiBBTQ0KPiBUbzogbWFxaXVmYW5nIChBKSA8bWFxaXVmYW5nMUBodWF3ZWku Y29tPg0KPiBDYzogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+OyBTdGVybmUsIEph c29uIChOb2tpYSAtDQo+IENBL090dGF3YSkgPGphc29uLnN0ZXJuZUBub2tpYS5jb20+OyBKYW4g TGluZGJsYWQgPGphbmxAdGFpbC1mLmNvbT47DQo+IEtlbnQgV2F0c2VuIDxrZW50QHdhdHNlbi5u ZXQ+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIE11c3Qgb2ZmbGlu ZS12YWxpZGF0aW9uIG9mIDxydW5uaW5nPiBhbG9uZSBiZSB2YWxpZD8NCj4gDQo+IE9uIFRodSwg RGVjIDA5LCAyMDIxIGF0IDAxOjA3OjA5UE0gKzAwMDAsIG1hcWl1ZmFuZyAoQSkgd3JvdGU6DQo+ ID4NCj4gPiBSZWdhcmRpbmcgb3BlbiAjMywgaXQgaXMgbmF0dXJhbCBmb3IgdGhlIGNsaWVudHMg dG8gYmVsaWV2ZSB0aGF0IHdoYXQgdGhleQ0KPiByZWFkIGJhY2sgZnJvbSB0aGUgc2VydmVyIGlz IGV4YWN0bHkgd2hhdCB0aGV5IHNlbnQgdG8gdGhlIHNlcnZlci4NCj4gPiBJZiB0aGVyZSBpcyBh ICJzeXN0ZW0gY2xpZW50IiBwbGF5aW5nIGEgcm9sZSwgdGhpcyB3b3VsZCByZXF1aXJlIHNvbWUg ZXh0cmENCj4gaGFuZGxpbmcgZm9yIHRoZSBvdGhlciByZW1vdGUgY2xpZW50cyBhbmQgYnJpbmcg dGhlbSBzdXJwcmlzZSBhbmQNCj4gaW5jb252ZW5pZW5jZS4NCj4gPg0KPiANCj4gQSBzZXJ2ZXIg YWNjZXB0aW5nIGFuZCByZXR1cm5pbmcgbm9uLXZhbGlkIGNvbmZpZyBpcyBhbHNvIGEgc3VycHJp c2UNCj4gYW5kIGluY29udmVuaWVuY2UuDQo+IA0KPiAvanMNCj4gDQo+IC0tDQo+IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy ZW1lbiB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6 Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Thu Dec 9 07:17: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 99F3B3A0D50 for ; Thu, 9 Dec 2021 07:17:33 -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=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 okbDQDxeQdIX for ; Thu, 9 Dec 2021 07:17:28 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2066.outbound.protection.outlook.com [40.107.20.66]) (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 413D53A0D46 for ; Thu, 9 Dec 2021 07:17:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lhSoO9ANyQcCB5+IFJ8dyvoMbrqWvU4ptzUovjq+DIaB1vMvl/M8I57O/CZCW5PrflSPk+nMQ/INCsGcACrUK2ZEOx4gAGavs8lfSjcX1f0/YOPnm7wVRxGAdLKm0PMpnHHB+7m/WT/WtoQfqIAin8SWyPOWuYbiE4eAv+fW6LwvrGZ2uUUAcIfQnO0L1uHS0bQmqe1eBSroTBB/8yIzIH1c32zgIgoCm9iNu0qh7u+WEJ6hTIeqjN3mDuaPiplC+TfhtxAqVLnOlLpyx6X+uGwV13+/mGIzNra++82DTLbdANr8YvOC/kSADshIrVHOa1BGxAoqM5wijE3Vx2IKDQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uC/KQVDAnqZr6GV9ayhldZ1BzW9lf++i5rZ6BNrsUT0=; b=VdpTlpkvz47fS1HeZQQjvSh7LWG1QeUNJvZ/7lqPFKvkBGYSQ//vIsSUkS9fAymXwz5aDSvKN6xUpjJN/g/C+1Coef4a1ZwFo6GcL6g2hgYgPxwRFDl54dmL6rLlKayOwykGPys7+Da/K13nzsnzFYcHXGlUSxIGL5ptPv18ivIcIUAb1T8n02dhSrdIdxn5DTWB3EDsxHbwLM/GPcL+WBcBmt8j57xUqb+YtaUN24t3pCvvWPUq80tNPI1/yVjPx+usFL9a3O/2YyAtkZIGtwJT5HwVtP2XzuFsO5ULzrH+TqjgkpbHavcRMBk+RsNtt/64p9MFlJwiWCADmb5e7w== 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=uC/KQVDAnqZr6GV9ayhldZ1BzW9lf++i5rZ6BNrsUT0=; b=O7iKsxQ0+ih90uE13QAnBNPWROEHRMB7AEDXEEDbQhdx+Ux4smmMmtiC6ED1/WniwWqajHzZ2dWnLJmUd3xbB7s4sNmdO14wj760OJnbDteoQzQBPTQ/IQ5krHV1XMsCAMjn9abGPWWlrWnj/e9Uukcfv8Lu+TpvdnFyarZClg4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1585.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3b6::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.12; Thu, 9 Dec 2021 15:17:24 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8%3]) with mapi id 15.20.4778.013; Thu, 9 Dec 2021 15:17:24 +0000 Date: Thu, 9 Dec 2021 16:17:23 +0100 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "maqiufang (A)" , Andy Bierman , Jan Lindblad , Kent Watsen , "netmod@ietf.org" Message-ID: <20211209151723.fjf4hjyoui5t6r4m@anna> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "maqiufang (A)" , Andy Bierman , Jan Lindblad , Kent Watsen , "netmod@ietf.org" References: <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <4010d6892a4b42249a5d3fda5d511788@huawei.com> <20211209134619.uspscxpn3kk2hycf@anna> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AM0PR07CA0027.eurprd07.prod.outlook.com (2603:10a6:208:ac::40) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c912e0cb-eec8-4899-d6c3-08d9bb270109 X-MS-TrafficTypeDiagnostic: AM9P190MB1585:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hmHQBhSltXN9LPkZzAxO8x4/7U6WspW05r52SODX6oXrgdA71KiBFuZJx8x3Ubk6fQVH43aiTs71RaYA89PvVkp77bT1xmv4ZF8zYHXPLVbNha86OgGczeEhEdzXWvLbGK0risK11C4chuRbM42Ca5Q+t6cs61YLyOA/iIJvAoegvP+4Xcdsd2hGOHBNL4p0Aw3MNrh+XHT5Ze66mhiptNErRT6zQxtVLDxsvl8TgRdNatCL+Wo8P14IFz6IrEaPOkUL7AJYbYUQZuxvddqgFHZ7eaiTfb0MQRYASertT5+vYokt/Y0vTbUaiEziA8KAtc4ecFo8sRWHF5yU66aFHX6PypW6/Gjedb4iQOrltQGLIt3r7aO5R/5ABbf9j3zL82c2GbdJ49uJX4OK+f+CX2QBkJ0bnC4It1TvEEWhqqk4WfSvTwSmPo2DxxAd05/B0Few7ZFpv3mJt2YyY/feOGqkCA8UxlMYbi1Czk4ei22mKweMbJLSmx6fL3DN+xCQvwyUdGnB68ubjQOOemF+VzEcTh2JEsshmjLG66i9+hZne2+SZwqP/ppDr3hNjJIyKQ5G9YwBL20gYO3VBQigDhRexOtNmOKF4EsSyXDt+KBFA/83+YvceMsn/0GpmI8AxXuTJGuX3G7BjtR9vA+ViRfvE0errfjk9Ykkmq/QCwwUdp6t7shAqzeBTrWagDxcqrLcux7oVQb4KyNgY+yAILdR0Rf6Dx4khfxT5yUdygIULz+SlNRRQcmMVuZ4OsnHATFb/tFUDcKGz3VvFBXXMnuNZ3aVXsh7IH3piPHPpMs= 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:(7916004)(366004)(86362001)(6506007)(4744005)(52116002)(5660300002)(8676002)(508600001)(1076003)(38350700002)(9686003)(6512007)(66574015)(38100700002)(85202003)(186003)(4326008)(40140700001)(66556008)(33716001)(66476007)(26005)(6486002)(85182001)(8936002)(296002)(316002)(2906002)(54906003)(6916009)(786003)(66946007)(3450700001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OS95NlFHdHVuaWlLcmtheWJITmxJaFB6WmV6NVdvRHpQL1BpTWs4SEJuR3Fv?= =?utf-8?B?UGNYclpsdkVtVXlnSUtjWG42NVB1RGFQbUxiMExUR1RNN2x1NmFWdk9BWjQ3?= =?utf-8?B?djhBdks2ZTc3M1huS01lbmNZQSt6b0hjdHdFUy9jUzN3UnhqaHdLWGN5Q1Bh?= =?utf-8?B?Q3J0RVFzSjRFZEFzUGc2MHIrOUhWZDQvK1pFWmVtc3FuV2Ixb1hYOEs2dFBP?= =?utf-8?B?RjhWK1kvYUNCR2RMVENhNnpxZUNBYXEzcm5kZ0RrV2YrRUhMQk55dW9tMmcx?= =?utf-8?B?Z01sL0Q4dlBxak1XVGRQVk9UdW9STmdTR04zbVFjWTVNQ3QweitEVVI2bno0?= =?utf-8?B?UGNlckxreHNYRVF4YVN0N3RmLzNGN2dYSVNwZEZlaDlCa1piWTNHUVNTaTRn?= =?utf-8?B?cUt1aTRTRXhUbGxsc0hTMHA4VkJXeXdDRU9RVlMwbktwaHBOTC8rMjZaT2RP?= =?utf-8?B?RkxzcW5zcGt1aE9oOG0yVFo2eFlDdW82ZHlKS1BFMFBhaEg0S0JpMDVCdWVh?= =?utf-8?B?TUdRYkd3ZjAyQXBoaEV1V0JsVHBJdU9qTEVJdktvY1c2NG5BVGtXL2s5OElE?= =?utf-8?B?a0NxRGpDeGpvdEx2enRSLzVmaVpLeUVBS2F0cWRMK1VobjAvYlRzSDNHUHl2?= =?utf-8?B?WXovc25TSWxvbmxGdmEydWpaOXV5bEpKckRIT0hteE44RlVTbTVTc2lQNU1z?= =?utf-8?B?dVpRYTJ0OXo2N0lUV1pmUE5lUXc0NVRialFTU2h2VUtWbmFnN2VJbGZyaHI1?= =?utf-8?B?Sm9CbEZHelJHRzJuRzZDT052WmJLRkVjK2xqVDlaSFRIZW11R1NPZFpVUC9m?= =?utf-8?B?ZEUyaXdQV1hGRHQvcDk1amZnNnJBcDkzNURBdWI5Vmc1NjRwTytQWXlxVjZF?= =?utf-8?B?L2ZkVUdGMm94eThPSTF1M2hCWk5FZ3BFYm1HeHBJZ2VMaVprckRtOTZtaGVG?= =?utf-8?B?d0pCZ0JUSU9rS3ZxZkFSWjVIOXQwbU5rWHIwQnZJbVZ5OUtGaDBtTEsxMytX?= =?utf-8?B?SndsK244eWJEVEp5NSt1WnNtQ2VQVC9YcTRhK2ZjVWFFM3FFRFhZaWd4Rk1v?= =?utf-8?B?Tmg4bmp2YW5oeUtrUmx0RnQxZVVXdFdFOGRVUytHeXFDdk1Qa3MrVTBFWU9h?= =?utf-8?B?ODZ0bStGMnd3RkZDMnFOUzNLSXVLak81WFliYnUxRHJ3RjFKb2U3U3RKT3RU?= =?utf-8?B?cWlvV0dueHdKaXZEOU5mTlFBaGJTME5Fd0J4TlREVEJCZ3NRWVIxK01EREJC?= =?utf-8?B?Z2t5WEwweFV3bG5mK0hmMTQzZ21TTjdXV3JyYzdMT0xSbUNYUW1JVEVORGta?= =?utf-8?B?OHE3VktwMFl4aEJnRml2VFdTdzdhYmdRdkw2OVZ1bi9lbWdGT1pkenRmUEFK?= =?utf-8?B?dm9ZVVZJVUNJTTdrd09rS1RTOUNuZ3EzRkovK2FYaHFhZ1l1TTJzSzl6Wlo5?= =?utf-8?B?VEFtYURmUW9DeXNZaTdTcVIrWXgrVjU5bGd1ZnlIWUE1UllsbVpNaUVCK1RP?= =?utf-8?B?c2NmM0tsL3grdHhsb1NoUXBEam5uUlZZekZTNnVOUlRwTVkrUnRMdW5YL1d5?= =?utf-8?B?OExncVlTc0pqNGtQb3lDLzJkVzI3U1ZwZ2RSVDZrRWdIa2xkcVNqMDRaYjlq?= =?utf-8?B?RTBLVkV3RFJYLy9Gb25KTEIwdzdwQXdFdHh1aWRMaU1TSEFuSU5rWmVGUFlV?= =?utf-8?B?Y2tsLzdkRm5VTGxhVjkzMFpsU2tDd3RjKzljT2xaOG9FVWVSdFRpemVudGlQ?= =?utf-8?B?eG5mZUhoMU1tbkMycHVnWDNtbjQxNXk4b2JqRExlUVFLbWhrYXJrNGFRNjVW?= =?utf-8?B?UTkrTkhyTlhIRkNRbGI0VFYrMlFWZ0NFbE5RR0FnY3BtbkFDRkxjMUlmNXlo?= =?utf-8?B?UDlFVC9CU0ZZZFV0UjgyNlRqQ29lZFYzQktLSytVY2ZQSDEzUnIrWUdRZnY5?= =?utf-8?B?dVIrMUpQQjJSYlQ1cFNiZkV4QmpTVFVwcmRLN3I0T3RZclQ4NSt5cW42ZDMz?= =?utf-8?B?TjVRdFNhc2ErZExXY3o0a2JjZGt6aEVwaUZIMW9kSkwvYlJsY0p4ZERGdzI5?= =?utf-8?B?NnJqV2g3VEpmOTJxa1AveWZ4cCtPLzEvZ004YTMvVHkwb0QyMnZQbTJJWERw?= =?utf-8?B?S1hZRml3ZTFJdjJ2eGIvQWczV0pQako3VTFyOXJkVkJSdXRvS2pRb2dUMjl5?= =?utf-8?B?U1hBQjRqU1lZdDYrUTh0VTV1Kzc3WTNlVEI0TVV4ZTA0WktBcUNjOUtlbVkv?= =?utf-8?Q?IzwHAASGMIA/HaiYhB+H9Oednr5o46d3GNrCgyUoTg=3D?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: c912e0cb-eec8-4899-d6c3-08d9bb270109 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2021 15:17:24.6113 (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: 69oeU3kpCNXAvvea1Kggx91OTXRgak0j1R+HsnX4azQWOZxPvN6SS19kcjQRU897/Br/5odlQJlAOK1cjUZYX83bETU90bnyUgQeanCHoXU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1585 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 09 Dec 2021 15:17:34 -0000 On Thu, Dec 09, 2021 at 03:15:24PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > A server accepting and returning non-valid config is also a surprise > > and inconvenience. > > Andy made a similar point in his reply but it is currently implemented today and there are some desirable aspects of that functionality. Many major server implementations (at least in the router space) have this concept of hidden config that can be referenced, and support configuration templates. Both of those mean the server is accepting and returning "non-valid config". > What defines "many major server implementations"? /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 Thu Dec 9 07:19: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 EA3113A0D6B for ; Thu, 9 Dec 2021 07:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 GgXA0kcyBfGs for ; Thu, 9 Dec 2021 07:19:02 -0800 (PST) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2110.outbound.protection.outlook.com [40.107.102.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 B915C3A0D56 for ; Thu, 9 Dec 2021 07:19:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mMjfUfMICa1KMNOzJzHqoqfkeDSbkrFkcLCFJ/GRCM71UI9fRTbbqpq6WcJXoBy89tiyLwmCkhnxkuoqiEacFfmUKX7A91kF3mR7yV68Nnj0fAj2acz1Z8DNTRk+0KDjZk38yNHR6Pz1dv6u9wtfJ9uJH0QKYKe6S9zDvIeLJZICT6aq67Nd+90URWmB98LPcwiPh6JJlofL892DsZMfRCuFpiTm1v3wQilmtJavQmoDyrnI34UolOICnN6E/fjX9vFuco9/fHsT+Cx8EigivdSzWXxJPRHHN80IwSutY1EAt7DXAf3MNCD0ou58o7bceoRMEVjL1xHXaUZAWWrw2Q== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Iry5XyrTSchftPx1gmjtw7Z84ZJIqmgLV+kyivFL5qY=; b=aw0uWxBcp8Hzh1dI6Cf1bqKxEkgn3Lo6d9tyV7+GTwY9o9hBtbvpaR+gyangz9CFiGucYnN6txfRQPdiNFza7HPO99BF8jNpQJEdGv/arEW0pNT1QuxaCFqSuB83IKVk/VsqiDOzjHYl9pcS8yWqfPHzLAO+TK4pY5x9fy1b+/qG+zx936DiPKg0yrWo4kjMh5A05iiPN4vTyzvQDt0V8x2FfKjQBuQreatlGJp/UgSfa5rZ9zSJuRX3buIciIN8wOh6RCpFJlBwRgDu1s48E4wHgi/ADIGJp6SMFdh5wWg8i1Kl2MuaA4M2FWA8zObTy5DQxpbwgLUBjBL4n7BSUg== 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=Iry5XyrTSchftPx1gmjtw7Z84ZJIqmgLV+kyivFL5qY=; b=NaiiISrEgvr93+ITsYQoVVBznIFuR6+1m41oYK5okvGLX2B89WWJKgpsboHbdPAPfcUP1K3XQBbERsl8fZeFk4dhyBNtCFh+FUQWUtdjbOvUg2FVV4YfMt+STFVEo2BjNJsQnfcmXkKA7w8ZtZk0AgMP4Nw5KS3iHpUSr/fJX54= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB4233.namprd08.prod.outlook.com (2603:10b6:5:9a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.11; Thu, 9 Dec 2021 15:19:00 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 15:19:00 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Andy Bierman CC: Juergen Schoenwaelder , Jan Lindblad , Kent Watsen , "maqiufang (A)" , "netmod@ietf.org" Thread-Topic: [netmod] Must offline-validation of alone be valid? Thread-Index: AQHX6DUp5BZXcFhAE0+IivjOGbmtWawpL+ewgAALk4CAARNlgA== Date: Thu, 9 Dec 2021 15:19:00 +0000 Message-ID: References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0d37f54-1222-4008-cfc3-08d9bb273a1c x-ms-traffictypediagnostic: DM6PR08MB4233:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1ucawF51cH/3SsNCeJEfKPjNtA1XqDnpB8UtuHMMQkzi+yicXVETtjxkrsNrkrd5zZxJz0r2EZKXppXBX0ptFx7u4OoHKyLA3uBEJKlbub5UVVIp3kp/ceO+hdxI5+w+HLgW0ABKdhS1/jN4SGjJh1fUDxpmYejAIMsGQQzOiUFs1uEPI3owTbGrXxSRCt+jQSGoI/KbfqABdtPy0qcrGCRsTBHF2a2VkRIro6qvKxf4aEiKTYoLpU8AwRgjDQRQG7J+6Wmhml4EK4tlxAPYKD1HUGuQ3leZtdwEomOWTSvbIbugBQRgUfGNL7R/8uw40jwcaM7bJkoT3pyl8inG5hlBHkNbwH+iGOQ8eRuMvHWm1F4xgWnrWP3PuGC1EZ/b/q9I8rE0Sd3qRRaD4HVxDY9cPQWrBUNbl+rfQVXa4bd2/wzhowGPqOFWf/vBGwVC7u9o9Iy4WV/Vr9TUbqxhL5U2fligCvqCbchR+KGuOEemigb+WiTbdYnvBNkM2ehCD2WE2yr8iud5RDIKM4pztiXjaALQo9p5RXSlaj6RulsxQ+6W5qbCn28On1LNShGzU3BBimAYQ1XF7wLgYzCBdANck7QAoz3iFa9EQt4s6yBAgTdHdIzeOFl1EX+BLkbCMDqopPniOEIAyod1OgP5YKxsOILzyLw3ApxNw0uwZdwh9rgYmJSsQvwW7lZ/B3Uk4x/LqzB4TweSs2Or8P8YJFYN7gl4cLV00ftJ0DTas084f+L6Fxvevzp0+dCfNV8+gCtVueOknYL0YuUph0rUrv87rUIGTyRseNabxkSA/uw= 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)(366004)(52536014)(38070700005)(122000001)(6916009)(55016003)(316002)(66574015)(33656002)(2906002)(71200400001)(54906003)(66476007)(66446008)(64756008)(7696005)(53546011)(966005)(66946007)(82960400001)(8936002)(83380400001)(8676002)(26005)(166002)(9686003)(6506007)(9326002)(86362001)(4326008)(38100700002)(5660300002)(40140700001)(66556008)(76116006)(186003)(508600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NlVNMGZDMVcvZ29NL3VCdFhMdm9vTUtpZDlTV0xmamtnYk16dkQyOFl6QXUv?= =?utf-8?B?Tzh1QUVMYWFzajZFb3VWQ2c0Z1VVOGhUM00zaEorc3ZzSHdzMm15UFRxaE5a?= =?utf-8?B?bmhQM3lmK1BGRG9JcWJwZjZGMS9Md3hDSEM5a1YrZ3pybEZlNjhZSnVveGNt?= =?utf-8?B?RXRWVTYrbGI3VnQ0bGNpLzhEUCsrUGw2ZmFUazBaWWpyTU1jQVd3YUFqZ2pT?= =?utf-8?B?Wk9lcVBVNmp4dytybHBmcndHdGFMVTU3NEw0c1ZNVHd4VUpJWEJUbWRYS0lh?= =?utf-8?B?cGRjOS82aDhzWnFJNG91OTVzVHJyWkJUSmhiSnlQZlRiRDVoYlJkMm90M3ZG?= =?utf-8?B?ZkcyV1hDR3dibENhNmsrYXNpeWJOZDVjSklPRUQ2WWI4UjljWm9Kenl4dW4w?= =?utf-8?B?NldLN2Q4RFA1VUd5ekVEalE4R0I2OGFRREljb0p6Vmo4QWU5bVNoL3VHRDJX?= =?utf-8?B?UzhuazNKamRkUkhPT3h0TTZJckRld3BGRUFrNW1tWlNjT3E4UzhtRldLay8v?= =?utf-8?B?N0JNNy8xMVVlY3FOMDBvaXh1UVk3YlBrSXJUOWxGd3h2eU9BNWMvUHZnN3Qw?= =?utf-8?B?elRNaHl6b1Zmakw3eG04YjBpcXV5VlJSc1drdEI4L1pHZjZkRzNZVldqRG55?= =?utf-8?B?c1VOUGtxdlNXQlNUbGVZbTNFaDFrbldoemdLcTBQMGpXTUZoZEVPYVRJTGJn?= =?utf-8?B?KzUxMSsyMTlwZTJJQXZib0tuSXk1S21zLzhpN3JURUNWT3NsdS9iRjl6TXBI?= =?utf-8?B?Vi96NUwwZUc2cTVTSDFwNGo4aGJDWWh6UnpQQVdVeGR3Q0pZbUNhTzRCamd4?= =?utf-8?B?Sy95bnRRekdiaElBSmFtK1FXbzJ1TWhhVHcrcWFZRE45RFlENUUvZWNKVHdD?= =?utf-8?B?THNWNWcxOFhWZ1JGa0tnS1lqSmVsZkdoTzVMeElRQ3NmVStaVWJDbk0xMTV1?= =?utf-8?B?aDV0ZmRhZjVnWG91WU1YdmovRUtzSklWOFovcXA2TUwyRU9RUVpXNGZnVmRN?= =?utf-8?B?T2FxU0dHbTlxcThLaUUyYVV5Q3hYa2t4bWZGbW1kbENSTWc2QmM4WHMxK0RZ?= =?utf-8?B?TXNxMmhUNk9aTmpPbmR2TWd6cFp3L0FPRkhLVEJ0Y25EL1hxOGtwM1hPL294?= =?utf-8?B?eUpGN2l0eGd1WmtFTzVGK2lER2JldmowbnFRUFZLYjNRYVNRR3B2akFveGgr?= =?utf-8?B?Q2hMODFpSXRML2k4U3I5TFROQ1Rid0F4c0s4c2k5U2FGcFVEdm52N29idTFB?= =?utf-8?B?cFVKczR5andJaWYzRnlvVDR3cFNHYnNSU0tOanUyZlNvSzhuRUxoMzFNaUQ1?= =?utf-8?B?ejJiSlVEL01OY3NFQU44dS9OVjYrbUorcFdoOFhiUzF6UWwwd0dKL09rdEhw?= =?utf-8?B?dlA5R2ZNa0lvTW5Ib3RRbjNndTR5azBCZ3hMdXd1NGRhSVVINEQrSWtod0xW?= =?utf-8?B?WUo4cGRQRGpkSFplbEVaSWhteElQMUpucnZYUjAwRVBubUVLVi90bFR4WmJi?= =?utf-8?B?T3lmY2dJWE1CVnZQQzZPYjNRV2lEaVd3VnJjR2dlWXRnMzk5UEt0bW5GN1JZ?= =?utf-8?B?dHoyZjlIUWt5YlJETFJkald6TzZNM1dtUGN1UlpCejg5RUM5aHUwOEthaUhz?= =?utf-8?B?SXZ6Mzc4KzZSUmo0Y3lwdGV5N0E5bFQ2dU1EVWVOSnZOVWZHeisxaCt3MGRG?= =?utf-8?B?TmZiWWVvS1ZOd3EzSVpzTE44Um8zVXNWTVprSTgwWHRWeDBPSVJRTnhpOUZG?= =?utf-8?B?U25DK1ZUb3lwM2NHQ2h0WG9sV3E0aDdPL0R0bVQ3VWpQTTdRRElsdy96LzNr?= =?utf-8?B?ODZaSU9PYUxzZFdUaFRTTXRwczlURHZiaE40TXlUWEU5bkk0MDZTL1E2QXo2?= =?utf-8?B?QlpadVY0dWwvaWNUQU5lcGtqRWhvTnRNQk52WWg1cFlHdlowQVpsMGI5dnU2?= =?utf-8?B?dUhDRFZIdU5aSmZjb1FHNU5SYVhtaEdjZjI5SEh2MHVhRkFmUWJTMlFIT3ZW?= =?utf-8?B?QStITi9DQ2QvR01icnVMOGhYNEFQSWtOc2FMSW5iN0xUL3JGNXhEb1VwZU52?= =?utf-8?B?SVY2eUFsTGJTZ1ZMaUhaeWI5Y2JUSW5mUnFoUE4rbmFNNDJjU2FIQXVaeFcx?= =?utf-8?B?OUJtTFBtTEVsNTZhVFJRRVJ6cUVHbDNaZWErZUphVEN4WHQ4MnZQa2dmNkhi?= =?utf-8?B?d2c9PQ==?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB50843C4B006A72F355598AF19B709DM6PR08MB5084namp_" 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: f0d37f54-1222-4008-cfc3-08d9bb273a1c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 15:19:00.1451 (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: gnTuvXK5qsNPwqV60QONkWbUDoAGcnvkuqpJS/zqMoAis6WOL6dk5IKUQ97dfwCIhBN2rhH43/TQkeNYMTBhTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4233 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 09 Dec 2021 15:19:08 -0000 --_000_DM6PR08MB50843C4B006A72F355598AF19B709DM6PR08MB5084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCBLZW50J3MgYWx0ZXJuYXRpdmUg dGhhdCB5b3UncmUgcmVmZXJlbmNpbmcgaGVyZS4gQXJlIHlvdSB0YWxraW5nIGFib3V0IHNvbWV0 aGluZyBsaWtlIEpVTk9TIGFjdGl2ZS9pbmFjdGl2ZSBjb25maWd1cmF0aW9uIGFubm90YXRpb24g Pw0KDQpJcyB0aGUgImVuYWJsZSIgc29tZSBjb25maWd1cmFibGUgbWV0YWRhdGEgYWdhaW5zdCBk YXRhIG5vZGVzID8NCg0KV2hlbiB5b3Ugc2F5IHRoZSAiZnVsbCBzZXQgb2Ygbm9kZXMgaW4gcnVu bmluZyIgYXJlIHlvdSB0YWxraW5nIGFib3V0IEphbidzIG9wdGlvbiAjMSBiZWxvdyAoYnV0IHBl cmhhcHMgd2l0aG91dCB0aGUgZXhwbGljaXQgPHN5c3RlbT4gZGF0YXN0b3JlKSA/ICBpLmUuIGFs bCB0aGUgc3lzdGVtIGNvbmZpZyBpcyBhY3R1YWxseSByZXR1cm5pbmcgZnJvbSBhIDxnZXQtY29u ZmlnPiBvZiBydW5uaW5nID8NCg0KSmFzb24NCg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1 bWF3b3Jrcy5jb20+DQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDgsIDIwMjEgNTo1MCBQTQ0K VG86IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EvT3R0YXdhKSA8amFzb24uc3Rlcm5lQG5va2lh LmNvbT4NCkNjOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZT47IEphbiBMaW5kYmxhZCA8amFubEB0YWlsLWYuY29tPjsgS2VudCBXYXRz ZW4gPGtlbnRAd2F0c2VuLm5ldD47IG1hcWl1ZmFuZyAoQSkgPG1hcWl1ZmFuZzE9NDBodWF3ZWku Y29tQGRtYXJjLmlldGYub3JnPjsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1v ZF0gTXVzdCBvZmZsaW5lLXZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+IGFsb25lIGJlIHZhbGlkPw0K DQoNCg0KT24gV2VkLCBEZWMgOCwgMjAyMSBhdCAyOjMxIFBNIFN0ZXJuZSwgSmFzb24gKE5va2lh IC0gQ0EvT3R0YXdhKSA8amFzb24uc3Rlcm5lQG5va2lhLmNvbTxtYWlsdG86amFzb24uc3Rlcm5l QG5va2lhLmNvbT4+IHdyb3RlOg0KSGkgZ3V5cywNCg0KQW5keSAtIGFib3V0IHVzZSBjYXNlcy4g IEhlcmUgaXMgYSBwcm9ibGVtIHdlJ3JlIHRyeWluZyB0byBhZGRyZXNzOg0KDQpUaGVyZSBhcmUg YXQgbGVhc3Qgc2V2ZXJhbCBtYWpvciByb3V0ZXIgaW1wbGVtZW50YXRpb25zIHRoYXQgaGF2ZSB0 aGlzIGNvbmNlcHQgb2YgImhpZGRlbiBjb25maWciIChpLmUuIGxpc3QgZW50cmllcyB0aGF0IGNh biBiZSByZWZlcmVuY2VkIGluIGEgbGVhZnJlZiBieSBleHBsaWNpdCB1c2VyIGNvbmZpZywgYnV0 IHRob3NlIGxpc3QgZW50cmllcyBhcmUgbm90IHJldHVybmVkIGluIGEgPGdldC1jb25maWc+KS4N Cg0KDQoNCkNsZWFybHkgbm90IGluIGNvbXBsaWFuY2Ugd2l0aCBSRkMgNzk1MC4NCg0KSU1PIHRo ZSAiZW5hYmxlIGZsYWciIGFwcHJvYWNoIHRvIHRoZSBnZW5lcmFsIHByb2JsZW0sIHByZXNlbnRl ZCBieSBLZW50IGEgY291cGxlIHllYXJzIGFnbywNCmlzIGEgbXVjaCBzaW1wbGVyIGFuZCBiZXR0 ZXIgc29sdXRpb24gdGhhbiBhIG5ldyA8c3lzdGVtPiBkYXRhc3RvcmUuDQpUaGUgZnVsbCBzZXQg b2Ygbm9kZXMgaXMgaW4gPHJ1bm5pbmc+Lg0KQSBnZW5lcmFsaXplZCAiZW5hYmxlIiBtZWNoYW5p c20gY2F1c2VzIHRoZSByZXNvdXJjZSB0byBiZSB1c2VkIG9yIG5vdCwNCndoZXJlIGl0IHNob3dz IHVwIGluIDxpbnRlbmRlZD4gYW5kIDxvcGVyYXRpb25hbD4gaWYgZW5hYmxlZD10cnVlLg0KDQpJ TU8gdGhpcyBmaXRzIHRoZSBvcmlnaW5hbCBpbnRlbnQgb2YgTk1EQSBhbmQgZG9lcyBzbyBpbiBh IHdheSB0aGF0IHJlcXVpcmVzDQp0aGUgbGVhc3QgZGlzcnVwdGlvbiB0byBjdXJyZW50IGNvbXBs aWFudCBpbXBsZW1lbnRhdGlvbnMuDQoNCkFuZHkNCg0KDQpUaGUgc2VydmVyIGFjY2VwdHMgdGhl c2UgY29uZmlndXJhdGlvbnMgKGkuZS4gYSB2YWxpZGF0ZSBvciBjb21taXQgc3VjY2VlZHMpLCBi dXQgaWYgeW91IGFjdHVhbGx5IHZhbGlkYXRlIChlLmcuIHdpdGggeWFuZ0xpbnQpIHRoZSBydW5u aW5nIGRhdGFzdG9yZSBjb250ZW50cyAoZS5nLiBmZXRjaGVkIHVzaW5nIDxnZXQtY29uZmlnPikg dG8gdGhlIFlBTkcgbW9kZWwgaXQgaXMgbm90IHZhbGlkLiBUaGF0IGlzIGFnYWluc3Qgc2V2ZXJh bCBSRkNzIHJlZmVyZW5jZWQgaW4gdGhlIGRpc2N1c3Npb25zIGJlbG93Lg0KDQpJTU8gdGhlcmUg aXNuJ3QgYW55ICJvZmZsaW5lIiB2cyIgb25saW5lIiB2YWxpZGF0aW9uIHRoYXQgaXMgZGlmZmVy ZW50LiBUaGUgY29udGVudHMgb2YgdGhlIHJ1bm5pbmcgbXVzdCBiZSB2YWxpZCBhZ2FpbnN0IHRo ZSBZQU5HIG1vZGVsLiAgQSA8Z2V0LWNvbmZpZz4gcmV0dXJucyB0aGUgY29udGVudHMgb2YgdGhl IHJ1bm5pbmcuICBUaGUgc2VydmVyIGNhbiB2YWxpZGF0ZSBpdCwgb3Igc29tZSBvdGhlciBlbnRp dHkgY2FuIHZhbGlkYXRlIGl0LCBidXQgaXQgbXVzdCBiZSB2YWxpZC4NCg0KSW4gSmFuJ3Mgb3B0 aW9uICMxIHRoZSBydW5uaW5nIGNvbmZpZyBjb3VsZCBiZSBwb2xsdXRlZCB3aXRoIDEwMHMgb3Ig MTAwMHMgb2YgbGluZXMgb2YgdW5yZWZlcmVuY2VkL3VudXNlZCBjb25maWcuIEEgPGdldC1jb25m aWc+IG9mIGEgc3lzdGVtIHdpdGhvdXQgbXVjaCBjb25maWcgd291bGQgaW5zdGVhZCByZXR1cm4g MTAwcy8xMDAwcyBvZiBsaW5lcy4gSSB0aGluayB0aGF0IHdvdWxkIGJlIHZlcnkgYW5ub3lpbmcg ZnJvbSBhIHVzYWJpbGl0eSBwZXJzcGVjdGl2ZS4NCg0KSSdtIGluIGZhdm9yIG9mIHRoaXMgYXNw ZWN0IG9mIEphbidzIG9wdGlvbiAjMjogICIgKyBDbGllbnRzIHVuYXdhcmUgb2YgdGhlIHN5c3Rl bSBkYXRhc3RvcmUgd291bGQgaGF2ZSB0byBpbmNsdWRlIChjb3B5KSBpbmZvcm1hdGlvbiBmcm9t IHRoZSBzeXN0ZW0gZGF0YXN0b3JlIHRvIHJ1bm5pbmcgaW4gb3JkZXIgdG8gcmVmZXJlbmNlIHRo ZW0uIg0KDQotPiBPbmx5IHRoZSBsaXN0IGtleXMgb2YgcmVmZXJlbmNlZCBzeXN0ZW0gb2JqZWN0 cyB3b3VsZCBoYXZlIHRvIGJlIGNvcGllZCAoY29uZmlndXJlZCkgaW50byB0aGUgcnVubmluZyBE UyAodG8gcmVzb2x2ZSBsZWFmcmVmcykuICBXZSB3b3VsZG4ndCBuZWVkIHRvIGNvcHkgYWxsIHRo ZSBkZXNjZW5kYW50IGVsZW1lbnRzIGluc2lkZSB0aGUgcmVmZXJlbmNlZCBvYmplY3QuDQotPiBU aGlzIGNvcHlpbmcgd291bGQgb25seSBuZWVkIHRvIGJlIGRvbmUgYnkgb3BlcmF0b3JzIHdpdGgg YSB3b3JrZmxvdyB0aGF0IHJlcXVpcmVzIG9mZmxpbmUgdmFsaWRhdGlvbg0KDQpTb21lIG9mIHRo aXMgYXBwcm9hY2ggaXMgYWxyZWFkeSBkZXNjcmliZWQgaW4gZHJhZnQtbWEtbmV0bW9kLXdpdGgt c3lzdGVtLTAxOg0KDQoiICAgSW4gYWxsIGNhc2VzLCB0aGUgY2xpZW50cyBzaG91bGQgaGF2ZSBj b250cm9sIG92ZXIgdGhlIGNvbmZpZ3VyYXRpb25zDQogICAsaS5lLiwgcmVhZC1iYWNrIG9mIDxy dW5uaW5nPiBzaG91bGQgY29udGFpbiBvbmx5IHdoYXQgd2FzIGV4cGxpY2l0bHkNCiAgIHNldCBi eSBjbGllbnRzLiINCg0KDQoiNC4zLiAgRXhwbGljaXQgZGVjbGFyYXRpb24gb2Ygc3lzdGVtIGNv bmZpZ3VyYXRpb24NCg0KICAgSW4gYWRkaXRpb24gdG8gbW9kaWZ5aW5nIHN5c3RlbSBjb25maWd1 cmF0aW9uLCBhbmQgYWRkaW5nIG5vZGVzIHRvDQogICBsaXN0cyBpbiBzeXN0ZW0gY29uZmlndXJh dGlvbiBhcyBkZXNjcmliZWQgYWJvdmUsIGEgY2xpZW50IGNhbiBhbHNvDQogICBleHBsaWNpdGx5 IGRlY2xhcmUgc3lzdGVtIGNvbmZpZ3VyYXRpb24gbm9kZXMgaW4gPHJ1bm5pbmc+IHdpdGggdGhl DQogICBzYW1lIHZhbHVlcyBhcyBpbiA8c3lzdGVtPi4gIFdoZW4gYSBjbGllbnQgY29uZmlndXJl cyBhIG5vZGUgKGxpc3QNCiAgIGVudHJ5LCBsZWFmLCBldGMpIGluIDxydW5uaW5nPiB0aGF0IG1h dGNoZXMgdGhlIHNhbWUgbm9kZSAmIHZhbHVlIGluDQogICA8c3lzdGVtPiwgdGhlbiB0aGF0IG5v ZGUgYmVjb21lcyBwYXJ0IG9mIDxydW5uaW5nPi4gIEEgcmVhZCBvZg0KICAgPHJ1bm5pbmc+IHJl dHVybnMgdGhvc2UgZXhwbGljaXRseSBjb25maWd1cmVkIG5vZGVzLg0KDQogICBUaGlzIGV4cGxp Y2l0IGNvbmZpZ3VyYXRpb24gb2Ygc3lzdGVtIGNvbmZpZ3VyYXRpb24gaW4gPHJ1bm5pbmc+IGNh bg0KICAgYmUgdXNlZnVsLCBmb3IgZXhhbXBsZSwgd2hlbiBhbiBvcGVyYXRvcidzIHdvcmtmbG93 IHJlcXVpcmVzIGEgY2xpZW50DQogICBvciBvZmZsaW5lIHRvb2wgdG8gc2VlIHRoZSA8cnVubmlu Zz4gY29uZmlndXJhdGlvbiBhcyB2YWxpZC4gIFRoZQ0KICAgY2xpZW50IGNhbiBleHBsaWNpdGx5 IGRlY2xhcmUgKGkuZS4gIGNvbmZpZ3VyZSBpbiA8cnVubmluZz4pIHRoZSBsaXN0DQogICBlbnRy aWVzICh3aXRoIGF0IGxlYXN0IHRoZSBrZXlzKSBmb3IgYW55IHN5c3RlbSBjb25maWd1cmF0aW9u IGxpc3QNCiAgIGVudHJpZXMgdGhhdCBhcmUgcmVmZXJlbmNlZCBlbHNld2hlcmUgaW4gPHJ1bm5p bmc+LiAgVGhlIGNsaWVudCBkb2VzDQogICBub3QgbmVjZXNzYXJpbHkgbmVlZCB0byBkZWNsYXJl IGFsbCB0aGUgY29udGVudHMgb2YgdGhlIGxpc3QgZW50cnkNCiAgIChpLmUuIHRoZSBkZXNjZW5k YW50IG5vZGVzKSAtIG9ubHkgdGhlIHBhcnRzIHRoYXQgYXJlIHJlcXVpcmVkIHRvDQogICBtYWtl IHRoZSA8cnVubmluZz4gYXBwZWFyIHZhbGlkIG9mZmxpbmUuICAiDQoNCkknbSBub3QgYSBmYW4g b2Ygb3B0aW9uICMzLiBJdCBkb2Vzbid0IGFsbG93IGEgbW9kZSBvZiBvcGVyYXRpbmcgd2hlcmUg YSBjbGllbnQvT1NTIGhhcyBmdWxsIGNvbnRyb2wgb3ZlciB0aGUgY29udGVudHMgb2YgdGhlIDxy dW5uaW5nPi4gIFNvbWUgb3BlcmF0b3JzIHdpbGwgd2FudCB0aGUgbWFzdGVyIGNvbmZpZyB0byBi ZSBvd25lZCB1cCBpbiB0aGVpciBjbGllbnQvT1NTIGFuZCBwdXNoIGl0IGRvd24uIFRoZSBzZXJ2 ZXIgc2hvdWxkIGp1c3QgYWNjZXB0IGl0IGFuZCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRv IGRvIGEgInJlYWQtYmFjayIgYW5kIHNlZSBleGFjdGx5IHdoYXQgd2FzIHNlbnQgcHJldmlvdXNs eS4NCg0KSSB0aGluayB3ZSBoYXZlIGEgcG90ZW50aWFsIHNvbHV0aW9uIGZvciB0aGlzIHN5c3Rl bSBjb25maWcgdGhhdCBrZWVwcyB0aGUgcnVubmluZyB2YWxpZC4gQnV0IEknbSBmYXIgbW9yZSB3 b3JyaWVkIGFib3V0IGNvbmZpZ3VyYXRpb24gdGVtcGxhdGVzLiBJIGRvbid0IHNlZSBob3cgd2Ug Y2FuIHBvc3NpYmx5IGtlZXAgPHJ1bm5pbmc+IHZhbGlkIHdpdGggY29uZmlnIHRlbXBsYXRlcy4g VGhhdCBzZWVtcyBsaWtlIGEgbWFqb3IgcHJvYmxlbSB0byBtZS4gQnV0IGlmIHdlIGV2ZXIgZGVj bGFyZSB0aGF0IDxydW5uaW5nPiBkb2Vzbid0IGhhdmUgdG8gYmUgdmFsaWQsIGFuZCBvbmx5IDxp bnRlbmRlZD4gaGFzIHRvIGJlIHZhbGlkLCB0aGVuIG9mZmxpbmUgdG9vbHMgY2FuIG5ldmVyIHZh bGlkYXRlIChhaGVhZCBvZiB0aW1lKSB0aGUgY29uZmlnIHRoZXkgYWN0dWFsbHkgZG93bmxvYWQg dG8gdGhlIHNlcnZlci4NCg0KSmFzb24NCg0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBB bmR5IEJpZXJtYW4NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMywgMjAyMSA2OjAxIEFNDQpUbzog SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+OyBKYW4gTGlu ZGJsYWQgPGphbmxAdGFpbC1mLmNvbTxtYWlsdG86amFubEB0YWlsLWYuY29tPj47IEtlbnQgV2F0 c2VuIDxrZW50QHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnRAd2F0c2VuLm5ldD4+OyBtYXFpdWZhbmcg KEEpIDxtYXFpdWZhbmcxPTQwaHVhd2VpLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBodWF3 ZWkuY29tQGRtYXJjLmlldGYub3JnPj47IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIE11c3Qgb2ZmbGluZS12YWxpZGF0aW9uIG9m IDxydW5uaW5nPiBhbG9uZSBiZSB2YWxpZD8NCg0KDQoNCk9uIEZyaSwgRGVjIDMsIDIwMjEgYXQg MjoyNiBBTSBKw7xyZ2VuIFNjaMO2bnfDpGxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4g d3JvdGU6DQpPbiBGcmksIERlYyAwMywgMjAyMSBhdCAxMDo1OToxMkFNICswMTAwLCBKYW4gTGlu ZGJsYWQgd3JvdGU6DQoNCj4gSSBtYWRlIHNvbWUgcHJvcG9zYWxzIGVhcmxpZXIsIGJvdGggb24g dGhlIGludGVyaW0gYW5kIHByaXZhdGVseSB0byB0aGUgZHJhZnQgYXV0aG9ycywgYWxvbmcgdGhl c2UgbGluZXM6DQo+DQo+IE9wdGlvbiAjMQ0KPiArIFdlIGNvdWxkIGhhdmUgYSBuZXcgc3lzdGVt IGRhdGFzdG9yZSB0aGF0IHRlY2huaWNhbGx5IGlzIGEgcGFydCBvZiBydW5uaW5nLiBFdmVyeXRo aW5nIGluIHN5c3RlbSB3b3VsZCBzaG93IHVwIGluIHJ1bm5pbmcgdG8gIGNsaWVudHMgdW5hd2Fy ZSBvZiB0aGUgc3lzdGVtIGRhdGFzdG9yZS4gRXZlcnkgdGltZSB0aGUgc3lzdGVtIGRhdGFzdG9y ZSBjaGFuZ2VzIGZvciB3aGF0ZXZlciByZWFzb24sIHRoZSBydW5uaW5nIGRhdGFzdG9yZSB0cmFu c2FjdGlvbiBpZHMgKGlmIHdlIG1hbmFnZSB0byBnZXQgdGhhdCBjb25jZXB0IGRlZmluZWQpLCBh cmUgdXBkYXRlZA0KPiArIENsaWVudHMgaW50ZXJlc3RlZCB0byBzZWUgcHVyZSB2aWV3IG9mIHRo ZSBzeXN0ZW0gZGF0YXN0b3JlIHdpdGhvdXQgYW55dGhpbmcgZWxzZSBpbiBydW5uaW5nIGNvdWxk IGlzc3VlIGEgZ2V0LWRhdGEgdG93YXJkcyB0aGUgc3lzdGVtIGRhdGFzdG9yZQ0KPiArIENsaWVu dHMgaW50ZXJlc3RlZCB0byBzZWUgYSBwdXJlIHZpZXcgb2YgcnVubmluZyB3aXRob3V0IGFueSBz eXN0ZW0gZGF0YXN0b3JlIGVsZW1lbnRzIGNvdWxkIGlzc3VlIGEgZ2V0LWRhdGEgdG93YXJkcyBy dW5uaW5nIHdpdGggYW4gZXh0cmEgZmxhZyBjYWxsZWQgJ3dpdGhvdXQtc3lzdGVtJw0KPiArIFNp bmNlIGFsbCBzeXN0ZW0gZWxlbWVudHMgYXJlIGFscmVhZHkgcGFydCBvZiBydW5uaW5nLCBjbGll bnRzIGhhdmUgbm8gbmVlZCB0byBjb3B5IGRhdGEgYmV0d2VlbiB0aGUgdHdvIGRhdGFzdG9yZXMN Cj4NCj4gT3B0aW9uICMyDQo+ICsgV2UgY291bGQgaGF2ZSBhIHN5c3RlbSBkYXRhc3RvcmUgdGhh dCB0ZWNobmljYWxseSBpcyBhIHBhcnQgb2Ygb3BlcmF0aW9uYWwuIEV2ZXJ5dGhpbmcgaW4gc3lz dGVtIHdvdWxkIHNob3cgdXAgaW4gb3BlcmF0aW9uYWwgdG8gIGNsaWVudHMgdW5hd2FyZSBvZiB0 aGUgc3lzdGVtIGRhdGFzdG9yZS4gVGhlIHJ1bm5pbmcgZGF0YXN0b3JlIGFsd2F5cyBtYWludGFp bnMgcmVmZXJlbnRpYWwgaW50ZWdyaXR5LCBpLmUuIGNhbm5vdCByZWZlcmVuY2UgdGhlIHN5c3Rl bSBkYXRhc3RvcmUuDQo+ICsgQ2xpZW50cyBpbnRlcmVzdGVkIHRvIHNlZSBwdXJlIHZpZXcgb2Yg dGhlIHN5c3RlbSBkYXRhc3RvcmUgY291bGQgaXNzdWUgYSBnZXQtZGF0YSB0b3dhcmRzIHRoZSBz eXN0ZW0gZGF0YXN0b3JlDQo+ICsgU2luY2UgdGhlIHN5c3RlbSBkYXRhc3RvcmUgaXMgbm90IHBh cnQgb2YgcnVubmluZywgY2xpZW50cyBjYW4gYWxyZWFkeSBzZWUgYSBwdXJlIHZpZXcgb2YgcnVu bmluZyB3aXRob3V0IGFueSBzeXN0ZW0gZGF0YXN0b3JlIGVsZW1lbnRzIHVzaW5nIGEgc2ltcGxl IGdldC1kYXRhLg0KPiArIENsaWVudHMgdGhhdCBhcmUgYXdhcmUgb2YgdGhlIHN5c3RlbSBkYXRh c3RvcmUgYW5kIGFyZSBpbnRlcmVzdGVkIHRvIGNvbmZpZ3VyZSByZWZlcmVuY2VzIGZyb20gcnVu bmluZyB0byBzeXN0ZW0gZWxlbWVudHMgd291bGQgaXNzdWUgYW4gZWRpdC1kYXRhIHJwYyB3aXRo IHRoZSBhZGRpdGlvbmFsIGZsYWcgJ3Jlc29sdmUtc3lzdGVtLXJlZmVyZW5jZXMnLiBUaGlzIHdp bGwgbWFrZSB0aGUgc2VydmVyIGNvcHkgYW55IHN5c3RlbSBlbGVtZW50cyByZWZlcmVuY2VkIGlu dG8gcnVubmluZyB3aXRob3V0IHRoZSBjbGllbnQgZG9pbmcgc28gZXhwbGljaXRseS4NCj4gKyBD bGllbnRzIHVuYXdhcmUgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUgd291bGQgaGF2ZSB0byBpbmNs dWRlIChjb3B5KSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIHRvIHJ1bm5p bmcgaW4gb3JkZXIgdG8gcmVmZXJlbmNlIHRoZW0uDQo+DQoNCk9wdGlvbiAjMw0KDQpUaGVyZSBp cyBhIGNsaWVudCBvbiB0aGUgc3lzdGVtIHRoYXQgbWFrZXMgY2hhbmdlcyB0byBydW5uaW5nIGp1 c3QNCmxpa2UgYW55IG90aGVyIHJlbW90ZSBjbGllbnRzIGNhbiBtYWtlIGNoYW5nZXMgdG8gcnVu bmluZy4gU3lzdGVtDQpnZW5lcmF0ZSBjb25maWcgdGhhdCBpcyBub3QgZWRpdGFibGUgZXhwbGlj aXQgY29uZmlnIGluIHJ1bm5pbmcgZ29lcw0Kc3RyYWlnaHQgaW50byB0aGUgYXBwbGllZCBjb25m aWcgaW4gb3BlcmF0aW9uYWwuIFRoaXMgZG9lcyBub3QgcmVxdWlyZQ0KYSBzeXN0ZW0gZGF0YXN0 b3JlIChpbiBmYWN0IHNvbWV0aGluZyBsaWtlIGEgc3lzdGVtIGRhdGFzdG9yZSBtYXkNCmV4aXN0 IGFzIHRoZSBfbG9naWNfIG9mIHRoZSBzeXN0ZW0gY2xpZW50LCB0aGUgZ29vZCBvbGQgZXhhbXBs ZSB3ZSBoYWQNCmlzIGFsbG9jdGluZyBhbiB1bnVzZWQgdWlkIGZvciBhbiBhY2NvdW50IHRoYXQs IG9uY2UgYWxsb2NhdGVkLCBpcw0KbWFpbnRhaW5lZCBpbiBydW5uaW5nKS4NCg0KDQorMSB0byBv cHRpb24gMy4NCkNvbnNpZGVyIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgbW92ZXMgYWxsIHRoZSAi aGlkZGVuIHN5c3RlbSBsb2dpYyIgb2ZmLWJveA0KdG8gYSBjb250cm9sbGVyLCBzdWNoIHRoYXQg dGhlIGluaXRpYWwgY29uZmlnIGlzIGxpdGVyYWxseSBzdXBwbGllZCBieSBhbiBleHRlcm5hbCBj bGllbnQuDQoNCkkgaGF2ZSB5ZXQgdG8gaGVhciBhIHNpbmdsZSB1c2UtY2FzZSBmb3IgY3JlYXRp bmcgYSA8c3lzdGVtPiBkYXRhc3RvcmUuDQoiVGhlIGNsaWVudCBtaWdodCB3YW50IiBpcyBub3Qg YSB1c2UtY2FzZSBmb3Igc3RhbmRhcmRpemF0aW9uLg0KSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUg InB1cmUgdmlldyIuIFNlZW1zIGxpa2UgaWYgdGhpcyB3YXMgYSByZWFsIHByb2JsZW0gdG8gc29s dmUsDQp0aGVuIE5NREEgd291bGQgaGF2ZSBpbmNsdWRlZCBhIHN5c3RlbSBkYXRhc3RvcmUgZnJv bSB0aGUgc3RhcnQuDQoNCg0KL2pzDQoNCg0KQW5keQ0KDQoNCi0tDQpKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0 OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2Vy bWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2Jz LXVuaXZlcnNpdHkuZGUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpu ZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0K --_000_DM6PR08MB50843C4B006A72F355598AF19B709DM6PR08MB5084namp_ 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 OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEFuZHksPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkknbSBub3Qgc3Vy ZSBJIHVuZGVyc3RhbmQgS2VudCdzIGFsdGVybmF0aXZlIHRoYXQgeW91J3JlIHJlZmVyZW5jaW5n IGhlcmUuIEFyZSB5b3UgdGFsa2luZyBhYm91dCBzb21ldGhpbmcgbGlrZSBKVU5PUyBhY3RpdmUv aW5hY3RpdmUgY29uZmlndXJhdGlvbiBhbm5vdGF0aW9uID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SXMgdGhlICZxdW90O2Vu YWJsZSZxdW90OyBzb21lIGNvbmZpZ3VyYWJsZSBtZXRhZGF0YSBhZ2FpbnN0IGRhdGEgbm9kZXMg PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5XaGVuIHlvdSBzYXkgdGhlICZxdW90O2Z1bGwgc2V0IG9mIG5vZGVzIGluIHJ1bm5p bmcmcXVvdDsgYXJlIHlvdSB0YWxraW5nIGFib3V0IEphbidzIG9wdGlvbiAjMSBiZWxvdyAoYnV0 IHBlcmhhcHMgd2l0aG91dCB0aGUgZXhwbGljaXQgJmx0O3N5c3RlbSZndDsgZGF0YXN0b3JlKSA/ Jm5ic3A7IGkuZS4gYWxsIHRoZSBzeXN0ZW0gY29uZmlnIGlzIGFjdHVhbGx5IHJldHVybmluZw0K IGZyb20gYSAmbHQ7Z2V0LWNvbmZpZyZndDsgb2YgcnVubmluZyA/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkphc29uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiPiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZn dDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIERlY2VtYmVyIDgsIDIwMjEgNTo1MCBQ TTxicj4NCjxiPlRvOjwvYj4gU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2EpICZsdDtq YXNvbi5zdGVybmVAbm9raWEuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSnVlcmdlbiBTY2hvZW53 YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7OyBKYW4g TGluZGJsYWQgJmx0O2phbmxAdGFpbC1mLmNvbSZndDs7IEtlbnQgV2F0c2VuICZsdDtrZW50QHdh dHNlbi5uZXQmZ3Q7OyBtYXFpdWZhbmcgKEEpICZsdDttYXFpdWZhbmcxPTQwaHVhd2VpLmNvbUBk bWFyYy5pZXRmLm9yZyZndDs7IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW25ldG1vZF0gTXVzdCBvZmZsaW5lLXZhbGlkYXRpb24gb2YgJmx0O3J1bm5pbmcmZ3Q7IGFs b25lIGJlIHZhbGlkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyA4LCAyMDIxIGF0IDI6MzEgUE0gU3Rlcm5lLCBKYXNv biAoTm9raWEgLSBDQS9PdHRhd2EpICZsdDs8YSBocmVmPSJtYWlsdG86amFzb24uc3Rlcm5lQG5v a2lhLmNvbSI+amFzb24uc3Rlcm5lQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkhpIGd1eXMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmR5IC0gYWJvdXQg dXNlIGNhc2VzLiZuYnNwOyBIZXJlIGlzIGEgcHJvYmxlbSB3ZSdyZSB0cnlpbmcgdG8gYWRkcmVz czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NClRoZXJl IGFyZSBhdCBsZWFzdCBzZXZlcmFsIG1ham9yIHJvdXRlciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBo YXZlIHRoaXMgY29uY2VwdCBvZiAmcXVvdDtoaWRkZW4gY29uZmlnJnF1b3Q7IChpLmUuIGxpc3Qg ZW50cmllcyB0aGF0IGNhbiBiZSByZWZlcmVuY2VkIGluIGEgbGVhZnJlZiBieSBleHBsaWNpdCB1 c2VyIGNvbmZpZywgYnV0IHRob3NlIGxpc3QgZW50cmllcyBhcmUgbm90IHJldHVybmVkIGluIGEg Jmx0O2dldC1jb25maWcmZ3Q7KS4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNsZWFybHkgbm90IGluIGNvbXBsaWFuY2Ugd2l0aCBSRkMgNzk1MC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1PIHRoZSAm cXVvdDtlbmFibGUgZmxhZyZxdW90OyBhcHByb2FjaCB0byB0aGUgZ2VuZXJhbCBwcm9ibGVtLCBw cmVzZW50ZWQgYnkgS2VudCBhIGNvdXBsZSB5ZWFycyBhZ28sPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcyBhIG11Y2ggc2ltcGxlciBhbmQgYmV0 dGVyIHNvbHV0aW9uIHRoYW4gYSBuZXcgJmx0O3N5c3RlbSZndDsgZGF0YXN0b3JlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZ1bGwgc2V0 IG9mIG5vZGVzIGlzIGluICZsdDtydW5uaW5nJmd0Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgZ2VuZXJhbGl6ZWQgJnF1b3Q7ZW5hYmxlJnF1 b3Q7IG1lY2hhbmlzbSBjYXVzZXMgdGhlIHJlc291cmNlIHRvIGJlIHVzZWQgb3Igbm90LDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hlcmUgaXQg c2hvd3MgdXAgaW4gJmx0O2ludGVuZGVkJmd0OyBhbmQgJmx0O29wZXJhdGlvbmFsJmd0OyBpZiBl bmFibGVkPXRydWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklNTyB0aGlzIGZpdHMgdGhlIG9yaWdpbmFsIGludGVudCBvZiBOTURBIGFuZCBk b2VzIHNvIGluIGEgd2F5IHRoYXQgcmVxdWlyZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBsZWFzdCBkaXNydXB0aW9uIHRvIGN1cnJlbnQg Y29tcGxpYW50IGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM2LjBwdCI+DQpUaGUgc2VydmVyIGFjY2VwdHMgdGhlc2UgY29uZmlndXJhdGlvbnMgKGku ZS4gYSB2YWxpZGF0ZSBvciBjb21taXQgc3VjY2VlZHMpLCBidXQgaWYgeW91IGFjdHVhbGx5IHZh bGlkYXRlIChlLmcuIHdpdGggeWFuZ0xpbnQpIHRoZSBydW5uaW5nIGRhdGFzdG9yZSBjb250ZW50 cyAoZS5nLiBmZXRjaGVkIHVzaW5nICZsdDtnZXQtY29uZmlnJmd0OykgdG8gdGhlIFlBTkcgbW9k ZWwgaXQgaXMgbm90IHZhbGlkLiBUaGF0IGlzIGFnYWluc3Qgc2V2ZXJhbCBSRkNzDQogcmVmZXJl bmNlZCBpbiB0aGUgZGlzY3Vzc2lvbnMgYmVsb3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JTU8gdGhlcmUgaXNuJ3QgYW55ICZxdW90O29mZmxpbmUmcXVvdDsgdnMmcXVvdDsgb25saW5l JnF1b3Q7IHZhbGlkYXRpb24gdGhhdCBpcyBkaWZmZXJlbnQuIFRoZSBjb250ZW50cyBvZiB0aGUg cnVubmluZyBtdXN0IGJlIHZhbGlkIGFnYWluc3QgdGhlIFlBTkcgbW9kZWwuJm5ic3A7IEEgJmx0 O2dldC1jb25maWcmZ3Q7IHJldHVybnMgdGhlIGNvbnRlbnRzIG9mDQogdGhlIHJ1bm5pbmcuJm5i c3A7IFRoZSBzZXJ2ZXIgY2FuIHZhbGlkYXRlIGl0LCBvciBzb21lIG90aGVyIGVudGl0eSBjYW4g dmFsaWRhdGUgaXQsIGJ1dCBpdCBtdXN0IGJlIHZhbGlkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SW4gSmFuJ3Mgb3B0aW9uICMxIHRoZSBydW5uaW5nIGNvbmZpZyBjb3VsZCBiZSBwb2xs dXRlZCB3aXRoIDEwMHMgb3IgMTAwMHMgb2YgbGluZXMgb2YgdW5yZWZlcmVuY2VkL3VudXNlZCBj b25maWcuIEEgJmx0O2dldC1jb25maWcmZ3Q7IG9mIGEgc3lzdGVtIHdpdGhvdXQgbXVjaCBjb25m aWcgd291bGQgaW5zdGVhZCByZXR1cm4NCiAxMDBzLzEwMDBzIG9mIGxpbmVzLiBJIHRoaW5rIHRo YXQgd291bGQgYmUgdmVyeSBhbm5veWluZyBmcm9tIGEgdXNhYmlsaXR5IHBlcnNwZWN0aXZlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIGluIGZhdm9yIG9mIHRoaXMgYXNwZWN0IG9m IEphbidzIG9wdGlvbiAjMjombmJzcDsgJnF1b3Q7ICsgQ2xpZW50cyB1bmF3YXJlIG9mIHRoZSBz eXN0ZW0gZGF0YXN0b3JlIHdvdWxkIGhhdmUgdG8gaW5jbHVkZSAoY29weSkgaW5mb3JtYXRpb24g ZnJvbSB0aGUgc3lzdGVtIGRhdGFzdG9yZSB0byBydW5uaW5nIGluIG9yZGVyDQogdG8gcmVmZXJl bmNlIHRoZW0uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tJmd0OyBPbmx5IHRo ZSBsaXN0IGtleXMgb2YgcmVmZXJlbmNlZCBzeXN0ZW0gb2JqZWN0cyB3b3VsZCBoYXZlIHRvIGJl IGNvcGllZCAoY29uZmlndXJlZCkgaW50byB0aGUgcnVubmluZyBEUyAodG8gcmVzb2x2ZSBsZWFm cmVmcykuJm5ic3A7IFdlIHdvdWxkbid0IG5lZWQgdG8gY29weSBhbGwgdGhlIGRlc2NlbmRhbnQg ZWxlbWVudHMNCiBpbnNpZGUgdGhlIHJlZmVyZW5jZWQgb2JqZWN0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4tJmd0OyBUaGlzIGNvcHlpbmcgd291bGQgb25seSBuZWVk IHRvIGJlIGRvbmUgYnkgb3BlcmF0b3JzIHdpdGggYSB3b3JrZmxvdyB0aGF0IHJlcXVpcmVzIG9m ZmxpbmUgdmFsaWRhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U29tZSBvZiB0aGlz IGFwcHJvYWNoIGlzIGFscmVhZHkgZGVzY3JpYmVkIGluIGRyYWZ0LW1hLW5ldG1vZC13aXRoLXN5 c3RlbS0wMTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90OyZuYnNwOyZuYnNwOyBJ biBhbGwgY2FzZXMsIHRoZSBjbGllbnRzIHNob3VsZCBoYXZlIGNvbnRyb2wgb3ZlciB0aGUgY29u ZmlndXJhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 Jm5ic3A7ICxpLmUuLCByZWFkLWJhY2sgb2YgJmx0O3J1bm5pbmcmZ3Q7IHNob3VsZCBjb250YWlu IG9ubHkgd2hhdCB3YXMgZXhwbGljaXRseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsmbmJzcDsgc2V0IGJ5IGNsaWVudHMuJnF1b3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+JnF1b3Q7NC4zLiZuYnNwOyBFeHBsaWNpdCBkZWNsYXJhdGlvbiBvZiBzeXN0ZW0gY29uZmln dXJhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IEluIGFkZGl0 aW9uIHRvIG1vZGlmeWluZyBzeXN0ZW0gY29uZmlndXJhdGlvbiwgYW5kIGFkZGluZyBub2RlcyB0 bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgbGlz dHMgaW4gc3lzdGVtIGNvbmZpZ3VyYXRpb24gYXMgZGVzY3JpYmVkIGFib3ZlLCBhIGNsaWVudCBj YW4gYWxzbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJz cDsgZXhwbGljaXRseSBkZWNsYXJlIHN5c3RlbSBjb25maWd1cmF0aW9uIG5vZGVzIGluICZsdDty dW5uaW5nJmd0OyB3aXRoIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsmbmJzcDsgc2FtZSB2YWx1ZXMgYXMgaW4gJmx0O3N5c3RlbSZndDsuJm5ic3A7IFdo ZW4gYSBjbGllbnQgY29uZmlndXJlcyBhIG5vZGUgKGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IGVudHJ5LCBsZWFmLCBldGMpIGluICZsdDty dW5uaW5nJmd0OyB0aGF0IG1hdGNoZXMgdGhlIHNhbWUgbm9kZSAmYW1wOyB2YWx1ZSBpbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgJmx0O3N5c3Rl bSZndDssIHRoZW4gdGhhdCBub2RlIGJlY29tZXMgcGFydCBvZiAmbHQ7cnVubmluZyZndDsuJm5i c3A7IEEgcmVhZCBvZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsmbmJzcDsgJmx0O3J1bm5pbmcmZ3Q7IHJldHVybnMgdGhvc2UgZXhwbGljaXRseSBjb25maWd1 cmVkIG5vZGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IFRoaXMg ZXhwbGljaXQgY29uZmlndXJhdGlvbiBvZiBzeXN0ZW0gY29uZmlndXJhdGlvbiBpbiAmbHQ7cnVu bmluZyZndDsgY2FuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyZuYnNwOyBiZSB1c2VmdWwsIGZvciBleGFtcGxlLCB3aGVuIGFuIG9wZXJhdG9yJ3Mgd29ya2Zs b3cgcmVxdWlyZXMgYSBjbGllbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7Jm5ic3A7IG9yIG9mZmxpbmUgdG9vbCB0byBzZWUgdGhlICZsdDtydW5uaW5nJmd0 OyBjb25maWd1cmF0aW9uIGFzIHZhbGlkLiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IGNsaWVudCBjYW4gZXhwbGljaXRseSBkZWNs YXJlIChpLmUuJm5ic3A7IGNvbmZpZ3VyZSBpbiAmbHQ7cnVubmluZyZndDspIHRoZSBsaXN0PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBlbnRyaWVz ICh3aXRoIGF0IGxlYXN0IHRoZSBrZXlzKSBmb3IgYW55IHN5c3RlbSBjb25maWd1cmF0aW9uIGxp c3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IGVu dHJpZXMgdGhhdCBhcmUgcmVmZXJlbmNlZCBlbHNld2hlcmUgaW4gJmx0O3J1bm5pbmcmZ3Q7LiZu YnNwOyBUaGUgY2xpZW50IGRvZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7Jm5ic3A7IG5vdCBuZWNlc3NhcmlseSBuZWVkIHRvIGRlY2xhcmUgYWxsIHRoZSBj b250ZW50cyBvZiB0aGUgbGlzdCBlbnRyeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsmbmJzcDsgKGkuZS4gdGhlIGRlc2NlbmRhbnQgbm9kZXMpIC0gb25seSB0 aGUgcGFydHMgdGhhdCBhcmUgcmVxdWlyZWQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IG1ha2UgdGhlICZsdDtydW5uaW5nJmd0OyBhcHBlYXIg dmFsaWQgb2ZmbGluZS4mbmJzcDsgJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J J20gbm90IGEgZmFuIG9mIG9wdGlvbiAjMy4gSXQgZG9lc24ndCBhbGxvdyBhIG1vZGUgb2Ygb3Bl cmF0aW5nIHdoZXJlIGEgY2xpZW50L09TUyBoYXMgZnVsbCBjb250cm9sIG92ZXIgdGhlIGNvbnRl bnRzIG9mIHRoZSAmbHQ7cnVubmluZyZndDsuJm5ic3A7IFNvbWUgb3BlcmF0b3JzIHdpbGwgd2Fu dCB0aGUgbWFzdGVyIGNvbmZpZw0KIHRvIGJlIG93bmVkIHVwIGluIHRoZWlyIGNsaWVudC9PU1Mg YW5kIHB1c2ggaXQgZG93bi4gVGhlIHNlcnZlciBzaG91bGQganVzdCBhY2NlcHQgaXQgYW5kIHRo ZSBjbGllbnQgc2hvdWxkIGJlIGFibGUgdG8gZG8gYSAmcXVvdDtyZWFkLWJhY2smcXVvdDsgYW5k IHNlZSBleGFjdGx5IHdoYXQgd2FzIHNlbnQgcHJldmlvdXNseS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkkgdGhpbmsgd2UgaGF2ZSBhIHBvdGVudGlhbCBzb2x1dGlvbiBmb3IgdGhpcyBz eXN0ZW0gY29uZmlnIHRoYXQga2VlcHMgdGhlIHJ1bm5pbmcgdmFsaWQuIEJ1dCBJJ20gZmFyIG1v cmUgd29ycmllZCBhYm91dCBjb25maWd1cmF0aW9uIHRlbXBsYXRlcy4gSSBkb24ndCBzZWUgaG93 IHdlIGNhbiBwb3NzaWJseQ0KIGtlZXAgJmx0O3J1bm5pbmcmZ3Q7IHZhbGlkIHdpdGggY29uZmln IHRlbXBsYXRlcy4gVGhhdCBzZWVtcyBsaWtlIGEgbWFqb3IgcHJvYmxlbSB0byBtZS4gQnV0IGlm IHdlIGV2ZXIgZGVjbGFyZSB0aGF0ICZsdDtydW5uaW5nJmd0OyBkb2Vzbid0IGhhdmUgdG8gYmUg dmFsaWQsIGFuZCBvbmx5ICZsdDtpbnRlbmRlZCZndDsgaGFzIHRvIGJlIHZhbGlkLCB0aGVuIG9m ZmxpbmUgdG9vbHMgY2FuIG5ldmVyIHZhbGlkYXRlIChhaGVhZCBvZiB0aW1lKSB0aGUgY29uZmln IHRoZXkgYWN0dWFsbHkNCiBkb3dubG9hZCB0byB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SmFzb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBuZXRtb2QgJmx0OzxhIGhyZWY9 Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZC1i b3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVybWFu PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRGVjZW1iZXIgMywgMjAyMSA2OjAxIEFNPGJyPg0K PGI+VG86PC9iPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNj aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiIHRhcmdldD0iX2JsYW5rIj5qLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+Jmd0OzsgSmFuIExpbmRibGFkICZsdDs8 YSBocmVmPSJtYWlsdG86amFubEB0YWlsLWYuY29tIiB0YXJnZXQ9Il9ibGFuayI+amFubEB0YWls LWYuY29tPC9hPiZndDs7IEtlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a2VudEB3YXRz ZW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+a2VudEB3YXRzZW4ubmV0PC9hPiZndDs7DQogbWFxaXVm YW5nIChBKSAmbHQ7bWFxaXVmYW5nMT08YSBocmVmPSJtYWlsdG86NDBodWF3ZWkuY29tQGRtYXJj LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnPC9h PiZndDs7DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gTXVz dCBvZmZsaW5lLXZhbGlkYXRpb24gb2YgJmx0O3J1bm5pbmcmZ3Q7IGFsb25lIGJlIHZhbGlkPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIEZyaSwgRGVjIDMsIDIwMjEgYXQgMjoyNiBBTSBKw7xyZ2VuIFNjaMO2bnfDpGxk ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGUiIHRhcmdldD0iX2JsYW5rIj5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIEZyaSwg RGVjIDAzLCAyMDIxIGF0IDEwOjU5OjEyQU0gKzAxMDAsIEphbiBMaW5kYmxhZCB3cm90ZTo8YnI+ DQo8YnI+DQomZ3Q7IEkgbWFkZSBzb21lIHByb3Bvc2FscyBlYXJsaWVyLCBib3RoIG9uIHRoZSBp bnRlcmltIGFuZCBwcml2YXRlbHkgdG8gdGhlIGRyYWZ0IGF1dGhvcnMsIGFsb25nIHRoZXNlIGxp bmVzOjxicj4NCiZndDsgPGJyPg0KJmd0OyBPcHRpb24gIzE8YnI+DQomZ3Q7ICsgV2UgY291bGQg aGF2ZSBhIG5ldyBzeXN0ZW0gZGF0YXN0b3JlIHRoYXQgdGVjaG5pY2FsbHkgaXMgYSBwYXJ0IG9m IHJ1bm5pbmcuIEV2ZXJ5dGhpbmcgaW4gc3lzdGVtIHdvdWxkIHNob3cgdXAgaW4gcnVubmluZyB0 byZuYnNwOyBjbGllbnRzIHVuYXdhcmUgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUuIEV2ZXJ5IHRp bWUgdGhlIHN5c3RlbSBkYXRhc3RvcmUgY2hhbmdlcyBmb3Igd2hhdGV2ZXIgcmVhc29uLCB0aGUg cnVubmluZyBkYXRhc3RvcmUgdHJhbnNhY3Rpb24NCiBpZHMgKGlmIHdlIG1hbmFnZSB0byBnZXQg dGhhdCBjb25jZXB0IGRlZmluZWQpLCBhcmUgdXBkYXRlZDxicj4NCiZndDsgKyBDbGllbnRzIGlu dGVyZXN0ZWQgdG8gc2VlIHB1cmUgdmlldyBvZiB0aGUgc3lzdGVtIGRhdGFzdG9yZSB3aXRob3V0 IGFueXRoaW5nIGVsc2UgaW4gcnVubmluZyBjb3VsZCBpc3N1ZSBhIGdldC1kYXRhIHRvd2FyZHMg dGhlIHN5c3RlbSBkYXRhc3RvcmU8YnI+DQomZ3Q7ICsgQ2xpZW50cyBpbnRlcmVzdGVkIHRvIHNl ZSBhIHB1cmUgdmlldyBvZiBydW5uaW5nIHdpdGhvdXQgYW55IHN5c3RlbSBkYXRhc3RvcmUgZWxl bWVudHMgY291bGQgaXNzdWUgYSBnZXQtZGF0YSB0b3dhcmRzIHJ1bm5pbmcgd2l0aCBhbiBleHRy YSBmbGFnIGNhbGxlZCAnd2l0aG91dC1zeXN0ZW0nPGJyPg0KJmd0OyArIFNpbmNlIGFsbCBzeXN0 ZW0gZWxlbWVudHMgYXJlIGFscmVhZHkgcGFydCBvZiBydW5uaW5nLCBjbGllbnRzIGhhdmUgbm8g bmVlZCB0byBjb3B5IGRhdGEgYmV0d2VlbiB0aGUgdHdvIGRhdGFzdG9yZXM8YnI+DQomZ3Q7IDxi cj4NCiZndDsgT3B0aW9uICMyPGJyPg0KJmd0OyArIFdlIGNvdWxkIGhhdmUgYSBzeXN0ZW0gZGF0 YXN0b3JlIHRoYXQgdGVjaG5pY2FsbHkgaXMgYSBwYXJ0IG9mIG9wZXJhdGlvbmFsLiBFdmVyeXRo aW5nIGluIHN5c3RlbSB3b3VsZCBzaG93IHVwIGluIG9wZXJhdGlvbmFsIHRvJm5ic3A7IGNsaWVu dHMgdW5hd2FyZSBvZiB0aGUgc3lzdGVtIGRhdGFzdG9yZS4gVGhlIHJ1bm5pbmcgZGF0YXN0b3Jl IGFsd2F5cyBtYWludGFpbnMgcmVmZXJlbnRpYWwgaW50ZWdyaXR5LCBpLmUuIGNhbm5vdCByZWZl cmVuY2UNCiB0aGUgc3lzdGVtIGRhdGFzdG9yZS48YnI+DQomZ3Q7ICsgQ2xpZW50cyBpbnRlcmVz dGVkIHRvIHNlZSBwdXJlIHZpZXcgb2YgdGhlIHN5c3RlbSBkYXRhc3RvcmUgY291bGQgaXNzdWUg YSBnZXQtZGF0YSB0b3dhcmRzIHRoZSBzeXN0ZW0gZGF0YXN0b3JlPGJyPg0KJmd0OyArIFNpbmNl IHRoZSBzeXN0ZW0gZGF0YXN0b3JlIGlzIG5vdCBwYXJ0IG9mIHJ1bm5pbmcsIGNsaWVudHMgY2Fu IGFscmVhZHkgc2VlIGEgcHVyZSB2aWV3IG9mIHJ1bm5pbmcgd2l0aG91dCBhbnkgc3lzdGVtIGRh dGFzdG9yZSBlbGVtZW50cyB1c2luZyBhIHNpbXBsZSBnZXQtZGF0YS4NCjxicj4NCiZndDsgKyBD bGllbnRzIHRoYXQgYXJlIGF3YXJlIG9mIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIGFuZCBhcmUgaW50 ZXJlc3RlZCB0byBjb25maWd1cmUgcmVmZXJlbmNlcyBmcm9tIHJ1bm5pbmcgdG8gc3lzdGVtIGVs ZW1lbnRzIHdvdWxkIGlzc3VlIGFuIGVkaXQtZGF0YSBycGMgd2l0aCB0aGUgYWRkaXRpb25hbCBm bGFnICdyZXNvbHZlLXN5c3RlbS1yZWZlcmVuY2VzJy4gVGhpcyB3aWxsIG1ha2UgdGhlIHNlcnZl ciBjb3B5IGFueSBzeXN0ZW0gZWxlbWVudHMNCiByZWZlcmVuY2VkIGludG8gcnVubmluZyB3aXRo b3V0IHRoZSBjbGllbnQgZG9pbmcgc28gZXhwbGljaXRseS48YnI+DQomZ3Q7ICsgQ2xpZW50cyB1 bmF3YXJlIG9mIHRoZSBzeXN0ZW0gZGF0YXN0b3JlIHdvdWxkIGhhdmUgdG8gaW5jbHVkZSAoY29w eSkgaW5mb3JtYXRpb24gZnJvbSB0aGUgc3lzdGVtIGRhdGFzdG9yZSB0byBydW5uaW5nIGluIG9y ZGVyIHRvIHJlZmVyZW5jZSB0aGVtLjxicj4NCiZndDs8YnI+DQo8YnI+DQpPcHRpb24gIzM8YnI+ DQo8YnI+DQpUaGVyZSBpcyBhIGNsaWVudCBvbiB0aGUgc3lzdGVtIHRoYXQgbWFrZXMgY2hhbmdl cyB0byBydW5uaW5nIGp1c3Q8YnI+DQpsaWtlIGFueSBvdGhlciByZW1vdGUgY2xpZW50cyBjYW4g bWFrZSBjaGFuZ2VzIHRvIHJ1bm5pbmcuIFN5c3RlbTxicj4NCmdlbmVyYXRlIGNvbmZpZyB0aGF0 IGlzIG5vdCBlZGl0YWJsZSBleHBsaWNpdCBjb25maWcgaW4gcnVubmluZyBnb2VzPGJyPg0Kc3Ry YWlnaHQgaW50byB0aGUgYXBwbGllZCBjb25maWcgaW4gb3BlcmF0aW9uYWwuIFRoaXMgZG9lcyBu b3QgcmVxdWlyZTxicj4NCmEgc3lzdGVtIGRhdGFzdG9yZSAoaW4gZmFjdCBzb21ldGhpbmcgbGlr ZSBhIHN5c3RlbSBkYXRhc3RvcmUgbWF5PGJyPg0KZXhpc3QgYXMgdGhlIF9sb2dpY18gb2YgdGhl IHN5c3RlbSBjbGllbnQsIHRoZSBnb29kIG9sZCBleGFtcGxlIHdlIGhhZDxicj4NCmlzIGFsbG9j dGluZyBhbiB1bnVzZWQgdWlkIGZvciBhbiBhY2NvdW50IHRoYXQsIG9uY2UgYWxsb2NhdGVkLCBp czxicj4NCm1haW50YWluZWQgaW4gcnVubmluZykuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPisxIHRvIG9wdGlvbiAz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5D b25zaWRlciBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IG1vdmVzIGFsbCB0aGUgJnF1b3Q7aGlkZGVu IHN5c3RlbSBsb2dpYyZxdW90OyBvZmYtYm94PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRvIGEgY29udHJvbGxlciwgc3VjaCB0aGF0IHRoZSBp bml0aWFsIGNvbmZpZyBpcyBsaXRlcmFsbHkgc3VwcGxpZWQgYnkgYW4gZXh0ZXJuYWwgY2xpZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSBoYXZlIHlldCB0byBoZWFyIGEgc2luZ2xlIHVzZS1jYXNlIGZvciBjcmVhdGluZyBhICZs dDtzeXN0ZW0mZ3Q7IGRhdGFzdG9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+JnF1b3Q7VGhlIGNsaWVudCBtaWdodCB3YW50JnF1b3Q7IGlz IG5vdCBhIHVzZS1jYXNlIGZvciBzdGFuZGFyZGl6YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG8gbm90IHVuZGVyc3RhbmQgdGhl ICZxdW90O3B1cmUgdmlldyZxdW90Oy4gU2VlbXMgbGlrZSBpZiB0aGlzIHdhcyBhIHJlYWwgcHJv YmxlbSB0byBzb2x2ZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+dGhlbiBOTURBIHdvdWxkIGhhdmUgaW5jbHVkZWQgYSBzeXN0ZW0gZGF0YXN0 b3JlIGZyb20gdGhlIHN0YXJ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4vanM8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCi0tIDxicj4NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkg QnJlbWVuIGdHbWJIPGJyPg0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8 YnI+DQpGYXg6Jm5ic3A7ICZuYnNwOys0OSA0MjEgMjAwIDMxMDMmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5 LmRlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwv YT4mZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5l dG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM6PR08MB50843C4B006A72F355598AF19B709DM6PR08MB5084namp_-- From nobody Thu Dec 9 07:46: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 047843A0D8D for ; Thu, 9 Dec 2021 07:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 o43Yk9HGgACa for ; Thu, 9 Dec 2021 07:46:11 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2091.outbound.protection.outlook.com [40.107.220.91]) (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 948E13A0912 for ; Thu, 9 Dec 2021 07:46:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mt+MTP2EnQ4WLPj5CH9NoUjFforwOzufVVolrm4Xa635bP6HeasHIRCN9vNM+0aLdPWpIO9QOFSbCjy2rHqlrnVip/z6jj+q0+fTrI4qmzIRzCXI9N3k/BYjcpNm97Tcbx4qHNP1y4XEd9BUF/4EdOTZ08RwIy3DAfKwu9K7CpMeofEwFMTiVzAroSjinRzT31uosOWdpTEOWY7za9AtDwEgRKtDH6t2j71ApUiqqL1RGSRniJYWyDsWmrRDTgUohRyQ2UY8Sp0yPVp2RnU/s3HGE5DR00vznSOus/5thIerGcQ1+WcOk6DF0bmdWc7QrIX7ZacN4p5rLo9p0DWhBw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xege8i3Y+Zdfmq2lBmd5qcs1tkwpyyEBioDBgVnlIb0=; b=JW/DYWnULlOf/imzLprD64b5SQdeaHIsbl2/xfmVkuIgDQwx6kYPCjIY0c7M2WgVTB4+xxqyFgaH9Y3Ri9MykZTVUuCsUdXQRkNyvrFTWgEUyc8Ps+wUa2wrSfOMU++E5RsDd94o93ol+9/3c4uV1fBlJACTNYM9bDzkWemFx3qc+A3mTBoKaPwpPzhK0x2iF6JcMZai++P+om7ArpKnIIbz8nZ0C6dbTYQuTJVK1g/VYZgr2gPcA00WV2rcU0vZa/ajtv0s/aQvDivd7xUCk8ubScmGxCsEYXkk4Pk4RwiYxPZ4XyEqgkyL5+cXYQuiPn+/VU6kOZn+bes9Y0eAEA== 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=xege8i3Y+Zdfmq2lBmd5qcs1tkwpyyEBioDBgVnlIb0=; b=PEGgJbRoa0tdNpgwqJZZ16yeD1h4JEVkkKsAe2Cx0BPVYBlpL+ObvjmNd6EkEnFLaNjTcBwndrjSrHWgtKwjABoi9BjNkU1a3fXKeouGqtVJen2DAnXE7+gh9rD2uA0FWrkPotjyVd1vuOIcE79kQ/ob57eGqNbKmnRzV8NjhVw= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6315.namprd08.prod.outlook.com (2603:10b6:5:1e6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.11; Thu, 9 Dec 2021 15:46:08 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 15:46:08 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "maqiufang (A)" CC: "netmod@ietf.org" Thread-Topic: [netmod] "immutable" flag Thread-Index: AdffmIO2eQWZH1bVQgKuM6kNhPhaAAM61mjgABANFhAAE2HggA== Date: Thu, 9 Dec 2021 15:46:08 +0000 Message-ID: References: <79459f02f6ea4a87bea56edc9772daa6@huawei.com> <178f7cabbf0141b4815349dad3555bb4@huawei.com> In-Reply-To: <178f7cabbf0141b4815349dad3555bb4@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 657a7be3-871b-496e-7eb1-08d9bb2b04d5 x-ms-traffictypediagnostic: DM6PR08MB6315:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mbWNQMz2gQ9nGRK2M2gBx8Rac7L9+6WPyut9V7ykNWS/MThK5jsqz3LtUgRyfS0yNsh3l4GmTVvmahUQR/YDIOe0HRAfF7wZ+kUbzmk8Vq1y2XTdBB1T4w6ZmX8CYmnTGNX4W+fLl9SR7kmBnf2kg0JDXX53/3pLXyKlQuFFe/oubYb0LQwpt7GIR22haukCVwmGdPuZng7sWtAhvo02zJXfl0oy/e54DsPgN9Wv14qIxPfB1VoxTMpnu6LWpmwsWTYw2jF7IOqTnNULuWaRvyoGCsUlJdf9FndafdgV2xP9b+AfmynrtWHIoH3TLST2WnQToUI6nMd/BdX/d3gu/kJhrU551SGm4Ehy9wWxMm1f2nMSQX/n4PB4r8c7LXO02mwjlQgUe+jhvB7gIAsXMROLJXnu0LZaBgn/noEES+TB2tOk8DMWvbtiJgskezQ7nx5+xvYWBZeVaWd+sgQ090DJ+FU7JhwdB8lvOUoXLYCQLmqFQUWXvsRjCdBnkPdDhh11jjnkBO8SqwFTyg+/Q4qGmZcDWufALYVI84cIoAQcg0PB9bimXWTvpT6LzhCrVRr72kvTCD+NjPp2+I/3T6iAQz+qS0EWRVlq3qy4aHvSNi7rvgBWm8GPMME9U+ttWQ/AK4dVe6UeTfxcbj4BJmYS83LYsuMty7lQfaDVfR0gQzvyY5DpbxVBXyQQI/YF7LCtOmEWTgrySeaIQ3hTUA== 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)(366004)(66946007)(66556008)(66446008)(26005)(76116006)(186003)(8676002)(508600001)(7696005)(52536014)(6506007)(9686003)(66476007)(6916009)(33656002)(38100700002)(64756008)(122000001)(53546011)(82960400001)(38070700005)(5660300002)(86362001)(55016003)(2906002)(71200400001)(8936002)(4326008)(316002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?wJ6csFkwQTJ5vztya2D544vYKjyAmTjs11R8V82DEyxHF/AQtAhfH5mZ8k/G?= =?us-ascii?Q?fcPSKsaQa77NxmQWeIe2FeIFbXz4UkJQAEsldujU7S76l+wkBo3ypk7Q7u+u?= =?us-ascii?Q?S/bvdbla26itkNokM2q4SgERTexIXS8Vbs3mVfv4IDCmxw/TfmXu7TNKvWse?= =?us-ascii?Q?Tt8Wd5WWgfmoOwQf8XHQMeUaceXimHbGVA00SdmVJZ5zxMlFhT7C5wM55+UD?= =?us-ascii?Q?GYFdJVKoK0Sh2Ve+3mnr8dCyPZPWjunDfyRw0gwpeKFKxd2xRkOFYNkE4pK8?= =?us-ascii?Q?pElEfej4ba0p/hqe5+cH0zWpNMU25jmQczuyh34cuZwU3isx9johpfGRhEW3?= =?us-ascii?Q?NzmRNIKjKETmM25aV8CeFQ/s5L7BWObxPTxZjaz3CNo21EUCTzG/0rudR5YR?= =?us-ascii?Q?dJwfzxgk89mRn8o7AJhupBvA9TTSifIZUv/gl6fcIar29m7PRGBZzNOsRbQA?= =?us-ascii?Q?pA5Xu2bASeaPCB0PQGHb0op3ef/eELiFKnbcmU0pvECQiQdcLDRAB0o9MLU5?= =?us-ascii?Q?XaDQ1OXR19XViIubkunmvK45/pgUA4o3pLZFaY01K+GPXQfxwSniF1GAUump?= =?us-ascii?Q?PnfbTPOHcvgXYoM78TQKMj56mhkl5FpkcwWNhgC7MbHhZ3LRN/tpBIhnU84j?= =?us-ascii?Q?S6cG4Rvr7cqW/jAu63DTC74wQtOBCF4Y8lbLZUTpljLStOmxhU0gtJ773z5k?= =?us-ascii?Q?Md8iNG9ykXbh2YikMGyC9eZH2ON9DdCphvigFZx8EOnt58xdT0MOX4/NyIsr?= =?us-ascii?Q?v6fzpMkSeP5j++nPaPKeP9kyzQsAmLDZP+Ys5duu+uLWqNjt1cpTLplCiYnL?= =?us-ascii?Q?wQBEYWGymVY7v5E4wUgLNMECvfDBlCx8khK3PZIAcJQLg57C8YDRfAznTSp5?= =?us-ascii?Q?aTb0tOnmM2On1Y98WFVVytXdL2RWYjapH2s454bBXDjZa70yoZ8Fzsd+bKL6?= =?us-ascii?Q?JD/hzW7YEjkP+weXPcfXNREsBDAMiDLEh/kD090esDUwo0kof3q4FC/AAjvw?= =?us-ascii?Q?lKGcosWiEiVK8DYnqx/+NCOKdJ3syl3ssR265kqfyNkSRSAK+sVsBjBcbGf3?= =?us-ascii?Q?FRhen50aNbf7kUPqNY6mcUMPfoo/GrcaBLmZOqW5HX994T67J8s9wQMTYZ4n?= =?us-ascii?Q?LR3B9l68ue1a8/60e1R4xtteHSCNvYlGbVyA9TBGchflnq19qC9Ussr1v9bp?= =?us-ascii?Q?b4CxsuAMDyrICfJoANMHKDx9WpZGWlOI0Gjy3yeCZlYIcn8gz3Q4hjNvHAo8?= =?us-ascii?Q?XyaALTYz8uIKVRMK4zvwJYwoJZJEqSNiUFNxt3H+1DufimTU8Qf28PaFjD//?= =?us-ascii?Q?q0CxKWizXE+QcRFqq2fd9KWBXTPYq7cMPABxdJL3og0Hjm0F5Y2I/WGBeLrt?= =?us-ascii?Q?b9HPzUcngXoJsE0NvlGP6uiuZpCTA6311NOND6So22XmlfXcDGluBkAdnIQI?= =?us-ascii?Q?uhVpT8/aOYpNAc9Uiauodk/ygBEaFr/kWnt40l01o+Ktu9xOZHO5upkHo8BF?= =?us-ascii?Q?Rca44xHUAVmx2CGPJ94IjRng2Oguwu89Gstx73f1SPwHNONY9uMW2bY91TEk?= =?us-ascii?Q?TLwy3ZaTjYtAIfP/R3noHe5AyLKDSbQyt4t+7Ce4NySuuMwzwjTzbpfnZI82?= =?us-ascii?Q?bw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084A00B6F9EB9EF2DE553519B709DM6PR08MB5084namp_" 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: 657a7be3-871b-496e-7eb1-08d9bb2b04d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 15:46:08.8044 (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: egDjgi0ZOucnRIXgnAZLAwikhbRyCk8Wk2d8pbMhalcYq9kIr3CAdD+t4jeWR1s85lm+Fb77bGvO22wrcQZzhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6315 Archived-At: Subject: Re: [netmod] "immutable" flag 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, 09 Dec 2021 15:46:17 -0000 --_000_DM6PR08MB5084A00B6F9EB9EF2DE553519B709DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qiufang Ma, Please see inline. Jason From: maqiufang (A) Sent: Thursday, December 9, 2021 7:57 AM To: Sterne, Jason (Nokia - CA/Ottawa) Cc: netmod@ietf.org Subject: RE: [netmod] "immutable" flag Hi, Jason, Thanks for your comments, please see my reply inline. From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:jason.sterne@nokia.com] Sent: Thursday, December 9, 2021 6:42 AM To: maqiufang (A) >; ne= tmod@ietf.org Subject: RE: [netmod] "immutable" flag Hi Qiufang, I think there are use-cases for "immutable" even outside of system config s= o we may not want to restrict it to system config. [Qiufang Ma] Agree that we can just define such an "immutable" flag without= restricting it to decorating system configuration. In that way, maybe we c= an discuss whether we should define this annotation in an independent I-D.[= >>JTS: ] Yes perhaps. Although I'm not sure this is an urgent item for the= WG. Interested to hear what others think as well. Regarding this "immutable" flag there may be a question to answer: what if= legacy clients receive some annotations they do not understand? Should the= y just ignore it silently? [>>JTS: ] Yes - that is what clients would have = to do. Not ideal but maybe not critical. Servers have various reasons they = may reject a configuration, even if that configuration looks valid against = the YANG model. I'm not sure it would be as simple as erroring when a write is attempted to= that value. Are you talking about an error at edit time, or at commit/validation time ? [Qiufang Ma] My assumption is an error at edit time, static checks are suff= icient for the server to detect the problem. But I think it's also okay to = report an error at commit/validation time. [>>JTS: ] I think in order to al= low the behavior I mention at the end, we'd need to make this a commit time= behavior. IMO the candidate should be allowed to contain a new/changed val= ue for an immutable leaf. The when the commit occurs, the system can attemp= t to achieve what the candidate is asking for. If it can't achieve it, then= it can reject. What if the value configured is the same as the current value ? [Qiufang Ma] I have the same question. Some implementations do allow the cl= ient to configure a same value(e.g., for the purpose of offline validation = of ). But I feel that it may depend on the discussion of another t= hread "should the origin=3D'system' be required for system configurations c= opied/pasted into '" which I posted to the WG. If the origin=3D"in= tended" , it actually means overwrite. [>>JTS: ] The "immutable" tag would be in the YANG model, which means it is= against that schema node whether there is an equivalent data node in or or both. I think it becomes a warning to the client that= the value can't be *changed* in a datastore. It can only be *created* init= ially (if it didn't already exist). For a leaf that is at the top level or= only has non-presence containers as ancestors, it means that leaf can only= be set once in any particular datastore (or maybe changing it requires a r= eboot ?). For leafs that are descendants of presence containers or lists,= then the nearest p-container or list entry ancestor would have to be effec= tively deleted and re-created under the hood to get to the config that the = user declared they want. It is probably best if this is a validation/commit time check. If the immutable leaf is inside a list entry, then it should probably be ac= ceptable for the server to allow a change to the leaf by destroying and re-= creating the list entry under the hood. i.e. allow a change to the immutab= le item (which is in line with configurations being "declarative" - just ge= t me there if possible). [Qiufang Ma] Are you suggesting a server should allow a client to delete/cr= eate the "immutable" data item in ? Wouldn't that be a little stra= nge if a client can delete a particular data item but has no right to chang= e its value? Theoretically, the deletable is modifiable. [>>JTS: ] I don't think delete is allowed unless a parent is deleted (i.e. = the nearest presence container or list entry). But we do need to allow pare= nts of immutable leafs to be deleted IMO. Best Regards, Qiufang Ma Jason From: netmod > On B= ehalf Of maqiufang (A) Sent: Monday, November 22, 2021 7:12 AM To: netmod@ietf.org Subject: [netmod] "immutable" flag Hi, all There are some system configuration which may not be modifiable for clients= (e.g., interface "name" and "type"). Should we define an "immutable" flag t= o indicate to the clients which system configuration is read-only or which = is not? The server will return an error if the clients attempt to configure a value= for a system defined data node with an "immutable" flag. My assumption is that this annotation should be carried only when the clien= ts retrieve with "with-system" parameter to get a merged view. Suggestions, comments and concerns about this issue? Best Regards, Qiufang Ma --_000_DM6PR08MB5084A00B6F9EB9EF2DE553519B709DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qiufan= g Ma,

Please se= e inline.

Jason

&nbs= p;

From: maqiufang (A) <maqiufang1@huawei.com>
Sent: Thursday, December 9, 2021 7:57 AM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>=
Cc: netmod@ietf.org
Subject: RE: [netmod] "immutable" flag

 

Hi, Jas= on,

&n= bsp;

Thanks = for your comments, please see my reply inline.

&n= bsp;

From: Sterne, Jason (Nokia - CA/Ottawa) [<= a href=3D"mailto:jason.sterne@nokia.com">mailto:jason.sterne@nokia.com]
Sent: Thursday, December 9, 2021 6:42 AM
To: maqiufang (A) <maqiu= fang1@huawei.com>; netmod@ietf.org
Subject: RE: [netmod] "immutable" flag

 

Hi Qiufang,

 

I think there are use-cases for "immutable" e= ven outside of system config so we may not want to restrict it to system co= nfig.

[Qiufang Ma] Agree that we can just define such an “immuta= ble” flag without restricting it to decorating system configuration. = In that way, maybe we can discuss whether we should define this annotation in an independent I-D.[>>JTS: ]  Yes perhaps. Altho= ugh I'm not sure this is an urgent item for the WG. Interested to hear what= others think as well.

Regarding this “immutable” flag  there may be a= question to answer: what if legacy clients receive some annotations they d= o not understand? Should they just ignore it silently? [>>JT= S: ] Yes - that is what clients would have to do. Not ideal but maybe not c= ritical. Servers have various reasons they may reject a configuration, even= if that configuration looks valid against the YANG model.  

 

I'm not sure it would be as simple as erroring when a w= rite is attempted to that value. 

 

Are you talking about an error at edit time, or at comm= it/validation time ?=

[Qiufang Ma] My assumption is an error at edit time, static chec= ks are sufficient for the server to detect the problem. But I think it̵= 7;s also okay to report an error at commit/validation time. [>= ;>JTS: ] I think in order to allow the behavior I mention at the end, we= 'd need to make this a commit time behavior. IMO the candidate should be al= lowed to contain a new/changed value for an immutable leaf. The when the commit occurs, the system can attempt to a= chieve what the candidate is asking for. If it can't achieve it, then it ca= n reject.

 

What if the value configured is the same as the current= value ?

[Qiufang Ma] I have the same question. Some implementations do a= llow the client to configure a same value(e.g., for the purpose of offline = validation of <running>). But I feel that it may depend on the discussion of another thread “should the o= rigin=3D’system’ be required for system configurations copied/p= asted into <running>’” which I posted to the WG. If the o= rigin=3D“intended” , it actually means overwrite.

[&g= t;>JTS: ] The "immutable" tag would be in the YANG model, whic= h means it is against that schema node whether there is an equivalent data = node in <system> or <candidate> or both. I think it becomes a warning to the client that the value can't be *changed* in a dat= astore. It can only be *created* initially (if it didn't already exist).&nb= sp; For a leaf that is at the top level or only has non-presence containers= as ancestors, it means that leaf can only be set once in any particular datastore (or maybe changing it require= s a reboot ?).   For leafs that are descendants of presence conta= iners or lists, then the nearest p-container or list entry ancestor would h= ave to be effectively deleted and re-created under the hood to get to the config that the user declared they want.=

 

 

 

It is probably best if this is a validation/commit time= check.

 

If the immutable leaf is inside a list entry, then it s= hould probably be acceptable for the server to allow a change to the leaf b= y destroying and re-creating the list entry under the hood.  i.e. allow a change to the immutable item (whi= ch is in line with configurations being "declarative" - just get = me there if possible).

[Qiufang Ma] Are you suggesting a server should allow a client t= o delete/create the “immutable” data item in <running>? W= ouldn't that be a little strange if a client can delete a particular data item but has no right to change its value?  Theoret= ically, the deletable is modifiable.

[&g= t;>JTS: ] I don't think delete is allowed unless a parent is deleted (i.= e. the nearest presence container or list entry). But we do need to allow p= arents of immutable leafs to be deleted IMO.

 

Best Regards,

Qiufang Ma

 

Jason

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:12 AM
To: netmod@ietf.org
Subject: [netmod] "immutable" flag

 

Hi, = all

 

Ther= e are some system configuration which may not be modifiable for clients(e.g= ., interface “name” and “type”). Should we define an “immutable” flag to indicate to the clients which system co= nfiguration is read-only or which is not?

 

The = server will return an error if the clients attempt to configure a value for= a system defined data node with an “immutable” flag.

 

My a= ssumption is that this annotation should be carried only when the clients r= etrieve <running> with “with-system” parameter to get  a merged view.

 

Sugg= estions, comments and concerns about this issue?

 

 

Best= Regards,

Qiuf= ang Ma

--_000_DM6PR08MB5084A00B6F9EB9EF2DE553519B709DM6PR08MB5084namp_-- From nobody Thu Dec 9 08:15: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 E34493A0E38 for ; Thu, 9 Dec 2021 08:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 Zt6iJswRHHl6 for ; Thu, 9 Dec 2021 08:15:27 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2093.outbound.protection.outlook.com [40.107.223.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 3E96E3A0E39 for ; Thu, 9 Dec 2021 08:15:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J8fl6qE7a1jDP4Z3LFzZPsGblf82xnYEcBiqEFEMMIWcdsEeHcGml/GQUhW+BgoDKE4IKZRhGqhaIJf6C49dmwmlPCp0/WmDft/uYmZtnDNGsZPiBm6qId6d8FJlN2TEaGVpZSFSZLTY8i8w9IOOg+okv9DCFUVXu1MD3kGB5IijJXxBFLg/YCgvjYdFb1NkW5sl1ExKVtXhsVQlkAKQmegM31tDgRbYYk6fgUQi9KtLQgxTxOL7C0pySC5NVg2SCt71Kjk613Au7yX5iATFQdSJ9oApk11gOkFuWMWKEOIYxXQdKiJEF2lcPzy7taLsHMpm0oWukWAvqOGyPl7b+Q== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/QSIH0Eum75w7qXk//6CMDlgKJBJKDRLOkNyRx5e2jg=; b=oBsub12sRE8CLxvnpseF2BFZ+9YN9z7M/4KN5ODz6UP2WkWbEaYRSvQ4EgHDx+thmT5OkiaQo5ejWoc5dlbEy4I7lA3FGdNSMSauXAJaMPGn4s4UrdC1pMv2WbNOeH6ai3da9V2SvvhaXT5o1HccNVA/7bHT5nOgmVgEesCiSe0OHF+Zb+p4prrupbg9PBhzFdhLRRLn/k827tW6aRlBLJ00yGLDoeOyrXhHEL2KLFiDqiUk9estQw8irKxaMMSpyMUfWJogMFcPUDxPWek5GaXtlBIxCFQN/v/JD2CSEetkDS8lStktiJ8kzShqwlS8o9/RjJwae/yvKRfbXnuLMg== 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=/QSIH0Eum75w7qXk//6CMDlgKJBJKDRLOkNyRx5e2jg=; b=vNdN7MVd5zth8wL4/+RQCARQ7YWSzLmnXvKGw/jdWKw3CjGkFAjtluFGyNlwFU3awBWab/s1gEzXLHkETQ1dp/uYlhTQ0NTYOHuH0Bk80N3DSRb8QT9QgMC8mW145LtqwmUY4hj59J8SQ49Nbhc9kGOvEs850XMVE6L1FYj3438= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR0801MB3685.namprd08.prod.outlook.com (2603:10b6:4:80::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.12; Thu, 9 Dec 2021 16:15:23 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 16:15:23 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "Rob Wilton (rwilton)" , Juergen Schoenwaelder , "maqiufang (A)" CC: "netmod@ietf.org" Thread-Topic: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? Thread-Index: AdffkR5sVtMRYIzeTpCisQ2IqIgmxwArAmcAAClLegAADLWFAAABjlZAAv7x7MA= Date: Thu, 9 Dec 2021 16:15:23 +0000 Message-ID: References: <691d9e3445a546608166ab3dbda96137@huawei.com> <20211123.083850.1266325188190711456.id@4668.se> <1ab9c19f3f7c4126b715d2e389eafdaf@huawei.com> <20211124092508.cga6mutlusyaq4mm@anna> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0362bc0f-752b-4bfe-5911-08d9bb2f1a77 x-ms-traffictypediagnostic: DM5PR0801MB3685:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QLFtbnavRlQHDkXX9UI/oD0SvL4GZN9LupoazxWSEnkeyHZoWm7MlOTeM9g9LKXezifstsoVj5iBWsHRKDlD1g6i/dxPuEniGvp4aMp89hc2BWgqjr9hJ2IicspLowok/AHaINZU3s7LGz5btVjyMx1QVlXvvHGpj2ChVwY2G+n6fxvthCWrxRIccnxGlHlMLE8hX76NtSLq39YXZsNKWGwsXAYkobpwmDszyxufuwmZvzQ1TwFYEhxe9ogS20lWgGbFyYtsJL2AbFWKKaLgxrNv4YBQeNSipgVe2gTN9niUHdEGOjgnaJ0yNS/QIfbmXoPmIFwEUrrN4iITm85azfvpNuzDegB4QXg7Pj9pM/Nk3DsJsas6FvDOPmcsO0Gzi9sK+9lC561RuKAkHorQeb7phKoKNmiRlBk+dckeSN7uwKI5Lgv8aRTsQP8M6A3grF0fksMJcmIwbb8Hfel5D5BBC4IcHqwnluTihNEQbPz4nIb485nAVLAt03PAQ9P6NPVQFbZB3QLIO9pzx0pjrjuOocq9FZJ3MF/ww9ejZnEVMNuIboyO51vxWUbBD1itrzuYQ8vMCazPfk3YhtY90NME9UYomwoiFXztV8puFiZyF2hDipl4lcfO2tDliuHh+L9sg/EK5ASoOswSaZC8AoUQq4fNAOYNaYrFIWL4uXo5o/ioLqHFidxvgQRTg0zsRSXTisbA/X/vmRqUQGjtvkprE/pN70lG8tLAK6iSKVhS8NMqSn7kGwTJ1ku+eIKqJ96qAo5bjwoJGmNpG2Hu4NVLJCbeLC5KYtF9c2gbGJc= 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)(366004)(8676002)(8936002)(52536014)(7696005)(122000001)(2906002)(26005)(38100700002)(316002)(83380400001)(186003)(5660300002)(508600001)(66556008)(110136005)(33656002)(66446008)(9686003)(66946007)(76116006)(86362001)(71200400001)(66476007)(64756008)(55016003)(38070700005)(40140700001)(82960400001)(4326008)(6506007)(966005)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?1YyP+hem9gPJssZfhGHPVmBe47uKdIyCslmyp6YVB1uZDCUXSzw4zPWxSk?= =?iso-8859-1?Q?tiuln/ILtcEJkYbXP0PhC/ipvV3jaWQoy9m32naw1Afdw12Lt+4cyjwjwx?= =?iso-8859-1?Q?+DbFFe3gKbi3YEeNhIheOF9MG3f1I8JrJnjQrIp7C6aFP11YX8rY1deUKz?= =?iso-8859-1?Q?lA9SzNL+JKQX/ToQ4jASgAf/b5+doKg/8ttGQwkSXzgLiak6gy97v5OGd/?= =?iso-8859-1?Q?h17CRykLHsejc+WU8F7XfztGudhARM4up8VFzrPVS63G+MaWloWMCFOtmz?= =?iso-8859-1?Q?06Xku6oRzLUagubJ1A0mZzusr0oMu8HoHsUbWtaLdhgiMtZOCKG9wSGjXg?= =?iso-8859-1?Q?xXZJjyh6alIwHYKzLDTR3bMfh91zBkr307BrDuw5Gkz/11bfqoAVFyhsbf?= =?iso-8859-1?Q?qxjoNcapXZraTT5azPSiscbyQrsbPdcDQ5IDAa5W+oxR3iucZ6WmQqAKNP?= =?iso-8859-1?Q?ix4wnghRngpRnXsxdv8Ae9jr0xCcGINND/TaIzev1smtpTS11x9t6PRDp4?= =?iso-8859-1?Q?qZjAm7wG4FdHUoyCJEdElQZd/WJePWrnMOSUgrD+3eFLIi+JKaCywEACAn?= =?iso-8859-1?Q?5VVpHFCiRrfPna4KDlUXbE/lJsCFa+50mC19G8telUSFo9xHGaxSF/Q+eZ?= =?iso-8859-1?Q?thLlR44opRXs17WlLiUQ1FayQRjdbAgx1tp1Hb9wNeLfS8l/NQ0t13o730?= =?iso-8859-1?Q?VKP3BA74WTqVfwb2+7ErFlZqnLqratOq0NlYsxuy0aiUNlC+UMy4Y5Aklt?= =?iso-8859-1?Q?h6idKRmi03taeSJCXj8STyH3HIGghlkhhAr9RgHmW39/WWK3D5G/2p5f5s?= =?iso-8859-1?Q?8cZOussVE9+dUdx12+HJB+YF1j5YTTqAIQvXZZGp+9b5dqs0cJXRuR/TIF?= =?iso-8859-1?Q?6vzUZIUX7FHN6WB85UJpGgdiOSyihos+Y3TzFZG6G/Aanz7+Z4kHS0Xpvx?= =?iso-8859-1?Q?GzIc7y/BYVa7LXZzZBUgcPrhO5UqJ3Ap7YwHsHhEer0SDbCyQhByEgnO6t?= =?iso-8859-1?Q?AXx5GYzb/9AVriF9QIzvNkOAPte2Ho/TZyJko+NAbR2y9HqdfESXT0/VeY?= =?iso-8859-1?Q?Vw/k78gPjKDidW6IpB3LZw9CkfG8z2+DMDys6Soi5HlcQSCaw7zgRT2gNr?= =?iso-8859-1?Q?yfYHdkzxKtYtYngUVyAps2xPkWpqC92rD7FelpH75RFTfg7ZWbTpOW/Ojc?= =?iso-8859-1?Q?Dpx03esN1eRva5Oabz4q5omKVavKFeRSU0Oe21Nr2ERxDazqK7bQZ3K++y?= =?iso-8859-1?Q?ZE51AbdT/GVGNsT5O2V2XYyLP67RuAZKs66HJwZXKCtCfzG8RwDCOd9vYW?= =?iso-8859-1?Q?IlRWZquPGpQZyuZB4+40l7w3w5vhETqOQtqIH0e3TFNMMb6+wnvYo0//S0?= =?iso-8859-1?Q?/kCdMR3meOHuuRjJ6E1g/hE14HVa77FSs80ksxpCuGAljib3VGrQY8i6bv?= =?iso-8859-1?Q?S55V0PHutTExnI8ZXL/3ZWDYwbGjb1avgoAEhOK1ppOpBnM2vAl3j2qRZS?= =?iso-8859-1?Q?xjpH5zO2AR6+OMqAfo6w7Pu6FE8Q7k9uBDvNyXw5dx8KZ6zRToRaZxsJZe?= =?iso-8859-1?Q?n5psQOFEWOdcaUxV1UhiOPUk1q5LAoqAdFo04DVJh+7YRRBSH1qKjZ+KPa?= =?iso-8859-1?Q?8CbTCqOMNh5JB2Tc48Kze7+CFii/u0MToy6AuydesbhhhoV5CvChC8Pw?= =?iso-8859-1?Q?=3D=3D?= 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: 0362bc0f-752b-4bfe-5911-08d9bb2f1a77 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 16:15:23.0222 (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: euSOqYYxHI0b2TzrJR390KgH94v2yxeZpCl8hUprvKMP6FKJPrEunGN4GVDyd72CkfNf0EccrgBumM4p3ljckw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0801MB3685 Archived-At: Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? 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, 09 Dec 2021 16:15:32 -0000 +1. If a value was explicitly configured in , that takes precedenc= e as origin whether it matches or not (just like it takes preceden= ce as the value in ). For config that is *not* in , and comes from , then we sho= uld probably go with "system" as the origin. It is a bit confusing that flows into , but then some data from intended has origin= =3Dintended and some has origin=3Dsystem. That effectively means origin inf= ormation can be added before the data flows into intended and is passed thr= ough transparently. Maybe the model is that unlabelled data flowing thru <= intended> gets labelled with origin=3Dintended, but anything with an origin= upon entry into keeps that origin. New datastores that get def= ined (e.g. ) that feed into can define if they tag an or= igin. Jason > -----Original Message----- > From: netmod On Behalf Of Rob Wilton > (rwilton) > Sent: Wednesday, November 24, 2021 5:17 AM > To: Juergen Schoenwaelder ; > maqiufang (A) > Cc: netmod@ietf.org > Subject: Re: [netmod] Should the origin=3D"system" be required for system > configurations copied/pasted into ? >=20 > +1 to Juergen's comment. >=20 > // As a contributor. >=20 >=20 > -----Original Message----- > From: netmod On Behalf Of J=FCrgen > Sch=F6nw=E4lder > Sent: 24 November 2021 09:25 > To: maqiufang (A) > Cc: netmod@ietf.org > Subject: Re: [netmod] Should the origin=3D"system" be required for system > configurations copied/pasted into ? >=20 > On Wed, Nov 24, 2021 at 03:21:14AM +0000, maqiufang (A) wrote: > > > > But suppose the node is a list entry (e.g., an interface) or a leaf wit= h the > same value. In this case, it is not clear which origin should be used. = I think it > would be ok to use "system" in this case. >=20 > For me, is explicit config and hence it has precedence. The > precedence must be a function of how the datastores related, it should > not depend on which values a config leaf has. >=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 >=20 > _______________________________________________ > 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 Thu Dec 9 08:25: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 22EB83A0E74 for ; Thu, 9 Dec 2021 08:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=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 DsrVguMq9tr1 for ; Thu, 9 Dec 2021 08:24:57 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2097.outbound.protection.outlook.com [40.107.244.97]) (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 920003A0E75 for ; Thu, 9 Dec 2021 08:24:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dd9XM9E4ET4e2+qx3IbK6i2/svbcgT1mL5JjJ/PZASohG4e1L3TLz0uDX34Mo8MWjZ8Y3kCHjMOY/GKzyxusY7A5QgzR8esu1yS/uCf75DFT+X+D5YBpR1LqdIY5aUB2Zml/vzRS8nY9GpAtF+mtYJvSA+bsMD1TXTkCBdij7AbflYXLVR1gOMQNAybpp1UB2b109KhFMSDVJUGIAr0UncUmHEgexFYqVjsX+DFPd0bf48m08p/EB0sZx6JcqvVgtF8Zzjt+MErDHChNJBZ34Hr7+XlKmbkee3ZPGfpW6rNnewop5IJ9I4RRh718CNG/xhUAfnFwzA7oRMR66ZzrZA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cvX6sGuDJ8BiZMhE/Bak3Xc9ZPiigyGkBF1FbXGJTQU=; b=DJdckgi1TW6eXpBS4H0YiDxe6reIsUNIuWDTkoPPvZMb6Zztt2GmRY6FFDdH1zmpNZ3kYImXDE1v1crOehgQS+xIkSfLCAbdWck29EH2GPbaLE6vwU0FehtTI9BLrY8lAyEfuYlqXnCQbxx2IbW8ZX0gJOXRXGCclMf+jqRG6ndTk7eSynBm9MTBinnuqUecWgXGslFUZQ2XPBbSwnfGR5bBG4qjn3iL1ijHaWFU68W3F5RCiIUxwWgIc00DcP69/PtndPcP2HGLPY7+3sYRyXMum5fLqT985wapAOm5gU12nqRmsieIkT65K6x4o2wSe5UAtfYwLz3lfDDk8s7FtA== 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=cvX6sGuDJ8BiZMhE/Bak3Xc9ZPiigyGkBF1FbXGJTQU=; b=rnUwDHd3Qo6uCx33hrNbSVswtneUB1yvHbkIzl7wE+tMt6Shu6dn85+igI9YE9O1SQqwxHVPVU2icb8DduMnyKT1XYUWjgmdES274e+ieQwo+oML7hK+IGwPHIV329Izkp7UviTrsWWxwF0HeE776cX16Osm7gP27VpdcsNbOEw= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5801.namprd08.prod.outlook.com (2603:10b6:5:17b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.20; Thu, 9 Dec 2021 16:24:51 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 16:24:51 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Juergen Schoenwaelder , "Rob Wilton (rwilton)" CC: "maqiufang1=40huawei.com@dmarc.ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? Thread-Index: AdffkR5sVtMRYIzeTpCisQ2IqIgmxwArAmcAAClLegAADLWFAAACviUAAC/xQ/AABJSBgALJobNA Date: Thu, 9 Dec 2021 16:24:51 +0000 Message-ID: References: <20211123.083850.1266325188190711456.id@4668.se> <1ab9c19f3f7c4126b715d2e389eafdaf@huawei.com> <20211124092508.cga6mutlusyaq4mm@anna> <20211124.114340.856721981810780593.id@4668.se> <20211125114733.phenv7mktyed6d4v@anna> In-Reply-To: <20211125114733.phenv7mktyed6d4v@anna> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0d9ba559-9888-45cb-ca25-08d9bb306d76 x-ms-traffictypediagnostic: DM6PR08MB5801:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 84gbTHHq4DGxpBKng4mQGpROeALqayvxe/2BVjmkxhebjkVo9OY6nSDLloV3N3H3izjpA8yDibKnJq7uNIHBa17jZi+gV9lMnpso0v8l8aOL/J7j8jKLmsUFxSoI3+56rrKbCChWYYfbCVeYup4e2VOTlaGrjrRUNiWjLc4T8sQf+Egiw7Dtiwl/trgT4oVfjel/fMEJK2rJI7fgyY+ew2N3QAcXt4IhRHuzdD8Av8daAcpVd8RggsBvwUhhYLVnYm+NUY8woslD/mJWSWZQD+UBPUYTdKleOaDbFUydXFOMoiS5p0VNpbYQDALTA8fv/hMgkaZ+9uRXwYWoWdaVZxlmwM2r4ugMXNKeuQsWGo9u7Vzv1zQb+WjDeQhUS/bRh6GCv/MUqebWivoZvSSCK4Hn88kaOzIc0zrX+jExz+2V7lhmveWPjCwC6AZTCvYulQKCqq0b3Llf3l6xe457BRZI/jNua3VxbjiVNnYNDEUCB+wcs7pgO7NazXlrcqyJtyf2PiwNNYb9idEPjQx8avX3c+5W56I24oRlQeWv0LzPUSLF1t4Rcz24R1wrffMUwx7WhJpPkdZiCY5FFNeBqg9dbW2PLulsHQVG6XRYm95FhiVoU/SLjJD+uWLORW94R5W2CwNVFzyqaE0LYQ1MGymoz/U8t75KiIfWOFwuhrQb1CkzuGkGE2/PdN8lC8Z7Kx1ByIdTQG77LUCWDjGdGiwRp2EU2zHo4veU6HKvPKjAGw5XSk5O57v2ftLE33uKcYLU9yuvNxeq5zytA+0JPMf+UTEPE22lR4UKDMfPm3w= 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)(366004)(83380400001)(316002)(66574015)(55016003)(508600001)(38100700002)(66556008)(66946007)(966005)(40140700001)(33656002)(38070700005)(122000001)(82960400001)(110136005)(54906003)(5660300002)(26005)(2906002)(8676002)(7696005)(6506007)(64756008)(52536014)(53546011)(76116006)(71200400001)(4326008)(8936002)(186003)(9686003)(66446008)(86362001)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eGNYOHkyaVR6MFQ1bHZwd0ZTajRvUDhNd3VrK0lDVUVVbVJWZit6T2JRd2tP?= =?utf-8?B?THpPTVRySTN6RW9pNElJYU5tcXZBM3AyaVF5WnVFNVoxZ3U1bjhBZ3NnZWJQ?= =?utf-8?B?R1AzN1ZPZVgwZXY2MWFkcy9PTHBBUlFNdXpueTFHQ21GMW5LZ0NhZnd5cGNX?= =?utf-8?B?R0hGckgvQzV3eUR4OUlMejV6WEduZno1Y0E4cVJFK3pTWTNZUUxmNGFvbVZr?= =?utf-8?B?ZVZJeWNHalVkTVZhMlR2VEVraXd0YkJQc1RDUVJPbmhLRm91MUozd0V6T0x5?= =?utf-8?B?Vm9ZUmd1ei9PSTFLajIxTVVGbG9PTUVpOTFrekNPS1pkL2E4VUVjZnNiS05K?= =?utf-8?B?SENrRWhXNUxIeGk1WVllOU1ESlpGYmNUVnY1ZjlrQVM2aGsyR28vOXRtT1FR?= =?utf-8?B?TVdMYW9YK3V1SjJQZVJKM1dFNmt3ODVOVmZSUTFLTnkrMlhIbGVwVERZOGRl?= =?utf-8?B?MFdESjFraFUyK0NBcE1WbXliY2t3RGkzbnFSR05XSWx3cnFlVkdLOEkvVHQ5?= =?utf-8?B?dlZ1bFFhOG1IWkJHVlk0c3NBS0hveWRFUG9pNnR0TVQ3MWp0YXZkZ1UrSjla?= =?utf-8?B?Z1RNWFVBR25BVFh3aXBINlNBRW81RzZiRk43TVUwclY5Q0Jwem41SkwwWGZu?= =?utf-8?B?dlRpb3RjSDhmL0RkSnJpQ1VBdDhnay94TjR3Y0IwaUN2Yml2WExoUjc0bVJ2?= =?utf-8?B?M3JRTDNwY0tDN0w5TytRSDVHaG8rYkFMaHQ2ZlJLemZ0QjlpR3dYRi9jRFhl?= =?utf-8?B?YUlvL2pvQXN5QzlFdzVOY2pTK2lmTXMzaUhobmZmMkZyVm0wTVVUcHJxU0hv?= =?utf-8?B?cDIvRVVlRTVYeld3dC9NUCt3eDVTMXdzaHQ3UWNIcmlYczJaMnRFVHVNSUdQ?= =?utf-8?B?ekFpSUtXZUhmcGNIWWZDbTZySnNhY2FURkhHMUQzSEZ6SFpyQmFTb0U5VWd0?= =?utf-8?B?bHNiZGVIY1VvR2JsSWU4UURWcnFCOUU5TFdjK3lmSU9jcjQwRElwRjUwcVcy?= =?utf-8?B?UjNlcWcrRU1GaFBTcEtseHArdkN5djFSTERSTlorQU92cHhBTUQwMEJCc0NM?= =?utf-8?B?dFdpOHJ6RnlubTVDblZydTAzZWw1UVFBTUwwZWIyc2M4eXN1dStLS0ZaWXNZ?= =?utf-8?B?OE5HSW8yS3lJWUZMNTMwUm04TS85RGNjMzhOQllLY0ptK1JPOVJVOUJtUk1q?= =?utf-8?B?SkVCZ2dBRU4wSHNOR0Z4Y09MQUxqQklydVY2b3RwOTdoaFJZZVhadHVzbStw?= =?utf-8?B?UVpERnpiQ1N2M3VKRU80SVpPbkttOFZyVXQxTW9ML2NpVTJud0tkRGdtOHNJ?= =?utf-8?B?MW5TbFJHRVVsUFptYTJSOVVsbkNIc2pHSW5mSEFvNE5YR1RPY09ObEVLYUdL?= =?utf-8?B?YmpJTkRlajN2elBzdVcwYlVYZGc4VXFKUlNCZlNHZUdxVlpEcStJdXNrSW44?= =?utf-8?B?Q0toMTh0RFdadDlzODZZWTB3RmhyVmVPOXZRUmNCSkw2a1U5cE9haHg3aUZw?= =?utf-8?B?Z1RzQ0kxbUtYOXVXd1U1R2ZXUll5Z3JoT0hEL3ZsVFR3ZnNkOXpMY09DaTRs?= =?utf-8?B?amF4RjFESVEzWC9VVGVkNDFteUZwTUNqZnBuMEZCY3Q3R2V1TlNIV3d1cHRa?= =?utf-8?B?eUo4UCt3eGJUQUNBdzlkbXpaS2xSWE9yUnRmUlBDSXFTRE1DNDVkSERqdmJD?= =?utf-8?B?SWErZzhTMmEzcTRPY0xEeWthcnl5aU1QWHVyWmN4QmZrOVpURndEVnZvYnRy?= =?utf-8?B?VGdpNHM0enRNbU52b2dOZ0hmYzJVSjFsc2RRbGZGYmJTU2w4YTBPOER2UVor?= =?utf-8?B?ckhYbVZjaEVyakVHTnNSWTBmQ2pERWFCRGtRSm11M3lMYm1Ja2pRTHBlQWt6?= =?utf-8?B?dFBCODlwa1VLc1dyWVFqeEUyYUh5ak9sTHNvYUdoNHFpK0NIMndUMzJoeVpl?= =?utf-8?B?REl1SlZ3eXJhU21TRFRiODgyRWRtdW5lUlIvdVFJZk5iVERVdXRILzV3T3Iy?= =?utf-8?B?c2JhWitGc3EvaFRWZkVSQ2VlUXEydHZGZ0dkSUtNNjJ6MmdJWWVESlBra3Nk?= =?utf-8?B?ZmxZV3NZWTNHSmE0ZE5YeHhEbkNxaDhLTlVOV2xYcVR4Uy95WGp5VURQSkZl?= =?utf-8?B?endJdXFKZkV3SHJjcWFiaGk3ODl5TGRpTm9UYmpDM0Z1NGJrdHVJSVFMVUZw?= =?utf-8?B?emc9PQ==?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: 0d9ba559-9888-45cb-ca25-08d9bb306d76 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 16:24:51.7902 (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: 0Kjz5LmqyI/WdCGpbxaaV5Ui7REnVv2KNRInOhy7dDXlM5WXLOV5X+IPWTjCLormdTL5c+jIz/PTkn2poZ4a7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5801 Archived-At: Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? 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, 09 Dec 2021 16:25:02 -0000 SSB0aGluayBpdCBtYXkgYmUgYSBzZXJ2ZXIgaW1wbGVtZW50b3IncyBjaG9pY2Ugd2hldGhlciB0 aGV5IHdvdWxkIHB1dCBhIGxvb3BiYWNrIGludGVyZmFjZSBpbnRvIDxzeXN0ZW0+IChpLmUuIGNv bnNpZGVyIGl0IGFzIHN5c3RlbSBwcm92aXNpb25lZCBjb25maWd1cmF0aW9uKSwgb3IgaW50byA8 b3BlcmF0aW9uYWw+IChhbmQgbm90IHN5c3RlbSwgaS5lLiBjb25zaWRlciBpdCBhcyBzdGF0ZSBp bmZvcm1hdGlvbikuDQoNClRoZSBwcmltYXJ5IDxzeXN0ZW0+IGNvbmZpZyB1c2UgY2FzZXMgSSBz ZWUgYXJlbid0IHNvIG11Y2ggaW50ZXJmYWNlcywgY2FyZHMsIGV0Yy4gSXQgaXMgbW9yZSBmb3Ig dGhpbmdzIGxpa2UgYnVpbHQgaW4gcW9zIHByb2ZpbGVzIGFuZCBvdGhlciBoYW5keSBwb2xpY3kg b2JqZWN0cyB0aGF0IGFyZSBtb3JlIHN0YXRpYyAoZS5nLiBsaWtlIEtlbnQncyBKVU5PUyBleGFt cGxlcyBoZSBoYXMgZGVzY3JpYmVkKS4gIEknbSBub3QgbmVjZXNzYXJpbHkgc2F5aW5nIHdlIHBy ZWNsdWRlIHNvbWUgb2YgdGhlIHJlc291cmNlLWJhc2VkIGR5bmFtaWMgc3lzdGVtIGNvbmZpZyBw cm9wb3NlZCBpbiB0aGUgZHJhZnQsIGJ1dCBtYXliZSB0aG9zZSBwYXJ0cyBhcmUgbW9yZSBjb25m dXNpbmcvY29udGVudGlvdXMuDQoNCkphc29uIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBP ZiBKw7xyZ2VuDQo+IFNjaMO2bnfDpGxkZXINCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDI1 LCAyMDIxIDY6NDggQU0NCj4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2Nv LmNvbT4NCj4gQ2M6IG1hcWl1ZmFuZzE9NDBodWF3ZWkuY29tQGRtYXJjLmlldGYub3JnOyBuZXRt b2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFNob3VsZCB0aGUgb3JpZ2luPSJz eXN0ZW0iIGJlIHJlcXVpcmVkIGZvciBzeXN0ZW0NCj4gY29uZmlndXJhdGlvbnMgY29waWVkL3Bh c3RlZCBpbnRvIDxydW5uaW5nPj8NCj4gDQo+IEkgcGVyc29uYWxseSBiZWxpZXZlIHRoaXMgbm90 aW9uIG9mIGEgc3lzdGVtIGRhdGFzdG9yZSBpcyBhY3R1YWxseSBhDQo+IGJhZCBpZGVhLiBBIGxv b3BiYWNrIGludGVyZmFjZSwgZm9yIGV4YW1wbGUsIGlzIHN5c3RlbSBnZW5lcmF0ZWQgYW5kDQo+ IGl0IGV4aXN0cyBpbiBvcGVyYXRpb25hbCBidXQgdXN1YWxseSBub3QgaW4gaW50ZW5kZWQuIEkg dGhpbmsgaXQgaXMNCj4gd3JvbmcgdG8gdGhpbmsgdGhhdCBhIHN5c3RlbSBkYXRhc3RvcmUgZmVl ZHMgaW50byBpbnRlbmRlZC4gQWZ0ZXIgYWxsLA0KPiBzeXN0ZW0gY29uZmlnIGFsc28gY29tZXMg YW5kIGdvZXMgYXQgdGhlIHdpbGwgb2YgdGhlIHN5c3RlbS4gSSBhbSBub3QNCj4gZm9sbG93aW5n IHRoaXMgaW4gZGV0YWlsIGJ1dCBJIGZlYXIgdGhpcyB3b3JrIGxpa2VseSBjcmVhdGVzIG1vcmUN Cj4gZGFtYWdlIHRoYW4gdGhhdCBpcyBzb2x2ZXMgc2VyaW91cyByZWFsLXdvcmxkIHByb2JsZW1z Lg0KPiANCj4gL2pzDQo+IA0KPiBPbiBUaHUsIE5vdiAyNSwgMjAyMSBhdCAwOTo0NTo1NkFNICsw MDAwLCBSb2IgV2lsdG9uIChyd2lsdG9uKSB3cm90ZToNCj4gPiBIaSBNYXJ0aW4sDQo+ID4NCj4g PiBJIHRoaW5rIHRoYXQgdGhlIHByb3Bvc2FsIGlzIHRoYXQgPHN5c3RlbT4gc2hvdWxkIGZlZWQg aW50byA8aW50ZW5kZWQ+DQo+IHJhdGhlciB0aGFuIGRpcmVjdGx5IGludG8gPG9wZXJhdGlvbmFs Pi4gIFRoZSByZWFzb25pbmcgZm9yIHRoaXMgaXMgdG8gYWxsb3cNCj4gY29uZmlndXJhdGlvbiB0 byBkZXBlbmQgb24gc3lzdGVtIGRlZmluZWQgY29uZmlndXJhdGlvbiBkdXJpbmcgdmFsaWRhdGlv bg0KPiB3aXRob3V0IHJlcXVpcmluZyB0aGF0IGNvbmZpZ3VyYXRpb24gdG8gYmUgY29waWVkIGlu dG8gPHJ1bm5pbmc+LiAgQ2xpZW50cw0KPiB3b3VsZCBzdGlsbCBiZSBhbGxvd2VkIHRvIGV4cGxp Y2l0bHkgZXhwcmVzcyB0aGUgc3lzdGVtIGNvbmZpZ3VyYXRpb24gaXMNCj4gcnVubmluZyBhcyB3 ZWxsIC0gZS5nLiwgaWYgdGhleSB3YW50ZWQgYSBmdWxsIGNvbmZpZ3VyYXRpb24gdGhhdCB0aGV5 IGNhbg0KPiB2YWxpZGF0ZSBvZmYgYm94Lg0KPiA+DQo+ID4gSW4geW91ciBleGFtcGxlIGJlbG93 LCBJIHdvdWxkIHByb2JhYmx5IG1hcmsgdGhlIG9yaWdpbiBvZiB0aGUgbG8NCj4gaW50ZXJmYWNl LCB0aGUgbmFtZSBsZWFmLCBhbmQgZGVzY3JpcHRpb24gbGVhZiBhcyAiaW50ZW5kZWQiLCBidXQg dGhlIHR5cGUgaXMNCj4gInN5c3RlbSIuICBJIHRoaW5rIHRoYXQgdGhpcyB3b3VsZCBiZSBzaW1p bGFyIHRvIGhvdyBJIHdvdWxkIGV4cGVjdCBhIGRlZmF1bHQNCj4gdmFsdWUgdG8gYmUgcmVwb3J0 ZWQuICBJLmUuLCBpZiB0aGUgcnVubmluZyBjb25maWcgZXhwbGljaXRseSBzZXRzIGEgbGVhZiB0 byBpdHMNCj4gZGVmYXVsdCB2YWx1ZSwgSSB0aGluayB0aGF0IGl0IGlzIG1vcmUgaW5mb3JtYXRp dmUgdG8gcmVwb3J0IHRoYXQgYXMgb3JpZ2luDQo+ICJpbnRlbmRlZCIgcmF0aGVyIHRoYW4gIm9y aWdpbiIgZGVmYXVsdC4gIEJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgUkZDIDgzNDINCj4gcHJvc2Ny aWJlcyB3aGF0IGlzIGJlIHVzZWQgaW4gdGhlc2UgY2FzZXMuDQo+ID4NCj4gPiBSZWdhcmRzLA0K PiA+IFJvYg0KPiA+DQo+ID4gLy8gQXMgYSBjb250cmlidXRvcg0KPiA+DQo+ID4NCj4gPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFydGluDQo+IEJqw7Zya2x1bmQNCj4gPiA+IFNl bnQ6IDI0IE5vdmVtYmVyIDIwMjEgMTA6NDQNCj4gPiA+IFRvOiBqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGUNCj4gPiA+IENjOiBtYXFpdWZhbmcxPTQwaHVhd2VpLmNvbUBkbWFy Yy5pZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0g U2hvdWxkIHRoZSBvcmlnaW49InN5c3RlbSIgYmUgcmVxdWlyZWQgZm9yIHN5c3RlbQ0KPiA+ID4g Y29uZmlndXJhdGlvbnMgY29waWVkL3Bhc3RlZCBpbnRvIDxydW5uaW5nPj8NCj4gPiA+DQo+ID4g PiBKw7xyZ2VuIFNjaMO2bnfDpGxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZT4gd3JvdGU6DQo+ID4gPiA+IE9uIFdlZCwgTm92IDI0LCAyMDIxIGF0IDAzOjIxOjE0QU0g KzAwMDAsIG1hcWl1ZmFuZyAoQSkgd3JvdGU6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBCdXQgc3Vw cG9zZSB0aGUgbm9kZSBpcyBhIGxpc3QgZW50cnkgKGUuZy4sIGFuIGludGVyZmFjZSkgb3IgYSBs ZWFmIHdpdGgNCj4gdGhlDQo+ID4gPiBzYW1lIHZhbHVlLiAgSW4gdGhpcyBjYXNlLCBpdCBpcyBu b3QgY2xlYXIgd2hpY2ggb3JpZ2luIHNob3VsZCBiZSB1c2VkLiAgSQ0KPiB0aGluayBpdA0KPiA+ ID4gd291bGQgYmUgb2sgdG8gdXNlICJzeXN0ZW0iIGluIHRoaXMgY2FzZS4NCj4gPiA+ID4NCj4g PiA+ID4gRm9yIG1lLCA8cnVubmluZz4gaXMgZXhwbGljaXQgY29uZmlnIGFuZCBoZW5jZSBpdCBo YXMgcHJlY2VkZW5jZS4gVGhlDQo+ID4gPiA+IHByZWNlZGVuY2UgbXVzdCBiZSBhIGZ1bmN0aW9u IG9mIGhvdyB0aGUgZGF0YXN0b3JlcyByZWxhdGVkLCBpdCBzaG91bGQNCj4gPiA+ID4gbm90IGRl cGVuZCBvbiB3aGljaCB2YWx1ZXMgYSBjb25maWcgbGVhZiBoYXMuDQo+ID4gPg0KPiA+ID4gSGVy ZSdzIGEgc2ltcGxlIGV4YW1wbGUuDQo+ID4gPg0KPiA+ID4gU3VwcG9zZSA8c3lzdGVtPiBoYXM6 DQo+ID4gPg0KPiA+ID4gICAgPGludGVyZmFjZT4NCj4gPiA+ICAgICAgPG5hbWU+bG88L25hbWU+ DQo+ID4gPiAgICAgIDx0eXBlPmxvb3BiYWNrPC90eXBlPg0KPiA+ID4gICAgICA8ZGVzY3JpcHRp b24+YWRkZWQgYnkgc3lzdGVtPC9kZXNjcmlwdGlvbj4NCj4gPiA+ICAgIDwvaW50ZXJmYWNlPg0K PiA+ID4NCj4gPiA+IGFuZCA8aW50ZW5kZWQ+IGhhczoNCj4gPiA+DQo+ID4gPiAgICA8aW50ZXJm YWNlPg0KPiA+ID4gICAgICA8bmFtZT5sbzwvbmFtZT4NCj4gPiA+ICAgICAgPGRlc2NyaXB0aW9u PnNldCBieSBhIGNsaWVudDwvZGVzY3JpcHRpb24+DQo+ID4gPiAgICA8L2ludGVyZmFjZT4NCj4g PiA+DQo+ID4gPiBOb3cgd2UgZm9sbG93IHRoZSBwaWN0dXJlIGluIFJGQyA4MzQyOg0KPiA+ID4N Cj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKw0KPiA+ID4gICAgICAg ICAgICAgICAgICAgICAgIHwgPGludGVuZGVkPiB8IC8vIHN1YmplY3QgdG8gdmFsaWRhdGlvbg0K PiA+ID4gICAgICAgICAgICAgICAgICAgICAgIHwgKGN0LCBybykgICB8DQo+ID4gPiAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsNCj4gPiA+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAvLyBjaGFuZ2VzIGFwcGxpZWQsIHN1YmplY3QgdG8NCj4gPiA+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAvLyBsb2NhbCBmYWN0b3JzLCBlLmcu LCBtaXNzaW5nDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgLy8g cmVzb3VyY2VzLCBkZWxheXMNCj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ ID4gPiAgICAgICAgZHluYW1pYyAgICAgICAgICAgICAgfCAgICstLS0tLS0tLSBsZWFybmVkIGNv bmZpZ3VyYXRpb24NCj4gPiA+ICAgICAgICBjb25maWd1cmF0aW9uICAgICAgICB8ICAgKy0tLS0t LS0tIHN5c3RlbSBjb25maWd1cmF0aW9uDQo+ID4gPiAgICAgICAgZGF0YXN0b3JlcyAtLS0tLSsg ICAgfCAgICstLS0tLS0tLSBkZWZhdWx0IGNvbmZpZ3VyYXRpb24NCj4gPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICB8ICAgfA0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICB2ICAg IHYgICB2DQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDQo+ID4g PiAgICAgICAgICAgICAgICAgICAgIHwgPG9wZXJhdGlvbmFsPiB8IDwtLSBzeXN0ZW0gc3RhdGUN Cj4gPiA+ICAgICAgICAgICAgICAgICAgICAgfCAoY3QgKyBjZiwgcm8pIHwNCj4gPiA+ICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCj4gPiA+DQo+ID4gPg0KPiA+ID4gU28g bm93IHdlIG1lcmdlIGludGVuZGVkIGFuZCBzeXN0ZW0gaW50byBvcGVyYXRpb25hbCBzdGF0ZS4g IEZpcnN0IHdlDQo+ID4gPiBhZGQgc3lzdGVtIHRvIGdldDoNCj4gPiA+DQo+ID4gPiAgIDxpbnRl cmZhY2Ugb3JpZ2luPSJzeXN0ZW0iPg0KPiA+ID4gICAgIDxuYW1lPmxvPC9uYW1lPg0KPiA+ID4g ICAgIDx0eXBlPmxvb3BiYWNrPC90eXBlPg0KPiA+ID4gICAgIDxkZXNjcmlwdGlvbj5hZGRlZCBi eSBzeXN0ZW08L2Rlc2NyaXB0aW9uPg0KPiA+ID4gICA8L2ludGVyZmFjZT4NCj4gPiA+DQo+ID4g PiBhbmQgdGhlbiB3ZSBhZGQgaW50ZW5kZWQgdG8gYXJyaXZlIGF0Og0KPiA+ID4NCj4gPiA+ICAg PGludGVyZmFjZSBvcmlnaW49InN5c3RlbSI+DQo+ID4gPiAgICAgPG5hbWU+bG88L25hbWU+DQo+ ID4gPiAgICAgPHR5cGU+bG9vcGJhY2s8L3R5cGU+DQo+ID4gPiAgICAgPGRlc2NyaXB0aW9uIG9y aWdpbj0iaW50ZW5kZWQiPnNldCBieSBhIGNsaWVudDwvZGVzY3JpcHRpb24+DQo+ID4gPiAgIDwv aW50ZXJmYWNlPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBEb2Vzbid0IHRoaXMgbWFrZSBzZW5zZT8N Cj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC9tYXJ0aW4NCj4gPiA+DQo+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbmV0bW9kIG1h aWxpbmcgbGlzdA0KPiA+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53 YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6 ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwg R2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5q YWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Thu Dec 9 08:27: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 9BD563A0E7C for ; Thu, 9 Dec 2021 08:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 PXM6nMKK6IAM for ; Thu, 9 Dec 2021 08:27:30 -0800 (PST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2091.outbound.protection.outlook.com [40.107.212.91]) (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 936D23A0E7F for ; Thu, 9 Dec 2021 08:27:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZPYU7767Z4IXSaRNOYxvOIxrcKDb6ucoiA4AJIhstlG5v92QSXuwH04ym7OkJibyqR2zyiQ5dxjiEQIni6vj/l6B6MUuw7o5ppBljnVxk3vFSF/HIkKU3gQnwnrfZwbMZidy6FcpmZBkl3KI0xyD3UtUePxaCI72b/esqRDppgPfhtp2B9muk2tukPJZ9cCBvxqX8f8MOLlKF8szII4viMrKjekX+DF5YBq7eX2nWJf9NHzezvfr9RoFwh7ap7hbcsiyj1C5654dRjEwUAmcdk5F/0vaaBpzA/tyqrw1XR77MRx+/L/ExLqhpp9ZRdr2A9GV953mu5VCWT76nILALg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6vFD+gA3jY2i53yHF2abzbI60qo4qhLsBgJ+lx9Val8=; b=fFcWHru1cIe4MWxUazyj7na1HM9gINyVzu59QX8jJxBIcCwbcviuM47XyChm5KABr0z3fqWU33P5H+lyjmN61xrax2M96+MZkv2Sz06VXR5MV2gLmmfpwGOy5ZhnjWuPqZqu+8coSOMOBcEil/u9DfAMc3gEyONkdgUwwrw/j8sSeqnLy/0ANG94aNsYcbDxL496N3OTnq6tkmVMLUvFrTdv+KkQlRqAkQC+LkuAHQsN/+cGrKvWlDP9LUuJwptbQAZAaHltxROqKgEbY1xCb+kQHKgrvC+Cw5LKa4pycY8mgYXKzrMqZ21pUDH+UKVr08+Nro8UFlwtMiq+46YbzQ== 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=6vFD+gA3jY2i53yHF2abzbI60qo4qhLsBgJ+lx9Val8=; b=Rguu5h4MX4WSf/wxnSP7jaBRdHTy1pRYYA4ys8hD38UeKdJ8eogdiG8crojsG4HX8ZmP+K0/6uDlm1o6D6C2Ox+3ZGVsjGh5Ecv7Guxj1RZfGJKGZ7FMwwiRTdLNgI1aUP/Ujxc9S1jvGAVZZWQTU7nqi+X5L3+q3qub/An1Chg= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB3324.namprd08.prod.outlook.com (2603:10b6:4:65::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.22; Thu, 9 Dec 2021 16:27:23 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 16:27:23 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Kent Watsen , Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? Thread-Index: AQHX7RmkVtMRYIzeTpCisQ2IqIgmxw== Date: Thu, 9 Dec 2021 16:27:23 +0000 Message-ID: References: <20211124.114340.856721981810780593.id@4668.se> <20211125114733.phenv7mktyed6d4v@anna> <20211125.130155.1636018839435459937.id@4668.se> <20211125130128.ogpuzktbdyp6yydj@anna> <0100017d6de3a63d-89d0e981-5347-47be-9779-52d70ccbcda6-000000@email.amazonses.com> In-Reply-To: <0100017d6de3a63d-89d0e981-5347-47be-9779-52d70ccbcda6-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b2bd15bb-950b-44d5-fd2d-08d9bb30c7b3 x-ms-traffictypediagnostic: DM5PR08MB3324:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UcsUVThzEnYND71V66mzkgIHFFZMMqp/i+jV36iWBnGBd0KkMXC7KYfD/NTB4OMQT33Q4/vjbNvFpx9ZaESelap/z6MniGZ/r+mGIsYH2nc1PMGy6Jf+tOCGCdrZ8ZdotG0hJdHF6xgkYFKgLDB48oAuFI8WGlqNcgtSZMG/YCpYwK2dP49m+qYqeJXmGX0rkVJrY16eTq0MINJcq6xHWmGW5SahGoH8oxQiToEi2iu4wJvHkcSTcq5u9puNrtGYch9h5vNEDcS5fG3aQrx3G/G6knHAMY1uHx9ymcjaMPj5ItkwBtBjHWD2ANPMfXIC+dr7tc1sI+53vL8tkUQugeP9pIoaso7xvnuS87OlVyEXMI1KEeOo9wee9LMSNEAq4Ubn5M1bp/SL1dCkK33AhPId8tWwer1tISPIIjbPXchkgkj4KhWvDbQx0QdZaf8/ZEakxFgy63CJ9SCxXGob1wa5o4vrYFmMkbh/iypMQgmkIjEss6JXjz6KTI2igdU9+OuTRkYZ/V3TAa7Yxga0DC9sq/1d7OBzX3PoZoE4zgk7kDpAhr1/oHzXxYxh9D5pBx7B68m/3qjPaX2HFmnzUEdPHNRZfkDJps/t8aFefWO3mGgDM+pcQps7Z0mQKNBV4leE2ngoxyS9p47IKSfdcnENNEJfwMeI90mmJ3zH8zTjP5QRGSIFx9M6mcuXvxy5Y4fZ3o2O4PTua7RKdRiUA/I9I1Ke/6XjOtfeKimLG1nWJeKgzpYAnNVWqgPAKfnGrz8CBqlK86Gmx9Jg8Z6SbzXweq5JRWvAXcbXHB1uWr4= 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)(366004)(5660300002)(64756008)(76116006)(66946007)(66556008)(38070700005)(66476007)(33656002)(316002)(52536014)(110136005)(186003)(26005)(8676002)(66446008)(9686003)(86362001)(122000001)(8936002)(38100700002)(2906002)(508600001)(4326008)(53546011)(55016003)(71200400001)(82960400001)(7696005)(966005)(6506007)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MnduUGdyNzhMWG84ODJQRDZ6YlYxQ0F4b1VoRWt6VUlYRHlxUzJvR245dFFS?= =?utf-8?B?clREeStaRVF0NmZqQUo2blNFa1NIQ0I4bGRlNnM1M1YxUFUxekJ3YlBjaXZO?= =?utf-8?B?YnJTMk5ZanRaNjZ1UFczQzZjaEZWVlgxR2NlOCtFdU1jeVB6L0k1T0UyMDE1?= =?utf-8?B?emV1OTNyUUw0ajRVMDJNeFJWUnpPWlV0UlZpdnpVeTNDdHZzbGYwODlWYi9B?= =?utf-8?B?Ylhwd0VhRlZneWdLMm85Mlg2WWlzRm1uNTJMczJZcUpicWNackdQeWtLSmZK?= =?utf-8?B?SStzWWJVRFlJMVRad3BUTUxva0MxK1BkamJCbnZjajhwbkx4MCt5R2NyUHYz?= =?utf-8?B?VWcyZGFEbytHU1M4V0pWWHpmQmFhdUV3cEVZcC84Umtla3ZCYWkrZ0htVG5U?= =?utf-8?B?SzNkOUpvQjdKMDNmZTRITXhiYk9aQW8xelRKbnozN1VwVis3M2doVGtzdTFT?= =?utf-8?B?LzVsU3NBR0FjRERFSjdFenZiSmtrRGljeUVKc1RRQ0FTUEk2VzdkWXdnS0Y2?= =?utf-8?B?SlpISE9rS01teWlHQkdvRU82RUdJTXJZWGVCakFseDN1M1JzVk5wQWx5d3Bm?= =?utf-8?B?RXVZQWgxU2x2eDhBVjFLUUxXWW9kUDh6L3NXU1EyNUs2VkxQNzZ5UEthWE9J?= =?utf-8?B?S29lVDFtcDlBMStRK0hHVGJBMGRJUk5Xc3pLMWtsOVdwME5wMG1XdXVTODRX?= =?utf-8?B?OUlZT3VKejRrVTNIY29PNjdjVjdQQlJ6RWRiTjVGd3RubCtEVk5UN1dTZW1x?= =?utf-8?B?eXVZcjN3bUNmZDV1U0Q1VHlSMzRrR1VPSVpwNUo1SW9Rak9idWZ2Z1B4ZUZI?= =?utf-8?B?QkVHU08wR3Q0blFBYWFORWpId2ZHWjQ1bUZRNEJTV1RuU2VXeG5DVyt2citu?= =?utf-8?B?aEpjckVlVUJSZCtselRERTJCMnVDSXhieHJVbk8vT25kVnNFa25NYzlBQ3A1?= =?utf-8?B?T1BNdEw4aS9nUGgzNnZqc1lOVE5EdkdDZWZwTC9ySHhBRjV5SjdZdExOVzhy?= =?utf-8?B?U3EvNWZZcEcxeGR0ZGNPZ0pQRzVuUEZKSGlkN2dZOTNEaWExejJ2YlRrZ2h1?= =?utf-8?B?amtWd2trMDA0czZIYzEyckZyZTZ6U3JpSEFFLytKOHY5WnRPS2ZEL2tvS2I4?= =?utf-8?B?WmlLazE1dnZYNDJjb05ZamZLTlZ3NVJ2bzVtUlE0d1lmTGp2eHM2N0x4MkdI?= =?utf-8?B?U3VzZU9EdkhvVUpGMmVVVURVUlZPMEN6RElLNWxwYWQ3MkNFTnhVZWZjbkc3?= =?utf-8?B?Q2VFdlYvcUFCUFBuUlY3N21US3NyMGpSaXkvczAraTFEd1lPeDRSS0lrZ0JM?= =?utf-8?B?ZmpFZkYzcFpkc3BLejJFYW8rRTBOQmE0MC91YXg3a1pTSzY2ckpkQXF1T1NK?= =?utf-8?B?VWl0R0ZMdWlpaUtLL05sYTJua3ZKU2c1VjFBQUtCUFZHYmlFZ1Q2aXc1M1c0?= =?utf-8?B?SFlNL3M1RUNkUjRybDNNZGhyRVVDSUhUbWJhLytMY2ZEU2ppeWdXNm5vclV0?= =?utf-8?B?YzBHUUVabHdxNExVTXhjV09pNWNMR2pTZWlrK2xUVlAySU16MjRldzI0aVUy?= =?utf-8?B?Z0JwZDQvaWVJM1R6c0xLY2hFaHkvanlFR2VtSjhBNVlWaEJ5dWdjdWhOZzFE?= =?utf-8?B?aVpYZWgzMGxzLzdvVzR5L2NKbFZ5c0hFRjNvc2RHSndjQ1NuVWwxMHQ2b081?= =?utf-8?B?YVhyUjM5SVJRTHJ0RFBIYXZwYWtoOWRzd1Nza3FaUnd6bVFkVGtrMHUxSWsy?= =?utf-8?B?ZEU1WVNzSUEyd2xTcDBvQ0t3KytaUnNPWHZIUVdVRHVaV2ZmUHA4YjdVUG5K?= =?utf-8?B?U3Izak5qYmJ3cFBCMmtQN2ltYzc0aER4UU0wWmNXcnRMTWhYeTF0UzBicUtT?= =?utf-8?B?eHZhNW52V29xbTcwSTRyRHdKY2xzMGVqMTlpaHpmd1FwdHUwQTFuenc5Uk9a?= =?utf-8?B?N0krdXhUSE0zd0xrbTk2bHBKQVI2bTdvMWtZOVhGcXhjTC8wWE95MmxsaTEx?= =?utf-8?B?bExOZjZiMGlWMTgyTzFwRW5jd1E5L3ZSTjI2Z3pUbjNmZ3Yxb3VsQ1BqNHF6?= =?utf-8?B?S2hnYW8wWnBDOGQ5dGQvY2VMMkRLZWNWcUs5aHhYb3pteStoTzJhTEJNcytN?= =?utf-8?B?aWlUclBJYVdvS0hmb2hsdW93NzNFOFRHVFVsRXBLUWVRdS9tS3ZiK1NJVVls?= =?utf-8?B?bWc9PQ==?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: b2bd15bb-950b-44d5-fd2d-08d9bb30c7b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 16:27:23.2182 (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: UkjtXrkwTeo7fZFaAyeOwqiW0czL3gZCfUQaDDzlJG7bl7n73tdSc+j7+MaD/JiBGYdBKiGX2IqB480e0ybk6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB3324 Archived-At: Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? 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, 09 Dec 2021 16:27:36 -0000 PiBXZeKAmXZlIGFsd2F5cyBtYWludGFpbmVkIHRoYXQgPHJ1bm5pbmc+IHNob3VsZCBvbmx5IGNv bnRhaW4gY2xpZW50LXByb3ZpZGVkDQo+IGNvbmZpZywgcmlnaHQ/DQoNCisxDQoNCk9yIGF0IGxl YXN0IHRoZSBjbGllbnRzIChvciBhdCBsZWFzdCBvcGVyYXRvcnMgb2YgYSBuZXR3b3JrIGVsZW1l bnQpIHNob3VsZCBoYXZlIHRoZSBvcHRpb24gb2YgYXZvaWRpbmcgYW55IGNvbmZpZyBhcHBlYXJp bmcgaW4gdGhlIHJ1bm5pbmcgYmVzaWRlcyB3aGF0IHRoZXkgcHV0IGluIHRoZXJlLg0KDQpJZiBj b25maWcgY2FuIG1hZ2ljYWxseSBhcHBlYXIgaW4gcnVubmluZywgSU1PIHRoYXQgc2hvdWxkIGJl IHNvbWUgb3B0aW9uYWwgYmVoYXZpb3IgdGhhdCBjYW4gYmUgdHVybmVkIG9mZiAob3Igc3BlY2lm aWNhbGx5IHJlcXVlc3RlZCB2aWEgY29uZmlnLCBvciBSUENzKS4NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgS2VudCBXYXRzZW4NCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyOSwgMjAy MSA1OjUwIFBNDQo+IFRvOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4NCj4gQ2M6 IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gU2hvdWxkIHRoZSBvcmln aW49InN5c3RlbSIgYmUgcmVxdWlyZWQgZm9yIHN5c3RlbQ0KPiBjb25maWd1cmF0aW9ucyBjb3Bp ZWQvcGFzdGVkIGludG8gPHJ1bm5pbmc+Pw0KPiANCj4gSGkgQW5keSwNCj4gDQo+ID4gUkZDIDc5 NTAgcnVsZXMgYWJvdXQgbGVhZnJlZiB2YWxpZGF0aW9uIGFyZSB2ZXJ5IGNsZWFyLg0KPiA+IEFk ZGluZyBhIG5ldyBkYXRhc3RvcmUgdG8gdGhlc2UgcnVsZXMgcmVxdWlyZXMgYSBtYXNzaXZlIGNo YW5nZSB0byBOTURBDQo+ID4gYW5kIGFsbCBpbXBsZW1lbnRhdGlvbnMuDQo+IA0KPiBOb3QgcmVh bGx5IG9yLCByYXRoZXIsIGl0IHNlZW1zIGxpa2UgaXQgd291bGQgYmUganVzdCBwYXJ0IG9mIGFk ZGluZyBzdXBwb3J0IGZvcg0KPiA8c3lzdGVtPiwgd2hpY2ggaW1wbGllcyBhZGRpbmcgc3VwcG9y dCBmb3IgPGludGVuZGVkPiAoaWYgbm90IHN1cHBvcnRlZA0KPiBhbHJlYWR5KSBhbmQgZG9pbmcg dGhlIHZhbGlkYXRpb24gb24gPGludGVuZGVkPiBpbnN0ZWFkLg0KPiANCj4gDQo+ID4gMikgQXMg SnVlcmdlbiBwb2ludHMgb3V0LCBzZXJ2ZXJzIHBvcHVsYXRlIHRoZSBzeXN0ZW0gY29uZmlnIGlu IDxydW5uaW5nPg0KPiBhbmQgdGhlIG9wZXJhdG9yIGlzDQo+ID4gZnJlZSB0byBpZ25vcmUgaXQs IHJlZmVyZW5jZSBpdCwgb3IgcG9zc2libHkgY2hhbmdlIGl0LiAgVGhlIHByZW1pc2Ugb2YNCj4g PHN5c3RlbT4gc2VlbXMgdG8NCj4gPiBiZSB0aGF0IHRoaXMgYXBwcm9hY2ggaXMgbm90ICJwdXJl IGVub3VnaCIgZm9yIE5NREEgYW5kIDxydW5uaW5nPiBNVVNUDQo+IG9ubHkgY29udGFpbg0KPiA+ IG9wZXJhdG9yLWNyZWF0ZWQgY29uZmlndXJhdGlvbi4gV2h5PyBXaGF0IHJlYWwgcHJvYmxlbXMg d291bGQgdGhpcw0KPiBjaGFuZ2Ugc29sdmU/DQo+IA0KPiBTZXJ2ZXJzIHBvcHVsYXRpbmcgPHJ1 bm5pbmc+IChiZXlvbmQgY29waW5nIDxzdGFydHVwPiBpbnRvIDxydW5uaW5nPikgaGFzDQo+IG5l dmVyIGJlZW4gYSBzdXBwb3J0ZWQgaWRlYS4gIFdl4oCZdmUgYWx3YXlzIG1haW50YWluZWQgdGhh dCA8cnVubmluZz4NCj4gc2hvdWxkIG9ubHkgY29udGFpbiBjbGllbnQtcHJvdmlkZWQgY29uZmln LCByaWdodD8NCj4gDQo+IEnigJltIHVuc3VyZSB3aGF0IHRoZSDigJxjaGFuZ2XigJ0gaW4geW91 ciBsYXN0IHF1ZXN0aW9uIHBvaW50cyB0by4gIEJ1dCBub3RlIHRoYXQNCj4gb24gSlVOT1MtYmFz ZWQgc3lzdGVtcywgdGhlcmUgYXJlIG1hbnkgaHVuZHJlZHMgb2Ygc3lzdGVtLWRlZmluZWQNCj4g bm9kZXMgYXZhaWxhYmxlIHRvIGJlIHJlZmVyZW5jZWQgYnkgY29uZmlnIGluIDxydW5uaW5nPi4g IFB1dHRpbmcgYWxsIHRoZXNlDQo+IG5vZGVzIGludG8gPHJ1bm5pbmc+IHdvdWxkIGNsdXR0ZXIg dGhlIGNvbmZpZyBpbW1lbnNlbHkuDQo+IA0KPiBGV0lXLCBKVU5PUyDigJxzb2x2ZXPigJ0gdGhp cyBieSAqaGlkaW5nKiB0aGVzZSBzeXN0ZW0tbm9kZXMsIHN1Y2ggdGhhdA0KPiBjbGllbnRzIG11 c3QgdXNlIGEgc3BlY2lhbCBjb21tYW5kIGp1c3QgdG8gZGlzY292ZXIgdGhlbS4gICBBbmQsIHll cywgaWYgZXZlcg0KPiBhbnkgb2YgdGhlc2UgYXJlIGhpZGRlbi1ub2RlcyBhcmUgcmVmZXJlbmNl LCBvZmZsaW5lLXZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+DQo+IHdpbGwgZmFpbC4gIFRoZSA8c3lz dGVtPiBkYXRhc3RvcmUgYmVpbmcgZGlzY3Vzc2VkIGVmZmVjdGl2ZWx5IG1pbWljcyB0aGlzDQo+ IGFzcGVjdCBvZiB0aGUgSlVOT1Mgc29sdXRpb24uDQo+IA0KPiBUaGVyZSBpcyBhIHNlcGFyYXRl IHRocmVhZCBmb3IgaWYgKm9mZmxpbmUqIHZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+ICphbG9uZSoN Cj4gbXVzdCBzdWNjZWVkLiAgVGhlIHNvZnQgKGZhbGxiYWNrKSBzb2x1dGlvbiBpcyB0byBoYXZl IGNsaWVudHMgY29weS9wYXN0ZSB0aGUNCj4gcmVmZXJlbmNlZC1zdWJzZXQgb2YgdGhlIHN5c3Rl bS1kZWZpbmVkIG5vZGVzIGludG8gPHJ1bm5pbmc+LiAgVGhlIHRoZW9yeQ0KPiBiZWluZyB0aGF0 LCBzaW5jZSBpdOKAmXMganVzdCBhIHN1YnNldCwgaXQgd29u4oCZdCBjbHV0dGVyIHRoaW5ncyB1 cCB0b28gYmFkbHkgYW5kLCBhcw0KPiBpdCBpcyBhbHJlYWR5IHRoZSBjYXNlIHRoYXQgc29tZSBz eXN0ZW0tZGVmaW5lZCBub2RlcyBtdXN0IGJlIGNvcHkvcGFzdGVkDQo+IGludG8gPHJ1bm5pbmc+ IGluIG9yZGVyIGZvciBjbGllbnRzIHRvIGNvbmZpZ3VyZSBkZXNjZW5kZW50IG5vZGVzIChlLmcu LCBzb21lDQo+IHR1bmFibGUgZm9yIHRoZSBzeXN0ZW0tZGVmaW5lZCDigJxsb+KAnSBpbnRlcmZh Y2UpLCB0aGUgd2F0ZXIgaXMgYWxyZWFkeSBvdmVyIHRoZQ0KPiBicmlkZ2UsIHNvIHRvIHNwZWFr LCBvbiB0aGUgY29weS9wYXN0aW5nIGRlYmF0ZS4gIFRoZSBvbmx5IGhvbGRvdXQgIGZvciBub3QN Cj4gYWxyZWFkeSBkZW1hbmRpbmcgY2xpZW504oCZcyBhbHNvIGNvcHkvcGFzdGUgdGhlIHN1YnNl dCBvZiByZWZlcmVuY2VkIHN5c3RlbS0NCj4gZGVmaW5lZCBub2RlcyBpcyB0aGF0IGl0IGlzIGNv bXBsZXRlbHkgdW5uZWNlc3NhcnksIHVubGVzcyB0cnlpbmcgdG8gZW5zdXJlDQo+IG9mZmxpbmUg dmFsaWRhdGlvbiBvZiA8cnVubmluZz4gYWxvbmUuDQo+IA0KPiANCj4gDQo+ID4gQW5keQ0KPiAN Cj4gS2VudCwgYXMgYSBjb250cmlidXRvci4NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K PiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCg== From nobody Thu Dec 9 08:31: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 C0C793A0E8F for ; Thu, 9 Dec 2021 08:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 vko-tPgaiJHo for ; Thu, 9 Dec 2021 08:31:09 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2094.outbound.protection.outlook.com [40.107.236.94]) (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 E202F3A0E8E for ; Thu, 9 Dec 2021 08:31:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mxe59DsuAmzsPYtTh6+/cr9y93QHP+HoczVGHKRQ4d1UFHOcumhdNyVPsyymkviWCicSiSopcsAUv7rFdiUBxV+xZQnZoxq24FYiXPK5ra5SQSVBHxJ/F8GJs2gsBBXvvmLcAqudjzPDtAqDj3DIgbPoWh7gd5aMGXyC+RU/8BuXp9avdAkuw2qQV2JjMcVuUYrC+sR2/iWK6PNpQ7SPeNLByC+f5svgt6/2lBFKo/bxoxyBzp7Xkzqfg1alEmzhAsinSTxZrJ+ZOVzqoBb7D9q08NHO8vuHJKaLCFM3F94JaiWyVUp+fhTr7Gyuw+89odF3BI938cyE6AkKZ16MhQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XivKGqZVxi8ofeXfjAlnzGQKDgnZMNZBiNDrkXO+6Wo=; b=jnCrQv0GGoW//f/anUKhqh69VjZI0bE7JOC15PF77HFt5Ze7TDg9HafzN1Cw7cGBdcADKexm3rhMLtC0TcwvZ1ZVsQAXkrMdAfTUTPfX8RHZC72/TN2elHM2TJwJ2gZMKlkY8Q5D7LChkYtIA4kPA+G3XGHa7iKSMKliP42IO9DJZnayDnsV5TxP5bGSD+CDkHeI+q05aj0SuBcV9Z9yDp2P3IHk35jbXYxDx78UFFU4eJ7H3x9PpboahuuHPMYWk78Sv6CZz1VH1u3yF5d9MaQHU5nux/C79y48s1kDTuvvmKhTAPDR6MzxtvW2hOWFN9ZSGgdHPbpC8eFft3vLeQ== 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=XivKGqZVxi8ofeXfjAlnzGQKDgnZMNZBiNDrkXO+6Wo=; b=qLos+v1/G3Ao+mhm6CmiLIBOAj/ZmHQcZv1ARu+53VC5v8cZOX4RYnT7qJaaRULg9BMEWPAR+CbPtQbz7qPBgaXHB1yQgAh7HavnpStix5LkoyJZe4B7NSPfrYLr0MWidzK6DTyGVOj3IYWKyUAg1sLGavw5JqrIiAJYqQ49IJU= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB4089.namprd08.prod.outlook.com (2603:10b6:5:8a::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Thu, 9 Dec 2021 16:31:05 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 16:31:05 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Kent Watsen , Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? Thread-Index: AQHX7RooVtMRYIzeTpCisQ2IqIgmxw== Date: Thu, 9 Dec 2021 16:31:05 +0000 Message-ID: References: <20211124.114340.856721981810780593.id@4668.se> <20211125114733.phenv7mktyed6d4v@anna> <20211125.130155.1636018839435459937.id@4668.se> <20211125130128.ogpuzktbdyp6yydj@anna> <0100017d6de3a63d-89d0e981-5347-47be-9779-52d70ccbcda6-000000@email.amazonses.com> In-Reply-To: <0100017d6de3a63d-89d0e981-5347-47be-9779-52d70ccbcda6-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8e39eec8-68ac-4f14-e023-08d9bb314c42 x-ms-traffictypediagnostic: DM6PR08MB4089:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hv7VaM5f+AkiMHnv1oZRPOG4YHZhJUpDh7jrbDPJB5UE7VnUA2joJBBQGFabhDIzvYz9eKbnQqNVpOLDYEiwUDDcESljoVl5YtJsvXcV5fqsja1M4BES4yNHguZ8q83mo0vtiWhc7/L23UQw75wNKPJwDWLXiONwiUUunDKoh1vKIWuhRBHbkofV6JunNc92+MhKd7YE6Ma2u/HL/pJ+K+H8G9q2vAhr/EkMb6+NKVYWBAaBRJTBZb4CgMPXkdry3fYnR4sMk0poajuTQN4b/zIPHjKr2XouRkWSzlH4taT78GvHYEpAR8RVFjWffOpVmwWbJ7VSaOMwhwIf8kxiDXXYJDCCINnaZTotvSwtoix842hIe9RfXXb2v71Tg/kVQkDLdpoTaUNjSKF5xxHJwmxa1e2+bbdIz1rfmljod7vI5/n8JJM9DSiESHX2udabwBl4pb7AfUdczfBKnxywDZ8CAu8SB5PZ+aNIsixKsA0RxOp+QzFLN5hvWEJqPjicJNQ46qBj5lFjaDNcKKnzUkZA8Xl7lguBRiaLZve5pIR6dsrxktSgWyNwOdXpxJ16lLiA6pH0+Ql7A1Z0zxeBcHIzgCzpLbOvXoBiPQIoAXm7msgcyW1WreWOGvMGbBXYYJviYQrnJ4stoY/MVQqqUm2FPt2wtwo2h7NsP0fbmSx6tzeYARbtz2MSY6YFOXEOTTtMQO1Nr6cKvSHgjPXp9zG5Jg/n6dgtbYWdi/EkkVacmYbLMK224qnnJf25nQymg9AYObdHSZuDk5qfi2KuRieUq8bQTs3YToEmhIMhYAw= 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)(366004)(508600001)(66556008)(66946007)(52536014)(9686003)(122000001)(38100700002)(8676002)(186003)(966005)(5660300002)(110136005)(66476007)(83380400001)(316002)(76116006)(4326008)(66446008)(71200400001)(8936002)(82960400001)(86362001)(55016003)(64756008)(6506007)(38070700005)(7696005)(26005)(2906002)(33656002)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NjhmYXNCZkpBRm5uQmNhVTZ3Zkc1K3JLVW5ING0vNnZnZHFqYnB1WVpLcFlE?= =?utf-8?B?Qk9qQlBwTno2NE5Wa1QwQXd6ZDh1eTFHSFhoeDM0dzliYXdtRHVCWXJNblJs?= =?utf-8?B?WHNGUlFsNkRkSzlYOEJNalhrSyt5ZlFqZFY2RHNYa3VsbGhlVjJQeXJxaVpa?= =?utf-8?B?N3hHM3d2dlhHejdnSGtmWHdnZFR5NmR1TzBnWndFanBzbkxKeGtwTU95L3pW?= =?utf-8?B?cUJhc1pvT0ZmdkpOd2xQL3lneXZVVW9IdXovRXBtcFJ0bmwyOFdyeE0zUmZS?= =?utf-8?B?bDhjc0VZVVh2REFEQkJ3RWNja1RTYXFRYlJuZ3JQWU1teDA3R2V4Z0lkZDAy?= =?utf-8?B?ejZWaXA5M1NieWE1L1dhNVdxYzhzSEZpSERmMW5XZC9UUmsrZzhkeDd0ek16?= =?utf-8?B?WTNWOVNzZFYyZi9hSCtnMGZFMUYwcitXc2xoRHNvVjVtdHpEVSt5S2o5WU1S?= =?utf-8?B?dXNUbXVLUUNGbG1kM0tabWxCM1M3bXI1djAxSGVFbUV1MSsrNDFXVmx2U2kx?= =?utf-8?B?dHEzdHZZaGx0c3lJdmI5NjUxeFdQUGNXcWVIWkRkY3E0a3JsaFVJS0htUzhp?= =?utf-8?B?eEZjQU9NUTYyT3dpUzZTUklGWnNEb3VJaGFRRHdoOWtZNW1scTkvY0c0VzBi?= =?utf-8?B?dDhLaE9MSnJKbnZoSyt5anlKVVEyd25OL2kvVXI2aTBXSmhSQ0xFb1JDZ3Jm?= =?utf-8?B?dWJHZ2xJenk3dHo4d2haOGcwREpzM2hMclJualRXTU9xR2t4eGdreE16L0Np?= =?utf-8?B?Vmw3MVBxaktSc3ZMKytnU01pVE9wSlA5UzhXL1BpZjZId1Jpb0xwZmczcWt3?= =?utf-8?B?TExHUnp5Tlp0N08vQ3dOVkpSdWVLZGpXZy95dGpRKzJGR29TKzkrVTBXZDRp?= =?utf-8?B?WGdJQUJud1lRUHZjSEZKTVplM2RpZndSbmdBRnQvSm1zbmR3Z1ZFK1NJNEx2?= =?utf-8?B?TkxPMjFxa1VWU1l0cm1nRkxFZWVhV1lNVnJtY2dzenM4d3B3ZjcxV0tXTUIx?= =?utf-8?B?Wk4ySFJqTUtMU05jSDNpVXU2L1NUN256Zk9WUFBWc3dqRURwdmpWaXZKUi9i?= =?utf-8?B?TkRoYU1EOW9LeHg5eDRwMUxqejRXc3JQaE1sSkVBZ0JmUDF3aUxnV3JJd25T?= =?utf-8?B?RkUvTjRPNXllcEp5b09iUmJia0VHdWNNN3ArbHFOcDdRVXJKZVpwYXUwakUz?= =?utf-8?B?c0UyZ2pHcW9vZkN0anJzQVlkZW1xM05sQk1sMFp0aWJhUHB2MG5TajYvZ0t1?= =?utf-8?B?SkpVajRUN3VYT1JHOHR2aFFiWEUvcjA3NnNURVVSZVloOVhPOWNnS0hyZ1cw?= =?utf-8?B?QTFISGp3dkFPcFlqdmhpRFFkdnpDK2pYd0R1d2VEZzhtQ3BNNnRyQkdFSFZL?= =?utf-8?B?eXowelNuMldmK21lM09ab1MvYXZ4MEtkcXRBa1dwY2RuK3RmTkhucWZLYVNI?= =?utf-8?B?TTdRUUVIcDBmb01xM3RXYm11Sjg3OW5hOEo5VTJDQVZRTnVzUnFocDhWOTJx?= =?utf-8?B?L2ZQRFdkTHpaTW0vQkhFSDN5THZhcW5heVpyOU1BNDVybDRXSStnSFFsWGRN?= =?utf-8?B?MEM2N0ZVVzk5OUs3ZFFmZFdPY2d3YXZTV2V2QVh2NXpUV1A2VXJzL2VycmRv?= =?utf-8?B?ZCtDT3laeUNvR0RvYnZaUmVOWmJ0VmsxWndyM0Z4TStmTFJ0WXRTQXMzMHhn?= =?utf-8?B?TTBoQWJGTHQ4OXNlUFFXRDEwUlI0c2RVZmRacjZ4blRTYzJXSXVLVXVOS205?= =?utf-8?B?UTU0cktIWkFRVVltRzAvSTJsemt4S1ZTb25VZjQ4NnhDY2VycVFvbVRvWURW?= =?utf-8?B?dFB1N044ZWk2Uks0dVBYMDBOM3lpRHFVMmRrd043bUZqOVh4cCtKenZ3N2pv?= =?utf-8?B?QXR1TktCcHdQR2RxQnNJdDV5T3JhT1IvUGJWTmNvWFcwSDRmcjBBZ3VNVGti?= =?utf-8?B?MzJsdThvUUs5b0NDbHdpM3dkRHJBdVZ4WnRYUms4eCs1WXFiMmRLVVVOUzNM?= =?utf-8?B?TlNpS0VJUHhLSi9teHdLMXRDMC9oU3Y3YjR2WG9VZnozWm5wdHNZUGIrTThl?= =?utf-8?B?elI3Rk9BTlRUaEM4cUVVMjNkNmtXZUEyVGVLaW11a1lBZ1NSc3Fhd3lydzFI?= =?utf-8?B?elB6cDQ4SVZUVE5jeS9yUGVuWTlweUR5Tk85R3RzWmxabzJrMmlNSlQrWGw3?= =?utf-8?B?UUE9PQ==?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: 8e39eec8-68ac-4f14-e023-08d9bb314c42 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 16:31:05.6129 (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: o+ClDuNZZBfdQZnUEqNsJJEJ75k0Skcd9HS6FtvxH2qt3vtq8RVIZF23z4MDtHY/4ZpBJCuGeB+2lP0vWdrMzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4089 Archived-At: Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? 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, 09 Dec 2021 16:31:14 -0000 PiBGV0lXLCBKVU5PUyDigJxzb2x2ZXPigJ0gdGhpcyBieSAqaGlkaW5nKiB0aGVzZSBzeXN0ZW0t bm9kZXMsIHN1Y2ggdGhhdA0KPiBjbGllbnRzIG11c3QgdXNlIGEgc3BlY2lhbCBjb21tYW5kIGp1 c3QgdG8gZGlzY292ZXIgdGhlbS4gICBBbmQsIHllcywgaWYgZXZlcg0KPiBhbnkgb2YgdGhlc2Ug YXJlIGhpZGRlbi1ub2RlcyBhcmUgcmVmZXJlbmNlLCBvZmZsaW5lLXZhbGlkYXRpb24gb2YgPHJ1 bm5pbmc+DQo+IHdpbGwgZmFpbC4gIA0KDQpPdGhlciBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBhIHNp bWlsYXIgY29uY2VwdCB3aXRoIHRoZSBzYW1lIGNvbnNlcXVlbmNlLg0KDQo+IFRoZSA8c3lzdGVt PiBkYXRhc3RvcmUgYmVpbmcgZGlzY3Vzc2VkIGVmZmVjdGl2ZWx5IG1pbWljcyB0aGlzDQo+IGFz cGVjdCBvZiB0aGUgSlVOT1Mgc29sdXRpb24uDQo+IA0KPiBUaGVyZSBpcyBhIHNlcGFyYXRlIHRo cmVhZCBmb3IgaWYgKm9mZmxpbmUqIHZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+ICphbG9uZSoNCj4g bXVzdCBzdWNjZWVkLiAgVGhlIHNvZnQgKGZhbGxiYWNrKSBzb2x1dGlvbiBpcyB0byBoYXZlIGNs aWVudHMgY29weS9wYXN0ZSB0aGUNCj4gcmVmZXJlbmNlZC1zdWJzZXQgb2YgdGhlIHN5c3RlbS1k ZWZpbmVkIG5vZGVzIGludG8gPHJ1bm5pbmc+LiAgVGhlIHRoZW9yeQ0KPiBiZWluZyB0aGF0LCBz aW5jZSBpdOKAmXMganVzdCBhIHN1YnNldCwgaXQgd29u4oCZdCBjbHV0dGVyIHRoaW5ncyB1cCB0 b28gYmFkbHkgYW5kLCBhcw0KPiBpdCBpcyBhbHJlYWR5IHRoZSBjYXNlIHRoYXQgc29tZSBzeXN0 ZW0tZGVmaW5lZCBub2RlcyBtdXN0IGJlIGNvcHkvcGFzdGVkDQo+IGludG8gPHJ1bm5pbmc+IGlu IG9yZGVyIGZvciBjbGllbnRzIHRvIGNvbmZpZ3VyZSBkZXNjZW5kZW50IG5vZGVzIChlLmcuLCBz b21lDQo+IHR1bmFibGUgZm9yIHRoZSBzeXN0ZW0tZGVmaW5lZCDigJxsb+KAnSBpbnRlcmZhY2Up LCB0aGUgd2F0ZXIgaXMgYWxyZWFkeSBvdmVyIHRoZQ0KPiBicmlkZ2UsIHNvIHRvIHNwZWFrLCBv biB0aGUgY29weS9wYXN0aW5nIGRlYmF0ZS4gIFRoZSBvbmx5IGhvbGRvdXQgIGZvciBub3QNCj4g YWxyZWFkeSBkZW1hbmRpbmcgY2xpZW504oCZcyBhbHNvIGNvcHkvcGFzdGUgdGhlIHN1YnNldCBv ZiByZWZlcmVuY2VkIHN5c3RlbS0NCj4gZGVmaW5lZCBub2RlcyBpcyB0aGF0IGl0IGlzIGNvbXBs ZXRlbHkgdW5uZWNlc3NhcnksIHVubGVzcyB0cnlpbmcgdG8gZW5zdXJlDQo+IG9mZmxpbmUgdmFs aWRhdGlvbiBvZiA8cnVubmluZz4gYWxvbmUuDQoNClllcyAtIHNvIG9ubHkgdXNlcnMvY2xpZW50 cyB3aXRoIHRoaXMgcmVxdWlyZW1lbnQgd291bGQgbmVlZCB0byBleHBsaWNpdGx5IGNvbmZpZ3Vy ZSB0aGUgcmVmZXJlbmNlZCBzdWJzZXQuIEFueW9uZSBlbHNlIGNhbiBqdXN0IGRvIG5vdGhpbmcg YW5kIGNvbnRpbnVlIG9uIGFzIHRoZXkgZG8gdG9kYXkuDQoNCkphc29uDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9y Zz4gT24gQmVoYWxmIE9mIEtlbnQgV2F0c2VuDQo+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjks IDIwMjEgNTo1MCBQTQ0KPiBUbzogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQo+ IENjOiBuZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFNob3VsZCB0aGUg b3JpZ2luPSJzeXN0ZW0iIGJlIHJlcXVpcmVkIGZvciBzeXN0ZW0NCj4gY29uZmlndXJhdGlvbnMg Y29waWVkL3Bhc3RlZCBpbnRvIDxydW5uaW5nPj8NCj4gDQo+IEhpIEFuZHksDQo+IA0KPiA+IFJG QyA3OTUwIHJ1bGVzIGFib3V0IGxlYWZyZWYgdmFsaWRhdGlvbiBhcmUgdmVyeSBjbGVhci4NCj4g PiBBZGRpbmcgYSBuZXcgZGF0YXN0b3JlIHRvIHRoZXNlIHJ1bGVzIHJlcXVpcmVzIGEgbWFzc2l2 ZSBjaGFuZ2UgdG8gTk1EQQ0KPiA+IGFuZCBhbGwgaW1wbGVtZW50YXRpb25zLg0KPiANCj4gTm90 IHJlYWxseSBvciwgcmF0aGVyLCBpdCBzZWVtcyBsaWtlIGl0IHdvdWxkIGJlIGp1c3QgcGFydCBv ZiBhZGRpbmcgc3VwcG9ydCBmb3INCj4gPHN5c3RlbT4sIHdoaWNoIGltcGxpZXMgYWRkaW5nIHN1 cHBvcnQgZm9yIDxpbnRlbmRlZD4gKGlmIG5vdCBzdXBwb3J0ZWQNCj4gYWxyZWFkeSkgYW5kIGRv aW5nIHRoZSB2YWxpZGF0aW9uIG9uIDxpbnRlbmRlZD4gaW5zdGVhZC4NCj4gDQo+IA0KPiA+IDIp IEFzIEp1ZXJnZW4gcG9pbnRzIG91dCwgc2VydmVycyBwb3B1bGF0ZSB0aGUgc3lzdGVtIGNvbmZp ZyBpbiA8cnVubmluZz4NCj4gYW5kIHRoZSBvcGVyYXRvciBpcw0KPiA+IGZyZWUgdG8gaWdub3Jl IGl0LCByZWZlcmVuY2UgaXQsIG9yIHBvc3NpYmx5IGNoYW5nZSBpdC4gIFRoZSBwcmVtaXNlIG9m DQo+IDxzeXN0ZW0+IHNlZW1zIHRvDQo+ID4gYmUgdGhhdCB0aGlzIGFwcHJvYWNoIGlzIG5vdCAi cHVyZSBlbm91Z2giIGZvciBOTURBIGFuZCA8cnVubmluZz4gTVVTVA0KPiBvbmx5IGNvbnRhaW4N Cj4gPiBvcGVyYXRvci1jcmVhdGVkIGNvbmZpZ3VyYXRpb24uIFdoeT8gV2hhdCByZWFsIHByb2Js ZW1zIHdvdWxkIHRoaXMNCj4gY2hhbmdlIHNvbHZlPw0KPiANCj4gU2VydmVycyBwb3B1bGF0aW5n IDxydW5uaW5nPiAoYmV5b25kIGNvcGluZyA8c3RhcnR1cD4gaW50byA8cnVubmluZz4pIGhhcw0K PiBuZXZlciBiZWVuIGEgc3VwcG9ydGVkIGlkZWEuICBXZeKAmXZlIGFsd2F5cyBtYWludGFpbmVk IHRoYXQgPHJ1bm5pbmc+DQo+IHNob3VsZCBvbmx5IGNvbnRhaW4gY2xpZW50LXByb3ZpZGVkIGNv bmZpZywgcmlnaHQ/DQo+IA0KPiBJ4oCZbSB1bnN1cmUgd2hhdCB0aGUg4oCcY2hhbmdl4oCdIGlu IHlvdXIgbGFzdCBxdWVzdGlvbiBwb2ludHMgdG8uICBCdXQgbm90ZSB0aGF0DQo+IG9uIEpVTk9T LWJhc2VkIHN5c3RlbXMsIHRoZXJlIGFyZSBtYW55IGh1bmRyZWRzIG9mIHN5c3RlbS1kZWZpbmVk DQo+IG5vZGVzIGF2YWlsYWJsZSB0byBiZSByZWZlcmVuY2VkIGJ5IGNvbmZpZyBpbiA8cnVubmlu Zz4uICBQdXR0aW5nIGFsbCB0aGVzZQ0KPiBub2RlcyBpbnRvIDxydW5uaW5nPiB3b3VsZCBjbHV0 dGVyIHRoZSBjb25maWcgaW1tZW5zZWx5Lg0KPiANCj4gRldJVywgSlVOT1Mg4oCcc29sdmVz4oCd IHRoaXMgYnkgKmhpZGluZyogdGhlc2Ugc3lzdGVtLW5vZGVzLCBzdWNoIHRoYXQNCj4gY2xpZW50 cyBtdXN0IHVzZSBhIHNwZWNpYWwgY29tbWFuZCBqdXN0IHRvIGRpc2NvdmVyIHRoZW0uICAgQW5k LCB5ZXMsIGlmIGV2ZXINCj4gYW55IG9mIHRoZXNlIGFyZSBoaWRkZW4tbm9kZXMgYXJlIHJlZmVy ZW5jZSwgb2ZmbGluZS12YWxpZGF0aW9uIG9mIDxydW5uaW5nPg0KPiB3aWxsIGZhaWwuICBUaGUg PHN5c3RlbT4gZGF0YXN0b3JlIGJlaW5nIGRpc2N1c3NlZCBlZmZlY3RpdmVseSBtaW1pY3MgdGhp cw0KPiBhc3BlY3Qgb2YgdGhlIEpVTk9TIHNvbHV0aW9uLg0KPiANCj4gVGhlcmUgaXMgYSBzZXBh cmF0ZSB0aHJlYWQgZm9yIGlmICpvZmZsaW5lKiB2YWxpZGF0aW9uIG9mIDxydW5uaW5nPiAqYWxv bmUqDQo+IG11c3Qgc3VjY2VlZC4gIFRoZSBzb2Z0IChmYWxsYmFjaykgc29sdXRpb24gaXMgdG8g aGF2ZSBjbGllbnRzIGNvcHkvcGFzdGUgdGhlDQo+IHJlZmVyZW5jZWQtc3Vic2V0IG9mIHRoZSBz eXN0ZW0tZGVmaW5lZCBub2RlcyBpbnRvIDxydW5uaW5nPi4gIFRoZSB0aGVvcnkNCj4gYmVpbmcg dGhhdCwgc2luY2UgaXTigJlzIGp1c3QgYSBzdWJzZXQsIGl0IHdvbuKAmXQgY2x1dHRlciB0aGlu Z3MgdXAgdG9vIGJhZGx5IGFuZCwgYXMNCj4gaXQgaXMgYWxyZWFkeSB0aGUgY2FzZSB0aGF0IHNv bWUgc3lzdGVtLWRlZmluZWQgbm9kZXMgbXVzdCBiZSBjb3B5L3Bhc3RlZA0KPiBpbnRvIDxydW5u aW5nPiBpbiBvcmRlciBmb3IgY2xpZW50cyB0byBjb25maWd1cmUgZGVzY2VuZGVudCBub2RlcyAo ZS5nLiwgc29tZQ0KPiB0dW5hYmxlIGZvciB0aGUgc3lzdGVtLWRlZmluZWQg4oCcbG/igJ0gaW50 ZXJmYWNlKSwgdGhlIHdhdGVyIGlzIGFscmVhZHkgb3ZlciB0aGUNCj4gYnJpZGdlLCBzbyB0byBz cGVhaywgb24gdGhlIGNvcHkvcGFzdGluZyBkZWJhdGUuICBUaGUgb25seSBob2xkb3V0ICBmb3Ig bm90DQo+IGFscmVhZHkgZGVtYW5kaW5nIGNsaWVudOKAmXMgYWxzbyBjb3B5L3Bhc3RlIHRoZSBz dWJzZXQgb2YgcmVmZXJlbmNlZCBzeXN0ZW0tDQo+IGRlZmluZWQgbm9kZXMgaXMgdGhhdCBpdCBp cyBjb21wbGV0ZWx5IHVubmVjZXNzYXJ5LCB1bmxlc3MgdHJ5aW5nIHRvIGVuc3VyZQ0KPiBvZmZs aW5lIHZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+IGFsb25lLg0KPiANCj4gDQo+IA0KPiA+IEFuZHkN Cj4gDQo+IEtlbnQsIGFzIGEgY29udHJpYnV0b3IuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxp c3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kDQo= From nobody Thu Dec 9 08:33: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 A04793A0A29 for ; Thu, 9 Dec 2021 08:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 4Bl1X5IfEmxw for ; Thu, 9 Dec 2021 08:33:16 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2099.outbound.protection.outlook.com [40.107.223.99]) (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 8CCA53A0F40 for ; Thu, 9 Dec 2021 08:33:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DXkDQtBLpLzAXa6qF1AzDlVX35nuzPEETxKTKssHLtW/y8Qkz6e7erJkFt+9XLEgWabPzkDJX6yqHYAvsv5WawKWJaE02WpkWivlyx/+aIEv0ErZwgatgBUaZb4WGQ3HcRAJtXzmjMiFJwwa27FEsfxyuO4bu8UV6s2qai+pWEA7LEadPocu0AULDkJUAtBOuhyz0LBywS4kCK3MjxM9GzDq3bzmE6vyZPxJxS6FraZ2Wmh+59NSyRK6qcuKvEXQZpJM7DsFCGls2ynA90sV8HGFr/joSnk2KGF4IMaM6Ekzmuzigbp4fFtDeuJLWgB9bTQcwbPBPfV31TEvG3kJNQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qd4bfAkVsuFkUUVmiV06qLnl1+otGlXWnhVzIjWGBJk=; b=RiExSFbtWZwenoTI2VEhLfqpZ/O9K12nngp/urzyWGr9+OXO+mdLJqxiie3ybPL7k/oh/sNQFOn1EowrAB2UCtp9CcZBwgJxJhMsxDZbZfbj42c+Nfj/teLflcRb873HQJNP/wBctmSGY0GdamY1YwBzkU0YuTEYfhOtkq6IuUh/OWKoXeCyP7tQeg+JfAVRCc63pORGzmGAj9En3WgZywINqVdMohGvhFftpWlqlEAzOzuBdwPtEygmCthCOWcllR272tAHxNXTlQC406qhvRsGhEQtudxaIi40y8no5v6OW0NLm3v3ZXPAoAwj+XM4CtOP4euTAjbIHn+scF9iHQ== 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=qd4bfAkVsuFkUUVmiV06qLnl1+otGlXWnhVzIjWGBJk=; b=F7dA4/vCGPotutnsrlAXkElilJml/bK99QvnlPLpO8QVZxkYDzMsnVKXe0WqxVe7egDHHDJCwuO1skMiJirhZitBhrMoXZ9EVUZaCUbVLHuDbJw9si2McwV3IUkMQlaA6ieSW8C45bNi24Jl9lzApzdFvQ1pBJ+DzqzaIljmzp0= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB4699.namprd08.prod.outlook.com (2603:10b6:5:13::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Thu, 9 Dec 2021 16:33:07 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 16:33:07 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Andy Bierman , Kent Watsen CC: "netmod@ietf.org" Thread-Topic: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? Thread-Index: AQHX7RpxVtMRYIzeTpCisQ2IqIgmxw== Date: Thu, 9 Dec 2021 16:33:07 +0000 Message-ID: References: <20211124.114340.856721981810780593.id@4668.se> <20211125114733.phenv7mktyed6d4v@anna> <20211125.130155.1636018839435459937.id@4668.se> <20211125130128.ogpuzktbdyp6yydj@anna> <0100017d6de3a63d-89d0e981-5347-47be-9779-52d70ccbcda6-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1dde81fe-9fc0-4f34-4b41-08d9bb319518 x-ms-traffictypediagnostic: DM6PR08MB4699:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: M29Er0hU08yrDyAxOr1kKqQy7gTYqepHbrwFeMVax5l9M+gwsNOPAjpzYo877lGVs1pnUB06gHLaKz9Aa4oO8l9kRulLtMk37LwMvP/C0e5uxOQHe3Qn6+kM/UpEPvlYdWiPakY42QxYHeFwaOPrunpoRFMysJQLbJl7SlH+hYAWyrICxBJaFe2BhwPOAAmIJgx+c9sDfJL8pd0Ip+PV7nDkZ8pRNTMUclFU511rDktnXvhQ77s3f8z1sjY/OYjBlobrOUgnePSxc77imaKhbzHGgjFiaLYRMJDBoDAnDt9N64/HvSeJmYWBqnFttlsq6R63InBCAcGBCP1WxtSmvFBmd3EZEw6sRW4SySwyLq22gwixDsILMWNNdIp8ZTEXS55hqFG5s0X8IFHigS1ybErwu51W4eo3LdGZ6pdOhE7PnSr7mC49yoeawflFyCLRQDSU3SNxziilLCPUrdSPpdeZ6Ibr6ROHUm7dfiVQ/hHMDqdTUA1PgUtUNVElHPJd6dMNcQ7JiOV0uWtFsxCdjAYFPTo+qTUZy/PyRoRmbuKAUEhrxFxXq39P7JmmWdSofXRJrd/d+MW/g/pYrBa7P/IbQXXU72HqC9e1NS3jimxDlZX2WXEJbW05G80rP1G1zbBvUJSYpa+Kt2zOseshGcNmSq2nzaPsgesjiUEnbSDDbyPsM/T/zsGgpKJGzXfg320MSpCoUeDuVFlFKrDzzg== 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)(366004)(110136005)(66946007)(38100700002)(66556008)(508600001)(71200400001)(5660300002)(33656002)(38070700005)(9326002)(8936002)(4326008)(66476007)(66446008)(83380400001)(8676002)(122000001)(52536014)(55016003)(64756008)(76116006)(53546011)(86362001)(2906002)(82960400001)(26005)(316002)(7696005)(186003)(6506007)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SHJwY09heDlGdlh0K2l0Sy9uZjc2Vlh3Rm5lY0NjMXc1RHZnNnNTdStQWTdI?= =?utf-8?B?VXQ2Z0d4RmJXTXVrUGVDRk5yOHJENWlOcFdXeE1KR28zbERtUlJlU1B0bkp6?= =?utf-8?B?bGdPQXNTT2YyUms1aU1lQSszMjVaLzVVamR6cFVwNDk1OEt2ZG96TjcrWXZn?= =?utf-8?B?MU1RK1NXQ1BRQklVbUpQQnF1WFFMSUMxazM5TGJab1hyT3pHWkdVT0pDYmVM?= =?utf-8?B?RzIyT05JNlB1Qm56V0tZczltSndMcyt6SmJXSkNCWjRhbVgzT2kzTFMrWitj?= =?utf-8?B?blROMVZ0QUd1UmNqRnRmdVRuWU9KYjBOaXU0Tjlyenp3MGdWSmFNR01GUVRR?= =?utf-8?B?LzFYQTFVUDJXVy8wRE1aVTJYOWNGeWZacHNqWG8zN285OEZFUlVwSlRtSWFJ?= =?utf-8?B?UGR0eTIrVFAxVE83WjU3K1VOK0ZSOEZNQ0dGVGozMmQxZjkzYUU1ZFpiUkE5?= =?utf-8?B?YVNMMnN2b2dTOXBhR2QxS1FFZmJ0ZHlYdkY4RTVqeGZmU0Z2bUEyajJMdkZS?= =?utf-8?B?K3E2WnIwbEhWMXBLVEkrSUVvWVRGQXNnYURkMGtqVm1ySDFCMlhnbU9rSC8z?= =?utf-8?B?aEIwT1EzZGVuMEJCUTdjb0JJdU5Pc0ZkeDlMVlpJak1uS3VUQzE3SVJpVXlP?= =?utf-8?B?V1dCc1N1OVhkMzJJbHRtblN2SVprdDZ0cmlCQUdxSnhqYzd1NGpBb0tNaWNn?= =?utf-8?B?TDJPaWFZMWNFM2hCVWlFVzN5S3RESFU1WUl0Tkk0c0laRVpIYkJGUzVuamN6?= =?utf-8?B?Z0dZYUpsVTM0TTBoZmErTHpzM0tOa2JUK2dqZmhvVzZCTldKZGlzSW90SENY?= =?utf-8?B?YTkvRnFRQm1YNGNvVzd2a0JyK01NWS8wZXJXN1lxQ2I2SFF0RS9zSzN0UTlL?= =?utf-8?B?bUVMWDQwQWExckVoeGloc2p4WlNZdTBndFNRaTRXYWdHSjRmOU5sN08raTNr?= =?utf-8?B?ZVRXRDRUN1FjSEI0eDloZUFqNFRkM3p6MHBpdk1vdzhmM2xsUnNvd09xTVkw?= =?utf-8?B?emJTcUNDVUhUVTFQMCtlYUdRNHZzUnVlUGZ6SnNjbGQ0NlFCQ2tkMm9UNURF?= =?utf-8?B?dXQrYjFycUV4T21ZVWdCUSswSnEzbXFHV0VLOXBMVno1dm5kNkdOU1loVS81?= =?utf-8?B?UGdDYUV6NkUrRW9wNHo0MWlOMGhNN2kySlRPQktDcDdnZ040dnUwZkRobDZh?= =?utf-8?B?MWNPRU9zM1FzbWZFV052NHR2NS9vaUUvbHY1WkpxaVJGdnI1K2VJTFUzRUt2?= =?utf-8?B?bENKNWlMRlJFa3RaMHh4czEwNTVyU2REUzVvQldhREVZUkJNVUlYSDFzQTdl?= =?utf-8?B?UncwL0QvTnJkRzZzaG9xKzg1YWsyMDdWTnJWM0N5MlpuOVhGd2Z1K0l2aUw0?= =?utf-8?B?TVlBODA5MDlQQnVGc3R6OVBUd2xBZURNek9yUHVBQW1vOWVqWXlabDVmYWFw?= =?utf-8?B?dE40VVhlT1poeGV2Z1gvendFUGo3NnFSTk51bzk2Y1Qrb2sxbFdycEV1YjVw?= =?utf-8?B?U3BqR2kvTW1BZWU2NmlyamJNcVQrNmRnOWRKOUpjOTRaRmZHSnNlTFJZYU9s?= =?utf-8?B?N3IzL1U1UnhWOEtzUlRkTi9QaCtyZkR4aENWRGdvcWptendCemI4eTlrOXBP?= =?utf-8?B?Wk93M21vck9rQWJLdjRIYWpaZGV1VWp0TENvYmc2bCs5YjNONzJWNmc5VytF?= =?utf-8?B?ZFBzdVdmUm9xT0VpQjB0VXVDckZQUytmYVMwdk9iRXcwTWtUUTlqSGpaeXhV?= =?utf-8?B?dEx4K3Rkdlc4UWhnNE52R2ZYSGRhaGFqSkZGSFQzeG5ic0U3MjVjV2xLVWhL?= =?utf-8?B?TXg3ZUdmY1FNRDk5c3JGU3p2bE9QWVJWTVRhTlpBN2gxTnYvbExYWVB3Vyt3?= =?utf-8?B?aWYxZE9qbzNBY3ZEOGh4VDVqenBDSXYwR3NWTURIbkpGOHVxeXl1Ny9lYkxs?= =?utf-8?B?QW11eXpDRTBNRHdwbXo2RmZGZFVMWG5mdjZzcHY3K0xzQ0F5YkhybWFORHg0?= =?utf-8?B?OXloWnVrMXV6RnY4Z1FRUFg3ZkV4NFdtLzNHdEgydHFHdjdhSW9DdkJsSkJB?= =?utf-8?B?WUZWNFFTWkI5ZTNxczQ4TVc4a2JmdmNyUnhIMFdpRlU2SFgxM2JUa2Z6ZGpY?= =?utf-8?B?bTJEeXk0MjZvYXZCSVRFOWs2QmJ3WHB5ZEpKMDFuUjdXUXQ4dzRHRGpXZzVR?= =?utf-8?B?NHc9PQ==?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084FB588792F7F44A180BF89B709DM6PR08MB5084namp_" 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: 1dde81fe-9fc0-4f34-4b41-08d9bb319518 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 16:33:07.8065 (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: 6+6nrXXyNdwl9iafPKYsmcWtxomtkx9u9YQbE5h53usrCwxZUT1n6WAnGXZoej0zZCJCxq3SNpRVQaoPabWR1g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4699 Archived-At: Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? 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, 09 Dec 2021 16:33:21 -0000 --_000_DM6PR08MB5084FB588792F7F44A180BF89B709DM6PR08MB5084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhlIGFjdHVhbCBzeXN0ZW0gaW5zdGFuY2UgZGF0YSBpc24ndCBpbiBhIFlB TkcgbW9kZWwsIGJ1dCB0aGF0IGluc3RhbmNlIGRhdGEgc2l0cyBpbiBzY2hlbWEgZGVmaW5lZCBp biB0aGUgWUFORyBtb2RlbC4gSXQgaXMgdHlwaWNhbGx5IGEgbGlzdCBlbnRyeSBwb3B1bGF0ZWQg YnkgdGhlIHN5c3RlbS4gIEJ1dCB0aGVyZSBtYXkgYWxzbyBiZSBvdGhlciBsaXN0IGVudHJpZXMg Y3JlYXRlZCBieSB0aGUgdXNlcnMvY2xpZW50cywgYW5kIG90aGVyIGFyZWFzIG9mIHRoZSBZQU5H IG1vZGVsIG1heSByZWZlcmVuY2UgdGhvc2UgbGlzdHMgdXNpbmcgbGVhZnJlZnMuDQoNCkphc29u DQoNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBB bmR5IEJpZXJtYW4NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjksIDIwMjEgNjoxNCBQTQ0KVG86 IEtlbnQgV2F0c2VuIDxrZW50QHdhdHNlbi5uZXQ+DQpDYzogbmV0bW9kQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW25ldG1vZF0gU2hvdWxkIHRoZSBvcmlnaW49InN5c3RlbSIgYmUgcmVxdWlyZWQg Zm9yIHN5c3RlbSBjb25maWd1cmF0aW9ucyBjb3BpZWQvcGFzdGVkIGludG8gPHJ1bm5pbmc+Pw0K DQoNCg0KT24gTW9uLCBOb3YgMjksIDIwMjEgYXQgMjo0OSBQTSBLZW50IFdhdHNlbiA8a2VudEB3 YXRzZW4ubmV0PG1haWx0bzprZW50QHdhdHNlbi5uZXQ+PiB3cm90ZToNCkhpIEFuZHksDQoNCj4g UkZDIDc5NTAgcnVsZXMgYWJvdXQgbGVhZnJlZiB2YWxpZGF0aW9uIGFyZSB2ZXJ5IGNsZWFyLg0K PiBBZGRpbmcgYSBuZXcgZGF0YXN0b3JlIHRvIHRoZXNlIHJ1bGVzIHJlcXVpcmVzIGEgbWFzc2l2 ZSBjaGFuZ2UgdG8gTk1EQQ0KPiBhbmQgYWxsIGltcGxlbWVudGF0aW9ucy4NCg0KTm90IHJlYWxs eSBvciwgcmF0aGVyLCBpdCBzZWVtcyBsaWtlIGl0IHdvdWxkIGJlIGp1c3QgcGFydCBvZiBhZGRp bmcgc3VwcG9ydCBmb3IgPHN5c3RlbT4sIHdoaWNoIGltcGxpZXMgYWRkaW5nIHN1cHBvcnQgZm9y IDxpbnRlbmRlZD4gKGlmIG5vdCBzdXBwb3J0ZWQgYWxyZWFkeSkgYW5kIGRvaW5nIHRoZSB2YWxp ZGF0aW9uIG9uIDxpbnRlbmRlZD4gaW5zdGVhZC4NCg0KDQo+IDIpIEFzIEp1ZXJnZW4gcG9pbnRz IG91dCwgc2VydmVycyBwb3B1bGF0ZSB0aGUgc3lzdGVtIGNvbmZpZyBpbiA8cnVubmluZz4gYW5k IHRoZSBvcGVyYXRvciBpcw0KPiBmcmVlIHRvIGlnbm9yZSBpdCwgcmVmZXJlbmNlIGl0LCBvciBw b3NzaWJseSBjaGFuZ2UgaXQuICBUaGUgcHJlbWlzZSBvZiA8c3lzdGVtPiBzZWVtcyB0bw0KPiBi ZSB0aGF0IHRoaXMgYXBwcm9hY2ggaXMgbm90ICJwdXJlIGVub3VnaCIgZm9yIE5NREEgYW5kIDxy dW5uaW5nPiBNVVNUIG9ubHkgY29udGFpbg0KPiBvcGVyYXRvci1jcmVhdGVkIGNvbmZpZ3VyYXRp b24uIFdoeT8gV2hhdCByZWFsIHByb2JsZW1zIHdvdWxkIHRoaXMgY2hhbmdlIHNvbHZlPw0KDQpT ZXJ2ZXJzIHBvcHVsYXRpbmcgPHJ1bm5pbmc+IChiZXlvbmQgY29waW5nIDxzdGFydHVwPiBpbnRv IDxydW5uaW5nPikgaGFzIG5ldmVyIGJlZW4gYSBzdXBwb3J0ZWQgaWRlYS4gIFdl4oCZdmUgYWx3 YXlzIG1haW50YWluZWQgdGhhdCA8cnVubmluZz4gc2hvdWxkIG9ubHkgY29udGFpbiBjbGllbnQt cHJvdmlkZWQgY29uZmlnLCByaWdodD8NCg0KSeKAmW0gdW5zdXJlIHdoYXQgdGhlIOKAnGNoYW5n ZeKAnSBpbiB5b3VyIGxhc3QgcXVlc3Rpb24gcG9pbnRzIHRvLiAgQnV0IG5vdGUgdGhhdCBvbiBK VU5PUy1iYXNlZCBzeXN0ZW1zLCB0aGVyZSBhcmUgbWFueSBodW5kcmVkcyBvZiBzeXN0ZW0tZGVm aW5lZCBub2RlcyBhdmFpbGFibGUgdG8gYmUgcmVmZXJlbmNlZCBieSBjb25maWcgaW4gPHJ1bm5p bmc+LiAgUHV0dGluZyBhbGwgdGhlc2Ugbm9kZXMgaW50byA8cnVubmluZz4gd291bGQgY2x1dHRl ciB0aGUgY29uZmlnIGltbWVuc2VseS4NCg0KRldJVywgSlVOT1Mg4oCcc29sdmVz4oCdIHRoaXMg YnkgKmhpZGluZyogdGhlc2Ugc3lzdGVtLW5vZGVzLCBzdWNoIHRoYXQgY2xpZW50cyBtdXN0IHVz ZSBhIHNwZWNpYWwgY29tbWFuZCBqdXN0IHRvIGRpc2NvdmVyIHRoZW0uICAgQW5kLCB5ZXMsIGlm IGV2ZXIgYW55IG9mIHRoZXNlIGFyZSBoaWRkZW4tbm9kZXMgYXJlIHJlZmVyZW5jZSwgb2ZmbGlu ZS12YWxpZGF0aW9uIG9mIDxydW5uaW5nPiB3aWxsIGZhaWwuICBUaGUgPHN5c3RlbT4gZGF0YXN0 b3JlIGJlaW5nIGRpc2N1c3NlZCBlZmZlY3RpdmVseSBtaW1pY3MgdGhpcyBhc3BlY3Qgb2YgdGhl IEpVTk9TIHNvbHV0aW9uLg0KDQpUaGVyZSBpcyBhIHNlcGFyYXRlIHRocmVhZCBmb3IgaWYgKm9m ZmxpbmUqIHZhbGlkYXRpb24gb2YgPHJ1bm5pbmc+ICphbG9uZSogbXVzdCBzdWNjZWVkLiAgVGhl IHNvZnQgKGZhbGxiYWNrKSBzb2x1dGlvbiBpcyB0byBoYXZlIGNsaWVudHMgY29weS9wYXN0ZSB0 aGUgcmVmZXJlbmNlZC1zdWJzZXQgb2YgdGhlIHN5c3RlbS1kZWZpbmVkIG5vZGVzIGludG8gPHJ1 bm5pbmc+LiAgVGhlIHRoZW9yeSBiZWluZyB0aGF0LCBzaW5jZSBpdOKAmXMganVzdCBhIHN1YnNl dCwgaXQgd29u4oCZdCBjbHV0dGVyIHRoaW5ncyB1cCB0b28gYmFkbHkgYW5kLCBhcyBpdCBpcyBh bHJlYWR5IHRoZSBjYXNlIHRoYXQgc29tZSBzeXN0ZW0tZGVmaW5lZCBub2RlcyBtdXN0IGJlIGNv cHkvcGFzdGVkIGludG8gPHJ1bm5pbmc+IGluIG9yZGVyIGZvciBjbGllbnRzIHRvIGNvbmZpZ3Vy ZSBkZXNjZW5kZW50IG5vZGVzIChlLmcuLCBzb21lIHR1bmFibGUgZm9yIHRoZSBzeXN0ZW0tZGVm aW5lZCDigJxsb+KAnSBpbnRlcmZhY2UpLCB0aGUgd2F0ZXIgaXMgYWxyZWFkeSBvdmVyIHRoZSBi cmlkZ2UsIHNvIHRvIHNwZWFrLCBvbiB0aGUgY29weS9wYXN0aW5nIGRlYmF0ZS4gIFRoZSBvbmx5 IGhvbGRvdXQgIGZvciBub3QgYWxyZWFkeSBkZW1hbmRpbmcgY2xpZW504oCZcyBhbHNvIGNvcHkv cGFzdGUgdGhlIHN1YnNldCBvZiByZWZlcmVuY2VkIHN5c3RlbS1kZWZpbmVkIG5vZGVzIGlzIHRo YXQgaXQgaXMgY29tcGxldGVseSB1bm5lY2Vzc2FyeSwgdW5sZXNzIHRyeWluZyB0byBlbnN1cmUg b2ZmbGluZSB2YWxpZGF0aW9uIG9mIDxydW5uaW5nPiBhbG9uZS4NCg0KDQoNCg0KSU1PIHRoZSBs ZWFzdCBkaXNydXB0aXZlIHNvbHV0aW9uIHBvc3NpYmxlIHNob3VsZCBiZSB1c2VkLg0KVGhlcmUg aXMgYSB1c2UtY2FzZSBmb3IgYWRkaW5nICJvcmlnaW4iIHN1cHBvcnQgdG8gdGhlIDxydW5uaW5n PiBkYXRhc3RvcmUgaW4gdGhlIDxnZXQtZGF0YT4gb3BlcmF0aW9uLg0KVGhpcyBhbGxvd3MgYW4g Tk1EQSBjbGllbnQgdG8gaWRlbnRpZnkgc3lzdGVtIGNvbmZpZyB0aGF0IGlzIG5vdCBiZWluZyB1 c2VkIGluIDxvcGVyYXRpb25hbD4uDQoNCkFsbCAicmVzb3VyY2UiIG9yaWVudGVkIGRhdGEgbW9k ZWxzIHNob3VsZCBoYXZlIHNvbWUgbWVjaGFuaXNtIHRvIHJlcXVpcmUgdGhlIHJlc291cmNlcw0K dG8gYmUgdXRpbGl6ZWQgb3IgZW5hYmxlZCBzb21laG93LCB3aXRoaW4gdGhlIGRhdGEgbW9kZWwu IFVuZm9ydHVuYXRlbHkgdGhpcyBjYW5ub3QgYmUgc3RhbmRhcmRpemVkDQp3aXRoIGEgMS1zaXpl LWZpdHMtYWxsIHNvbHV0aW9uLg0KDQpBIHZlbmRvciBtdXN0IHNvbWVob3cgcG9wdWxhdGUgdGhl c2UgZGF0YSBtb2RlbHMgd2l0aCBvcmlnaW49c3lzdGVtIGRhdGEgbm9kZXMuDQpUaGUgImhpZGRl biBzeXN0ZW0iIGRhdGEgdXNlcyBwcm9wcmlldGFyeSBsb2dpYyB0byBkZWNpZGUgd2hhdCBub2Rl cyB0byBhZGQgKGFuZCB3aGVuKS4NClRoaXMgZGF0YSBpcyBwcm9iYWJseSBub3QgcmVwcmVzZW50 ZWQgd2l0aCBZQU5HIG1vZGVscy4gIFRyYW5zZm9ybWluZyB0aGUgaGlkZGVuIHN5c3RlbSBkYXRh DQp0byB0aGUgYXBwcm9wcmlhdGUgWUFORyBtb2RlbHMgaW4gYW55IGRhdGFzdG9yZSBpcyBhbiBp bXBsZW1lbnRhdGlvbiBkZXRhaWwsIG91dCBvZiBzY29wZQ0KZm9yIHN0YW5kYXJkaXphdGlvbi4N Cg0KDQo+IEFuZHkNCg0KS2VudCwgYXMgYSBjb250cmlidXRvci4NCg0KDQoNCkFuZHkNCg0KDQo= --_000_DM6PR08MB5084FB588792F7F44A180BF89B709DM6PR08MB5084namp_ 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 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgYWN0dWFsIHN5 c3RlbSBpbnN0YW5jZSBkYXRhIGlzbid0IGluIGEgWUFORyBtb2RlbCwgYnV0IHRoYXQgaW5zdGFu Y2UgZGF0YSBzaXRzIGluIHNjaGVtYSBkZWZpbmVkIGluIHRoZSBZQU5HIG1vZGVsLiBJdCBpcyB0 eXBpY2FsbHkgYSBsaXN0IGVudHJ5IHBvcHVsYXRlZCBieSB0aGUgc3lzdGVtLiZuYnNwOyBCdXQg dGhlcmUgbWF5IGFsc28gYmUNCiBvdGhlciBsaXN0IGVudHJpZXMgY3JlYXRlZCBieSB0aGUgdXNl cnMvY2xpZW50cywgYW5kIG90aGVyIGFyZWFzIG9mIHRoZSBZQU5HIG1vZGVsIG1heSByZWZlcmVu Y2UgdGhvc2UgbGlzdHMgdXNpbmcgbGVhZnJlZnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkphc29uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiBuZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24g QmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3Zl bWJlciAyOSwgMjAyMSA2OjE0IFBNPGJyPg0KPGI+VG86PC9iPiBLZW50IFdhdHNlbiAmbHQ7a2Vu dEB3YXRzZW4ubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBTaG91bGQgdGhlIG9yaWdpbj0mcXVvdDtzeXN0ZW0m cXVvdDsgYmUgcmVxdWlyZWQgZm9yIHN5c3RlbSBjb25maWd1cmF0aW9ucyBjb3BpZWQvcGFzdGVk IGludG8gJmx0O3J1bm5pbmcmZ3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE5vdiAyOSwgMjAyMSBhdCAyOjQ5IFBNIEtl bnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a2VudEB3YXRzZW4ubmV0Ij5rZW50QHdhdHNl bi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgQW5k eSw8YnI+DQo8YnI+DQomZ3Q7IFJGQyA3OTUwIHJ1bGVzIGFib3V0IGxlYWZyZWYgdmFsaWRhdGlv biBhcmUgdmVyeSBjbGVhci48YnI+DQomZ3Q7IEFkZGluZyBhIG5ldyBkYXRhc3RvcmUgdG8gdGhl c2UgcnVsZXMgcmVxdWlyZXMgYSBtYXNzaXZlIGNoYW5nZSB0byBOTURBPGJyPg0KJmd0OyBhbmQg YWxsIGltcGxlbWVudGF0aW9ucy48YnI+DQo8YnI+DQpOb3QgcmVhbGx5IG9yLCByYXRoZXIsIGl0 IHNlZW1zIGxpa2UgaXQgd291bGQgYmUganVzdCBwYXJ0IG9mIGFkZGluZyBzdXBwb3J0IGZvciAm bHQ7c3lzdGVtJmd0Oywgd2hpY2ggaW1wbGllcyBhZGRpbmcgc3VwcG9ydCBmb3IgJmx0O2ludGVu ZGVkJmd0OyAoaWYgbm90IHN1cHBvcnRlZCBhbHJlYWR5KSBhbmQgZG9pbmcgdGhlIHZhbGlkYXRp b24gb24gJmx0O2ludGVuZGVkJmd0OyBpbnN0ZWFkLjxicj4NCjxicj4NCjxicj4NCiZndDsgMikg QXMgSnVlcmdlbiBwb2ludHMgb3V0LCBzZXJ2ZXJzIHBvcHVsYXRlIHRoZSBzeXN0ZW0gY29uZmln IGluICZsdDtydW5uaW5nJmd0OyBhbmQgdGhlIG9wZXJhdG9yIGlzPGJyPg0KJmd0OyBmcmVlIHRv IGlnbm9yZSBpdCwgcmVmZXJlbmNlIGl0LCBvciBwb3NzaWJseSBjaGFuZ2UgaXQuJm5ic3A7IFRo ZSBwcmVtaXNlIG9mICZsdDtzeXN0ZW0mZ3Q7IHNlZW1zIHRvPGJyPg0KJmd0OyBiZSB0aGF0IHRo aXMgYXBwcm9hY2ggaXMgbm90ICZxdW90O3B1cmUgZW5vdWdoJnF1b3Q7IGZvciBOTURBIGFuZCAm bHQ7cnVubmluZyZndDsgTVVTVCBvbmx5IGNvbnRhaW48YnI+DQomZ3Q7IG9wZXJhdG9yLWNyZWF0 ZWQgY29uZmlndXJhdGlvbi4gV2h5PyBXaGF0IHJlYWwgcHJvYmxlbXMgd291bGQgdGhpcyBjaGFu Z2Ugc29sdmU/PGJyPg0KPGJyPg0KU2VydmVycyBwb3B1bGF0aW5nICZsdDtydW5uaW5nJmd0OyAo YmV5b25kIGNvcGluZyAmbHQ7c3RhcnR1cCZndDsgaW50byAmbHQ7cnVubmluZyZndDspIGhhcyBu ZXZlciBiZWVuIGEgc3VwcG9ydGVkIGlkZWEuJm5ic3A7IFdl4oCZdmUgYWx3YXlzIG1haW50YWlu ZWQgdGhhdCAmbHQ7cnVubmluZyZndDsgc2hvdWxkIG9ubHkgY29udGFpbiBjbGllbnQtcHJvdmlk ZWQgY29uZmlnLCByaWdodD88YnI+DQo8YnI+DQpJ4oCZbSB1bnN1cmUgd2hhdCB0aGUg4oCcY2hh bmdl4oCdIGluIHlvdXIgbGFzdCBxdWVzdGlvbiBwb2ludHMgdG8uJm5ic3A7IEJ1dCBub3RlIHRo YXQgb24gSlVOT1MtYmFzZWQgc3lzdGVtcywgdGhlcmUgYXJlIG1hbnkgaHVuZHJlZHMgb2Ygc3lz dGVtLWRlZmluZWQgbm9kZXMgYXZhaWxhYmxlIHRvIGJlIHJlZmVyZW5jZWQgYnkgY29uZmlnIGlu ICZsdDtydW5uaW5nJmd0Oy4mbmJzcDsgUHV0dGluZyBhbGwgdGhlc2Ugbm9kZXMgaW50byAmbHQ7 cnVubmluZyZndDsgd291bGQgY2x1dHRlciB0aGUNCiBjb25maWcgaW1tZW5zZWx5LiZuYnNwOyAm bmJzcDs8YnI+DQo8YnI+DQpGV0lXLCBKVU5PUyDigJxzb2x2ZXPigJ0gdGhpcyBieSAqaGlkaW5n KiB0aGVzZSBzeXN0ZW0tbm9kZXMsIHN1Y2ggdGhhdCBjbGllbnRzIG11c3QgdXNlIGEgc3BlY2lh bCBjb21tYW5kIGp1c3QgdG8gZGlzY292ZXIgdGhlbS4mbmJzcDsgJm5ic3A7QW5kLCB5ZXMsIGlm IGV2ZXIgYW55IG9mIHRoZXNlIGFyZSBoaWRkZW4tbm9kZXMgYXJlIHJlZmVyZW5jZSwgb2ZmbGlu ZS12YWxpZGF0aW9uIG9mICZsdDtydW5uaW5nJmd0OyB3aWxsIGZhaWwuJm5ic3A7IFRoZSAmbHQ7 c3lzdGVtJmd0OyBkYXRhc3RvcmUNCiBiZWluZyBkaXNjdXNzZWQgZWZmZWN0aXZlbHkgbWltaWNz IHRoaXMgYXNwZWN0IG9mIHRoZSBKVU5PUyBzb2x1dGlvbi48YnI+DQo8YnI+DQpUaGVyZSBpcyBh IHNlcGFyYXRlIHRocmVhZCBmb3IgaWYgKm9mZmxpbmUqIHZhbGlkYXRpb24gb2YgJmx0O3J1bm5p bmcmZ3Q7ICphbG9uZSogbXVzdCBzdWNjZWVkLiZuYnNwOyBUaGUgc29mdCAoZmFsbGJhY2spIHNv bHV0aW9uIGlzIHRvIGhhdmUgY2xpZW50cyBjb3B5L3Bhc3RlIHRoZSByZWZlcmVuY2VkLXN1YnNl dCBvZiB0aGUgc3lzdGVtLWRlZmluZWQgbm9kZXMgaW50byAmbHQ7cnVubmluZyZndDsuJm5ic3A7 IFRoZSB0aGVvcnkgYmVpbmcgdGhhdCwgc2luY2UgaXTigJlzIGp1c3QgYQ0KIHN1YnNldCwgaXQg d29u4oCZdCBjbHV0dGVyIHRoaW5ncyB1cCB0b28gYmFkbHkgYW5kLCBhcyBpdCBpcyBhbHJlYWR5 IHRoZSBjYXNlIHRoYXQgc29tZSBzeXN0ZW0tZGVmaW5lZCBub2RlcyBtdXN0IGJlIGNvcHkvcGFz dGVkIGludG8gJmx0O3J1bm5pbmcmZ3Q7IGluIG9yZGVyIGZvciBjbGllbnRzIHRvIGNvbmZpZ3Vy ZSBkZXNjZW5kZW50IG5vZGVzIChlLmcuLCBzb21lIHR1bmFibGUgZm9yIHRoZSBzeXN0ZW0tZGVm aW5lZCDigJxsb+KAnSBpbnRlcmZhY2UpLCB0aGUNCiB3YXRlciBpcyBhbHJlYWR5IG92ZXIgdGhl IGJyaWRnZSwgc28gdG8gc3BlYWssIG9uIHRoZSBjb3B5L3Bhc3RpbmcgZGViYXRlLiZuYnNwOyBU aGUgb25seSBob2xkb3V0Jm5ic3A7IGZvciBub3QgYWxyZWFkeSBkZW1hbmRpbmcgY2xpZW504oCZ cyBhbHNvIGNvcHkvcGFzdGUgdGhlIHN1YnNldCBvZiByZWZlcmVuY2VkIHN5c3RlbS1kZWZpbmVk IG5vZGVzIGlzIHRoYXQgaXQgaXMgY29tcGxldGVseSB1bm5lY2Vzc2FyeSwgdW5sZXNzIHRyeWlu ZyB0byBlbnN1cmUgb2ZmbGluZQ0KIHZhbGlkYXRpb24gb2YgJmx0O3J1bm5pbmcmZ3Q7IGFsb25l Ljxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gdGhlIGxlYXN0IGRpc3J1cHRpdmUgc29sdXRp b24gcG9zc2libGUgc2hvdWxkIGJlIHVzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhIHVzZS1jYXNlIGZvciBhZGRpbmcgJnF1 b3Q7b3JpZ2luJnF1b3Q7IHN1cHBvcnQgdG8gdGhlICZsdDtydW5uaW5nJmd0OyBkYXRhc3RvcmUg aW4gdGhlICZsdDtnZXQtZGF0YSZndDsgb3BlcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBhbGxvd3MgYW4gTk1EQSBjbGllbnQg dG8gaWRlbnRpZnkgc3lzdGVtIGNvbmZpZyB0aGF0IGlzIG5vdCBiZWluZyB1c2VkIGluICZsdDtv cGVyYXRpb25hbCZndDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFsbCAmcXVvdDtyZXNvdXJjZSZxdW90OyBvcmllbnRlZCBkYXRhIG1vZGVs cyBzaG91bGQgaGF2ZSBzb21lIG1lY2hhbmlzbSB0byByZXF1aXJlIHRoZSByZXNvdXJjZXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIGJlIHV0 aWxpemVkIG9yIGVuYWJsZWQgc29tZWhvdywgd2l0aGluIHRoZSBkYXRhIG1vZGVsLiBVbmZvcnR1 bmF0ZWx5IHRoaXMgY2Fubm90IGJlIHN0YW5kYXJkaXplZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2l0aCBhIDEtc2l6ZS1maXRzLWFsbCBzb2x1 dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QSB2ZW5kb3IgbXVzdCBzb21laG93IHBvcHVsYXRlIHRoZXNlIGRhdGEgbW9kZWxzIHdpdGgg b3JpZ2luPXN5c3RlbSBkYXRhIG5vZGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlICZxdW90O2hpZGRlbiBzeXN0ZW0mcXVvdDsgZGF0YSB1 c2VzIHByb3ByaWV0YXJ5IGxvZ2ljIHRvIGRlY2lkZSB3aGF0IG5vZGVzIHRvIGFkZCAoYW5kIHdo ZW4pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBkYXRhIGlzIHByb2JhYmx5IG5vdCByZXByZXNlbnRlZCB3aXRoIFlBTkcgbW9kZWxzLiZu YnNwOyBUcmFuc2Zvcm1pbmcgdGhlIGhpZGRlbiBzeXN0ZW0gZGF0YTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gdGhlIGFwcHJvcHJpYXRlIFlB TkcgbW9kZWxzIGluIGFueSBkYXRhc3RvcmUgaXMgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLCBv dXQgb2Ygc2NvcGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmZvciBzdGFuZGFyZGl6YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij4mZ3Q7IEFuZHk8YnI+DQo8YnI+DQpLZW50LCBhcyBhIGNvbnRyaWJ1dG9yLjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR08MB5084FB588792F7F44A180BF89B709DM6PR08MB5084namp_-- From nobody Thu Dec 9 08:38: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 678653A0EAF for ; Thu, 9 Dec 2021 08:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 hW7UJ_GNqbPu for ; Thu, 9 Dec 2021 08:38:33 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2109.outbound.protection.outlook.com [40.107.93.109]) (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 5ED6E3A0E8F for ; Thu, 9 Dec 2021 08:38:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kLWwFesebnkvI9S9cqB0uapsPsNaFgII3cJcnEWqRV4i0r9CtFmjLqhXqkBbw5o68xZkm0PcQkkc5YAT7zyc7W8evaMvevjOehROjywgL7BbgY45SbcxuFaGc23KphBAnwO4k+s23l0Kz/LRYQThTvRylMtJdzlP6/eL/0g0K/WoNNmgs7dbovdMiaMj237r3fVUDANZEzT5DVlUDG5uEsqiKyGpKJbNuI/Ew1nYGk/tgv+31NaRw4yTUuJ3QVRVVuXMI7jHryJibx7W2KrAc+QROxLgIAHwII2sWmyQpPMUGfqIUQDSubMXjtOq9lhHE3ncTtNa6JQIE+NNm03bVA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=o0WKiHijjnySmHiMKJMr0AonEpVLnMbHQ1Wk+kzbUp4=; b=AfrM9xTmgxkDG6CSY3Rcg6StW3vnmfE6LazkseyzwUYrs0BI9Sep6oPe6z1yWPi41RC1dkWY6/vaIuR9PrUubZTWPqWdHFGfQ3xplNZvazZn1RV/yACoBSANkVStduB5WXutLXUE0Hie2gvA+KwCov9nXfNjW5CZAvdpXm7sUiBUY81CfdGvCoWEUlQ2J4v5cC0ykbO08tYWt5kNKj0qF5/LiTRXQ3LsO9eQUzZwzJ7MIqUqi69DFIZXhgDrWd09VmV3xjZdWVTzvI8t8Byui+5szK5iunNTnslBYDQ2Ii6NDtkv3DmU4RpKdKbFNF2w4jvgaqepM7S2rNPUSG89xQ== 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=o0WKiHijjnySmHiMKJMr0AonEpVLnMbHQ1Wk+kzbUp4=; b=tUr6DOJg2hkXgxhNqo9Wlan4mwLsJ/2O+IxrQfRbnegGIhoTDV2Zb4zp+yOFuR1sMWFXeWVLrzm7El91wK/CVrqieHgHX+g9Dtn52h93c066iR+anZU4SmDRmumo/8fznqgmXnNSnSmWIiTaT9b/F9Sy+Ep733w3gH7/mdR+7cE= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DS7PR08MB6879.namprd08.prod.outlook.com (2603:10b6:5:3a0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Thu, 9 Dec 2021 16:38:29 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 16:38:28 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Juergen Schoenwaelder CC: "maqiufang (A)" , Andy Bierman , Jan Lindblad , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] Must offline-validation of alone be valid? Thread-Index: AQHX6DUp5BZXcFhAE0+IivjOGbmtWawpL+ewgAALk4CAAO90gIAACvGAgAAXKdCAAAJJgIAAFWAA Date: Thu, 9 Dec 2021 16:38:28 +0000 Message-ID: References: <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <4010d6892a4b42249a5d3fda5d511788@huawei.com> <20211209134619.uspscxpn3kk2hycf@anna> <20211209151723.fjf4hjyoui5t6r4m@anna> In-Reply-To: <20211209151723.fjf4hjyoui5t6r4m@anna> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df5b8526-33f7-4d1f-5cae-08d9bb32542d x-ms-traffictypediagnostic: DS7PR08MB6879:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y595Q8bc3fsM22kmLgq4zEfMRa2g+pkhmmv00lTemEvBSRMfQ6mII7d4/zRPs1o0stBZI6zllVDsq6CCzWX78uUGnjekhQ7S9exLAHPKpcgPkv7DB751EfBhGFDPDvcRUC7RqTjIR0EaPVlH2olTgcaH3KYkKniSd9NPMc9joTy+fGtlhb/CdswCr9dBpIIcHEkXw9a4dcdmx8av8KHu76zwBf83sGXDW2TBShWLYv08/lgF+BdGtqxHDAJrLd27+NhGGWatSLzBd0514S05fns8Ivej2U8msczbsAiF2kFhxC6k1hqgrs/HTWNGYlWMOMessYmKDzc1RH95EIio9LFvSPWkJngHJyJnqT1GGCzMUbw/Mqy3AKxXl4KFfLd/HQhGIBwBoGvz5Yf7/2Nfa0h/ka0aHPWFvnqCF15P1xrBptUm4HOSakn9qd8JyuVB1NuVKU4jWEENXmvuUXg4NOOpzmxs7RPZulaCOJFmlPUxchhfZ4cp6csavR1gdcv+4iGqWAYakIG0EwMG+V6cILMJ8rFDY/Uo+knraM4ctzRdkXRDEgxNmqop7dep3QOcRumWxXYXjyjML0TwBPIlNgC7xl+w7m99Cc8djRKgPaSGMHN6Q5y6hrNY+xEPuQIt4OrJ23+V36LOZOK/0Fdr9ZXvSv0RLbSfwJ4nIEqR03u8tlGbTyu+A/Ma5B+5hXvoyXOKtHmS2RiiK0RCn9U97Rg6N/UDSfGeg6EWWI8lg3Lm2gN6/pe1SxQvLPhMQw7tXqi1kh+Eh+bxwuBsPIdLnJC2+CH/Ob4+o6vh1YU9jeM= 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)(366004)(8936002)(316002)(508600001)(83380400001)(66574015)(38070700005)(54906003)(4326008)(6916009)(7696005)(76116006)(40140700001)(66446008)(9686003)(186003)(8676002)(33656002)(66556008)(64756008)(53546011)(122000001)(86362001)(26005)(38100700002)(5660300002)(66476007)(71200400001)(66946007)(52536014)(55016003)(2906002)(82960400001)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?c2VZL0llaVpNdVNVMlNpQWlpcVk2M0ZjZWJUeXkvOXppeFVRQmt2TkRINThS?= =?utf-8?B?UThoYU9WUko1YTBOQ3Y4TkQ0RTEvOW81N01vK29HMXR0QjQ3TnZxOWxRZWVs?= =?utf-8?B?bVdSa2Q1VjVUTXJTZHlXZ1VzMWlpQjRveURkQTBzOXR2cmVWSDFIaXRPY3FK?= =?utf-8?B?dzlmMGRhQzdicHlrbjk4Zk5vZCtjNWhJZFBPZUU1T0xnM2JWakhGY2NCTnBE?= =?utf-8?B?c2VIV2Z1cHZ6WGZlWUVocG1Cb2ZCSmdKdVErRlVTN3Q5U1RQTDNsMkRTenlt?= =?utf-8?B?aHlicFpybkpWM2EvUXM5SDVSWWExajczWkhhM3FtU1VzNEg1ajZjZk5GUFA3?= =?utf-8?B?aSthWHhJdnpKcjlkYmsxSE92Y2dvUXdkYzgzWFQ5dS9vODh1blc1QzRPYWM5?= =?utf-8?B?Wks3THhEcnZwSUZTRG4waTJ1Zyt5cXJtWEMwR1oyYzFXNThZd0lKbnJRRmIr?= =?utf-8?B?TU9iMWlqeWYrc3hrMDZ0V2dwbUpPL1pzQm1yLzA3L0VSREM2Z1h6c2lNYnVK?= =?utf-8?B?a1dXdkRnQ2JSeDVhMjMxTWl1VUtjb1JTRUJBOHlvSHdhUXdaOHVwTTlRcktZ?= =?utf-8?B?a0EybU9NNitBWlRZUTMwZkVMczFVSm9SNFdrQld2UDlPeFgzK1VaMGxxbXY2?= =?utf-8?B?RDVKSnV0anBwOW1udTB4d0V2RE9Yd1pNZHZZRVo5SjFDYkxSdTFjOEtXYW04?= =?utf-8?B?azI2bWIwQnhiUDVZcTQ5OEc1d01MeXMwQ1Z4WS8vUXhqblVKOXdUQTNjT1dy?= =?utf-8?B?WUVpQlhDMFg1aFpzWHNVUEVsUXBuYkwvM0tNTk1jQlAwVWZxbXBIREZGK0lU?= =?utf-8?B?dXhVS1phYVdmMDJnaEhoaDFSczJUSlNHRUNubGltVzhrcFZEV1NWM1EvQ291?= =?utf-8?B?bG1TSi91K3N2YUZFS1RYNkFUN09FdFF5Zk5FaVJUdyt2VFkxUGRWT2cvMDla?= =?utf-8?B?STh6cjVEdHB4TzRwUVRJb2RMa1BQMnFFeEJLYzVNQ2lYcWhlWXlsYTBpY3Y2?= =?utf-8?B?em9WLzROQnZ2ZHB5R2dDQVV5VWlVdVhYZ0lkMk1RS2QvdkRSNGZUTHNqWW1O?= =?utf-8?B?a1F4WklZMTRYaTB1S2tQeVZxSzlZaFNDSnFORnF4azZ3NGdqcFRtS3U4VUVR?= =?utf-8?B?UUtObkVxZXVlZkFUdUV2TFpDNW52MmU0RStjb2p0R29JaG54MVpLeXZadVFO?= =?utf-8?B?NUNucmlzTnF3dmJrNVJEaG5TSzhvMVlkanFCZ1dlVnFlbURyY25qMWxTUFdk?= =?utf-8?B?RU1kSllzczNUeEZFVHk0dGVEYlhBSWEvdzYxTXh2SVhQVVdXa1NlOEtvbGhP?= =?utf-8?B?QkVyNGZieGd5TjBBYkhOWGhuL3hpR0FkUlZZbE1MTzhiVXcxN2hRQTVmQnR5?= =?utf-8?B?UmZNckpXcFdKZEVOa0dyUWQ5em1OUXVmZW9YV2l1dzVLMlRKVU1zei9Ca0t3?= =?utf-8?B?dHQ2ZWxRK0dic2EyeVFyaUFPZkNNSmFMcmNMTnNvL1ppbTRXbUtsZFExWEhO?= =?utf-8?B?Z3pMTGFQYnpGVzVCYTF3WjdBdlk5Y1pLUTltWDlHcy9XbTdIQUtQdlhBWThw?= =?utf-8?B?YnlHQVBzbkNLNEpKVS8zV29mUllzbEp4anc3V0dlbXJVUFN0MDNJMURxbUp5?= =?utf-8?B?ZEphTGxIb1BxTmxTQW9CLzR5VTR4Zjc4cmJIeUJZVytmYmk0SDdIdE1zY0dw?= =?utf-8?B?TGRXNmQ3UmI3eUF2L2YrTGpnYVE2YlBoTW5ldWtwTjhQQlBqYm84MFgvYmdy?= =?utf-8?B?YmtYNzBkczBkZFZ2ejhpNmdUSlFwNkttUCtDNkxSdk52amlGR2hLZ3dMSVRp?= =?utf-8?B?NGsxYnVPZk51Uk1OSkI2QXpZajVObE5jU1h1MGdwMjhXeVpyTEU5VU1lQWhK?= =?utf-8?B?dmN0dGRqZzdPSHlmZHFCeG9NTnV5WEpHek1rNkVYL01lVVg5SmVtMU05azF3?= =?utf-8?B?T3hHUkFXOXlUdXlKaGJiQWhXNWxlUk9zU0lWS1ZMM0lhb0RBYUc1QXpvdDBU?= =?utf-8?B?UEdtRWxMc1JNZEJEdjhZejIzVVQ3SXRONzhZSzFvTmJRVHJ1U0NyQW1GdkI4?= =?utf-8?B?SCtpNktvRXFodG5sSXJvazBWV1YvM0tFa1JlWlpDaVBEQ2hWZ1l4eUZRMHhh?= =?utf-8?B?SWtlQi9TRk94WkRZczN6SVozZTIxN2VwY05RaXVJb1dhTk9ld2pLZmtsRExY?= =?utf-8?B?Z0E9PQ==?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: df5b8526-33f7-4d1f-5cae-08d9bb32542d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 16:38:28.3614 (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: 6HqM+v0Sq2D1oQtUS3Y/cTaIsMVL6uqLL7THFZLXoPiIkIn4cNtVy+TvW4VZYkfVH5B0aardS2S7HGTygH9XTA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR08MB6879 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 09 Dec 2021 16:38:39 -0000 VG8gaGVscCBpbGx1c3RyYXRlICJNYW55IG1ham9yIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgKGF0 IGxlYXN0IGluIHRoZSByb3V0ZXIgc3BhY2UpIjoNCg0KSlVOT1MgYW5kIE5va2lhIFNSIE9TIGhh dmUgaXQuDQoNCkknbSBub3Qgc3VyZSBhYm91dCBDaXNjbyAtIG1heWJlIHNvbWVvbmUgd2hvIGtu b3dzIElPUy1YUiB3ZWxsIGNvdWxkIHBvaW50IG91dCBhbiBleGFtcGxlIG9mIHRoaXMgKG9yIGNv bmZpcm0gdGhleSBkby9kb24ndCBoYXZlIGl0LCBvciBkby9kb24ndCBzZWUgYSB1c2UgY2FzZSBn aXZlbiB0aGVpciBtb2RlbC1kcml2ZW4gYXJjaGl0ZWN0dXJlKS4NCg0KSSBhc3N1bWUgSHVhd2Vp IG11c3QgaGF2ZSBpdCBnaXZlbiB0aGUgMyBwcmltYXJ5IGF1dGhvcnMgYXJlIGFzc29jaWF0ZWQg d2l0aCBIdWF3ZWkgaW4gdGhlIGRyYWZ0LiAgTWF5YmUgdGhleSBjYW4gY29uZmlybS4NCg0KSmFz b24NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKw7xyZ2VuIFNjaMO2 bnfDpGxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gU2VudDog VGh1cnNkYXksIERlY2VtYmVyIDksIDIwMjEgMTA6MTcgQU0NCj4gVG86IFN0ZXJuZSwgSmFzb24g KE5va2lhIC0gQ0EvT3R0YXdhKSA8amFzb24uc3Rlcm5lQG5va2lhLmNvbT4NCj4gQ2M6IG1hcWl1 ZmFuZyAoQSkgPG1hcWl1ZmFuZzFAaHVhd2VpLmNvbT47IEFuZHkgQmllcm1hbg0KPiA8YW5keUB5 dW1hd29ya3MuY29tPjsgSmFuIExpbmRibGFkIDxqYW5sQHRhaWwtZi5jb20+OyBLZW50IFdhdHNl bg0KPiA8a2VudEB3YXRzZW4ubmV0PjsgbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb bmV0bW9kXSBNdXN0IG9mZmxpbmUtdmFsaWRhdGlvbiBvZiA8cnVubmluZz4gYWxvbmUgYmUgdmFs aWQ/DQo+IA0KPiBPbiBUaHUsIERlYyAwOSwgMjAyMSBhdCAwMzoxNToyNFBNICswMDAwLCBTdGVy bmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkNCj4gd3JvdGU6DQo+ID4gPiBBIHNlcnZlciBh Y2NlcHRpbmcgYW5kIHJldHVybmluZyBub24tdmFsaWQgY29uZmlnIGlzIGFsc28gYSBzdXJwcmlz ZQ0KPiA+ID4gYW5kIGluY29udmVuaWVuY2UuDQo+ID4NCj4gPiBBbmR5IG1hZGUgYSBzaW1pbGFy IHBvaW50IGluIGhpcyByZXBseSBidXQgaXQgaXMgY3VycmVudGx5IGltcGxlbWVudGVkIHRvZGF5 DQo+IGFuZCB0aGVyZSBhcmUgc29tZSBkZXNpcmFibGUgYXNwZWN0cyBvZiB0aGF0IGZ1bmN0aW9u YWxpdHkuIE1hbnkgbWFqb3INCj4gc2VydmVyIGltcGxlbWVudGF0aW9ucyAoYXQgbGVhc3QgaW4g dGhlIHJvdXRlciBzcGFjZSkgaGF2ZSB0aGlzIGNvbmNlcHQgb2YNCj4gaGlkZGVuIGNvbmZpZyB0 aGF0IGNhbiBiZSByZWZlcmVuY2VkLCBhbmQgc3VwcG9ydCBjb25maWd1cmF0aW9uIHRlbXBsYXRl cy4NCj4gQm90aCBvZiB0aG9zZSBtZWFuIHRoZSBzZXJ2ZXIgaXMgYWNjZXB0aW5nIGFuZCByZXR1 cm5pbmcgIm5vbi12YWxpZCBjb25maWciLg0KPiA+DQo+IA0KPiBXaGF0IGRlZmluZXMgIm1hbnkg bWFqb3Igc2VydmVyIGltcGxlbWVudGF0aW9ucyI/DQo+IA0KPiAvanMNCj4gDQo+IC0tDQo+IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH bWJIDQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4 NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8 aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Thu Dec 9 08:47:28 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 3B5493A0F35 for ; Thu, 9 Dec 2021 08:47:22 -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.20210112.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 JSgT-WmORkIV for ; Thu, 9 Dec 2021 08:47:17 -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 CF30A3A0F74 for ; Thu, 9 Dec 2021 08:47:16 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id b1so13049233lfs.13 for ; Thu, 09 Dec 2021 08:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LOBfnX+SAfcfICvrhzQtOViOPJrzhm8gUo15Bw+6C9s=; b=cXdnl3fSVxRgZS8A548/qDSp/7dGNhxOc90C46ouwXy7XR+4uZWfd/Q66W9sB4c3dj AWGSpMcFbYvC2AMv3cgTYzZejyBriVJTjWAgaIsxmSnj1hKbq9UBzaS6UlTE0yG4HgPc jLUjgoQwajk66p0vdQDl60isSOnnOmRMQ1c5EKZ2R3P2BCFdKAKkcIBV54Ex0d3pc9sU TT+ht/cnCsGuoOSf+bwLtmep7s8n5ahJJeLxxM5v7Dk5DS1DUcR2nPcbVyRvlVjB1Q5c 3nLrBBlydFJLvPSeQ9DGRgmFSRrcseSLZMUPn1kDeXBvv+UyTg9jT5lqCfR5cnrNMW4g 3p0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LOBfnX+SAfcfICvrhzQtOViOPJrzhm8gUo15Bw+6C9s=; b=EELe/I5A+wmDCbhNlNa/8s8kFMRB6cE/hx39He24YoTqlguHLCTjaKsAbwbd+tGlpu 30O7X4vWWCJ4Bw96tNPjw3EHMS8Rm+/wTx6LgdO1/y4mhJq3m7coGiVE+NatHDGskhHr gkg0U4W1sazFO6Uu1jjuCPBsV6bYtphLBblRYh27cQCTqcKM/4QYB5dgvMncGQ3uwlk2 fhSvCUYHp9LvCPFE3ary4JlrXueA3gB5kqiyqNIQOxWRpVymGlPxZnquj4MhK5lWTgjd t06Q9/Msj1TWK6cLmjkHH0RxZu++x9ato7fwoSswG3EbeeDxJEJCawMNfp/WHuTLw1n3 M2DA== X-Gm-Message-State: AOAM531zKhDZaGcb6F4hp8iMRuFq5vJBKzwANjCR7aPvMKqyNajBSEUW hcVyoee4HSlnu5sFZkFvSdo0iQC1Z66KFUMHd35BAQ== X-Google-Smtp-Source: ABdhPJwYi01u5VKM91GPRyhFI1/T889KjSn6jHnikVt4bTGTIxQ11i7GZ0EX794BV3Dek3CtA0tX8vbZcGGuXMeWryY= X-Received: by 2002:a05:6512:68c:: with SMTP id t12mr7203574lfe.10.1639068433264; Thu, 09 Dec 2021 08:47:13 -0800 (PST) MIME-Version: 1.0 References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> In-Reply-To: From: Andy Bierman Date: Thu, 9 Dec 2021 08:47:02 -0800 Message-ID: To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: Juergen Schoenwaelder , Jan Lindblad , Kent Watsen , "maqiufang (A)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ba4dd605d2b95bce" Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 09 Dec 2021 16:47:27 -0000 --000000000000ba4dd605d2b95bce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 9, 2021 at 7:19 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.sterne@nokia.com> wrote: > Hi Andy, > > > > I'm not sure I understand Kent's alternative that you're referencing here= . > Are you talking about something like JUNOS active/inactive configuration > annotation ? > > > > Is the "enable" some configurable metadata against data nodes ? > > > I am not proposing a solution here. I am referring to RFC 8342 use of the term "inactive", e.g: https://datatracker.ietf.org/doc/html/rfc8342#section-5 Any solution that overrides MUST requirements in YANG 1.1 requires a new YANG version. IMO it is unwise to send the industry the message that YANG 1.1 and NMDA need to be replaced and NMDA is an unstable experiment that is not ready for production networks. NMDA allows for inactive nodes in . It is trivial to design a data model in such a way that it is inactive until a client uses it somehow. Where in RFC 8342 does it say that config MUST or even SHOULD contain only nodes explicitly created by an external client? > When you say the "full set of nodes in running" are you talking about > Jan's option #1 below (but perhaps without the explicit datastor= e) > ? i.e. all the system config is actually returning from a o= f > running ? > I am not interested in a new datastore for NMDA. It has enough already. can have active and inactive nodes in it. There is no need to create a new datastore and rewrite YANG to use a new datastore. > > Jason > Andy > > > *From:* Andy Bierman > *Sent:* Wednesday, December 8, 2021 5:50 PM > *To:* Sterne, Jason (Nokia - CA/Ottawa) > *Cc:* Juergen Schoenwaelder ; Jan > Lindblad ; Kent Watsen ; maqiufang (A) > ; netmod@ietf.org > *Subject:* Re: [netmod] Must offline-validation of alone be > valid? > > > > > > > > On Wed, Dec 8, 2021 at 2:31 PM Sterne, Jason (Nokia - CA/Ottawa) < > jason.sterne@nokia.com> wrote: > > Hi guys, > > > > Andy - about use cases. Here is a problem we're trying to address: > > > > There are at least several major router implementations that have this > concept of "hidden config" (i.e. list entries that can be referenced in a > leafref by explicit user config, but those list entries are not returned = in > a ). > > > > > > > > Clearly not in compliance with RFC 7950. > > > > IMO the "enable flag" approach to the general problem, presented by Kent = a > couple years ago, > > is a much simpler and better solution than a new datastore. > > The full set of nodes is in . > > A generalized "enable" mechanism causes the resource to be used or not, > > where it shows up in and if enabled=3Dtrue. > > > > IMO this fits the original intent of NMDA and does so in a way that > requires > > the least disruption to current compliant implementations. > > > > Andy > > > > > > The server accepts these configurations (i.e. a validate or commit > succeeds), but if you actually validate (e.g. with yangLint) the running > datastore contents (e.g. fetched using ) to the YANG model it > is not valid. That is against several RFCs referenced in the discussions > below. > > > > IMO there isn't any "offline" vs" online" validation that is different. > The contents of the running must be valid against the YANG model. A > returns the contents of the running. The server can validat= e > it, or some other entity can validate it, but it must be valid. > > > > In Jan's option #1 the running config could be polluted with 100s or 1000= s > of lines of unreferenced/unused config. A of a system withou= t > much config would instead return 100s/1000s of lines. I think that would = be > very annoying from a usability perspective. > > > > I'm in favor of this aspect of Jan's option #2: " + Clients unaware of > the system datastore would have to include (copy) information from the > system datastore to running in order to reference them." > > > > -> Only the list keys of referenced system objects would have to be copie= d > (configured) into the running DS (to resolve leafrefs). We wouldn't need > to copy all the descendant elements inside the referenced object. > > -> This copying would only need to be done by operators with a workflow > that requires offline validation > > > > Some of this approach is already described in > draft-ma-netmod-with-system-01: > > > > " In all cases, the clients should have control over the configurations > > ,i.e., read-back of should contain only what was explicitly > > set by clients." > > > > > > "4.3. Explicit declaration of system configuration > > > > In addition to modifying system configuration, and adding nodes to > > lists in system configuration as described above, a client can also > > explicitly declare system configuration nodes in with the > > same values as in . When a client configures a node (list > > entry, leaf, etc) in that matches the same node & value in > > , then that node becomes part of . A read of > > returns those explicitly configured nodes. > > > > This explicit configuration of system configuration in can > > be useful, for example, when an operator's workflow requires a client > > or offline tool to see the configuration as valid. The > > client can explicitly declare (i.e. configure in ) the list > > entries (with at least the keys) for any system configuration list > > entries that are referenced elsewhere in . The client does > > not necessarily need to declare all the contents of the list entry > > (i.e. the descendant nodes) - only the parts that are required to > > make the appear valid offline. " > > > > I'm not a fan of option #3. It doesn't allow a mode of operating where a > client/OSS has full control over the contents of the . Some > operators will want the master config to be owned up in their client/OSS > and push it down. The server should just accept it and the client should = be > able to do a "read-back" and see exactly what was sent previously. > > > > I think we have a potential solution for this system config that keeps th= e > running valid. But I'm far more worried about configuration templates. I > don't see how we can possibly keep valid with config templates. > That seems like a major problem to me. But if we ever declare that > doesn't have to be valid, and only has to be valid, > then offline tools can never validate (ahead of time) the config they > actually download to the server. > > > > Jason > > > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Friday, December 3, 2021 6:01 AM > *To:* Juergen Schoenwaelder ; Jan > Lindblad ; Kent Watsen ; maqiufang (A) > ; netmod@ietf.org > *Subject:* Re: [netmod] Must offline-validation of alone be > valid? > > > > > > > > On Fri, Dec 3, 2021 at 2:26 AM J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Fri, Dec 03, 2021 at 10:59:12AM +0100, Jan Lindblad wrote: > > > I made some proposals earlier, both on the interim and privately to the > draft authors, along these lines: > > > > Option #1 > > + We could have a new system datastore that technically is a part of > running. Everything in system would show up in running to clients unawar= e > of the system datastore. Every time the system datastore changes for > whatever reason, the running datastore transaction ids (if we manage to g= et > that concept defined), are updated > > + Clients interested to see pure view of the system datastore without > anything else in running could issue a get-data towards the system datast= ore > > + Clients interested to see a pure view of running without any system > datastore elements could issue a get-data towards running with an extra > flag called 'without-system' > > + Since all system elements are already part of running, clients have n= o > need to copy data between the two datastores > > > > Option #2 > > + We could have a system datastore that technically is a part of > operational. Everything in system would show up in operational to client= s > unaware of the system datastore. The running datastore always maintains > referential integrity, i.e. cannot reference the system datastore. > > + Clients interested to see pure view of the system datastore could > issue a get-data towards the system datastore > > + Since the system datastore is not part of running, clients can alread= y > see a pure view of running without any system datastore elements using a > simple get-data. > > + Clients that are aware of the system datastore and are interested to > configure references from running to system elements would issue an > edit-data rpc with the additional flag 'resolve-system-references'. This > will make the server copy any system elements referenced into running > without the client doing so explicitly. > > + Clients unaware of the system datastore would have to include (copy) > information from the system datastore to running in order to reference th= em. > > > > Option #3 > > There is a client on the system that makes changes to running just > like any other remote clients can make changes to running. System > generate config that is not editable explicit config in running goes > straight into the applied config in operational. This does not require > a system datastore (in fact something like a system datastore may > exist as the _logic_ of the system client, the good old example we had > is allocting an unused uid for an account that, once allocated, is > maintained in running). > > > > > > +1 to option 3. > > Consider an implementation that moves all the "hidden system logic" off-b= ox > > to a controller, such that the initial config is literally supplied by an > external client. > > > > I have yet to hear a single use-case for creating a datastore. > > "The client might want" is not a use-case for standardization. > > I do not understand the "pure view". Seems like if this was a real proble= m > to solve, > > then NMDA would have included a system datastore from the start. > > > > > > /js > > > > > > Andy > > > > > -- > 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 > > --000000000000ba4dd605d2b95bce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 9, 2021 at 7:19 AM Sterne= , Jason (Nokia - CA/Ottawa) <j= ason.sterne@nokia.com> wrote:

Hi Andy,

=C2=A0

I'm not sure I understand Kent's alter= native that you're referencing here. Are you talking about something li= ke JUNOS active/inactive configuration annotation ?

=C2=A0

Is the "enable" some configurable me= tadata against data nodes ?

=C2=A0



I am not proposing a solution here.
I am referring to RFC 8342 use of the term "inactive", e= .g:

Any solution that overrides MUST requirements in YANG 1.1 = requires a new YANG version.

IMO it is unwise to s= end the industry the message that YANG 1.1 and NMDA need to be
re= placed and NMDA is an unstable experiment that is not ready for production = networks.
NMDA allows for inactive nodes in <running>. It i= s trivial to design a data model
in such a way that it is inactiv= e until a client uses it somehow.

Where in RFC 834= 2 does it say that <running> config MUST or even SHOULD contain
=
only nodes explicitly created by an external client?
=C2=A0<= /div>

When you say the "full set of nodes in ru= nning" are you talking about Jan's option #1 below (but perhaps wi= thout the explicit <system> datastore) ?=C2=A0 i.e. all the system co= nfig is actually returning from a <get-config> of running ?

=

I am not interested in a new datastore for NMDA. It has= enough already.
<running> can have active and inactive nod= es in it. There is no need to
create a new datastore and rewrite = YANG to use a new datastore.

=C2=A0

Jason

=

Andy
=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: Wednesday, December 8, 2021 5:50 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Jan Lindblad <janl@tail-f.com>; Kent Watsen <kent@watsen.net>; maqiufang (A) <maqiufang1= =3D40huawe= i.com@dmarc.ietf.org>; netmod@ietf.org
Subject: Re: [netmod] Must offline-validation of <running> alo= ne be valid?

=C2=A0

=C2=A0

=C2=A0

On Wed, Dec 8, 2021 at 2:31 PM Sterne, Jason (Nokia = - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Hi guys,

=C2=A0

Andy - about use cases.=C2=A0 Here is a problem we&#= 39;re trying to address:

=C2=A0

There are at least several major router implementations that have this conc= ept of "hidden config" (i.e. list entries that can be referenced = in a leafref by explicit user config, but those list entries are not return= ed in a <get-config>).=C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0

Clearly not in compliance with RFC 7950.

=C2=A0

IMO the "enable flag" approach to the gene= ral problem, presented by Kent a couple years ago,

is a much simpler and better solution than a new <= ;system> datastore.

The full set of nodes is in <running>.<= u>

A generalized "enable" mechanism causes th= e resource to be used or not,

where it shows up in <intended> and <operat= ional> if enabled=3Dtrue.

=C2=A0

IMO this fits the original intent of NMDA and does s= o in a way that requires

the least disruption to current compliant implementa= tions.

=C2=A0

Andy

=C2=A0

=C2=A0

The server accepts these configurations (i.e. a validate or commit succeeds= ), but if you actually validate (e.g. with yangLint) the running datastore = contents (e.g. fetched using <get-config>) to the YANG model it is no= t valid. That is against several RFCs referenced in the discussions below.

=C2=A0

IMO there isn't any "offline" vs"= online" validation that is different. The contents of the running mus= t be valid against the YANG model.=C2=A0 A <get-config> returns the c= ontents of the running.=C2=A0 The server can validate it, or some other entity can va= lidate it, but it must be valid.

=C2=A0

In Jan's option #1 the running config could be p= olluted with 100s or 1000s of lines of unreferenced/unused config. A <ge= t-config> of a system without much config would instead return 100s/1000s of lines. I think that would be very annoying from a usability = perspective.

=C2=A0

I'm in favor of this aspect of Jan's option = #2:=C2=A0 " + Clients unaware of the system datastore would have to in= clude (copy) information from the system datastore to running in order to reference them."

=C2=A0

-> Only the list keys of referenced system object= s would have to be copied (configured) into the running DS (to resolve leaf= refs).=C2=A0 We wouldn't need to copy all the descendant elements inside the referenced object.

-> This copying would only need to be done by ope= rators with a workflow that requires offline validation

=C2=A0

Some of this approach is already described in draft-= ma-netmod-with-system-01:

=C2=A0

"=C2=A0=C2=A0 In all cases, the clients should = have control over the configurations

=C2=A0=C2=A0 ,i.e., read-back of <running> sho= uld contain only what was explicitly

=C2=A0=C2=A0 set by clients."

=C2=A0

=C2=A0

"4.3.=C2=A0 Explicit declaration of system conf= iguration

=C2=A0

=C2=A0=C2=A0 In addition to modifying system configu= ration, and adding nodes to

=C2=A0=C2=A0 lists in system configuration as descri= bed above, a client can also

=C2=A0=C2=A0 explicitly declare system configuration= nodes in <running> with the

=C2=A0=C2=A0 same values as in <system>.=C2=A0= When a client configures a node (list

=C2=A0=C2=A0 entry, leaf, etc) in <running> th= at matches the same node & value in

=C2=A0=C2=A0 <system>, then that node becomes = part of <running>.=C2=A0 A read of

=C2=A0=C2=A0 <running> returns those explicitl= y configured nodes.

=C2=A0

=C2=A0=C2=A0 This explicit configuration of system c= onfiguration in <running> can

=C2=A0=C2=A0 be useful, for example, when an operato= r's workflow requires a client

=C2=A0=C2=A0 or offline tool to see the <running&= gt; configuration as valid.=C2=A0 The

=C2=A0=C2=A0 client can explicitly declare (i.e.=C2= =A0 configure in <running>) the list

=C2=A0=C2=A0 entries (with at least the keys) for an= y system configuration list

=C2=A0=C2=A0 entries that are referenced elsewhere i= n <running>.=C2=A0 The client does

=C2=A0=C2=A0 not necessarily need to declare all the= contents of the list entry

=C2=A0=C2=A0 (i.e. the descendant nodes) - only the = parts that are required to

=C2=A0=C2=A0 make the <running> appear valid o= ffline.=C2=A0 "

=C2=A0

I'm not a fan of option #3. It doesn't allow= a mode of operating where a client/OSS has full control over the contents = of the <running>.=C2=A0 Some operators will want the master config to be owned up in their client/OSS and push it down. The server should jus= t accept it and the client should be able to do a "read-back" and= see exactly what was sent previously.

=C2=A0

I think we have a potential solution for this system= config that keeps the running valid. But I'm far more worried about co= nfiguration templates. I don't see how we can possibly keep <running> valid with config templates. That seems like a major = problem to me. But if we ever declare that <running> doesn't have= to be valid, and only <intended> has to be valid, then offline tools= can never validate (ahead of time) the config they actually download to the server.

=C2=A0

Jason

=C2=A0

=C2=A0

From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Friday, December 3, 2021 6:01 AM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Jan Lindblad <janl@tail-f.com>; Kent Watsen <kent@watsen.net>; maqiufang (A) <maqiufang1=3D40huawei.com@dmarc.ietf.org>; netmod@ietf.org Subject: Re: [netmod] Must offline-validation of <running> alo= ne be valid?

=C2=A0

=C2=A0

=C2=A0

On Fri, Dec 3, 2021 at 2:26 AM J=C3=BCrgen Sch=C3=B6= nw=C3=A4lder <j.schoenwaelder@jacobs-university.de> wrote:<= u>

On Fri, Dec 03, 2021 at= 10:59:12AM +0100, Jan Lindblad wrote:

> I made some proposals earlier, both on the interim and privately to th= e draft authors, along these lines:
>
> Option #1
> + We could have a new system datastore that technically is a part of r= unning. Everything in system would show up in running to=C2=A0 clients unaw= are of the system datastore. Every time the system datastore changes for wh= atever reason, the running datastore transaction ids (if we manage to get that concept defined), are updated
> + Clients interested to see pure view of the system datastore without = anything else in running could issue a get-data towards the system datastor= e
> + Clients interested to see a pure view of running without any system = datastore elements could issue a get-data towards running with an extra fla= g called 'without-system'
> + Since all system elements are already part of running, clients have = no need to copy data between the two datastores
>
> Option #2
> + We could have a system datastore that technically is a part of opera= tional. Everything in system would show up in operational to=C2=A0 clients = unaware of the system datastore. The running datastore always maintains ref= erential integrity, i.e. cannot reference the system datastore.
> + Clients interested to see pure view of the system datastore could is= sue a get-data towards the system datastore
> + Since the system datastore is not part of running, clients can alrea= dy see a pure view of running without any system datastore elements using a= simple get-data.
> + Clients that are aware of the system datastore and are interested to= configure references from running to system elements would issue an edit-d= ata rpc with the additional flag 'resolve-system-references'. This = will make the server copy any system elements referenced into running without the client doing so explicitly.
> + Clients unaware of the system datastore would have to include (copy)= information from the system datastore to running in order to reference the= m.
>

Option #3

There is a client on the system that makes changes to running just
like any other remote clients can make changes to running. System
generate config that is not editable explicit config in running goes
straight into the applied config in operational. This does not require
a system datastore (in fact something like a system datastore may
exist as the _logic_ of the system client, the good old example we had
is allocting an unused uid for an account that, once allocated, is
maintained in running).

=C2=A0

=C2=A0

+1 to option 3.

Consider an implementation that moves all the "= hidden system logic" off-box

to a controller, such that the initial config is lit= erally supplied by an external client.

=C2=A0

I have yet to hear a single use-case for creating a = <system> datastore.

"The client might want" is not a use-case = for standardization.

I do not understand the "pure view". Seems= like if this was a real problem to solve,

then NMDA would have included a system datastore fro= m the start.

=C2=A0

=C2=A0

/js

=C2=A0

=C2=A0

Andy

=C2=A0


--
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

--000000000000ba4dd605d2b95bce-- From nobody Thu Dec 9 09:52: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 E2F5D3A115E for ; Thu, 9 Dec 2021 09:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 XgzhplgnYF5m for ; Thu, 9 Dec 2021 09:51:53 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2109.outbound.protection.outlook.com [40.107.220.109]) (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 C27513A115A for ; Thu, 9 Dec 2021 09:51:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j8oevh8z4501WwJ9d/9znLaMOzQv7OdONvi6HnTK+09M+X0BVKn5ejEIWFgajsPud9cBO1LWQy2kVl8jGt0AvDR3uZ237u7EbJGcPPZcB86fqi6kThbQbkmjM30lETK2hvCvqpu0l8izY/y5CSmf/gEtoU3l9ejmC8Ddqp1sj3vnc8hy3q3ygja64y1Fx070+TPYd23ZL3NuKNYQzqYFsCnC0N/xEQVomMXX2j5n5pxQwb8BTDb9586v6WJ0gfdQLVIk6T26+yvajU7Lhhd3MyuS/ixDnwxZNxzqREe04jXFI/zwQzZzNvYH7iYuNgdbog3ZWGYudvAdXRMmKqqtJQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WRLfHwq45PoSo8BMHrYJEX4ioCUa0h45QXWNdYVUnbI=; b=Sks4ezWPRgOOlUWXWwJp2jUkZ+r5No2mJqqWAqfOvTKldMRLB52qaQ8p2TlgI9u+/nvMHMkcUxKbjNN+wIwXYGEvd3Mtbm8FS0RHgrz2CfxkN8UY7/HnVZ47CUdMK1daWOFt0p/GH/9EyaV9zsPFzApyHAGjnrXJQeYRx04ILKPWEV72PZx5Icg3j45ceGE6T/NZBMRRb9pYgPu9FMGY0QXBzPp9aQbs42QqSL+VIum9bnaA5R00AE2cG9xv85K213D6xUjc8JoIG/UyeoH4ItMMJhfZ1j/Ms4MpfQP//kW8/N3lsgosP/h15Vrz7+H2BJXFarOR+Xi0ddNl74F7cg== 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=WRLfHwq45PoSo8BMHrYJEX4ioCUa0h45QXWNdYVUnbI=; b=bVO1pG5cExqSbjaf4fidjku1vM3gPafLfQcFNnh7TCz58TqEFT1B8ZKTmKzGnZ0UmrfwzG6FXNtETiwHO/VTHy9LTjhzEGxbDuSUJmBrlLD0m7ZRdvyZ/6IL8oAP4XAscveZdK/qjfWgbq1WDT1vVzZ0h8KVUy6Zf1mkZzy5E5U= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5961.namprd08.prod.outlook.com (2603:10b6:5:157::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.19; Thu, 9 Dec 2021 17:51:49 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4755.025; Thu, 9 Dec 2021 17:51:48 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "maqiufang (A)" , "netmod@ietf.org" Thread-Topic: system DS polluting intended and operational Thread-Index: AdftJDTUHgXdkjwsR2+EQX3pIo8vsg== Date: Thu, 9 Dec 2021 17:51:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6fed251d-0333-4db4-a8ec-08d9bb3c9314 x-ms-traffictypediagnostic: DM6PR08MB5961:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BH/kehej3UuKSN3gfJ+vrAbbJA/hqPDsz3gYS92BZbAEXKfz0+WagP3v13WfTFpPkHsmBAFzeI7w0a66x0wqtw9le6lMbxK7z1B1tnCDdk63Xg7Ea6EwQmhC4MRUfGxNJMUGmXjyEUfPVd4pmUkYN0FSRpovK9O8F/BLDinLGkAWx8x5Sz8ENqBF1QDlpbjnNF0XAjecP+tJN/lVZ5FS+mN50c17Mi1BXfn7gw9L19L0j3GCAY6JjD/V07a1+sUjTLT6p5laiUuIWkCrAD/OY7kNhm32XohJhVK5KS0cYQIFZhoY1m1kjuVvpbcisbmt4lGwAlvufgNntiZYR1AMHDCBgxOmLQeIixLGiTyudnWJMvPb6Lu9mdT6cMqzr5ljVTEZKkP79oqsCeP1YM3RLEDdeac2RWKSI9NPJp2Vf+zSClg5+eSD46XK+IcIXoI6MVhYK3qFSyRbbEFfekeGnERZh1FL0ieH/TOETRb0ZPyjR9WtHvcBNMJ+GTsJDyWInkAEQmkqe9uUqLGLBJ9fMTzLMseENXqSx8IPc9uiZQWRcyz77m/PZF51JIrjTvKZgVCYhj7ZkO/VRalR6CJOpKys1ZwIZvXpKfRBg88AbI9LFkt0xF7jHlU2DRwwH0BvRLrKYPvHE5OpgCytv6SpMRHPAHwvrBYGO4M5KN3cBMsmK/tr6vm8hdqJFxCd5X9B8I9wJgCgT+S0t7n7yZeJGg== 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)(366004)(52536014)(5660300002)(122000001)(7696005)(38070700005)(38100700002)(9686003)(82960400001)(33656002)(8936002)(86362001)(316002)(71200400001)(2906002)(8676002)(110136005)(186003)(66556008)(66476007)(64756008)(66946007)(66446008)(76116006)(55016003)(6506007)(53546011)(83380400001)(508600001)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?FPl4Q3WrLRNqFI/58h6GCbyoMN0v0n2nfahB9+bnXebTM5Olb1dLoY6904Pn?= =?us-ascii?Q?xvyIRjIl+MCd3QS8okaAPeRMjfMZ1NnYx1BRnEmCKpmOICyiQcNFmOz/o2PX?= =?us-ascii?Q?UKySG0AEeNeVGJkF7OojuWnqFf8/Ot1jbejQ+GSg8rbOVO3cpvPomGJ+Z7ho?= =?us-ascii?Q?rJbw7te9pQseSskTaZSJFMcP1LCn7YcMLNe7qDVQRM3E682fNWsQL6dC+A4k?= =?us-ascii?Q?e8ZeBPxw0s25mSrJuxu56L/QhDg0oDUpwgU0LKKNwwpbYtvWhTD2stcLONzh?= =?us-ascii?Q?1ViHF6D8z+KPgPvY1/1JSBI1xo+olxjahE/UlN5DS+lk866X3ASZqodTPN4u?= =?us-ascii?Q?/w56IehjlPSRWcpoZVx4U3t2G5apxkYnw006rGLQUvyK7ljwdj99a3BdewfE?= =?us-ascii?Q?ZKGsVi2fw6PwirPsJgBMxigCaV1+nn2FMdVJ5XtvXi8/eA/fMbYDS0rvcsXR?= =?us-ascii?Q?jUuA1394XTqsS7IDTXMhT8ErtlIIKDLGFH4K2nLGf0Yk4kZ7eCHi0b00aTn/?= =?us-ascii?Q?DAwCRBjLCJTa02IytfS6vwsjZBVx3PmEtHYJAANPmqFaiSL4uavFKL7WYA2i?= =?us-ascii?Q?piIeewM7tccpjVleQEtyqU/ezQlhspPNvUN0ybLT5bROGxg86+C2QQ8BRUtp?= =?us-ascii?Q?ZLl10mVtzdf9sbss4Zn5i2iYq2jEjGwf7/IzqyhkpL4Bbgn+wjmkAA1OnXWs?= =?us-ascii?Q?G6EflrUot5xSP+A5V/Tr5nEATEOuyt2cZiiWuPuQPEKtZOvgnqlA/HUwlXy+?= =?us-ascii?Q?CNsLVKLam812u9rEukJ93ZHl6RmW2dzti7xiG/GEDecKbH7RSpRYXVBmSI0Q?= =?us-ascii?Q?pOuSRG5l4Zg2s5pzfUEhztTu/YYe3ZqJfa9n4rgi0Y+l36bOvvwaHsgVe/Do?= =?us-ascii?Q?nVAADpCsYyqdtkesiRlVRJGmCXQm2NJtihNQxmSvKcXND2MxWaUyzYSnWTed?= =?us-ascii?Q?c5Y0UoO027W8wFTmJgS2iSHmPEo5N383tZ+2HUI1XHNX5zUFlN3Yq59lj8MD?= =?us-ascii?Q?um7H4bIluBrNIxiVyTwhDm3BpgPN3amJtn5VO43uEDKFzXKX6iqXAd7l5Vj7?= =?us-ascii?Q?Wh3BD/dirRMc4ruaYxnwLKFNvzv9y5u6KxFXgY4R2tZwvNVpBCT8kMR520qm?= =?us-ascii?Q?ZcbAA4fKIPHcXrst+diLSxukQSqtcFXt+RCd2AjY5vm69eSRJGFMbAMBle2d?= =?us-ascii?Q?oD5gX3KJrkuLgwRow79/yZ8DDq0NlbXomWIcCTTzk4kD2YF/LbnZE4EqoHp+?= =?us-ascii?Q?vPy7jTOB74wkJt88a9RWgiD4wDoLiXsO5UrQifBY6yy9qVWiaSvY8MeVO+TZ?= =?us-ascii?Q?4XaLO6D21z2+1sU4TvoD5BpLcUXibK+9tR9TTRwIBeUMzFs72STZPTmlzN/l?= =?us-ascii?Q?SOgYw1lO/WoauCdDnFVUMns3FW+Ld9FxXWKBqmnuyfBwwnnIaio5He3yVLVK?= =?us-ascii?Q?tOrjWH2ccx/R6LUYB5oUfMSK8BE1JbzODYpekhm+fkeKYK6SW7PV9cnkycLj?= =?us-ascii?Q?27P8cn/GUIiRAS0TBFYu2qjABJ51T2e2h7K4gJOwE7KFlXVVYT4zME7y2O3f?= =?us-ascii?Q?0CsVpvciqt6h+GSHK6nB4UJHwjHzc6JEe6dn+Nl2s6qTFUdx7EFgpJybTWuZ?= =?us-ascii?Q?FA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084B9DBE725907D5F4576FE9B709DM6PR08MB5084namp_" 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: 6fed251d-0333-4db4-a8ec-08d9bb3c9314 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2021 17:51:48.7713 (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: Fco0q3DJzbIOJUIphGDO7lBDdo/Z0ZdIVTsWWOoso/pHYu4vBFTsYBVvIzgeYJgFkp6ZDzwaDn6WAcJau8afCA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5961 Archived-At: Subject: [netmod] system DS polluting intended and operational 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, 09 Dec 2021 17:51:59 -0000 --_000_DM6PR08MB5084B9DBE725907D5F4576FE9B709DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wonder if having all the system config appear in intended and operational= may be annoying. We didn't want to pollute running with 100s/1000s of line= s of unreferenced system config. So maybe putting all that in intended & op= erational is also ugly ? We should have *some* way that a client can retrieve system configuration t= hough. Some potential options (without system flowing 100% of its contents into in= tended): a) DS that can be read (but doesn't flow into intended or operatio= nal) b) a "with-system" extension (like "with-defaults"). Returns a merge of run= ning+system (or candidate+system, or intended+system). Maybe we'd also want (or maybe want instead) is a way to see *referenced* s= ystem config (either on its own, or merged with another DS). Jason From: netmod On Behalf Of maqiufang (A) Sent: Monday, November 22, 2021 9:58 PM To: netmod@ietf.org Subject: [netmod] Should the origin=3D"system" be required for system confi= gurations copied/pasted into ? Hi, all There is still another issue which is about origin metadata annotation: sho= uld the origin=3D"system" be required for system configurations copied/past= ed into ? Currently any system configuration explicitly declared in in orde= r to configure its descendant nodes or maintain offline-valid wil= l show up in with origin=3Dintended. The question behind this issue is whether we want a copied/pasted system de= fined data node to override and take precedence over . The choices and some considerations of this issue received so far: o Origin=3Dsystem IS required for system configuration copied/pasted into = ? I believe that "system" reflects the most accurate source in this case. = And only in this way, a server can allow a read-only system configuration t= o be declared in (e.g., in order to valid ) by the client= s. ? The challenge for this choice is on the server side. It MUST be able to = recognize a particular data node which explicitly defined in is a= ctually a mirror of what is in . o Origin=3Dsystem is NOT required for system configuration copied/pasted i= nto ? Good consistency. For all configurations explicitly defined in = , if they appear in , the origin value is "intended" with no e= xceptions. o Define a system-mode which is similar to with-defaults basic mode and al= low a server to advertise a particular behavior ? Does it mean we could get the Pros from both choices? Any other thoughts? --_000_DM6PR08MB5084B9DBE725907D5F4576FE9B709DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wonder = if having all the system config appear in intended and operational may be a= nnoying. We didn't want to pollute running with 100s/1000s of lines of unre= ferenced system config. So maybe putting all that in intended & operational is also ugly ?

&nbs= p;

We should= have *some* way that a client can retrieve system configuration tho= ugh.

&nbs= p;

Some pote= ntial options (without system flowing 100% of its contents into intended):<= o:p>

a) <sy= stem> DS that can be read (but doesn't flow into intended or operational= )

b) a &quo= t;with-system" extension (like "with-defaults"). Returns a m= erge of running+system (or candidate+system, or intended+system).

&nbs= p;

Maybe we'= d also want (or maybe want instead) is a way to see *referenced* sys= tem config (either on its own, or merged with another DS).

&nbs= p;

Jason

&nbs= p;

From: netmod <netmod-bounces@ietf.org> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 9:58 PM
To: netmod@ietf.org
Subject: [netmod] Should the origin=3D"system" be required= for system configurations copied/pasted into <running>?

 

Hi, all

 

There is still another issue whic= h is about origin metadata annotation: should the origin=3D”system= 221; be required for system configurations copied/pasted into <running>?

 

Currently any system configuratio= n explicitly declared in <running> in order to configure its descenda= nt nodes or maintain <running> offline-valid will show up in <operational> with origin=3Dintended.

The question behind this issue is= whether we want a copied/pasted system defined data node to override and t= ake precedence over <system>.

 

The choices and some consideratio= ns of this issue received so far:

o  Origin= =3Dsystem IS required for system configuration copied/pasted into <runni= ng>

§  I believ= e that “system” reflects the most accurate source in this case.= And only in this way, a server can allow a read-only system configuration to be declared in <running>(e.g., in order to valid &l= t;running>) by the clients.

§  The chal= lenge for this choice is on the server side. It MUST be able to recognize a= particular data node which explicitly defined in <running> is actually a mirror of what is in <system>.=

o  Origin= =3Dsystem is NOT required for system configuration copied/pasted into <r= unning>

§  Good con= sistency. For all configurations explicitly defined in <running>, if = they appear in <operational>, the origin value is “intendedR= 21; with no exceptions.

o  Define a= system-mode which is similar to with-defaults basic mode and allow a serve= r to advertise a particular behavior

§  Does it = mean we could get the Pros from both choices?

Any other thoughts?

 

--_000_DM6PR08MB5084B9DBE725907D5F4576FE9B709DM6PR08MB5084namp_-- From nobody Thu Dec 9 10:19:28 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 2BA913A07B5 for ; Thu, 9 Dec 2021 10:19:26 -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=unavailable 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 YSH9IO1xS3Zl for ; Thu, 9 Dec 2021 10:19:21 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130079.outbound.protection.outlook.com [40.107.13.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 4DAFB3A089D for ; Thu, 9 Dec 2021 10:19:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R4/ybB9XB+E1Soq5ei+MMjD3OHFvnqjnSs2O01SeNHhPEf0EAqgw0TGkLi2NWA5YyuRBl4hRS/MXnLIgEREwwhBnw8v+C8J3/POaY6D80GiKi/5Ff2JK5h8Dj2B3n9LvjvRRsBt99VZXZHNOj3AeIcZIY7u5kMrMLgM3viygfFkaI8vkDyj2FD8dJT2UPVSQHHiFw2SZJy2R7WNbKnamy071iYmHkiZkpVfTqzZjRXFOvmDBFGt4OVNTEFgTTREYNfSbQ/Sg/gKeKGI6hryiouX1TiIsGaUFTikcj1/jfyVj4hj+tt+LzjQJVDN/KgVFQas/lI8ME0F9vVlMb8SGEg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yfifnSzLUcTTAvklRkC+qloyXPpZsHDXNqE1Qh3SvDc=; b=dhhEvXgbn9xdzLFY0bOTROcqj9UnDi7wTuvHK57c711/ClnNTQ/WCaEW39uZxLy/QvXz9fjmmHirNtBc5hafwcqqn03jibFw+2iP/Sknnzlr8t4brdGV9ncroznPVRV2dP0OEsBjEeqmsAKEj6FVc0xUZ37ybpfaxR8t6edJGO58REKKr7oGAPn/LOOyanFF8/GCAy0lfZk81S4ESg3uliq09snwNYrBLplEd1VlZLH3weDwIw36QF1+e+LnwQaKW3CwGPL15dxrxCeU5Ys2rU2qena5rTQqcaG3wsZFoMJSie62hQw7bLQdYTWDA/wnve3qiKrP6X9ccDTp6R505A== 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=yfifnSzLUcTTAvklRkC+qloyXPpZsHDXNqE1Qh3SvDc=; b=PqBuPkD9ZqBuH9bziB5IE49seMRxNZNX8chH3ASmjKQ2Kv5gL/buDu4IbrqyMtlGof2NmRwSOdCz53Gyql/qokJD1G4yru6DckjcKwcnkoFhySt7vdyTjgbHpISMVfpsfyAjzaRQKIGeAGGBqGtKutJYgNpjPbylFpnLVHPBCes= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0115.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:5e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.20; Thu, 9 Dec 2021 18:19:00 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8%3]) with mapi id 15.20.4778.013; Thu, 9 Dec 2021 18:19:00 +0000 Date: Thu, 9 Dec 2021 19:19:00 +0100 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "maqiufang (A)" , "netmod@ietf.org" Message-ID: <20211209181900.imnvmxjywszmgnwz@anna> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "maqiufang (A)" , "netmod@ietf.org" References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AM0PR06CA0092.eurprd06.prod.outlook.com (2603:10a6:208:fa::33) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9bc990cd-0161-46dc-9a81-08d9bb405f9e X-MS-TrafficTypeDiagnostic: AM4P190MB0115:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3968; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EVoHeZWmD6XpDhVyZNRmoHfDmvM3mxJPa9QP7zFyIAWPJ/Y3VqCZLhjFMX7pJuU5588gjQiEE9Fp+dyZA4R0ctSkmmSPiBdB754D0o7cv3Zlm+19eR2nszQCf9QkiCvzYuoS/9HF1VGvD0q6RmHgqWCIWz1FZOIfu36DJqVOX9JoNjbtWrU0D528D/5je4rpTU5a1NNYxgirZtGkAEqOxxOnDcWB77pK0HRZf2lHIH4qQm6OflhFL/tWEisEk+OHxcllVVvYPR3K+ti68l2BtuCzONkU+lPH9yYcTSI4eRbbGgcxtrXhqfejjM9nQiXJ+hPclmxOU69Pc+ML+P6hb+bC36dc2cJX9dTLMOvdI5a9oj/xGDuiHEHBAV5K8+9nsUSfMFohn/E28VLlArJv4Zki/tpzaU3UsZ+CoU1wgFOviWpLqJa3oDzaebcWPa9OtZUFsfXtVY1TmuVRwaWH5g/vLrx4dVSvckH3KquEMsr1pHzv/sQee1h3x2H5KziRUWwZOetLgad0cae7LEjHq38u0IhBUSpWKZ647SjbKT7t5oHlJFPOh9ZMq0yMcxSrFrZHiKcY2XL1Dbx5cdIN94us9c7Q6b9/pL/X1GiSZXhwe3QqCJ5yEBbUInnGf5Q6wgzgJ/t/sluhhzPM1Jy3EXR18KP5+yyArH3XaAHxdHDbYeAAuF9vpkVHGTGRbMtsN7U/sdfXwaziyIavqD6p5WH8HwEIoFNxeV7W8ETNEVygwiaWAYMAKUQ35Hxzu4e8NX5wKBjN/xLM5jlWqS14BWq13BgrFYKPvGCjqwimd9g= 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:(7916004)(366004)(85182001)(6916009)(26005)(3716004)(40140700001)(6506007)(2906002)(3450700001)(66946007)(498600001)(38100700002)(38350700002)(66556008)(66476007)(9686003)(8936002)(4326008)(8676002)(54906003)(6512007)(5660300002)(86362001)(186003)(6486002)(1076003)(296002)(85202003)(52116002)(33716001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UGwvQzkxc3JBNzFYSUlJMVFkMGZ3N1ZNOWxJYXdjakMvWjgxc1EyVk5CVU1k?= =?utf-8?B?YUR5Y1puQ1FMVFpXUXh4anY1dzZHZHVIWlk2VXZLZXRxaHdRZG5qc1FGb041?= =?utf-8?B?aHZRdU5IRGlaRlRrOUc4SmNXY2FuUE5CNjQ5anJxclJUSUFlRlA4bXR3T0tu?= =?utf-8?B?aGwzL0psS1V3Vkhqb2hCdGNXQ3BvUXAxRmxTa2pLZnE0dU8wZWZCaVhjcDJO?= =?utf-8?B?K1ErcnRvY1NoMzlobFlFeFB3RktmNjc0QnQ1T2d3T29QRVpsTDl0eDNWZnYr?= =?utf-8?B?Z0pWREtMdUxiVnJkaldVN0JiTXhRRyt3UmcrWEZHcER1cWZhVmRRZnJ6L3k4?= =?utf-8?B?am1rTktSb3BUY2FQemdDamI1QXJUT3ZTOEZEaktKVU1KeVhyM1EvMHd2akM0?= =?utf-8?B?U0hKb2QyU3d2YTl3V0hBYXB4ZXR1b3g3MlpGOVhLNXFEazcwL0tXcTZLRG5x?= =?utf-8?B?bTJhZzR0TExxTm1XRGs2dldUcVRsaEdWYjNteWJWQWZEMnRYaFVpNjRuUEhL?= =?utf-8?B?c3h3VXdTQXptdzZSZUxWQ1V2TmlZR01abUlxeDNiTFlxdHBQbmUvc0kwWmFI?= =?utf-8?B?eUt0eHlsTTZKTjlTeUtDOXpjMXRYMzBCTkpPOHNhL1BvMDBFcGxUTzJuSWhk?= =?utf-8?B?ZEVpaWJXMTVmUXhDMEV2Y2d5UVpZb0I3Sm1ESlZPOTBsKzBTYmpQcFhwUlkz?= =?utf-8?B?UDIyc3J0MGRScTdHUVU2b2xNRE1NaTM3ZU16TW1tTlVFaEJ5RGFIUzJxRys3?= =?utf-8?B?ZXQza2k4aTJPdkpaTUVpbVVKbzVnNk9wRkV0ZjAySWxQY3EwaGFKcC8rNGFu?= =?utf-8?B?dXZpSWxtMkY5Y3FkbFpEZ3FyT0dQaTQyWVF6TERPV0xrTjlWQk8rOTRGQWUz?= =?utf-8?B?WU84c3R5VUpZQTFZR0lMc3lWK2dXb3lsTEs3bDExbGpLL3hoTUxPN1Q4SlJp?= =?utf-8?B?YS93d1luemZOR1NXdEJmdWRhK1RCR2I4eTAxUVRiTVAwMVhEcGtZK0h4aHdQ?= =?utf-8?B?U0o4dHpPZlBaekp5SzRTYzFEeC85cW9NRzhmMHdwWWtxMEZxQnNoOHpjYkdM?= =?utf-8?B?SkNXbERodzFwbVJwelZFU09ZWVR4WUtnejJvaW5Db0FNRHI4ZXBVdHRzYjhD?= =?utf-8?B?ZVROVjg3Z2JMZjI5R0RVWWhNd214VGxiL2diN0RtL2Z0WUYwMi84bVE4c1ly?= =?utf-8?B?eCt1LzJTbWdybmsyeWk5YWkveUNGMittWFdWY1RnczRWTkNHMjdYdG9zcEdF?= =?utf-8?B?Uzc3WDhEYVYvSFlQeVZGSjRvK3ZQenBGNnUraHhIM2dhVWI4Ync1ZDdLQmM5?= =?utf-8?B?TnpXTk01ZVpPUCtjWUdiYVdHeCtxRUEydk5iYjZvUWdVM1dFMTRZQ3FhVGU2?= =?utf-8?B?cnphbVErWXo1Y3FxU0RQM3lZV0s5MTB3aDhocTdnbXdwRWlPT0s1czdhbElE?= =?utf-8?B?ajg4OTVMdTQvUFV6MnVDNkFvdTF0NnhKZEZaSkV1VFJNRzhScmoxbXNSMHhW?= =?utf-8?B?Y1Jid0Exc25DbjcxMmVnMjltamtMaWpRRFN6bkNQVnl3UzF0YXVhb0UyQTUw?= =?utf-8?B?WFdIOVJ1QlJTbTdPdmtKdEM0QWdqS2JWTW1jVlhnc3BwM2JMWFVrcE5aN1p1?= =?utf-8?B?NTBJajUzWDE5NWw0ZFp6ZXFsVHVZT2d0RHB2YndPM3VnYmhKRTRCTFZUSG1o?= =?utf-8?B?OEhNcDBRY3EyS2lzOFRKcy9xb3VaRUJwaTNSbnNKVWNucGhidXhyb0tONndS?= =?utf-8?B?OTc1Y1UvbklFMzd6RjZsdWZSMXBZVktrY2xIRW5zTWZXMzVwc0k5QnpFbWpJ?= =?utf-8?B?Ukx2QnZuV1JyTVEzekZjd3RMWWNBYVp5aThORFhmWGoweFFNR2VvOTZzV2FI?= =?utf-8?B?OHA3d0tuWUdEM2JZR3NrN2xFL1NnWTZVRnFYM2xPeEFKbEtSNDFmVGVKTndB?= =?utf-8?B?cnFsL2dJV3BGRERZU0x2Z1FZVmJrdnJ3RFhZcjJmYmpKUzlTL21ic0VXOUgv?= =?utf-8?B?ckt1TUdaVlcwa3krU2t5WGZkKytld0hkY3cvd1pjMUw2WFZ0WHRERnp1ejND?= =?utf-8?B?bmc2TUFHbmd4b2w5TmtBNG9rNDhVOUJJN3ZOc2JycHZzVkx1SU9qR2dzdURJ?= =?utf-8?B?aGlLcVhYdXpyUktxVkVTVXVOZ3krenlMclU2Z1JHRThkQ1RjSTNDK3VCcmdk?= =?utf-8?B?OWFCNWVic25PWjgzck5TZ1JYNXhMVHd5Rzl1Y1pDRC9Md0JyaFIzcDVtRTdz?= =?utf-8?Q?XXNrBykHPRphbSXo+dtSSQhyj+hlvwqNsu+i0gptvo=3D?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 9bc990cd-0161-46dc-9a81-08d9bb405f9e X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2021 18:19:00.6791 (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: +YFt4+QZXOLoMkof2pjCQ6lsPeHYt5EdTOZGud083cbRFqXlGda2RcGsrD4AuDzejzuZWRP8D7F+kO0nOzej7ii6QzpayWsPcqI4CvnKspE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0115 Archived-At: Subject: Re: [netmod] system DS polluting intended and operational 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, 09 Dec 2021 18:19:26 -0000 On Thu, Dec 09, 2021 at 05:51:48PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > I wonder if having all the system config appear in intended and operational may be annoying. We didn't want to pollute running with 100s/1000s of lines of unreferenced system config. So maybe putting all that in intended & operational is also ugly ? > The applied config, part of operational, is the config that is actually used by the device. RFC 8342 has the details. > We should have *some* way that a client can retrieve system configuration though. > > Some potential options (without system flowing 100% of its contents into intended): > a) DS that can be read (but doesn't flow into intended or operational) > b) a "with-system" extension (like "with-defaults"). Returns a merge of running+system (or candidate+system, or intended+system). You want to rewrite RFC 8342? > Maybe we'd also want (or maybe want instead) is a way to see *referenced* system config (either on its own, or merged with another DS). The 'referenced system config' has to be in running since otherwise it can't be referenced. /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 Dec 10 10:11: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 B0D953A0A50; Fri, 10 Dec 2021 10:11:21 -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, RCVD_IN_MSPIKE_H2=-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=att.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 RoCWAsFOJJrM; Fri, 10 Dec 2021 10:11:17 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.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 3963C3A0A4F; Fri, 10 Dec 2021 10:11:17 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.1.2/8.16.1.2) with SMTP id 1BAHXSE6015150; Fri, 10 Dec 2021 13:11:15 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 3cv8xync6q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Dec 2021 13:11:15 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 1BAIBDDN023729; Fri, 10 Dec 2021 13:11:14 -0500 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 1BAIB9ZD023483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Dec 2021 13:11:09 -0500 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id 7EC9E4009E8A; Fri, 10 Dec 2021 18:11:09 +0000 (GMT) Received: from MISOUT7MSGEX2BA.ITServices.sbc.com (unknown [135.66.184.217]) by zlp27127.vci.att.com (Service) with ESMTP id 621B34009E84; Fri, 10 Dec 2021 18:11:09 +0000 (GMT) Received: from MISOUT7MSGED1AC.ITServices.sbc.com (135.66.184.173) by MISOUT7MSGEX2BA.ITServices.sbc.com (135.66.184.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Fri, 10 Dec 2021 13:11:08 -0500 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGED1AC.ITServices.sbc.com (135.66.184.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17 via Frontend Transport; Fri, 10 Dec 2021 13:11:08 -0500 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.46) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.17; Fri, 10 Dec 2021 13:10:59 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DvHbg2buoyk1Wnz5yem6c9KcM+he+/KOvSoPnBAcZZTu0OH1GCCQkIOBbBNlBOHtU0qfQnUICma5QRlc0sMMzfqXQIyGjnaL+9xavJqEDGHat8uRcuWcDFOJyzYBWDlz4p1L6a5knbe/QNAG+nhl59bcH42z39FwzazHSovc7xzBk5/SKm1WzAFoDpw4cy1q+aO/g+PHjQnhtODljkVrJHqUwTYvrNSGUWW+SXDW2CKR2jyPjwfiZze865FtifyqtiMZpSI2hwAhPwKkSUv47qTqodZ170EyDL0a1qJNSVFdNjNpYZRGYEQ/W9e+kWJlVeEQ2l+w9IV0UX/+8GjfeA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zW/0VeXU5ruYVcjTcSnHLr8vyaWJaf6jdHiHNK7grJg=; b=hOj8auD4c5mEYrcQUpnCaxQiPVwWl+l3wfilUVQMc2DVfr/f2FDCK5xVZtrgRst4dvFWOK6CEbSyYtvHH4TJbig/4WG5QkTyKvaR9RUXmxHiYVH8C8iwLbG7pgQYZrQ/n1UnRqfbg80HCBPtV1dwcLOI3wuUSOQXC2ZiyHJQU5Bpp+mS1wulnhTzryHLj0tS/vGFkxTK2FjHtC/eHratN4QCppf+AUwaZa6V7irKy6unaqXIlRoxXlQp6+ixk8JUW1ZV+MxrivY/7jwlJI2ZDw29JHHRZ9yC/sMVY7U0na7yXFb6xGFl8ceDFYFNgHYBbJpX/e4frmt9iEpsHuKLXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zW/0VeXU5ruYVcjTcSnHLr8vyaWJaf6jdHiHNK7grJg=; b=ORMPYOL6QzRs6DoAHX4WFVUNYd5tb/lF5po4wMDXqB994uwrWQaAqu/vB8b/kO+cILUXYTePNeBYlOeen3Ut9iWwcLQfhYlk6FHN+r3dCWx+9UCFk0MgcpSUNq1q3fgpYbHWgNRLa2D/EvewipB8sDBGJKymW6KZ8k+ogxkuBmQ= Received: from CH0PR02MB7980.namprd02.prod.outlook.com (2603:10b6:610:105::17) by CH2PR02MB6277.namprd02.prod.outlook.com (2603:10b6:610:6::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.11; Fri, 10 Dec 2021 18:10:58 +0000 Received: from CH0PR02MB7980.namprd02.prod.outlook.com ([fe80::f170:596c:6616:4df9]) by CH0PR02MB7980.namprd02.prod.outlook.com ([fe80::f170:596c:6616:4df9%5]) with mapi id 15.20.4755.024; Fri, 10 Dec 2021 18:10:58 +0000 From: "MORTON JR., AL" To: "bmwg@ietf.org" , "netmod@ietf.org" , "yang-doctors@ietf.org" , "rwilton@cisco.com" CC: OpsAWG-Chairs , "opsawg@ietf.org" Thread-Topic: WG Adoption Call for draft-vassilev-bmwg-network-interconnect-tester-07 Thread-Index: Adft7hit5e8+fa6UREqILemtWXJ/nA== Date: Fri, 10 Dec 2021 18:10:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa033380-1d66-4a28-5f73-08d9bc086a69 x-ms-traffictypediagnostic: CH2PR02MB6277:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8Uh/ABz5fEy7V1PLUJkgfJxaILEdau7cQfMW2Y01qGvaHsFZhvC8AYicqb+8O5eyjt1oZud9ps7nAjRRWAty1TeztGNe7HMgkxLXUM+NUcnCqKKisFGSmjXepIDMLCJWLhzV/l7pXqR2grU9Ysu03vc+XImgfxYXY6Off5vKIxTnzSAS3LkfNErYskPtYcE2O4CAvkOeAPKOLePmV6OzvDPNazCHhgnC7q9aJggDa/yL1INKlgQQ7Kz9z5DpcUSZHjey/6LL7mXo2fOd2MqY7OVwlVOlUq3FCVoFbk8hs9aWaIDTtKQ4n+RfZVdBsSxV3qIO14xo8bhNnMpKp41z5SPwFdUVcUIXHydgfncCVjYqa5IPWr0e8LtTmBzGKpdFWD3luzheIjkSVniRnnx+kNcm+rk85ckUgUJBZmcxP38hsXIQMGl3nPiSUltursHlID+MXV9XOf8yqIGwqX80RFJPA+ODIdjMm6RoD6DnOmIlaoPHn7tEi9vp6bNynSfZ8ZODJzpxvt7OSYZCSeHh8eUSZW6LwReNE0WmQoqPUUystA6Oxxi6Fsq734t9uFCqXqt6dWh2VryAOShlOqtx+orvvBZs6hMLM8MO97X2rAgH2nyNXip7/evsry/CBglxXQROAJtJm/SLPCsl4ghN1l91xi0U+19U0jLepwx2HjrzlusD1QtWc1W9566VrB9zEdcz61z2HTbTSKTYuW8Sd42jCINw9HDE1uNoQIWnsmmat3s5vNI1JY4rNLY65RqAa5hor+M5IAi1YcEBSiNfWDwFYzFS/99OI6d1eUZ7+Vz+uu4XrHAXdbPj+gkwuzSx x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR02MB7980.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(54906003)(52536014)(82202003)(508600001)(33656002)(71200400001)(55016003)(82960400001)(86362001)(83380400001)(66574015)(38100700002)(122000001)(38070700005)(8676002)(110136005)(5660300002)(316002)(26005)(186003)(4326008)(66946007)(66556008)(9686003)(66446008)(64756008)(53546011)(6506007)(66476007)(966005)(2906002)(7696005)(8936002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NjRURnR4azlWUklnS0EyOTNhSEo0Nk9WYnRtMUI2Q05HWmRtWS9pQWJ3eHR2?= =?utf-8?B?cGd1OFVtQTZYRlQ5YTJuellCRTRPbVdEN25oaWFZa016MndWVVJnMEpaMWpk?= =?utf-8?B?RHhINHU4Z1E2aHlFcVRKcnRXZVdSUk1LSjAyWFBWck5wZHdnNEZCL3gxY1Fv?= =?utf-8?B?M09ma2FaZThaSU1xR05xdldTZk9zdFYyM3d4QzhwV0Fnd2M3N05pWjFZcUIv?= =?utf-8?B?T2dPSlpmVDNHdjJSUW83L1lkOVNMS3hmUDFBQ1Nad1FQcldMUTkwREs3a2Vk?= =?utf-8?B?NzY4MVdMa0c3WkVia1dsY2UwODdlWTl1VHFJOU9ZWHU4NkRLTndGYkxSbFA1?= =?utf-8?B?R01IT0hFbVlqdlRtK1RVdmpVTjJRS0pEdlIzVHVQSEphZSt5S2FoMmNPSDR0?= =?utf-8?B?UENQYmY3VHhreG9id1V6Z2ZIai9GT09mR1pSZE5xQmVwaFRCaGZCSThWVTFC?= =?utf-8?B?dnNRNnR6MkJEMStKNHJadlBsbDFwZDZqU3ViOFYvUFgzVlNWZkM3UjY1OGd3?= =?utf-8?B?djBQN21zcURrUitZVlFmM1oySC9Fb1l4MlpBOXdkQWxNd09GUzdPeHBzTHRZ?= =?utf-8?B?cXZOcG53LzVSeDhIQnlqZDRnNGhZbWZMWTRiUXRqZDFjQ2RpL2E4NFl5VUZp?= =?utf-8?B?Nml0d21mSy8wSGNXbnVzcndjL2ptTnFnRU10VjQrcDFoV1ZGUWFQTUNaREtu?= =?utf-8?B?c0FXV1NMdXc3MnRkL3BKaDNrRkwyNzRjN3RTcHZvWXBIMU9rNVUrSWNpaUJ2?= =?utf-8?B?WGJjNjJuRjc5TzJKb28xd25jZi9vV2RQNlZjajJKMlE1YzhvVUJUdnRmZnFj?= =?utf-8?B?alIyODdXZmlsNG1weDNPQndkaHZKZDhRM1NIYjBaMWs1dmphY2RUdjMzYW9B?= =?utf-8?B?WFNpNnJ3M0lVNUFOeDNabHZYSzhYR0dVV1pLT0hNclVYSHF2bG9LVzhxVW1t?= =?utf-8?B?bTRHMEpKeFgveWRZMnV3bUNkZmxBcDV6V3BLSnA2NStlNU1LNzBxeGtpQUVQ?= =?utf-8?B?d090RVplRm14OFBiMUlCcXpQKzVrTDZpekMvbXAwc21VUk5FeFdFaS9LZlpz?= =?utf-8?B?WGdtemZWYnpYUWtjL2xtK2hudXJLYWVMUEZDSk1sYWJxb1hsVWtTaXArZm90?= =?utf-8?B?Uk5JZEhPQVNTTmhtRGhPQTJzZ1g0RHNIdmNRTHgra1piSnVEOTh0S09hTkpy?= =?utf-8?B?NmRnN0JDU3lhaDZSNVlra0o0L3QxSVdlZmc4ZnI1UzZFUXBDM0Z2cU5vekkz?= =?utf-8?B?S0F2ZWNweVI2SWluNUZFWm1pT3FTNWtsUjcxMDdZSnB0QmNrR3pROCtHM0lO?= =?utf-8?B?VDlqdWZ0VE5oZkw0akNLcXpPdWFLbXl1ek92MmU1WGg2SnJ6RWZaTTgxRFQ1?= =?utf-8?B?NEw4NkhOd1lLZGR6Wm1xeC8ybEhhRkE4VGZGcUpGdDRVWk5hQjdyd09zZXIv?= =?utf-8?B?YjZGeE4rd1QrUDlsMUhHUnFnWXdjVkxOSnpOelhNWEl6dDl2VWozTWZuWnpJ?= =?utf-8?B?VlduWlBPRzFwRzN1Y1BwQnJIV1doaUY4UjQ0VU95MjZaOFpnVHFSa1RBSGdo?= =?utf-8?B?enRUNHA1RFBNSmpqRDU5eWVvR3Z5NTA5aWlBcXBYemFoUWtsVm9BVk9vc05k?= =?utf-8?B?dHphMU96bUs4R0c1SlBoT3R0cDd3WWlpQVkwaVo0VjkzVnJ5S2JMWFdPN0VN?= =?utf-8?B?Y3lvUE1YZ1dLS3NKcklFSFhxbGZmY0Y1MlVaMzBGYXk4cHM0QlNwaUx5K0J4?= =?utf-8?B?b1VOVElicjU3LzF6MDJGWWFCTUhBejJxWmE0R0NpWGZtQ2Uwb1NFN0d2WUwy?= =?utf-8?B?cm02VDVjbnpsU2VQN1FFZUpneFVOQjZXS0M4T0JIY3FjK0VxWlpuaWFaS3V5?= =?utf-8?B?K1VKUVM2c2RoaVBLcytwVDV1clErQk9iYUpqcERUWVErZGozd3NOVllJTXE0?= =?utf-8?B?blVla0haVW9QeFIvdmlVZ3BBZXN2TGo5Ym5QbkhHQ3M2U1llbFdUdXpGZWZ3?= =?utf-8?B?WGRQVG9waEVRR2JpaUc1SjIyWkZuN0tUclJPSTVhcnpGdFdmS25CaW8rSFg0?= =?utf-8?B?dEpjN2VDRHpoeG1xYkVGUDcrdlZpaGhJYklIdz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH0PR02MB7980.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa033380-1d66-4a28-5f73-08d9bc086a69 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2021 18:10:57.9959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gXeKAZxJhGrhzAmUpCxWcilX44Lk1m1tgOJBZ8P4cjBL//f5O4e546oOYT0ExW6w X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR02MB6277 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 339A688FE10F7EB25AD199CC01CEFD9F77BCD576F23020E5026D845D06BD35D52 X-Proofpoint-ORIG-GUID: ASRa33iulhDVSHOJO9aeSTVe9RKu0f-C X-Proofpoint-GUID: ASRa33iulhDVSHOJO9aeSTVe9RKu0f-C X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-10_06,2021-12-10_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1011 spamscore=0 mlxscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 impostorscore=0 bulkscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112100101 Archived-At: Subject: [netmod] WG Adoption Call for draft-vassilev-bmwg-network-interconnect-tester-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, 10 Dec 2021 18:11:22 -0000 Qk1XRyBhbmQgb3RoZXIgT1BTIFdHLA0KDQpCTVdHIGRpc2N1c3NlZCB0aGUgcHJldmlvdXMgV0cg YWRvcHRpb24tY2FsbCBmb3IgDQoNCiBkcmFmdC12YXNzaWxldi1ibXdnLW5ldHdvcmstaW50ZXJj b25uZWN0LXRlc3Rlcg0KDQpkdXJpbmcgb3VyIHNlc3Npb24gYXQgSUVURi0xMTIuIA0KDQpUaGUg bWVldGluZyBhZ3JlZWQgdG8gcmVwZWF0IHRoZSBjYWxsIGZvciBBZG9wdGlvbiwgd2l0aDoNCg0K KyBQcm9wb3NlZCBBZG9wdGlvbiBhcyBhIFN0YW5kYXJkcyBUcmFjayBEb2MgKG9rIHdpdGggb3Vy IGN1cnJlbnQgY2hhcnRlcikNCisgQ3Jvc3MtcG9zdCB0byBuZXRtb2QsIG9wc2F3ZywgeWFuZy1k b2N0b3JzQGlldGYub3JnIGFuZCByd2lsdG9uQGNpc2NvLmNvbQ0KDQpHaXZlbiB0aGF0IHRoZSBo b2xpZGF5IHNlYXNvbiBpcyBhbHJlYWR5IHVwb24gdXMsIHRoaXMgd2lsbCBiZSBhIDQgd2VlayBD YWxsIGZvciBBZG9wdGlvbiwgZW5kaW5nIG9uIEphbnVhcnkgNy4gMjAyMi4NCg0KQSBVUkwgZm9y IHRoaXMgZHJhZnQgaXMgWzFdLg0KDQpQbGVhc2Ugc2VuZCBjb21tZW50cyBhbmQvb3IgaW5kaWNh dGlvbnMgb2Ygc3VwcG9ydCB0byB0aGUgYm13Zy1saXN0IChibXdnQGlldGYub3JnKQ0KYW5kL29y IHRvIG1lIChhY21vcnRvbihhdClhdHQuY29tKS4NCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMs DQpBbA0KYm13ZyBjby1jaGFpcg0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC12YXNzaWxldi1ibXdnLW5ldHdvcmstaW50ZXJjb25uZWN0LXRlc3Rlci0w Nw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGJtd2cgPGJtd2ctYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFZsYWRpbWlyIFZhc3NpbGV2DQo+IFNlbnQ6IE1v bmRheSwgTm92ZW1iZXIgOCwgMjAyMSA5OjUzIEFNDQo+IFRvOiBibXdnQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbYm13Z10gV0cgQWRvcHRpb24gQ2FsbCBmb3IgZHJhZnQtdmFzc2lsZXYtYm13 Zy1uZXR3b3JrLQ0KPiBpbnRlcmNvbm5lY3QtdGVzdGVyLTA2DQo+IA0KPiBIaSwNCj4gDQo+IElu IHN1bW1hcnkNCj4gDQo+IDEuIFRvbSBQZXRjaCBwb3N0ZWQgYW4gb2JqZWN0aW9uIGJhc2VkIG9u IHRoZSBwcmVmaXhlcyBmb3IgdGhlIHRyYWZmaWMtDQo+IGFuYWx5emVyIGFuZCB0cmFmZmljLWdl bmVyYXRvciBtb2R1bGVzIGJlaW5nIHRvbyBzaG9ydC4gVGhlIG9ubHkgY2hhbmdlIGluIC0wNw0K PiBhZGRyZXNzZXMgdGhpcyBjb25jZXJuIGFuZCB1cGRhdGVzIHRoZSBwcmVmaXhlcyBmcm9tIHRn Og0KPiAtPiBudHRnOiwgInRhOiIgLT4gIm50dGE6Ii4NCj4gDQo+IDIuIErDvHJnZW4gU2Now7Zu d8OkbGRlciBwcm92aWRlZCB1c2VmdWwgaW5wdXQgb24gdGhlIFlBTkcgZGVzaWduIG9mIHRoZSBt b2R1bGVzLg0KPiBSZWNvbW1lbmRhdGlvbnMgdGhhdCB0aGUgd29yayBncm91cCBjYW4gdGFrZSBp bnRvIGFjY291bnQgaWYgaXQgZGVjaWRlcyB0bw0KPiBhZG9wdCB0aGlzIGRyYWZ0Lg0KPiANCj4g L1ZsYWRpbWlyDQo+IA0KPiANCj4gT24gMDgvMDkvMjAyMSAxNS4zNSwgTU9SVE9OIEpSLiwgQUwg d3JvdGU6DQo+ID4gQk1XRzoNCj4gPg0KPiA+IEEgV0cgQWRvcHRpb24gQ2FsbCBmb3IgdGhlIElu dGVybmV0LURyYWZ0IG9uDQo+ID4NCj4gPiAgICAgICAgQSBZQU5HIERhdGEgTW9kZWwgZm9yIE5l dHdvcmsgSW50ZXJjb25uZWN0IFRlc3RlciBNYW5hZ2VtZW50DQo+ID4gICAgICAgICAgICAgZHJh ZnQtdmFzc2lsZXYtYm13Zy1uZXR3b3JrLWludGVyY29ubmVjdC10ZXN0ZXItMDYNCj4gPg0KPiA+ IHdpbGwgYmUgb3BlbiBmcm9tIDggU2VwdGVtYmVyIHRocm91Z2ggNiBPY3RvYmVyLCAyMDIxLg0K PiA+DQo+ID4gUGxlYXNlIHdlaWdoLWluIG9uIHRoaXMgdG9waWMgYnkgcHJvdmlkaW5nOg0KPiA+ DQo+ID4gKyB3aGV0aGVyIG9yIG5vdCB5b3UgYmVsaWV2ZSB0aGUgd29ya2luZyBncm91cCBzaG91 bGQgYWRvcHQgdGhpcw0KPiA+ICsgSW50ZXJuZXQtRHJhZnQNCj4gPiBhcyBhIHdvcmsgaXRlbSwg Zm9yIGV2ZW50dWFsIHB1YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KPiA+ICsg eW91ciBjdXJyZW50IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCBmcm9tIHlvdXIgYWRvcHRpb24gY2Fs bCByZXZpZXcNCj4gPiAocmVjZW50IGNvbW1lbnRzIG9uIHRoZSBsaXN0IHNob3VsZCBiZSByZWZl cmVuY2VkKS4NCj4gPiArIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgd2lsbGluZyB0byByZXZpZXcg bmV3IHZlcnNpb25zIG9mIHRoZSBkcmFmdA0KPiA+ICsgZHVyaW5nDQo+ID4gZGV2ZWxvcG1lbnQu DQo+ID4NCj4gPiBTZW5kIHlvdXIgY29tbWVudHMgdG8gdGhpcyBsaXN0IEBibXdnQGlldGYub3Jn DQo+ID4NCj4gPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBbMF0NCj4gPg0KPiA+ IEFsDQo+ID4gYm13ZyBjby1jaGFpcg0KPiA+DQo+ID4gWzBdDQo+ID4gaHR0cHM6Ly91cmxkZWZl bnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZg0K PiA+IHQtdmFzc2lsZXYtYm13Zy1uZXR3b3JrLWludGVyY29ubmVjdC10ZXN0ZXItMDYudHh0X187 ISFCaGRUITNWUTV4a1FDTEMNCj4gPiBPeF9RYmVhUlpNWU5iS2NyVF9uV2ktaHJfRWtYbHE1OXNs QzVWTEdUOVhuNG1uZWFvYyQNCj4gPg0KDQo= From nobody Fri Dec 10 17:07: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 CC5893A0B3C; Fri, 10 Dec 2021 17:07:23 -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, 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 yLuNEWZPFegn; Fri, 10 Dec 2021 17:07:18 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B391C3A0AAF; Fri, 10 Dec 2021 17:07:18 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 499) id 2B90718505F; Fri, 10 Dec 2021 17:07:17 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netmod@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20211211010717.2B90718505F@rfc-editor.org> Date: Fri, 10 Dec 2021 17:07:17 -0800 (PST) Archived-At: Subject: [netmod] =?utf-8?q?RFC_9144_on_Comparison_of_Network_Management_?= =?utf-8?q?Datastore_Architecture_=28NMDA=29_Datastores?= 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, 11 Dec 2021 01:07:24 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9144 Title: Comparison of Network Management Datastore Architecture (NMDA) Datastores Author: A. Clemm, Y. Qu, J. Tantsura, A. Bierman Status: Standards Track Stream: IETF Date: December 2021 Mailbox: ludwig@clemm.org, yqu@futurewei.com, jefftant.ietf@gmail.com, andy@yumaworks.com Pages: 16 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-nmda-diff-12.txt URL: https://www.rfc-editor.org/info/rfc9144 DOI: 10.17487/RFC9144 This document defines a Remote Procedure Call (RPC) operation to compare management datastores that comply with the Network Management Datastore Architecture (NMDA). This document is a product of the Network Modeling Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Dec 12 13:17:12 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 CCF963A0B6B for ; Sun, 12 Dec 2021 13:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=sandelman.ca 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 KLKi_0k0JmSm for ; Sun, 12 Dec 2021 13:17:05 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4B23A0B6A for ; Sun, 12 Dec 2021 13:17:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0764438AE9 for ; Sun, 12 Dec 2021 16:21:04 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HedaOoMew42m for ; Sun, 12 Dec 2021 16:21:03 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 072EE38AE7 for ; Sun, 12 Dec 2021 16:21:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1639344063; bh=XFjqnaYRWLPYM4PX565MU2g9KZRUOfOdDQvQFGKUmFc=; h=From:To:Subject:Date:From; b=ionTQOqHriO+iGMa++TTMm9XWiozXiSIk7L4+NeLBBh3UXqKaH/RKYdK7aMvRnXri vN1sxynx2XFjBsmwFfCv2py+n0wr0p3r8cJHRoZrgqHpBynRaDPK6UvE/hOmukHxNj Lt4LMbMigLq4Fmfgyj71oM6YR5Sz05fPO/apJta3r2u//XXaNlfFRnBn5/YNTqV5D/ EUHQsMZB2Eyrazn8+WaaYJhH1WqnJ9UYloxvqt+YU/FqCrjBgSr0nnrLAFC2zPgR9J YgSzIPR/SIGlB5E/rwLnWYpTzixCDaIZ0qKC00r1GT/rc7wvXVQrAvinXkz5VZEVbp jaqj/0OxSXlPw== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 925A93E9 for ; Sun, 12 Dec 2021 16:17:02 -0500 (EST) From: Michael Richardson To: netmod@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [netmod] too long lines from IANA module inclusion 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, 12 Dec 2021 21:17:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm working on draft-richardson-anima-rfc8366bis, trying to make it RFC8791. I'm getting many too long line found. I sure wish for description, that pyang had a wrap option, but I can cope with doing that manually. What I don't know how to deal with: .../draft-richardson-anima-rfc8366bis.xml(397): Warning: Too long line foun= d (L382), 1 characters longer than 72 characters: namespace "urn:ietf:params:xml:ns:yang:iana-voucher-assertion-type"; okay, I could contract the name, but that seems wrong. (I also could use a FAQ/Tutorial/screencast on adapting to RFC8791) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmG2Zs0ACgkQgItw+93Q 3WXQDAf9Gb44Ay3jkPgkGTDdWKhw3GLITObGZEGwmurWtk07WdbN3hpKz74cyXl9 4ApY3qR6ON7JEuNThP8XGkR8KjPhFtCXBV7xGPbWq4p7YiQJl+wld4xLeeYg9Hvj 5rNvyyJhr0fGqyABX9JJFbeSPOd29j7/E9zjZ1oU78tciIdddkaP1m4K6Q4MXrx9 +ys94x/61MH9Y4bFsepSZavbsJQZuoca3/V3dT3jc3HzOK7v4hE36iUq0MaKQSV7 Q27iiqtNvmbvWPksYDKAS0IM2OfW0EtwIYiAuu085cLG7jp2SMCl/ND0Vn/4HKA/ WpU9LrDx6B30R9YpOh+a3aaTKenxlQ== =silh -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Dec 12 14:00: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 431323A0BF5 for ; Sun, 12 Dec 2021 14:00:34 -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, 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 4mK8cWp7LpHn for ; Sun, 12 Dec 2021 14:00:29 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B0B3A0BF4 for ; Sun, 12 Dec 2021 14:00:28 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JBz8n0WhGzDCvk; Sun, 12 Dec 2021 23:00:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <11003.1639343822@localhost> Date: Sun, 12 Dec 2021 23:00:24 +0100 Cc: netmod@ietf.org X-Mao-Original-Outgoing-Id: 661039224.650281-ef8204847bbf3fc2931b1c991242d9de Content-Transfer-Encoding: quoted-printable Message-Id: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> References: <11003.1639343822@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 12 Dec 2021 22:00:35 -0000 On 2021-12-12, at 22:17, Michael Richardson = wrote: > I'm working on draft-richardson-anima-rfc8366bis, trying to make it = RFC8791. [=E2=80=A6] > What I don't know how to deal with: RFC 8792? (ducks) Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Dec 12 14:10: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 8889F3A0BFF for ; Sun, 12 Dec 2021 14:10:41 -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=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 hOdn4q77SYzF for ; Sun, 12 Dec 2021 14:10:36 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10080.outbound.protection.outlook.com [40.107.1.80]) (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 814AA3A0BFC for ; Sun, 12 Dec 2021 14:10:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XfmFxbdUNI2U/Hn9W+6XDkjeMIy0UYwMHTW6mVWTFA//YN0bj59N2GjlrDLZ3hy+SOAN+7+YquKRTRJjLqAXIBnp1HDaVc1knOcSUa5abmoUszcvKC2Jnltw4k6r4zo9FqKrmAIWcEBZbM2QHGOjQsayAtKH96jGkpX309dMcIyGkavV8tmOoX+v1GJg4X7Tcx1W4GBpXkvO+jcSeVNTuJuYPMvWveoanR03SXrNNMJ2SXuyedlrKEQ6ppCsyK8i/tt7N8D+NiOowQsq0GNw2BdX0coDI7R+5l99yfM/716PMEMOycigc2KKwPfYfiE3pFbclnzUmBpuMyx9dNRdcg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tCMEsy9Ca4uBJB4DuiYmv2n8I8VyAG4Xv5RZ97NT1+U=; b=L0tA/HFfEZ7f5HargOhqZK0pcOnq98eprBtcvL0SftE7bX1Sg/BOPPVvvdu+75++YMAoJlKnug9p/5PnzuSymytncWYX3g45wwYQFXp80DFETZ6bFIftMMEMOLQgq6A8SGls7wvmlRN+//AI1rDBlAk1TLvy+KFJ8VM/9dgUDBUoo+eEQOElGaHRWV+TxKpgCImhRskSRgkHmxnSEi81hKZaWd9qpVbmScsoe5E3UiTQTVYTSRjW2O/zUjJtvKHHB3ReArwN5KndMjjKOyd8+ZUIMXEuutjxyo7Rg05Jt/QElnZncawCadkmQGqxlJTfJOed0eDxjKK/5nVeNSTlMQ== 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=tCMEsy9Ca4uBJB4DuiYmv2n8I8VyAG4Xv5RZ97NT1+U=; b=q+bje5op7d/75Hk8N/mf0eB/WL9RzCfA2HhiY2Yq1gT0Cb+6oNtojSvZo9/e58sxpPrUc8P0O3Vs8oxrytJSIo/hye06Imodl9ya8XstTQrhnVzCSYbUmpTHUy87JxYnZ/joaSOHS3pj50MLPQk+PE/0ModuVAL6jIoM89LHChE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0738.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.17; Sun, 12 Dec 2021 22:10:31 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8%3]) with mapi id 15.20.4778.017; Sun, 12 Dec 2021 22:10:31 +0000 Date: Sun, 12 Dec 2021 23:10:30 +0100 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Michael Richardson Cc: netmod@ietf.org Message-ID: <20211212221030.tycpmhjtndzhdjkr@anna> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michael Richardson , netmod@ietf.org References: <11003.1639343822@localhost> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <11003.1639343822@localhost> X-ClientProxiedBy: AM3PR07CA0143.eurprd07.prod.outlook.com (2603:10a6:207:8::29) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 90c7684b-c0eb-4e04-00f6-08d9bdbc3650 X-MS-TrafficTypeDiagnostic: AM0P190MB0738:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: r9b3tdFpGLzlPRQ0KLaB11mZb0jg1RzTbpj6zV8Q3QW5KLbgbLjduD7UVQ1FRa398Mdq5VGZp+QoyshP+plM7q0rg6Sj3U5chwNzcYhvMy3LqyaN+zWNaPsilKRGh3BTRcjtj6JtZfZtHf0G0ajImrol0N8E7Qo2oPHtzumbSfIjjaR6s3/FAAugL393ksDqRhazXUth7a0Vv0ERLjtnEsT1pRba7XVgEF9SGw/W2kxJNue49lA9RfkQ2lKE4xq+TE9jsqooJSBDOiaJcyepYEuRfcumSDz7ICSJJ7VuZxYsGQHLEbt/FAhWXjAwrq+C3W6d5IsK0+WsydY+gpmXUny82gKoE9gYEh1odzjdPznUoEBHaX/FK0/0J2CZUCRkWsUjUdNBpsKzmHNahZ28Xw/0pfdbEUS7T0d4m3m4gdTaiwl84qqEnVTTGVVwwRWgk7lupkwXSzwE2xicwBdahKrVhUMN5WZYov+9BU/UYX4fVBR0RcpsRxsKv08lj23hwoAY1EKqcVqiXAFRexh+rwb9pL5cZnOfxwXlJOC1e5CfkPKOxalRUWbRwQncFwwdevoAWtwz9JlTxtCrSOX2n2UkcWY0yehMAdxPurZKamhQ0xvnKyvKhqLpdyj4W8Ub2IFIpukHZR0Qb5UfBWiicGL9YPzYsEr/3YCKy1qiwN0eXVrfNJtkyMqP51JIIuXJ6leD+vZl2oWebR52J0ZvjJZSmElB/FYMNMCDyrPbov68HrviOFqT5/t0aD6AbsPVrY3ppRglpkGYTZ7rK4+RlVDRCoVswYk80qX/DYMlm8A= 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:(7916004)(366004)(4744005)(6486002)(6506007)(38350700002)(38100700002)(1076003)(40140700001)(5660300002)(66476007)(186003)(52116002)(8676002)(66946007)(66556008)(786003)(8936002)(83380400001)(33716001)(508600001)(26005)(3716004)(4326008)(9686003)(85182001)(316002)(3450700001)(2906002)(86362001)(6512007)(85202003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c2NrY3FvQTNwRlA0L3NOS24wT3NGUjBxeHhBak1sdEQ2NXlHWkZuRnpCOU9j?= =?utf-8?B?MzdGQ1BsMjVZWG9DL2hxeHlVd2M0T0Z0TlhWM3poUWQ1anNwRVFscHp2M09R?= =?utf-8?B?cWZsajZyQ2haeTY0MVJTbkpWUVpSUG5nUWRvQ1VHTnU0bkFBUG5reHZUSmtT?= =?utf-8?B?T1lKVCtGZ0w3Z1RPSUxRUEJIV1dwTEtXU2Y1UURxSjNEbkw4SE9WT1l2K0Ez?= =?utf-8?B?bkdlSENoMUZKZ05LZ1VVZmtMaFpUWW01a29WWVFtZzYxRW5GRnhpdjNIRTVH?= =?utf-8?B?NlowUVV5dWI2SDdYeitJVjcycWxmL1VueHVrY1N2MWFGaGsyd3dySmRxdm1B?= =?utf-8?B?NDNJY2R0RjlOME01TVJNTGJUeUhYQ3VzcDZEOEUvMkZ5RGM4V0ZEbCtyV2th?= =?utf-8?B?Wmx5MjE0WVJkelo5R1ZTdzJ2VS9jOUxCNjJMaWpIQlltWEErc1RkWXM1d1NH?= =?utf-8?B?NlYwV09hNHNxNStuaGtjMWZjVmJTZnJFNTl1eUxDMmc2MXNxc052RmpLSEc5?= =?utf-8?B?SlRkOEFNaHdBWGkwblQyR1VoUFFqVUpvSU5UOGdQWWJFdWFnYTlweHJkZGls?= =?utf-8?B?YW1ud1pwQ1pva01adXpvQXlxSXBrVzZvU05UMzlZRTBoSVFIdTZwc1BiVHZP?= =?utf-8?B?MmUzdTBUWUtjZy9KOTZ2RjIwcDAyWFRvLzZjaVhRM24yZXhQeXM1MVN3YlFE?= =?utf-8?B?SDRKaWZaTW4rRysrRkR4Y05XcXlKMHdtaTUxVHpZVmpnc3V2Q2hpTjVhRXhi?= =?utf-8?B?OENubHdydzRnQS9LL203N0FyTGRkUVZGVEZQYkExL0RxNE1BbzBYcmUwQjds?= =?utf-8?B?VFNjSHZ3MzVVa25lUEZwRG1FemZIVHFEQnZGSDBVTGVHK0lCaWZwb01EcTFD?= =?utf-8?B?TnVTb2pFaFhJUjdYTnBzUkJCZ24xU1BOYkhEV2YwTUR3cnlCZGpMcHVoODlY?= =?utf-8?B?cTRZVXdpV1ZQRVIrRG1xQ0RYYUZtMFZOYmdaUmZQdFhJVzJaY3k2b0NHbW8x?= =?utf-8?B?RndJejcwNTBEbVI1Rmx1NlNkZkc1azkrY1A0b3RsWGxQV0c3QWwvMStXamhT?= =?utf-8?B?QW8yUVVJNUh4M25XOWRVaWpHelFzZGYyMTlBc2t2SFpob0pYbzA5SHFGVm96?= =?utf-8?B?M2pPMmsrT093bExJUjJBSWNXaUxVWmt4amJzZldvenA4RFNuWHNWRTZYNVVN?= =?utf-8?B?eW5CSm5PTlYrV3ZkR01nd1UvQW1PcVBLMjhlVkp0OWZhZzA1bjYzTnpTSGpF?= =?utf-8?B?QzlLeENlOXB0WThoQnNQcU1UME1VMnVlVjhEd2NSd241M1JPbzAzOWs1Mmt3?= =?utf-8?B?QlJIb0Z6cTlHRjNvVEl2dHJyVjFGS285a0p4WnJ2L3VZUGkvcGszRDRJSGFE?= =?utf-8?B?RVZzVW5UdGJLMDJVS1FjcWpXUzZkRXlxc0ZkZk5SM1ZDVjUzQ09DQ1NsQ3JU?= =?utf-8?B?M1RlTVJqUnRRN3JGSDc3V2ZNekkySEZHMXY2UTl5VVdpRmNuSDJweWhzSU1o?= =?utf-8?B?VHdjNDJ3ZldIS3I2R3UxRHVPeWZyYW1FT2E2Y1FHeEw5UWx3VEd0VEpsQnJG?= =?utf-8?B?cFBRd3A3VEw3MEcxb3VhcExDaDQ0YS9abjc5OHdNZGltbDN0VG4xUkxPQ1hn?= =?utf-8?B?eXcyaHJNNTE3RVE2bjErS3ZUL0dCTGdibFUvY0d1UWtsRHVhSE02Vnc4Rndq?= =?utf-8?B?OEY3NWRKeUcybjlkeDFHTlB4WVl4UFh3MDgyOEs0Wncrb2hSN2cxSWZUMjlY?= =?utf-8?B?Z3VsRFVIUkxha09NWU1BM1N2SnBPOFEvbVpoMXhGMjVkeDdnZDg1bkZjQUJp?= =?utf-8?B?WWRldG15TjRxdGM4T3Q1QWdOY1c3QVdPTVUvUXZQcTZSNzRKUUx4OEdIY1hM?= =?utf-8?B?Yzd2OGwrTmFBVjh2UThLOHJQaXY5SVBZSy9tdXkrb0hqVHZPZDdNYlduWjlM?= =?utf-8?B?S3VHVjhOWHJQOG93SlJwRFV4cUlUQzBkRE05dVl2Sm1qUnBlUmM3MEI5WVVq?= =?utf-8?B?clV5dmZZb2M0L2VhK0F0Y2pUdDdzSEhJOGxxTjlXcjJBRGp4MFhqV0h5Rk42?= =?utf-8?B?aTdvZWpJQStNUHc4V01GLzB5cm9qclRXNUZkMkg3c1ZRTnlzQitsNVpkVGRv?= =?utf-8?B?Qm5uSURVdUd3QXcrZHovUi8yelFRbThCaER3MG1ZTUpsanQyWmtDdU1GNjhr?= =?utf-8?B?UGFuSkFDVWpOWTk1TkZzMWQreWxqSWJLRVBSb2NZejhCSnV6ZUFHTDA3aHhV?= =?utf-8?Q?AYYOLWpdc9gmBBNs7bquRJgTzQt88jo/PxVS8L6Ee0=3D?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 90c7684b-c0eb-4e04-00f6-08d9bdbc3650 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2021 22:10:31.3443 (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: 8tNvzQ3/HkqkIV9zNk16HrtOGhZFL2DhlPVsEKwsxqFMNCvLlyiuu/bK0rKTed7+iUjTygfnkvb0ePfERrY9RhP9rPLcS1RodxvGo9GP4S8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0738 Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 12 Dec 2021 22:10:42 -0000 On Sun, Dec 12, 2021 at 04:17:02PM -0500, Michael Richardson wrote: > > What I don't know how to deal with: > > .../draft-richardson-anima-rfc8366bis.xml(397): Warning: Too long line found (L382), 1 characters longer than 72 characters: > namespace "urn:ietf:params:xml:ns:yang:iana-voucher-assertion-type"; > > okay, I could contract the name, but that seems wrong. > YANG allows you to split quoted string like this: namespace "urn:ietf:params:xml:ns:yang:" + "iana-voucher-assertion-type"; /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 Sun Dec 12 14:11: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 588823A0C00 for ; Sun, 12 Dec 2021 14:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=sandelman.ca 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 UFXpeKzU1TSy for ; Sun, 12 Dec 2021 14:11:37 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898073A0C02 for ; Sun, 12 Dec 2021 14:11:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B7CDF38B3A; Sun, 12 Dec 2021 17:15:35 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lay2u8svvfXh; Sun, 12 Dec 2021 17:15:34 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4D85E38B38; Sun, 12 Dec 2021 17:15:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1639347334; bh=kKYmOR3x2li5vYcgvpd+3IxNRpCX++Lnl5J/Jr07ou4=; h=From:To:Subject:In-Reply-To:References:Date:From; b=1fyTbAGwffKMBTEXwwwTOUoKKdilcntqclX4e4tY+mG8Hn13utJbOcqcW0U5wGpW8 J47d2O1Kdo+q1cT/OTwY/7doJqFaMTSx5dLa5asUAfsZP08+ayFKvmkrlRSAb5U99d k0ISfFyCk4kBlnmdgfPjyxZ1WSLnf4VhTxjPKt3OlmA0k3oHMYSS+DRiZR7CLfJdTT c9DO7eEqhFByv0RDZZ9BCxccR9RwV535nKr0C96ccd6JaOdUtSRRFdyoaH/34oo5zG KuOvmb6jNMdS6HUQDzcFSEKdlUQ9yi/h3hVJFRWlgmpTxHbBWm/oH97NBUFMD1vXJo KlOadWkXf7VVQ== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B62A348F; Sun, 12 Dec 2021 17:11:33 -0500 (EST) From: Michael Richardson To: Carsten Bormann , netmod@ietf.org In-Reply-To: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> References: <11003.1639343822@localhost> <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 12 Dec 2021 22:11:43 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2021-12-12, at 22:17, Michael Richardson w= rote: >> I'm working on draft-richardson-anima-rfc8366bis, trying to make it = RFC8791. > [=E2=80=A6] >> What I don't know how to deal with: > RFC 8792? If I put \ into the original .yang file, then it won't process. So if RFC8792 is the solution, then I think that I probably prefer to have ::include do it. Otherwise, I have to add another step to the workflow. I'd also want assurance that the YANG module extractor knows about 8792. Maybe given that Kent is a leader author on that... it's already taken care= of. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmG2c5UACgkQgItw+93Q 3WUdBwgAo7vi0skF4X2MA2FjmotohUQ2gfOG5wPYhQZmlJzMAbzGwfMAOyvbECaq 0OdWciJ2HjTWLTFQbjMlYI5SUOJMwl6MWQHsOhNoIlMu9l59UUqCiaU8d2kSTNCC vYBiL0FZDkrj6ScOd1utB0TxUIkqGj+OK8fMA1xMomziNokH1921aW0xwXtjRdVF bEuR+vLVN+lYwLOIgASPZfRyhe+0Dri1F6zYbOsOwCgjjf26HrOK9x/LQ2BvjYqc tzJAyRPCbkUnUGUCclnVchhnXFEFRsTGOlI3RJum2MLBbgNanuZEkWSRL+vzY0Xn +Au82WZFv9xV0Yd/Et//7CHRompx5g== =v30y -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Dec 12 23:31: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 2960A3A0E66 for ; Sun, 12 Dec 2021 23:31:13 -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 nWVVXjPcEEpF for ; Sun, 12 Dec 2021 23:31:08 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9A93A0E67 for ; Sun, 12 Dec 2021 23:31:06 -0800 (PST) Received: from smtpclient.apple (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JCCqD1nprzDCx6; Mon, 13 Dec 2021 08:31:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <24856.1639347093@localhost> Date: Mon, 13 Dec 2021 08:31:03 +0100 Cc: netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A20597C-4526-4090-A4A3-9E527756EA57@tzi.org> References: <11003.1639343822@localhost> <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 13 Dec 2021 07:31:13 -0000 On 12. Dec 2021, at 23:11, Michael Richardson = wrote: >=20 > So if RFC8792 is the solution, then I think that I probably prefer to = have > ::include do it. Try {::include-fold =E2=80=A6} in 1.5.22. The fold flag will do nothing if not needed, and RFC-8792-fold1 = otherwise. (I have only implemented =E2=80=98\=E2=80=99-folding. If you really = need more than 60-something blank spaces in a line, I can add = =E2=80=98\\=E2=80=99-folding later=E2=80=A6) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 13 08:53: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 5CEFE3A08D6 for ; Mon, 13 Dec 2021 08:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 A_h6XbxSWOPR for ; Mon, 13 Dec 2021 08:53:09 -0800 (PST) Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08on2124.outbound.protection.outlook.com [40.107.100.124]) (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 6BAA83A0944 for ; Mon, 13 Dec 2021 08:53:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HEXXEN74/V1gHBlPepFKcJhwLnsif3OzTPK7Cs7O+ziy1VOtT4BV0AW4By/RMlEMKpEqrTAXhwunxMGjjVU4np5juOx9Gq1iM2F4871mhtTiqsTBtH5vBvuWf6UGgtw0tFQw6HE8xlO1HZhJKPKRDEP2moBAyvTyTx+UPcBvbE5Ds2rnBVZ9A5dLY2hOpT7k6UU2t9/zoMHk/FIqZCTIaKE1KG9XMowDC0BIS3pIvDp1fPA2L+Q+qz7kLawxex0/1F0/SDTyEVIrnOSzhVpJ7OQTA6O4jaz1r4pD5w7Q9nuZZXCOkNQ+ho3ffKuMHckB33Cz+DuyZpHkTiuqz1XdFQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fGQUnbWPCFzhV2N5WbT7Yikuh6Dncuye3DByKnPB4BE=; b=BU+OUbbZtfckkcZmx5tZ3gFEnypBy8CJwTdOaprX1jJxVJ8tz2FNyBkjibVei3TcAkDYtOHAmbFLdWJsa5lznxNA7fcRn70Ocrio6htwB3yMWdCmUATdgX8TTsCp2cpj4ScWMOOunCW/HJBBTi9/fk3Mde8FFgrNJRpaMSbI0Qwlk9v7tbboUyfpcm/1KUQ5KlNCYyJY2rwYPyocJ3C2qZ9tb/Fe/l7XyuXrY3tKDujj3yQWEEP6rjZG4UcN+j443ZTsKoaynQEzFbp7vYfRp1IdZHb3y+IJnnUPQUDOV2ur239lx7h8gRtbHpQ6dsd2b35nXdxMqgRcOimfTSE62w== 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=fGQUnbWPCFzhV2N5WbT7Yikuh6Dncuye3DByKnPB4BE=; b=oRNExhZTNw7cY2KtL5ddYm7PZHz44yBW+Ojp0JfjfOFs1164ruLCkLKTI1hG+JCfHVtgelyIBbKksliQHpzVT0juI2tWey5oXeuKYxnZlVa7VQKz8mCRe1sHPhdmRVQheHgzi2YODf3zXr1JvzGkqOzsh1f7jKL+qYYtAkoi4m4= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6267.namprd08.prod.outlook.com (2603:10b6:5:1ec::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.17; Mon, 13 Dec 2021 16:53:06 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4778.017; Mon, 13 Dec 2021 16:53:06 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG versioning call Dec 14: topics for discussion (Packages vs module-sets) Thread-Index: AdfwQeVKgo1LSoV6TRiXuGel4ta3hg== Date: Mon, 13 Dec 2021 16:53:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a0bfb92-ea69-4042-92e6-08d9be590945 x-ms-traffictypediagnostic: DM6PR08MB6267:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EFoyunBW7tZ1wWO/lOr4bso0QGB+geAthzSaQLV7+9oKZjL6Uo4BH9VG5s/LOpM55cSXZsCe6HTSPp3n5BU/ixip3i8ke3k0/SFf7PHoc8BhqoXPoFtoIdUc562kzg+YYcwDl2UCVwdD4kkdoZgM85eduLYEQwb9CC1mARSPLY9gjN35C9VTRcnYabOBUse3yYtUHrkRwC3WqrGtljzEE+70LTWqfPUVgX5Uw7cj/4XJD8TMyWOhCKf5LNrX3eFGeAStr83NfPQsYGNKjPUYTkPFuB1Dioha4vUgsfbBz5KpZSXc0HW7oifR+aECPXbrV0ow2cV+Toi3sVQM1kUcNVKJ6bG56E8uZxkSfeekOgvgE3HCyl8uaMFyH320VEaOuu2hMo4wkOVKNpvxks5EYFasGr7vvyfNE0/nhKIan/c/1n/H+8nyG1UaaUNYHC4WkTuFjsZ948BgU3Grx2Ap/Vqjk9KDeH7u1wI98F3a58OHD683BES5TiL4mY8KXFZz9LryhiJsVCnlv7FnHecHPOTGnuu1piMiFq+3H/hAOlm/6KW4S4+7OUNw3za4hWDSX3CF4I3UHIJ1l0RpJVi0+cZAa302UTmAYr8PgGdLmPAgDfyLQqdXvZT3sSSR7osnhjiTf/1/PCZNwyLN895yOd6e1Zps8dZprCwIirqqBajgcDd4AjB4SmOZcr+SJWGXUE44b7t+/YZIPxvBEbqKHna+WDpGXpSVELH91zhlmhwnuPjPJa66sCVw2NdVvlrfMotaDj/o9osLhA15ew8HFIAz60bFEZCYV5vHGDzHbjo= 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)(366004)(7696005)(38100700002)(38070700005)(55016003)(122000001)(71200400001)(86362001)(5660300002)(316002)(8936002)(16799955002)(6506007)(40140700001)(52536014)(66446008)(2906002)(966005)(76116006)(83380400001)(66556008)(8676002)(4744005)(33656002)(9686003)(66946007)(508600001)(66476007)(186003)(82960400001)(166002)(64756008)(6916009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?cXacdXZa5wssvrPFg1AautreEB0sSQ0zaKz/1rWh6y5ycFn7i6FczgYdyQvO?= =?us-ascii?Q?Ie6yEdTlFfl9okNYcQxbVQCrjlO/9+KBDHL4lJ10dcQ/TSNJ9Kkxe5dtvL0X?= =?us-ascii?Q?prdtCZ6hHqeOnxpr8IyfKiF4mtqWvcZar6QlRaXfesxgdWopgJl38w3951Jw?= =?us-ascii?Q?xalvLPkI+P8HFZZwYXhOKL149GDWjMvhHaTI/N4l+RZMqU6FbGwOkI52nBb2?= =?us-ascii?Q?s/FunZFgQeDWVOlfnk48n06muJlEepwFW/Og5Ooc8IGMJ9LtIriI6J1EotNs?= =?us-ascii?Q?bgpGRO1fPazwygp4pESWbaFu3oHvdR6WrxnaFbmBTSsaOCD0wbfSB0/Cbb9d?= =?us-ascii?Q?2xY3a+LwfZXDq1+rL5OdrWse6Ck6XVWoLbR7fK2LrhH8vVjaordfKYPWnJEc?= =?us-ascii?Q?I0Wfkrb+8R2Mb+VfvzyqfbsDJkeONjswJlEEWNb4o8wB2F8fi+RgXf2UmxzH?= =?us-ascii?Q?YStdjrWS/KwiIa/cWVrxCwTKeCWaVEY3qOS2MmJERFjhuDihYFfjsEuhaCKr?= =?us-ascii?Q?RTVPyFqFy/50XOsF47ycIxIJSNNkezu7C3QwhLpoqY9gQkIKdjEAr2iTcP6C?= =?us-ascii?Q?AMtiRonCb/6POr+bZwkGG3H6gCgWB510fGIpTenY6neo1kIdzJaCd0CFx3pD?= =?us-ascii?Q?hSSQEqAL7nTdgPn8tY+pfxPK1ziiSbYB3HAGcHrQjbnxVO0bRB9agSWGn99m?= =?us-ascii?Q?c9bPgmrj2oQ2L4adAncBrdZ66KW0f61V4BfirLMMBf5P+iEBwn3ql7I+2pvp?= =?us-ascii?Q?Xs8AzGNkc349SHGeZbkzqcW+LczSz/1s8nq29q63JyZoY265RrMnlTvSIhHU?= =?us-ascii?Q?GsI0kvI+SL2C7+PKvW1J9Dy92UwpvxMhnl+yLi7/KhZLiibWNjA5nFvWUjWn?= =?us-ascii?Q?8U4M19H5hFA1R/q3gueAV20zzA9vPXgGlgac/OTWYj3f2PcPxvBBmgyhNMwE?= =?us-ascii?Q?FWzlKFZOR/oG90JYgcJM9AzQGkEASRLDoBMqS3wtz5j8AwKa0m00UpHwocTL?= =?us-ascii?Q?2TzP2kkdMJxVYr7RVL1LpPTGxLPzZXSwQlBFOSjLYxClRgrVAqdEgqiiW8cn?= =?us-ascii?Q?5G9j2oN1ZE9Lpbe3TYS6ynhV84cdAWDUzYEnQ9WpoS9EnNPUeDzSh5nlbhIZ?= =?us-ascii?Q?SG1JS9Al6sAR+0UWE5Qi+6WJYcNvk+5926512MSDBLTWGpWbkTJfm2+Jwgae?= =?us-ascii?Q?HyljBig550PX53s/Zhy9KuhXJ7NJAUDmBj5B+n0dCDRKB/f0AoKaKwmHn/eu?= =?us-ascii?Q?pzcSvQPB/6BXm9UNrLWW50CGpQcnsARnxdwp4iIYvW2Vc6P9yPIUcT7AtYVQ?= =?us-ascii?Q?iptew4d1Kx/8tYj3I49W+pNSLsdDOamWU4U8S51qVsix6fnj309vkYief2VF?= =?us-ascii?Q?I3IcAdXyHUXk5OANmeoivtF5w5u/pD5EZMYmW0fdXpa3bxBY4xfvajcpHnWW?= =?us-ascii?Q?kJi9hjzgUkeLuaCutZmAJWVQ7P5JwDDaaFggC24x0XCfvn7pBaRjWVWGY3Jb?= =?us-ascii?Q?0QokI4kFEnOOApgv2yfi13DhZPYOntCzXnalFHNXLuImPGK/OgkYZZQpSJRw?= =?us-ascii?Q?+ZKPpQeBviSDkx5uP2gDytxAhswhdHGG38daK7oUnG98mU+S+tVeHzATUaDL?= =?us-ascii?Q?hFeU7E3nPHUAnpiWL/Qk7Fs9qbszBVxz8uXwXtNlmYJ//7CTm3VG953iigTy?= =?us-ascii?Q?YmsrcSBDiFfJRusqnlEqydg+kdg=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084792FCF2A48C74108AF1A9B749DM6PR08MB5084namp_" 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: 1a0bfb92-ea69-4042-92e6-08d9be590945 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2021 16:53:06.6197 (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: f6bGfd2N+hMCvsIyEjm3GbJRokeg8Lz6UeL6WP1my8cuqkGdyA/SF9jHvixTz3hOu18hc33HA+By+t7gXeGjWg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6267 Archived-At: Subject: [netmod] YANG versioning call Dec 14: topics for discussion (Packages vs module-sets) 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, 13 Dec 2021 16:53:22 -0000 --_000_DM6PR08MB5084792FCF2A48C74108AF1A9B749DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The main discussion topic for the weekly YANG Versioning call tomorrow is a= fairly fundamental one: the basic structure of Packages and how they fit i= n with YANG Library. We are debating 2 approaches that we will walk through and discuss on the c= all. It is mainly related to how "included packages" are modelled (as part of a = Package vs as part of a module-set), and whether module-sets *are* Packages= (or if they are somewhat independent entities). Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 161 096 5630 Meeting password: semver? Occurs every Tuesday effective Tuesday, November 16, 2021 from 9:00 AM to 1= 0:00 AM, (UTC-05:00) Eastern Time (US & Canada) 9:00 AM | (UTC-05:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dme2c6491ebcc37b8127c1244d244d2754 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1610965630## Call-in toll number (US/Canada) --_000_DM6PR08MB5084792FCF2A48C74108AF1A9B749DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The main discussion topic for the weekly YANG Versio= ning call tomorrow is a fairly fundamental one: the basic structure of Pack= ages and how they fit in with YANG Library.

 

We are debating 2 approaches that we will walk throu= gh and discuss on the call.

 

It is mainly related to how "included packages&= quot; are modelled (as part of a Package vs as part of a module-set), and w= hether module-sets *are* Packages (or if they are somewhat independe= nt entities).

 

Jason

 

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

Weekly webex call details:

 

Meeting number (access code): 161 096 5630

Meeting password: semver?

 

Occurs every Tuesday effective Tuesday, November 16,= 2021 from 9:00 AM to 10:00 AM, (UTC-05:00) Eastern Time (US & Canada)

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

 

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

Tap to join from a mobile device (attendees only)

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

 

--_000_DM6PR08MB5084792FCF2A48C74108AF1A9B749DM6PR08MB5084namp_-- From nobody Mon Dec 13 13:05:40 2021 Return-Path: <0100017db59d6ecc-b6b65626-fb21-4b6d-b083-463c44173cb4-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 835A43A0B45 for ; Mon, 13 Dec 2021 13:05:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 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 1knnlUGjwutT for ; Mon, 13 Dec 2021 13:05:34 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D573A0B4D for ; Mon, 13 Dec 2021 13:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639429533; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=zGefMqAJn2cdZSlZmHAABd4q5wUQlrj+VULoaF+ZSnw=; b=R+pTqgWNjofPJB8KD+3JrB5kPQSrE34EvFUVBMkyQh4kKL2JVIcMYrC8VqvB4eGm wPfd0frTYuBHyqbKSPDcXwUSPjqjZD6Kqoyz4XVx4ZilBHCBQkjb7uqIYkxm3sTrmYN 6JE4DGtuga0SKvHreFbs1xmB4HnLigrJoApEkJkE= From: Kent Watsen Message-ID: <0100017db59d6ecc-b6b65626-fb21-4b6d-b083-463c44173cb4-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_31F33B9E-8B2D-4399-A3D6-7B270FCB9A6D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 13 Dec 2021 21:05:33 +0000 In-Reply-To: <20211130080018.2amyfyoyuxefm5c4@anna> Cc: Andy Bierman , "netmod@ietf.org" To: Juergen Schoenwaelder References: <20211125114733.phenv7mktyed6d4v@anna> <20211125.130155.1636018839435459937.id@4668.se> <20211125130128.ogpuzktbdyp6yydj@anna> <0100017d6de3a63d-89d0e981-5347-47be-9779-52d70ccbcda6-000000@email.amazonses.com> <20211129234941.rzgo7q36qbbytcge@anna> <0100017d6ea8bf95-465cd96c-48c1-4bc0-b70f-f82043bae24c-000000@email.amazonses.com> <20211130080018.2amyfyoyuxefm5c4@anna> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.13-54.240.8.88 Archived-At: Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? 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, 13 Dec 2021 21:05:40 -0000 --Apple-Mail=_31F33B9E-8B2D-4399-A3D6-7B270FCB9A6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 30, 2021, at 3:00 AM, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = wrote: >=20 > On Tue, Nov 30, 2021 at 02:24:52AM +0000, Kent Watsen wrote: >> Hi Juergen, >>=20 >>=20 >>> On Nov 29, 2021, at 6:49 PM, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = wrote: >>>=20 >>> On Mon, Nov 29, 2021 at 03:14:06PM -0800, Andy Bierman wrote: >>>>=20 >>>> IMO the least disruptive solution possible should be used. >>>> There is a use-case for adding "origin" support to the = datastore >>>> in the operation. >>>> This allows an NMDA client to identify system config that is not = being used >>>> in . >>>>=20 >>>=20 >>> Looking at Figure 2 of RFC 8342, I wonder how system config gets = into >>> running - other than a client writing it into running, at which = point >>> the config becomes explicit config subject to the usual update rules >>> of . Conceptually, you can have a system daemon acting as a >>> client updating (perhaps even controllable by NACM). The >>> "origin" was not designed to track from which application config = data >>> in is originating, that's to be solved by other = mechanisms. >>=20 >> This idea is to mimic RFC6243=E2=80=99s =E2=80=9Cdefault=E2=80=9D = annotation and the "with-defaults" RPC. Just like with the = =E2=80=9Cexplicit=E2=80=9D mode server, if a client writes to = and default value w/o the annotation, the server assumes it is explicit = config (not the default anymore). Same here, if the client writes a = =E2=80=9Csystem=E2=80=9D node w/o the annotation, the server assumes it = is explicit config (not the -defined node). In both cases, if = the client includes the appropriate annotation, and the value/node = matches the default/system value, then the server assumes that it=E2=80=99= s actually the default/system value/node. >>=20 >> FWIW, about 5 months ago (June 29), I offered this modified version = of Figure 2 (Note the box on the left). The =E2=80=9Cunderlay=E2= =80=9D comment is meant to imply that always overrides = when they=E2=80=99re merged: >>=20 >>=20 >> +-------------+ +-----------+ >> | | | | >> | (ct, rw) |<---+ +--->| (ct, rw) | >> +-------------+ | | +-----------+ >> | | | | >> | +-----------+ | >> +-------->| |<--------+ >> | (ct, rw) | >> +-----------+ >> | >> +----------+ | // configuration transformations, >> | |-------------->| // e.g., removal of nodes marked = as >> | (ct, ro) | // underlay | // "inactive", expansion of >> +----------+ | // templates >> v >> +------------+ >> | | // subject to validation >> | (ct, ro) | >> +------------+ >> | // changes applied, subject to >> | // local factors, e.g., missing >> | // resources, delays >> | >> dynamic | +-------- learned configuration >> configuration | +-------- system configuration >> datastores -----+ | +-------- default configuration >> | | | >> v v v >> +---------------+ >> | | <-- system state >> | (ct + cf, ro) | >> +---------------+ >>=20 >=20 > Your first paragraph does not match the figure. In your figure, system > config does not go into instead it goes into a magic merge > box which is not shown (there is just an arror pointing to an arrow) > and then the result goes into intended. The diagram is fine (to me) and consistent with the first paragraph. = The goal of that diagram was to minimally-edit the RFC 8342 diagram. But. more importantly, do you now understand the = with-system/default-annotation relation? If not, why not? If so, does = it make sense now? =20 K. --Apple-Mail=_31F33B9E-8B2D-4399-A3D6-7B270FCB9A6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 30, 2021, at 3:00 AM, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = <j.schoenwaelder@jacobs-university.de> wrote:

On = Tue, Nov 30, 2021 at 02:24:52AM +0000, Kent Watsen wrote:
Hi Juergen,


On Nov 29, 2021, at 6:49 PM, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = <j.schoenwaelder@jacobs-university.de> wrote:

On Mon, Nov 29, 2021 at 03:14:06PM -0800, Andy = Bierman wrote:

IMO the least disruptive solution possible should be used.
There is a use-case for adding "origin" support to the = <running> datastore
in the <get-data> = operation.
This allows an NMDA client to identify system = config that is not being used
in <operational>.


Looking at Figure = 2 of RFC 8342, I wonder how system config gets into
running = - other than a client writing it into running, at which point
the config becomes explicit config subject to the usual = update rules
of <running>. Conceptually, you can = have a system daemon acting as a
client updating = <running> (perhaps even controllable by NACM). The
"origin" was not designed to track from which application = config data
in <running> is originating, that's to = be solved by other mechanisms.

This idea is to mimic RFC6243=E2=80=99s =E2=80=9Cdefault=E2=80=9D= annotation and the "with-defaults" RPC.  Just like with the = =E2=80=9Cexplicit=E2=80=9D mode server, if a client writes to = <running> and default value w/o the annotation, the server assumes = it is explicit config (not the default anymore).  Same here, if the = client writes a =E2=80=9Csystem=E2=80=9D node w/o the annotation, the = server assumes it is explicit config (not the <system>-defined = node).  In both cases, if the client includes the appropriate = annotation, and the value/node matches the default/system value, then = the server assumes that it=E2=80=99s actually the default/system = value/node.

FWIW, about 5 months ago (June = 29), I offered this modified version of Figure 2  (Note the = <system> box on the left).  The =E2=80=9Cunderlay=E2=80=9D = comment is meant to imply that <running> always overrides = <system> when they=E2=80=99re merged:


=     +-------------+ =             &n= bsp;   +-----------+
=     | <candidate> | =             &n= bsp;   | <startup> |
=     |  (ct, rw)   |<---+ =       +--->| (ct, rw)  |
    +-------------+    | =       |    +-----------+
=            | =           | =       | =           |
=            | =         +-----------+ =         |
=            +-------= ->| <running> |<--------+
=             &n= bsp;        | (ct, rw) =  |
=             &n= bsp;        +-----------+
=             &n= bsp;           &nbs= p;  |
+----------+ =             &n= bsp; |        // configuration = transformations,
| <system> |-------------->| =        // e.g., removal of nodes = marked as
| (ct, ro) | // underlay   | =        // "inactive", expansion of
+----------+ =             &n= bsp; |        // templates
=             &n= bsp;           &nbs= p;  v
=             &n= bsp;        +------------+
=             &n= bsp;        | <intended> | = // subject to validation
=             &n= bsp;        | (ct, ro) =   |
=             &n= bsp;        +------------+
=             &n= bsp;           &nbs= p;  |        // changes = applied, subject to
=             &n= bsp;           &nbs= p;  |        // local = factors, e.g., missing
=             &n= bsp;           &nbs= p;  |        // resources, = delays
=             &n= bsp;           &nbs= p;  |
=       dynamic =             &n= bsp;|   +-------- learned configuration
=       configuration =        |   +-------- system = configuration
=       datastores -----+ =    |   +-------- default configuration
=             &n= bsp;         | =    |   |
=             &n= bsp;         v =    v   v
=             &n= bsp;      +---------------+
=             &n= bsp;      | <operational> | <-- = system state
=             &n= bsp;      | (ct + cf, ro) |
=             &n= bsp;      +---------------+


Your first = paragraph does not match the figure. In your figure, system
config does not go into <running> instead it goes into = a magic merge
box which is not shown (there is just an = arror pointing to an arrow)
and then the result goes into = intended.


The diagram is = fine (to me) and consistent with the first paragraph.  The goal of = that diagram was to minimally-edit the RFC 8342 diagram.

But. more importantly, = do you now understand the with-system/default-annotation relation? =  If not, why not?  If so, does it make sense now? =  

K.


= --Apple-Mail=_31F33B9E-8B2D-4399-A3D6-7B270FCB9A6D-- From nobody Mon Dec 13 15:25:53 2021 Return-Path: <0100017db61dcda1-eab8e8d2-350a-4aed-aea0-7b59a8d08a85-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 109443A0C45 for ; Mon, 13 Dec 2021 15:25:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ZUtcdKi4c_Nm for ; Mon, 13 Dec 2021 15:25:47 -0800 (PST) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE7C3A0C42 for ; Mon, 13 Dec 2021 15:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639437946; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=2xV+FgAcyAX4oCT5oVR1wWJ7DgtwyhxJ2RslVHwhhho=; b=ZtZxQ5UHyQmKtz267Fll+m8kITTmXEvYzjwl3+DQBWqoWh8I3pCQ6dN41NWQtHfa js5DWzW72tMGcjHqly8qQT3D6B2dHcufPxYIKvgUmp4375nP6eEqY7iHyJepk9taTOw 3C4lkeCuS3vcPsTE3zWp9rirTBpsTs+NoUM1cg0A= From: Kent Watsen Message-ID: <0100017db61dcda1-eab8e8d2-350a-4aed-aea0-7b59a8d08a85-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ABC077F3-2C94-4394-AD13-0A86DBDC1544" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 13 Dec 2021 23:25:46 +0000 In-Reply-To: Cc: "maqiufang (A)" , "Belotti, Sergio (Nokia - IT/Vimercate)" , "netmod@ietf.org" To: Jan Lindblad References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.13-54.240.48.95 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 13 Dec 2021 23:25:51 -0000 --Apple-Mail=_ABC077F3-2C94-4394-AD13-0A86DBDC1544 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jan, > Here you are introducing two concepts that the RFCs (6020, 7950, 8342) = are never mentioning: online and offline validation. Then you say that = because the RFCs don't talk about these concepts, the behavior is = undefined. I strongly disagree. The RFCs talk about validation, and = describes the rules for how that happens. These rules always apply, = regardless of online, offline or the phase of the moon. Look, specs are very simple: stuff is written down in black and white = and either it=E2=80=99s there or not. In this case, the fact remains = that there is no document I can point to that says offline validation is = a thing. It is also notable that RFC 8341 say nothing about the fact = that clients effected by NACM may not be able to pass validation (it=E2=80= =99s not even mentioned). > If you think the online and offline validation concepts have merit, I = would like to see proper definitions of them, and how you would like to = modify the existing RFCs with respect to these concepts. It might also = be a good idea to update the proposed draft, which currently does not = mention these concepts. This is part of the discussion we=E2=80=99re having now. The outcome of = which may trigger clarifications to some RFCs. All fine suggestions, = but replace =E2=80=9Cyou=E2=80=9D with =E2=80=9Cfolks=E2=80=9D, as = it=E2=80=99s not on my shoulders to do any of this. > The added value and the core essence of YANG is enabling us to reason = about configurations and compute configuration changes without = necessarily asking the server if a configuration is valid by "trial and = error". This is possible because a YANG model is a detailed and = reasonably complete description of the management interface. Introducing = changes to YANG that breaks this basic premise would be dumbing down = YANG, and I can't see the benefit with this change, or how this would be = compatible with YANG 1.0, or 1.1 rules. I never said offline validation shouldn=E2=80=99t be possible. Rather, = please know that, NACM aside, my understanding of the goal of the draft = is that offline validation *is* supported...but it entails clients = merging their view of with the server=E2=80=99s = before doing the validation (i.e., alone may not be enough, = see Subject line). Good news is that, since is effectively = static, no new round-trips are incurred. > I think the ideas behind the system datastore are interesting and in = many use cases useful. We just need to introduce them in a way that = doesn't break existing, agnostic implementations. >=20 > I made some proposals earlier, both on the interim and privately to = the draft authors, along these lines: >=20 > Option #1 > + We could have a new system datastore that technically is a part of = running. Everything in system would show up in running to clients = unaware of the system datastore. Every time the system datastore changes = for whatever reason, the running datastore transaction ids (if we manage = to get that concept defined), are updated > + Clients interested to see pure view of the system datastore without = anything else in running could issue a get-data towards the system = datastore > + Clients interested to see a pure view of running without any system = datastore elements could issue a get-data towards running with an extra = flag called 'without-system' > + Since all system elements are already part of running, clients have = no need to copy data between the two datastores >=20 > Option #2 > + We could have a system datastore that technically is a part of = operational. Everything in system would show up in operational to = clients unaware of the system datastore. The running datastore always = maintains referential integrity, i.e. cannot reference the system = datastore. > + Clients interested to see pure view of the system datastore could = issue a get-data towards the system datastore > + Since the system datastore is not part of running, clients can = already see a pure view of running without any system datastore elements = using a simple get-data.=20 > + Clients that are aware of the system datastore and are interested to = configure references from running to system elements would issue an = edit-data rpc with the additional flag 'resolve-system-references'. This = will make the server copy any system elements referenced into running = without the client doing so explicitly. > + Clients unaware of the system datastore would have to include (copy) = information from the system datastore to running in order to reference = them. I see these as possible fallback solutions. >> In the meanwhile, can we discuss the issues around a legacy client = failing an offline validation? In this case, a production deployment = must have 1) deployed devices that support , 2) deployed at = least one client that supports , and 3) decided to let clients = start pushing config using . While in the pre-production = testing phase, it would be quickly discovered that all legacy clients = need to be updated. By the time of going to production, the deployment = should have all the clients updated, so it seems that only the forgotten = (relatively insignificant) clients might have an offline validation of = failure. Is this a fair assessment? >=20 > 1) agreed, without devices that support the system datastore, no = problem > 2,3) well, a "client" in this case could very well be a CLI operator = or other management interface. Even in highly automated networks, CLI = operators are still common Sure, but there=E2=80=99s no impact to CLI operators as they=E2=80=99re = effectively getting server-side validation all the time. Just saying = that CLI-ops don=E2=80=99t seem to be effected by any of this, right? > Your description of the operations environment where the operator has = full implementation control of all clients is very different from my = field experience. Not only do I believe the situation with multiple, = independent clients is the most commonly occurring one in the real world = across all server deployments, but I also think the operator usually has = limited insight into as well as control over which specific protocol = features the clients implement. I therefore think your assessment is = fair only for a minority of field situations. Sure, there will be some shops that play it loose, but serious = deployments know what is accessing their management network, whether = allowed through firewall rules or admin-accounts, it shouldn=E2=80=99t = be hard for them to round up a short-list of apps (clients) accessing = their management network. I=E2=80=99m sure the view you obtained via in your years differs from = mine. Please, provide more detail about the management practices of the = kinds of shops you have in mind. Are they providing NaaS (Network as a = Service)? Thanks, Kent --Apple-Mail=_ABC077F3-2C94-4394-AD13-0A86DBDC1544 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Jan,

Here you are introducing two concepts that = the RFCs (6020, 7950, 8342) are never mentioning: online and offline = validation. Then you say that because the RFCs don't talk about these = concepts, the behavior is undefined. I strongly disagree. The RFCs talk = about validation, and describes the rules for how that happens. These = rules always apply, regardless of online, offline or the phase of the = moon.

Look, specs are very simple: stuff is written down = in black and white and either it=E2=80=99s there or not.  In this = case, the fact remains that there is no document I can point to that = says offline validation is a thing.  It is also notable that RFC = 8341 say nothing about the fact that clients effected by NACM may not be able to pass = validation (it=E2=80=99s not even mentioned).


If you think the online and offline validation concepts have = merit, I would like to see proper definitions of them, and how you would = like to modify the existing RFCs with respect to these concepts. It = might also be a good idea to update the proposed draft, which currently = does not mention these = concepts.

This is part of the discussion we=E2=80=99re = having now.  The outcome of which may trigger clarifications to = some RFCs.   All fine suggestions, but replace =E2=80=9Cyou=E2=80=9D = with =E2=80=9Cfolks=E2=80=9D, as it=E2=80=99s not on my shoulders to do = any of this.


The added = value and the core essence of YANG is enabling us to reason about = configurations and compute configuration changes without necessarily = asking the server if a configuration is valid by "trial and error". This = is possible because a YANG model is a detailed and reasonably complete = description of the management interface. Introducing changes to YANG = that breaks this basic premise would be dumbing down YANG, and I can't = see the benefit with this change, or how this would be compatible with = YANG 1.0, or 1.1 rules.

I never said offline validation shouldn=E2=80=99t = be possible.  Rather, please know that, NACM aside, my = understanding of the goal of the draft is that offline validation *is* = supported...but it entails clients merging their view of <running> = with the server=E2=80=99s <system> before doing the validation = (i.e., <running> alone may not be enough, see Subject line). =  Good news is that, since <system> is effectively static, no = new round-trips are incurred.


I think = the ideas behind the system datastore are interesting and in many use = cases useful. We just need to introduce them in a way that doesn't break = existing, agnostic implementations.

I made some proposals earlier, both on = the interim and privately to the draft authors, along these = lines:

Option = #1
+ We could have a new system datastore that = technically is a part of running. Everything in system would show up in = running to  clients unaware of the system datastore. Every time the = system datastore changes for whatever reason, the running datastore = transaction ids (if we manage to get that concept defined), are = updated
+ Clients interested to see pure view of = the system datastore without anything else in running could issue a = get-data towards the system datastore
+ Clients = interested to see a pure view of running without any system datastore = elements could issue a get-data towards running with an extra flag = called 'without-system'
+ Since all system elements = are already part of running, clients have no need to copy data between = the two datastores

Option #2
+ We could = have a system datastore that technically is a part of operational. = Everything in system would show up in operational to  clients = unaware of the system datastore. The running datastore always maintains = referential integrity, i.e. cannot reference the system = datastore.
+ Clients interested to see pure view of = the system datastore could issue a get-data towards the system = datastore
+ Since the system datastore is not part = of running, clients can already see a pure view of running without any = system datastore elements using a simple get-data. 
+ Clients that are aware of the system datastore and are = interested to configure references from running to system elements would = issue an edit-data rpc with the additional flag = 'resolve-system-references'. This will make the server copy any system = elements referenced into running without the client doing so = explicitly.
+ Clients unaware of = the system datastore would have to include (copy) information from the = system datastore to running in order to reference = them.

I see these as possible fallback = solutions.


In the = meanwhile, can we discuss the issues around a legacy client failing an = offline validation?  In this case, a production deployment must = have 1) deployed devices that support <system>, 2) deployed at = least one client that supports <system>, and 3) decided to let = clients start pushing config using <system>.   While in the = pre-production testing phase, it would be quickly discovered that all = legacy clients need to be updated.  By the time of going to = production, the deployment should have all the clients updated, so it = seems that only the forgotten (relatively insignificant) clients might = have an offline validation of <running> failure.  Is this a = fair assessment?

1) agreed, without = devices that support the system datastore, no problem
2,3) well, a "client" in this case could very well be a CLI = operator or other management interface. Even in highly automated = networks, CLI operators are still = common

Sure,= but there=E2=80=99s no impact to CLI operators as they=E2=80=99re = effectively getting server-side validation all the time.  Just = saying that CLI-ops don=E2=80=99t seem to be effected by any of this, = right?


Your description of the = operations environment where the operator has full implementation = control of all clients is very different from my field experience. Not = only do I believe the situation with multiple, independent clients is = the most commonly occurring one in the real world across all server = deployments, but I also think the operator usually has limited insight = into as well as control over which specific protocol features the = clients implement. I therefore think your assessment is fair only for a = minority of field = situations.

Sure, there will be some shops that play it loose, = but serious deployments know what is accessing their management network, = whether allowed through firewall rules or admin-accounts, it shouldn=E2=80= =99t be hard for them to round up a short-list of apps = (clients) accessing their management = network.

I=E2=80=99m sure the = view you obtained via in your years differs from mine.  Please, provide more = detail about the management practices of the kinds of shops you have in = mind.  Are they providing NaaS (Network as a = Service)?



Thanks,
Kent


= --Apple-Mail=_ABC077F3-2C94-4394-AD13-0A86DBDC1544-- From nobody Mon Dec 13 15:44:39 2021 Return-Path: <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-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 7225A3A0C52 for ; Mon, 13 Dec 2021 15:44:37 -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 (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 YL6pPzjmWbT3 for ; Mon, 13 Dec 2021 15:44:33 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1E93A0C50 for ; Mon, 13 Dec 2021 15:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639439072; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=tFmyr1LTa/VxdufqvFIgmC9xOw/CTodJ7AN/V4xjknM=; b=DzRBp3bGE+MO3LJfMdWtqWva5PCssoFKIzy7Lt/ATfTSOczvebF5VvKBc7zovEFm 2iK8nBhEgSzQ9UmENBwOnTGVGKPcPHvt6QCIidngAqyrxOfPYpR728MU9FIdRGwLbXU 3fL0CdljWxzj6lMDhRCufv2O9uo9M+mcmQspwz9c= From: Kent Watsen Message-ID: <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DC94B009-8859-4F2D-A75B-D24E0428F609" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 13 Dec 2021 23:44:31 +0000 In-Reply-To: Cc: Juergen Schoenwaelder , Jan Lindblad , "maqiufang (A)" , "netmod@ietf.org" To: Andy Bierman References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.13-54.240.8.83 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 13 Dec 2021 23:44:38 -0000 --Apple-Mail=_DC94B009-8859-4F2D-A75B-D24E0428F609 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Juergen/Andy, > Option #3 >=20 > There is a client on the system that makes changes to running just > like any other remote clients can make changes to running. System > generate config that is not editable explicit config in running goes > straight into the applied config in operational. This does not require > a system datastore (in fact something like a system datastore may > exist as the _logic_ of the system client, the good old example we had > is allocting an unused uid for an account that, once allocated, is > maintained in running). >=20 Juergen, you mentioned this before. I don=E2=80=99t recall if there = were any responses, but how would this solution address the various = concerns that have been raised?=20 > +1 to option 3. > Consider an implementation that moves all the "hidden system logic" = off-box > to a controller, such that the initial config is literally supplied by = an external client. Andy, IIRC, you +1=E2=80=99ed Juergen=E2=80=99s previous =E2=80=9Coption = #3=E2=80=9D, but can you to answer the same question about how solution = address concerns? > I have yet to hear a single use-case for creating a = datastore. > "The client might want" is not a use-case for standardization. > I do not understand the "pure view". Seems like if this was a real = problem to solve, > then NMDA would have included a system datastore from the start. Use-cases and issues were discussed at both the Interim and at IETF 112. = I don=E2=80=99t recall you or Juergen attending either, but the = 112-recording starts at the 23-minute mark here: = https://play.conf.meetecho.com/Playout/?session=3DIETF112-NETMOD-20211111-= 1430 = K. // as a contributor --Apple-Mail=_DC94B009-8859-4F2D-A75B-D24E0428F609 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Juergen/Andy,


Option #3

There is a = client on the system that makes changes to running just
like= any other remote clients can make changes to running. System
generate config that is not editable explicit config in = running goes
straight into the applied config in = operational. This does not require
a system datastore (in = fact something like a system datastore may
exist as the = _logic_ of the system client, the good old example we had
is= allocting an unused uid for an account that, once allocated, is
maintained in running).


Juergen, you mentioned this before. =  I don=E2=80=99t recall if there were any responses, but how would = this solution address the various concerns that have been = raised? 


+1 to = option 3.
Consider an implementation that moves all the "hidden = system logic" off-box
to a controller, such that the = initial config is literally supplied by an external = client.

Andy, IIRC, = you +1=E2=80=99ed Juergen=E2=80=99s previous =E2=80=9Coption #3=E2=80=9D, = but can you to answer the same question about how solution address concerns?


I have yet to hear a single use-case for creating a = <system> datastore.
"The client might want" is not a = use-case for standardization.
I do not understand the "pure view". = Seems like if this was a real problem to solve,
then = NMDA would have included a system datastore from the = start.

Use-cases = and issues were discussed at both the Interim and at IETF 112.   I = don=E2=80=99t recall you or Juergen attending either, = but the 112-recording starts at the 23-minute mark = here: https://play.conf.meetecho.com/Playout/?session=3DIETF112-NETMO= D-20211111-1430


K.  // as a = contributor








= --Apple-Mail=_DC94B009-8859-4F2D-A75B-D24E0428F609-- From nobody Mon Dec 13 16:32:35 2021 Return-Path: <0100017db65ae724-35b0a474-a155-4bf4-907e-4309de903fb7-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 8E8CB3A0CCC for ; Mon, 13 Dec 2021 16:32:33 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 gbk1RRvhbL7M for ; Mon, 13 Dec 2021 16:32:32 -0800 (PST) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D040A3A0CC8 for ; Mon, 13 Dec 2021 16:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639441950; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=t5K947WGDLidqgvoEHAP7W3ylmwW+f15oCq0tCOrb0A=; b=IkhK16ELG7M43q5IwHC1U8zJnNr3t7O+KTm8X0jKWHow2XJS4/dZRu75UdNT3hK5 B/KZ6cfno8AHk1ITSuEHLxxxH6wh6aUXrQ4vV+XFScm1CWKokw6T6Xi1GOd5HL9evch e/U+oKe1eW6LQAs4quE1uFQ2OFll6fan+kUQmI2k= From: Kent Watsen Message-ID: <0100017db65ae724-35b0a474-a155-4bf4-907e-4309de903fb7-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CBFD7CDE-A8FD-445A-B989-1CB2E3CED544" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 00:32:30 +0000 In-Reply-To: Cc: Andy Bierman , Juergen Schoenwaelder , Jan Lindblad , "maqiufang (A)" , "netmod@ietf.org" To: "Sterne, Jason (Nokia - CA/Ottawa)" References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.48.110 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 00:32:34 -0000 --Apple-Mail=_CBFD7CDE-A8FD-445A-B989-1CB2E3CED544 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jason, > I think we have a potential solution for this system config that keeps = the running valid. But I'm far more worried about configuration = templates. I don't see how we can possibly keep valid with = config templates. That seems like a major problem to me. But if we ever = declare that doesn't have to be valid, and only has = to be valid, then offline tools can never validate (ahead of time) the = config they actually download to the server. It isn=E2=80=99t the case that clients can=E2=80=99t offline-validate = with templates (or with apparently-dangling refs to = -defined nodes), they just have to work for it a little more. =20= In the case of templates, they=E2=80=99d have to understand how to = perform the template-expansion logic and, in the case of dangling = -refs, they have to know how to do the merge-logic. =20 In both cases, the general statement is that, if clients want to do = offline validation, they need to understand how to =E2=80=9Ccook=E2=80=9D = and validate that instead. K. --Apple-Mail=_CBFD7CDE-A8FD-445A-B989-1CB2E3CED544 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jason,

I think we have a = potential solution for this system config that keeps the running valid. = But I'm far more worried about configuration templates. I don't see how = we can possibly keep <running> valid with config templates. That = seems like a major problem to me. But if we ever declare that = <running> doesn't have to be valid, and only <intended> has = to be valid, then offline tools can never validate (ahead of time) the = config they actually download to the = server.

It = isn=E2=80=99t the case that clients can=E2=80=99t offline-validate = <running> with templates (or <running> with = apparently-dangling refs to <system>-defined nodes), they just = have to work for it a little more.  

In the case of templates, they=E2=80=99d have to = understand how to perform the template-expansion logic and, in the case = of dangling <system>-refs, they have to know how to do the = merge-logic.  

In both cases, = the general statement is that, if clients want to do offline validation, = they need to understand how to =E2=80=9Ccook=E2=80=9D <intended> = and validate that instead.

K.



= --Apple-Mail=_CBFD7CDE-A8FD-445A-B989-1CB2E3CED544-- From nobody Mon Dec 13 16:42:56 2021 Return-Path: <0100017db664515c-d834ffd0-0860-4c60-b9be-0db0e349a69b-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 A6DF53A0CDC for ; Mon, 13 Dec 2021 16:42:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 VtsDFDlff4E1 for ; Mon, 13 Dec 2021 16:42:49 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A793A0CDB for ; Mon, 13 Dec 2021 16:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639442567; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ozbOZyjqniI2mu3HCcWexyi3JyOpjGQtgM7UqA2vPR8=; b=PrNaP/zQc51HCd0VgFpapEzK4vmdyomH2uFAf3XEeAz9bDOuGLGLy+/44iufg2WL uIra948g2rh/Blb6/7fSRZ2RHYk6eM5DHwFLjWv4iU0cTV4WVZ2hMSyNgeWt6FDiqIx CfeOdLU6scdeVnltPm511PKhPd38xgG6R30Epn4c= From: Kent Watsen Message-ID: <0100017db664515c-d834ffd0-0860-4c60-b9be-0db0e349a69b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7C294ACE-FA71-4C09-B35C-E73042D01950" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 00:42:47 +0000 In-Reply-To: Cc: Jan Lindblad , "maqiufang (A)" , "netmod@ietf.org" To: "Sterne, Jason (Nokia - CA/Ottawa)" References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.8.83 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 00:42:55 -0000 --Apple-Mail=_7C294ACE-FA71-4C09-B35C-E73042D01950 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jason, > I'm not following your "In the meanwhile" thoughts. > =20 > Legacy clients are failing offline validation today. If running config = has a leafref to system config, and doesn't return that = system config (which it doesn't in some implementations), then the = instance data returned to the client doesn't validate against the YANG = model. These implementations don't have an explicit datastore = today (but they do have these internal semi-hidden referenceable list = entries). You=E2=80=99re correct about that, and I said so before about how, with = JUNOS, any ref to a =E2=80=9Cjunos-defaults=E2=80=9D node would fail = offline-validation of running. This is already an issue today. Also to your point, JUNOS has a templating-like mechanism (apply-groups) = that clients MUST understand. The NMS we built at Juniper had to = understand the =E2=80=9Capply-groups=E2=80=9D mechanism just to import = config for devices during a new-device onboarding workflow. K. --Apple-Mail=_7C294ACE-FA71-4C09-B35C-E73042D01950 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Jason,


I'm not following your "In the = meanwhile" thoughts.
 
Legacy clients are failing offline validation today. If = running config has a leafref to system config, and <get-config> = doesn't return that system config (which it doesn't in some = implementations), then the instance data returned to the client doesn't = validate against the YANG model.  These implementations don't have = an explicit <system> datastore today (but they do have these = internal semi-hidden referenceable list = entries).

You=E2=80=99re correct about that, and I said so = before about how, with JUNOS, any ref to a =E2=80=9Cjunos-defaults=E2=80=9D= node would fail offline-validation of running.  This is already an = issue today.

Also to your point, = JUNOS has a templating-like mechanism (apply-groups) that clients MUST = understand.  The NMS we built at Juniper had to understand the = =E2=80=9Capply-groups=E2=80=9D mechanism just to import config for = devices during a new-device onboarding workflow.

K.

= --Apple-Mail=_7C294ACE-FA71-4C09-B35C-E73042D01950-- From nobody Mon Dec 13 16:47: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 9884E3A0CDD for ; Mon, 13 Dec 2021 16:47:02 -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.20210112.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 t-A1TqWTEQnM for ; Mon, 13 Dec 2021 16:46:57 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 816B43A0CDE for ; Mon, 13 Dec 2021 16:46:57 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id m6so22236369lfu.1 for ; Mon, 13 Dec 2021 16:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DAfrvy3PTBW+E3gx2go9n9lNOxct9tIXC2ee2p2nBYM=; b=aDSexkJGj8i3PJrTsnnHnCy1KowTiWQld4lk4YE0J0t7sP9B1un5vWE5TjGTED2L7u OBjAHXEkYDfJyXhjxtH63pkGHdMMMOyNEP19P7nLypNKLCXyDUnn3zIa/vBLSeKNSmPl /uVIXVqdGPmoXSLY1A7iOV7t6OjQS49cQknRTeXCClQRbWYowMtX0Su8F8fppGVN1scV D47o3L8BCn6silYGUqVzKVoLf4JB+bYFafw3wxd3/NblEBbqIONunc2HoQfMhjI0lraa pR3nvF8u+OFfTdIvYQVayd9gsdEELREQXWxCuw12G77Z1floHKdo6aN7iT8zUYdgWQ/q 7XVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DAfrvy3PTBW+E3gx2go9n9lNOxct9tIXC2ee2p2nBYM=; b=HfiDTA9FCZ8g2rMuJYBp+hcT6S9Ug0zBuYYMMeDU5JyyZrA61LAnz6I8paOZF/5gdy mdk+jkvwj9BRaxi9AW7wXYaJaBfOEnpp9vgjkt7u/Ww4GwpUcK32Rw8V+W8P5kQZxhTO OvJpqYwDE9cwjUFpkdwsgdlSibE1rRS3Ea5uv+aGp+XT80x0O37694msUquYEN2EAcvt 9EPiVcCMev1jWz3ZWeVBUYjYjZJHynDzwMrhcxeVIAo5UEAqnm8p3wCX5ASJjRtIMWwC 38DPKm3sCiLR7a7IQlfKKEkrYR1WqJsJVMd/FfUVqP85HmROeXDKQtlFHrhINbgGY5kZ bIBw== X-Gm-Message-State: AOAM530nuwOojhLnFDywRxJ2lJnv+JyQ1G6LEkjwNGwNoqZ1iw35fyuC 5J7cRV+6LI5OLG0pnpYXY8Ib6bJxjm9XvyIBVB7jdw== X-Google-Smtp-Source: ABdhPJyGAIH9LxqiRzr4ebG8Z+KeKJ8AAv6WfsaKSTSw3wlx51NvYdoPLJYQDqbjNZSunMgtcfkkuAdTJefX2a0+3d0= X-Received: by 2002:a05:6512:3502:: with SMTP id h2mr1626381lfs.551.1639442813366; Mon, 13 Dec 2021 16:46:53 -0800 (PST) MIME-Version: 1.0 References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> In-Reply-To: <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> From: Andy Bierman Date: Mon, 13 Dec 2021 16:46:42 -0800 Message-ID: To: Kent Watsen Cc: Juergen Schoenwaelder , Jan Lindblad , "maqiufang (A)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008547d305d31086ee" Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 00:47:03 -0000 --0000000000008547d305d31086ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 13, 2021 at 3:44 PM Kent Watsen wrote: > Juergen/Andy, > > > Option #3 >> >> There is a client on the system that makes changes to running just >> like any other remote clients can make changes to running. System >> generate config that is not editable explicit config in running goes >> straight into the applied config in operational. This does not require >> a system datastore (in fact something like a system datastore may >> exist as the _logic_ of the system client, the good old example we had >> is allocting an unused uid for an account that, once allocated, is >> maintained in running). >> >> > Juergen, you mentioned this before. I don=E2=80=99t recall if there were= any > responses, but how would this solution address the various concerns that > have been raised? > > > +1 to option 3. > Consider an implementation that moves all the "hidden system logic" off-b= ox > to a controller, such that the initial config is literally supplied by an > external client. > > > Andy, IIRC, you +1=E2=80=99ed Juergen=E2=80=99s previous =E2=80=9Coption = #3=E2=80=9D, but can you to > answer the same question about how solution address concerns? > > I do not have any problem with containing active and inactive nodes. That's what has been in place for over 10 years. That's what is written in NMDA. I cannot find any RFC text that says has only nodes created by a client. I cannot find any RFC text that says system-injected config is special, especially since server implementations exist that treat these edits as just another client (although probably a 'root' user client). Rewriting NMDA and YANG validation to add a new datastore is a major change that will impede deployment. The IETF already had 1 "do-over= " because of NMDA. Not so sure a 2nd do-over is going to go over well. Andy > I have yet to hear a single use-case for creating a datastore. > "The client might want" is not a use-case for standardization. > I do not understand the "pure view". Seems like if this was a real proble= m > to solve, > then NMDA would have included a system datastore from the start. > > > Use-cases and issues were discussed at both the Interim and at IETF 112. > I don=E2=80=99t recall you or Juergen attending either, but the 112-recor= ding > starts at the 23-minute mark here: > https://play.conf.meetecho.com/Playout/?session=3DIETF112-NETMOD-20211111= -1430 > > > K. // as a contributor > > > > > > > > > --0000000000008547d305d31086ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 13, 2021 at 3:44 PM Kent = Watsen <kent@watsen.net> wrote= :
Juergen/Andy,


Opti= on #3

There is a client on the system that makes changes to running = just
like any other remote clients can make changes to running. Systemgenerate config that is not editable explicit config in running goes
s= traight into the applied config in operational. This does not require
a = system datastore (in fact something like a system datastore may
exist as= the _logic_ of the system client, the good old example we had
is alloct= ing an unused uid for an account that, once allocated, is
maintained in = running).


Juergen, you mentioned this before.=C2=A0 I don=E2=80=99t reca= ll if there were any responses, but how would this=C2=A0solution address th= e various concerns that have been raised?=C2=A0

+1 to option 3.
=
Consider an implementation that moves all the "hi= dden system logic" off-box
to a controller, = such that the initial config is literally supplied by an external client.

Andy, IIRC, you +1=E2=80=99ed Juergen= =E2=80=99s previous =E2=80=9Coption #3=E2=80=9D, but can you to answer the = same question about how=C2=A0solution addr= ess concerns?


=
I do not have any problem with <running> containing active= and inactive nodes.
That's what has been in place for over 1= 0 years. That's what is written in NMDA.
I cannot find any RF= C text that says <running> has only nodes created by a client.
<= div>I cannot find any RFC text that says system-injected config is special,= especially since
server implementations exist that treat these e= dits as just another client
(although probably a 'root' u= ser client).

Rewriting NMDA and YANG validation to= add a new <system> datastore is
a major change that will i= mpede deployment. The IETF already had 1 "do-over"
beca= use of NMDA.=C2=A0 Not so sure a 2nd do-over is going to go over well.

Andy


I have yet to h= ear a single use-case for creating a <system> datastore.
"The client might want" is not a use-case for stand= ardization.
I do not understand the "pure vi= ew". Seems like if this was a real problem to solve,
then NMDA would have included a system datastore from the start.=

Use-cases and issues were discussed at bo= th the Interim and at IETF 112. =C2=A0 I don=E2=80=99t recall you or Juerge= n attending=C2=A0either, but the 112-recordin= g starts at the 23-minute mark here:=C2=A0https://play.conf.meetecho.com/Playout/?session=3DIETF112-NE= TMOD-20211111-1430


K. =C2=A0// = as a contributor







--0000000000008547d305d31086ee-- From nobody Mon Dec 13 17:01: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 23E673A0CEA for ; Mon, 13 Dec 2021 17:01:50 -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.20210112.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 LJjJWLsp-aNk for ; Mon, 13 Dec 2021 17:01:45 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 29CDF3A0CD9 for ; Mon, 13 Dec 2021 17:01:45 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id z7so34011546lfi.11 for ; Mon, 13 Dec 2021 17:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FblA0Wbw2r3EmGwc99leu4hnFShVQA0eM1W6dhk49l8=; b=o34dHSH4/vb/MJEeD7ASgO+NFbdAxCTCxsaWufKkTBSEBKEdxb2qanr4y20OZoMXFz Yo4JvOX7sRQ0jDH2EtkJQeAd+19GhhQVg+YySx0hlnJaGfF3aCmU6QzHdyGT6CKW28US 0d89v8h4MPSvdBuX5jDBTvjEh/3JEVdpnsnQfaMSswTuuTjFo5wklxw4ay+KX8tHAJin 9qVT4qXGRIyG5WE+TB+D9H32IIV/DDoBEnheU6F1dqfO4KfdRep9uF2gQOjwVdXT9XLu xKJtj7uQm07n/RahkEaUcg6mxCJpbIn1sm9O0gGWUVuYbEOuJeApbismuLFV9rnqt5qi zQ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FblA0Wbw2r3EmGwc99leu4hnFShVQA0eM1W6dhk49l8=; b=gO21EhR61lBNwd8A7xTFPzyqnl4KoP/uBOEOjuncA/PaeTitgYbpRJVWbq3VbwDDEf 0RgtpcfCGo7RUKKOF9V54r4tkuc5z9ErmRoRtRqCWA/fj0KLWIufqeQoxjXvkAEsH0TA 7sCSvMiTnVAT9ElkG2Pf2cbdPBPoS/9g5sKKq1lpJfkGx3NhmSrF3xfRTvUELnvZdRpQ ZKxCsi//tb9hgR2nXbSam7dj9QGHGUmqvT/zVK/lFZNh8UU9G0cYV1wbTKWRby/xqQ// 3qTov/MVX5osUdT4V36qnPrxzoyz7S91xdba01zLi9dyT1idvaL9H2fGzHVEi28X6LJT zp8w== X-Gm-Message-State: AOAM532X37fVbtrz7tAA9sl/dqdTWusiKcdA7fgN7t1O2pvjEDUESK7k QlwkoQg4JGnN6eAEKyZbV3b1JqUFoIXLXi6ROiR65g== X-Google-Smtp-Source: ABdhPJx87+xiACXELkYaIJEgxz1msQ9LfkFOJN8hLmtnq8LR5l2iyu7kPBxuHPrCLpnh18/fimav+rJ5E/+M/ZNIep8= X-Received: by 2002:ac2:5317:: with SMTP id c23mr1670915lfh.525.1639443698272; Mon, 13 Dec 2021 17:01:38 -0800 (PST) MIME-Version: 1.0 References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <0100017db664515c-d834ffd0-0860-4c60-b9be-0db0e349a69b-000000@email.amazonses.com> In-Reply-To: <0100017db664515c-d834ffd0-0860-4c60-b9be-0db0e349a69b-000000@email.amazonses.com> From: Andy Bierman Date: Mon, 13 Dec 2021 17:01:27 -0800 Message-ID: To: Kent Watsen Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "maqiufang (A)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000043e11d05d310bb28" Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 01:01:50 -0000 --00000000000043e11d05d310bb28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Mon, Dec 13, 2021 at 4:43 PM Kent Watsen wrote: > > Hi Jason, > > > I'm not following your "In the meanwhile" thoughts. > > Legacy clients are failing offline validation today. If running config ha= s > a leafref to system config, and doesn't return that system > config (which it doesn't in some implementations), then the instance data > returned to the client doesn't validate against the YANG model. These > implementations don't have an explicit datastore today (but they > do have these internal semi-hidden referenceable list entries). > > > This is an implementation bug. YANG validation for configuration data nodes is very clear. It intentionally does not allow any leafrefs to point at data nodes outside . Vendors who follow these YANG rules can return a representation of that can be validated. Andy > You=E2=80=99re correct about that, and I said so before about how, with J= UNOS, any > ref to a =E2=80=9Cjunos-defaults=E2=80=9D node would fail offline-validat= ion of running. > This is already an issue today. > > Also to your point, JUNOS has a templating-like mechanism (apply-groups) > that clients MUST understand. The NMS we built at Juniper had to > understand the =E2=80=9Capply-groups=E2=80=9D mechanism just to import co= nfig for devices > during a new-device onboarding workflow. > > K. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000043e11d05d310bb28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,


On Mon, = Dec 13, 2021 at 4:43 PM Kent Watsen <= kent@watsen.net> wrote:

Hi Jason,


I'm not following your "In the meanwhile" tho= ughts.
=C2=A0
Leg= acy clients are failing offline validation today. If running config has a l= eafref to system config, and <get-config> doesn't return that sys= tem config (which it doesn't in some implementations), then the instanc= e data returned to the client doesn't validate against the YANG model.= =C2=A0 These implementations don't have an explicit <system> data= store today (but they do have these internal semi-hidden referenceable list= entries).



This is an implementation bug.
YAN= G validation for configuration data nodes is very clear.
It inten= tionally does not allow any leafrefs to point at data nodes outside <run= ning>.
Vendors who follow these YANG rules can return a repres= entation of <running>
that can be validated.=C2=A0

Andy

=C2=A0
You=E2=80=99re correct about that, and I said so befor= e about how, with JUNOS, any ref to a =E2=80=9Cjunos-defaults=E2=80=9D node= would fail offline-validation of running.=C2=A0 This is already an issue t= oday.

Also to your point, JUNOS has a templating-l= ike mechanism (apply-groups) that clients MUST understand.=C2=A0 The NMS we= built at Juniper had to understand the =E2=80=9Capply-groups=E2=80=9D mech= anism just to import config for devices during a new-device onboarding work= flow.

K.

_______________= ________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000043e11d05d310bb28-- From nobody Mon Dec 13 17:20:55 2021 Return-Path: <0100017db687265c-c29335a4-1b1d-4f15-bc9f-dfb3786ee5ce-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 CB2573A0D19 for ; Mon, 13 Dec 2021 17:20:53 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 (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 HJvohq28lrdT for ; Mon, 13 Dec 2021 17:20:52 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5DD3A0D18 for ; Mon, 13 Dec 2021 17:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639444850; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=QdLoE+YRb81yP/BeRMI1yySYih5Q+GSL423y+edTLeU=; b=is+y2mlPQwwOFm0OGxwdrbmdxVvqURvtw3jSR1kNm8VyL0OW7E/bHii+/mBZy1Hv wZSROru8ebXunYXAxs0xJ1ejhQtlKzKxrJzfdCPIdfRV7pWrFImKqpxCToYNdMQtXRQ TVz9M8zLh+JyNgG2zV3A77h91ScOuUrflU/H0dLI= From: Kent Watsen Message-ID: <0100017db687265c-c29335a4-1b1d-4f15-bc9f-dfb3786ee5ce-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_80E33BDE-4B6B-42EA-ADC8-DACB90FA287A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 01:20:50 +0000 In-Reply-To: Cc: "maqiufang (A)" , "netmod@ietf.org" To: "Sterne, Jason (Nokia - CA/Ottawa)" References: <79459f02f6ea4a87bea56edc9772daa6@huawei.com> <178f7cabbf0141b4815349dad3555bb4@huawei.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.8.96 Archived-At: Subject: Re: [netmod] "immutable" flag 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, 14 Dec 2021 01:20:54 -0000 --Apple-Mail=_80E33BDE-4B6B-42EA-ADC8-DACB90FA287A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jason, Quifang, > I think there are use-cases for "immutable" even outside of system = config so we may not want to restrict it to system config. > [Qiufang Ma] Agree that we can just define such an =E2=80=9Cimmutable=E2= =80=9D flag without restricting it to decorating system configuration. = In that way, maybe we can discuss whether we should define this = annotation in an independent I-D.[>>JTS: ] Yes perhaps. Although I'm = not sure this is an urgent item for the WG. Interested to hear what = others think as well. Agreed to not restricting context. For instance, in a past-life, I used = an =E2=80=9Cimmutable=E2=80=9D flag for config resources exported from a = host-system to logical-systems (think: host exports eth3 to logical = system; logical-system can see =E2=80=9Ceth3=E2=80=9D in its config = (perhaps now its config), but the config node is immutable from = the logical-system=E2=80=99s PoV. I do think an independent I-D is needed for an =E2=80=9Cimmutable=E2=80=9D= annotation. It may (or not) be the case that this work has a = normative dependency on that I-D. > Regarding this =E2=80=9Cimmutable=E2=80=9D flag there may be a = question to answer: what if legacy clients receive some annotations they = do not understand? Should they just ignore it silently? [>>JTS: ] Yes - = that is what clients would have to do. Not ideal but maybe not critical. = Servers have various reasons they may reject a configuration, even if = that configuration looks valid against the YANG model. =20 Handling legacy clients will be the biggest issue with introducing an = =E2=80=9Cimmutable=E2=80=9D flag. =20 > I'm not sure it would be as simple as erroring when a write is = attempted to that value.=20 Say some more, Jason, since this is the *only* =E2=80=9Crelief valve=E2=80= =9D we have with this solution=E2=80=A6 =20 > Are you talking about an error at edit time, or at commit/validation = time ? > [Qiufang Ma] My assumption is an error at edit time, static checks are = sufficient for the server to detect the problem. But I think it=E2=80=99s = also okay to report an error at commit/validation time. [>>JTS: ] I = think in order to allow the behavior I mention at the end, we'd need to = make this a commit time behavior. IMO the candidate should be allowed to = contain a new/changed value for an immutable leaf. The when the commit = occurs, the system can attempt to achieve what the candidate is asking = for. If it can't achieve it, then it can reject. Agreed. =20 > What if the value configured is the same as the current value ? > [Qiufang Ma] I have the same question. Some implementations do allow = the client to configure a same value(e.g., for the purpose of offline = validation of ). But I feel that it may depend on the = discussion of another thread =E2=80=9Cshould the origin=3D=E2=80=99system=E2= =80=99 be required for system configurations copied/pasted into = =E2=80=99=E2=80=9D which I posted to the WG. If the = origin=3D=E2=80=9Cintended=E2=80=9D , it actually means overwrite. > [>>JTS: ] The "immutable" tag would be in the YANG model, which means = it is against that schema node whether there is an equivalent data node = in or or both. I think it becomes a warning to the = client that the value can't be *changed* in a datastore. It can only be = *created* initially (if it didn't already exist). For a leaf that is at = the top level or only has non-presence containers as ancestors, it means = that leaf can only be set once in any particular datastore (or maybe = changing it requires a reboot ?). For leafs that are descendants of = presence containers or lists, then the nearest p-container or list entry = ancestor would have to be effectively deleted and re-created under the = hood to get to the config that the user declared they want. I think the =E2=80=9Cimmutable=E2=80=9D would be a metadata annotation = (not a YANG "extension") > It is probably best if this is a validation/commit time check. > =20 > If the immutable leaf is inside a list entry, then it should probably = be acceptable for the server to allow a change to the leaf by destroying = and re-creating the list entry under the hood. i.e. allow a change to = the immutable item (which is in line with configurations being = "declarative" - just get me there if possible). > [Qiufang Ma] Are you suggesting a server should allow a client to = delete/create the =E2=80=9Cimmutable=E2=80=9D data item in ? = Wouldn't that be a little strange if a client can delete a particular = data item but has no right to change its value? Theoretically, the = deletable is modifiable. > [>>JTS: ] I don't think delete is allowed unless a parent is deleted = (i.e. the nearest presence container or list entry). But we do need to = allow parents of immutable leafs to be deleted IMO. Hmmm, that last bit (deleting an immutable node=E2=80=99s ancestor) = doesn=E2=80=99t sit well with me=E2=80=A6do you have a use-case in mind? K. --Apple-Mail=_80E33BDE-4B6B-42EA-ADC8-DACB90FA287A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jason, Quifang,


I think there are use-cases for "immutable" even outside of = system config so we may not want to restrict it to system config.
[Qiufang = Ma] Agree that we can just define such an =E2=80=9Cimmutable=E2=80=9D = flag without restricting it to decorating system configuration. In that = way, maybe we can discuss whether we should define this annotation in an = independent I-D.[>>JTS: ]  Yes perhaps. Although I'm not sure this = is an urgent item for the WG. Interested to hear what others think as = well.

Agreed to not restricting context.  For = instance, in a past-life, I used an =E2=80=9Cimmutable=E2=80=9D flag for = config resources exported from a host-system to logical-systems (think: = host exports eth3 to logical system; logical-system can see =E2=80=9Ceth3=E2= =80=9D in its config (perhaps now its <system> config), but the = config node is immutable from the logical-system=E2=80=99s = PoV.

I do think an = independent I-D is needed for an =E2=80=9Cimmutable=E2=80=9D annotation. =  It may (or not) be the case that this <system> work has a = normative dependency on that I-D.


Regarding this =E2=80=9Cimmutable=E2=80=9D = flag  there may be a question to answer: what if legacy clients = receive some annotations they do not understand? Should they just ignore = it silently? [>>JTS: ] Yes - that is = what clients would have to do. Not ideal but maybe not critical. Servers = have various reasons they may reject a configuration, even if that = configuration looks valid against the YANG model. =  

Handling legacy clients will be the biggest issue with = introducing an =E2=80=9Cimmutable=E2=80=9D flag.

 
I'm = not sure it would be as simple as erroring when a write is attempted to = that value. 

Say some more, Jason, since this is the *only* =E2=80=9Crelief = valve=E2=80=9D we have with this solution=E2=80=A6


 
Are = you talking about an error at edit time, or at commit/validation time = ?
[Qiufang Ma] My assumption is an error at edit time, static = checks are sufficient for the server to detect the problem. But I think = it=E2=80=99s also okay to report an error at commit/validation = time. [>>JTS: ] I think in = order to allow the behavior I mention at the end, we'd need to make this = a commit time behavior. IMO the candidate should be allowed to contain a = new/changed value for an immutable leaf. The when the commit occurs, the = system can attempt to achieve what the candidate is asking for. If it = can't achieve it, then it can = reject.

Agreed.

 
What if the value configured is the same as the current value = ?
[Qiufang Ma] I have the same question. Some implementations = do allow the client to configure a same value(e.g., for the purpose of = offline validation of <running>). But I feel that it may depend on = the discussion of another thread =E2=80=9Cshould the origin=3D=E2=80=99sys= tem=E2=80=99 be required for system configurations copied/pasted into = <running>=E2=80=99=E2=80=9D which I posted to the WG. If the = origin=3D=E2=80=9Cintended=E2=80=9D , it actually means overwrite.
[>>JTS: ] The = "immutable" tag would be in the YANG model, which means it is against = that schema node whether there is an equivalent data node in = <system> or <candidate> or both. I think it becomes a = warning to the client that the value can't be *changed* in a datastore. = It can only be *created* initially (if it didn't already exist).  = For a leaf that is at the top level or only has non-presence containers = as ancestors, it means that leaf can only be set once in any particular = datastore (or maybe changing it requires a reboot ?).   For = leafs that are descendants of presence containers or lists, then the = nearest p-container or list entry ancestor would have to be effectively = deleted and re-created under the hood to get to the config that the user = declared they = want.

I think the =E2=80=9Cimmutable=E2=80=9D would be a = metadata annotation (not a YANG "extension")


It is probably best if this is a validation/commit time = check.
 
If the immutable leaf = is inside a list entry, then it should probably be acceptable for the = server to allow a change to the leaf by destroying and re-creating the = list entry under the hood.  i.e. allow a change to the immutable = item (which is in line with configurations being "declarative" - just = get me there if possible).
[Qiufang Ma] Are you suggesting a server = should allow a client to delete/create the =E2=80=9Cimmutable=E2=80=9D = data item in <running>? Wouldn't that be a little strange if a = client can delete a particular data item but has no right to change its = value?  Theoretically, the deletable is modifiable.
[>>JTS: ] I don't think = delete is allowed unless a parent is deleted (i.e. the nearest presence = container or list entry). But we do need to allow parents of immutable = leafs to be deleted = IMO.

Hmmm, that last bit (deleting an immutable = node=E2=80=99s ancestor) doesn=E2=80=99t sit well with me=E2=80=A6do you = have a use-case in mind?

K.


= --Apple-Mail=_80E33BDE-4B6B-42EA-ADC8-DACB90FA287A-- From nobody Mon Dec 13 17:32:14 2021 Return-Path: <0100017db69159e5-16596fab-ac8f-48b9-8e81-ad5db2e749bf-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 788973A0D70 for ; Mon, 13 Dec 2021 17:32:03 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=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 jB_JfVN_meYc for ; Mon, 13 Dec 2021 17:32:00 -0800 (PST) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F9B3A0D6F for ; Mon, 13 Dec 2021 17:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639445519; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=QOzm/3nYsJXdZ4O5ZNdb07rWZDB0afim0vsmWCpEn/k=; b=CFU4AMJhJm3pGAzygKAtYIfmHPbGkS3GRPgnIdGHA+0lUHacwN4L667nNtKBK7Zi uiY4SHpiPlMIFVb+MNdhdTmCys+zYSdtSXZfG8dMvE8e8AU7zVW4eBYnWbCxTDfA6lo RshUHZhMvaNrj41jonUH+lZ6muTkHd1UGrjU8QtE= From: Kent Watsen Message-ID: <0100017db69159e5-16596fab-ac8f-48b9-8e81-ad5db2e749bf-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B0EC4928-0398-4031-9350-BA438A4A87EA" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 01:31:58 +0000 In-Reply-To: Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "maqiufang (A)" , "netmod@ietf.org" To: Andy Bierman References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.48.90 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 01:32:13 -0000 --Apple-Mail=_B0EC4928-0398-4031-9350-BA438A4A87EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 8, 2021, at 5:50 PM, Andy Bierman wrote: >=20 > Andy - about use cases. Here is a problem we're trying to address: >=20 > =20 >=20 > There are at least several major router implementations that have this = concept of "hidden config" (i.e. list entries that can be referenced in = a leafref by explicit user config, but those list entries are not = returned in a ). =20 >=20 >=20 > Clearly not in compliance with RFC 7950. Andy, can you please point to the part in RFC 7950 that says offline = validation must be supported? I believe that this "common = understanding=E2=80=9D actually lacks a basis, and an equally-valid = interoperation is that the must be valid *on the server* = vis-a-vis it actually validating . > IMO the "enable flag" approach to the general problem, presented by = Kent a couple years ago, > is a much simpler and better solution than a new datastore. > The full set of nodes is in . > A generalized "enable" mechanism causes the resource to be used or = not, > where it shows up in and if enabled=3Dtrue. >=20 > IMO this fits the original intent of NMDA and does so in a way that = requires > the least disruption to current compliant implementations. You have the memory of an elephant ;) That I-D (conditional-enablement [1]) was mostly about how to support = JUNOS=E2=80=99s =E2=80=9Cinactive=E2=80=9D annotation. I replaced the = negative =E2=80=9Cinactive=E2=80=9D with positive =E2=80=9Cenabled=E2=80=9D= for readability. That draft also shined a light on how the = =E2=80=9Cenabled=E2=80=9D annotation could be used in firewall = pollination for, e.g., 9am-5pm ACL rules. I guess I=E2=80=99m unclear about the relation to the system-defined = config - can you say some more? [1] = https://datatracker.ietf.org/doc/html/draft-kwatsen-conditional-enablement= -00 = K. --Apple-Mail=_B0EC4928-0398-4031-9350-BA438A4A87EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 8, 2021, at 5:50 PM, Andy Bierman <andy@yumaworks.com> = wrote:

Andy - about use cases.  Here = is a problem we're trying to address:

 

There are at least several = major router implementations that have this concept of "hidden config" = (i.e. list entries that can be referenced in a leafref by explicit user = config, but those list entries are not returned in a = <get-config>).  


Clearly not in compliance with RFC = 7950.

Andy, can = you please point to the part in RFC 7950 that says offline validation = must be supported?   I believe that this "common understanding=E2=80=9D= actually lacks a basis, and an equally-valid interoperation is that the = <running> must be valid *on the server* vis-a-vis it actually = validating <intended>.



IMO the "enable flag" approach to the general problem, = presented by Kent a couple years ago,
is a much simpler and better solution = than a new <system> datastore.
The full set of nodes is in = <running>.
A generalized "enable" mechanism = causes the resource to be used or not,
where it shows up in <intended> = and <operational> if enabled=3Dtrue.

IMO = this fits the original intent of NMDA and does so in a way that = requires
the least disruption to current compliant = implementations.

You have = the memory of an elephant  ;)

That I-D (conditional-enablement [1]) was mostly = about how to support JUNOS=E2=80=99s =E2=80=9Cinactive=E2=80=9D = annotation.  I replaced the negative =E2=80=9Cinactive=E2=80=9D = with positive =E2=80=9Cenabled=E2=80=9D for readability.  That = draft also shined a light on how the =E2=80=9Cenabled=E2=80=9D = annotation could be used in firewall pollination for, e.g., 9am-5pm ACL = rules.

I guess I=E2=80=99m unclear = about the relation to the system-defined config - can you say some = more?

[1] https://datatracker.ietf.org/doc/html/draft-kwatsen-conditional= -enablement-00


K.



= --Apple-Mail=_B0EC4928-0398-4031-9350-BA438A4A87EA-- From nobody Mon Dec 13 17:36:48 2021 Return-Path: <0100017db695ae60-6353d5b1-c44a-4265-ba02-09ba8a306a77-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 22CC63A0D40 for ; Mon, 13 Dec 2021 17:36:45 -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_HELO_NONE=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=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 G-MypoNA4Ntq for ; Mon, 13 Dec 2021 17:36:44 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E3D3A0D3E for ; Mon, 13 Dec 2021 17:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639445802; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=09JoE5+MtK2sYBg3w1TI2ltvPJl+pIAztQzgTd7SACE=; b=by/v6y1IDCBa5qvcHIF0y2Ur2ORb/Dfj4GSm4r1SUk4DeD+6m0eE69SuWL+W4aXu p5yu62dJhBEtaTcDFHQxOtx6UlnEWUp3P7+abFjDjI1/pBp7r1MZBSU5ME7rAvTSHhF ylqbxLmgkZrlTUENG8bIRZSlv+zkT1cMDOuOxALU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: Date: Tue, 14 Dec 2021 01:36:42 +0000 Cc: Juergen Schoenwaelder , "Rob Wilton (rwilton)" , "maqiufang1=40huawei.com@dmarc.ietf.org" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017db695ae60-6353d5b1-c44a-4265-ba02-09ba8a306a77-000000@email.amazonses.com> References: <20211123.083850.1266325188190711456.id@4668.se> <1ab9c19f3f7c4126b715d2e389eafdaf@huawei.com> <20211124092508.cga6mutlusyaq4mm@anna> <20211124.114340.856721981810780593.id@4668.se> <20211125114733.phenv7mktyed6d4v@anna> To: "Sterne, Jason (Nokia - CA/Ottawa)" X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.8.96 Archived-At: Subject: Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ? 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, 14 Dec 2021 01:36:45 -0000 Hi Jason, > The primary config use cases I see aren't so much interfaces, = cards, etc. It is more for things like built in qos profiles and other = handy policy objects that are more static (e.g. like Kent's JUNOS = examples he has described). I'm not necessarily saying we preclude some = of the resource-based dynamic system config proposed in the draft, but = maybe those parts are more confusing/contentious. I agree about the primary focus being on the =E2=80=9Cshared = objects=E2=80=9D=E2=80=A6at least, that=E2=80=99s 90% of what=E2=80=99s = in the JUNOS junos-defaults =E2=80=9Cdatastore=E2=80=9D (in quotes = because it=E2=80=99s not really a datastore). K. From nobody Mon Dec 13 17:48: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 5FEBF3A0D4E for ; Mon, 13 Dec 2021 17:48:15 -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.20210112.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 5K70BGL-Q9yq for ; Mon, 13 Dec 2021 17:48:10 -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 DBF5A3A0D4C for ; Mon, 13 Dec 2021 17:48:09 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id 207so26207128ljf.10 for ; Mon, 13 Dec 2021 17:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dL24dl/E+vt5HINRyr7aKtyelcrpTNTJYifovaVgYQA=; b=4M/dSfcrZDHT+5RzjpheZn+06mgI6BrpMdziDuVr1jooG40yzdoRVOHjQgK/reakQ4 wi2d0UiE3NMO9ldOj1Dp4pPKyiU54NZQcFrVfaCFJLTrmAcHq8npPpfaowMXcTqF/QWE GclEQMnSQSTT/sdDLSbivGc3j604NYkGEZFXz/G+EpqrH+ZszEuU93ih+1zGVb250ZJf j96hoHwuB7euWsrdWuvy6qW7KhzR54PPEfzboMJMo/Gfs0ad9AsJpzhT1CdLilO6Ty7B MqSg4vYqkU+Buhj0YSJ2QKE6m1o7pbR8210V2hv5fD7zgZOyrMrHlQWcgOUhJD7OLBII GmDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dL24dl/E+vt5HINRyr7aKtyelcrpTNTJYifovaVgYQA=; b=el4d+ik82d8PQfDtdM4iBUo2NE5L8G0KQJvEABaI1jTatLyBFnvp4wHSSuIUFt1e3A 9c1lJAUJ8i83DL/DJT47wTSXyy7YnmlvEKi0gBhfdRdI3eWVz4AaEZbpk90jFx4le+OL DJwttRrq6KPXfGRnXnGjZj175rjy2y1Zyjqq6rbKIksoyRQyqfAOxvHH/IdSpmPJkIUE TkNGHch96M1TXeEyqNcodwZ/xEHxG3H1ivHWvLgVM9gUrr9EeWSjzThBxWaL1QkPYnbO 7BcAwzgOMN4E68Fja8q9/G2RgEiHhwIjNUhEVC5bp+N0TY5RJMF9VgQ/vIFRoFfE9841 gHMA== X-Gm-Message-State: AOAM532IW6IHPPxwPLHEwPLa/lcPTZfouRaAXTyjOEUd9i6/BYQ61AM5 JOSOiqz4EPRkRKWNecFcbxWrCfDvGU2spndizkSzyg== X-Google-Smtp-Source: ABdhPJxYGSc9p11m/FrVEqnnnAcjgtxRhoCz1w7ZnLG/GhOZU7EocgxiVt0XW0zSzk3MHcE6cNFrvK3E/O0WRHP2gBM= X-Received: by 2002:a2e:3012:: with SMTP id w18mr2018901ljw.344.1639446487159; Mon, 13 Dec 2021 17:48:07 -0800 (PST) MIME-Version: 1.0 References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db69159e5-16596fab-ac8f-48b9-8e81-ad5db2e749bf-000000@email.amazonses.com> In-Reply-To: <0100017db69159e5-16596fab-ac8f-48b9-8e81-ad5db2e749bf-000000@email.amazonses.com> From: Andy Bierman Date: Mon, 13 Dec 2021 17:47:56 -0800 Message-ID: To: Kent Watsen Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "maqiufang (A)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007ee9e005d3116162" Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 01:48:15 -0000 --0000000000007ee9e005d3116162 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 13, 2021 at 5:31 PM Kent Watsen wrote: > > > On Dec 8, 2021, at 5:50 PM, Andy Bierman wrote: > > Andy - about use cases. Here is a problem we're trying to address: >> >> >> >> There are at least several major router implementations that have this >> concept of "hidden config" (i.e. list entries that can be referenced in = a >> leafref by explicit user config, but those list entries are not returned= in >> a ). >> > > Clearly not in compliance with RFC 7950. > > > Andy, can you please point to the part in RFC 7950 that says offline > validation must be supported? I believe that this "common understanding= =E2=80=9D > actually lacks a basis, and an equally-valid interoperation is that the > must be valid *on the server* vis-a-vis it actually validating > . > > I think sec. 6.4 and sec. 8 are clear enough how validation of the datastore is done. Leafrefs in are not allowed to point to a node outside of . Andy > > IMO the "enable flag" approach to the general problem, presented by Kent = a > couple years ago, > is a much simpler and better solution than a new datastore. > The full set of nodes is in . > A generalized "enable" mechanism causes the resource to be used or not, > where it shows up in and if enabled=3Dtrue. > > IMO this fits the original intent of NMDA and does so in a way that > requires > the least disruption to current compliant implementations. > > > You have the memory of an elephant ;) > > That I-D (conditional-enablement [1]) was mostly about how to support > JUNOS=E2=80=99s =E2=80=9Cinactive=E2=80=9D annotation. I replaced the ne= gative =E2=80=9Cinactive=E2=80=9D with > positive =E2=80=9Cenabled=E2=80=9D for readability. That draft also shin= ed a light on how > the =E2=80=9Cenabled=E2=80=9D annotation could be used in firewall pollin= ation for, e.g., > 9am-5pm ACL rules. > > I guess I=E2=80=99m unclear about the relation to the system-defined conf= ig - can > you say some more? > > [1] > https://datatracker.ietf.org/doc/html/draft-kwatsen-conditional-enablemen= t-00 > > > K. > > > > --0000000000007ee9e005d3116162 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 13, 2021 at 5:31 PM Kent = Watsen <kent@watsen.net> wrote= :


On = Dec 8, 2021, at 5:50 PM, Andy Bierman <andy@yumaworks.com> wrote:

Andy - about use cases.=C2=A0 Here is a prob= lem we're trying to address:

=C2=A0

There are at least several major router implementati= ons that have this concept of "hidden config" (i.e. list entries = that can be referenced in a leafref by explicit user config, but those list= entries are not returned in a <get-config>).=C2=A0=C2=A0

<= /div>

Clearly not in compliance with RFC 7950.

=
Andy, can you please point to the part in RFC 7950 that says off= line validation must be supported? =C2=A0 I believe that this "common = understanding=E2=80=9D actually lacks a basis, and an equally-valid interop= eration is that the <running> must be valid *on the server* vis-a-vis= it actually validating <intended>.

<= /blockquote>

I think sec. 6.4 and sec. 8 are clear enoug= h how validation of the <running> datastore is done.
Leafre= fs=C2=A0in <running> are not allowed to point to a node outside of &l= t;running>.

Andy



IMO the "enable flag" approach to the general = problem, presented by Kent a couple years ago,
is= a much simpler and better solution than a new <system> datastore.
The full set of nodes is in <running>.
<= div style=3D"font-family:Helvetica;font-size:14px;font-style:normal;font-va= riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start= ;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te= xt-decoration:none">A generalized "enable" mechanism causes the r= esource to be used or not,
where it shows up in &= lt;intended> and <operational> if enabled=3Dtrue.

IMO this fits the original intent= of NMDA and does so in a way that requires
the l= east disruption to current compliant implementations.

You have the memory = of an elephant =C2=A0;)

That I-D (conditional-enab= lement [1]) was mostly about how to support JUNOS=E2=80=99s =E2=80=9Cinacti= ve=E2=80=9D annotation.=C2=A0 I replaced the negative =E2=80=9Cinactive=E2= =80=9D with positive =E2=80=9Cenabled=E2=80=9D for readability.=C2=A0 That = draft also shined a light on how the =E2=80=9Cenabled=E2=80=9D annotation c= ould be used in firewall pollination for, e.g., 9am-5pm ACL rules.

I guess I=E2=80=99m unclear about the relation to the syst= em-defined config - can you say some more?

[1]=C2=A0https://datatracker.ietf.org/doc/html/draft-k= watsen-conditional-enablement-00


K.



--0000000000007ee9e005d3116162-- From nobody Mon Dec 13 17:49:15 2021 Return-Path: <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-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 B3C263A0D47 for ; Mon, 13 Dec 2021 17:49:12 -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, RCVD_IN_MSPIKE_H2=-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=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 tlDtFoAxWPMK for ; Mon, 13 Dec 2021 17:49:07 -0800 (PST) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B6F3A0D43 for ; Mon, 13 Dec 2021 17:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639446546; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=5lyi1eph6q2glhkyUDXudRE8ijVCY3Z5DMwGDb4ABPU=; b=KS7DkUoh0/FWQhIApZ64lxw2cbwng2F79j81zCnem2M+Prp5iraHb5528pFvyLJd JgWWCC+QMWtF0N3i3teClWqUoC/AbmvOy3nNv/ZTRYCAFe7O5dm74wKDUedi0KPZcyW I9b42SmdSMUCSaQm1mlvklsiTDDF3JPm/IChG3xA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: <24856.1639347093@localhost> Date: Tue, 14 Dec 2021 01:49:06 +0000 Cc: Carsten Bormann , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> References: <11003.1639343822@localhost> <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.48.93 Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 14 Dec 2021 01:49:13 -0000 > On Dec 12, 2021, at 5:11 PM, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >> On 2021-12-12, at 22:17, Michael Richardson = wrote: >=20 >>> I'm working on draft-richardson-anima-rfc8366bis, trying to make it = RFC8791. >> [=E2=80=A6] >>> What I don't know how to deal with: >=20 >> RFC 8792? >=20 > If I put \ into the original .yang file, then it won't process. > So if RFC8792 is the solution, then I think that I probably prefer to = have > ::include do it. Otherwise, I have to add another step to the = workflow. >=20 > I'd also want assurance that the YANG module extractor knows about = 8792. > Maybe given that Kent is a leader author on that... it's already taken = care of. `pyang` and I think `yanglint` also know how to extract folded = and elements. That said, I have never needed to fold a YANG module in an I-D. As = Juergen mentioned, YANG=E2=80=99s built-in mechanisms have always = enabled me to fit within 69-columns. Unsure about module-extractor. My guess is that it will barf ;) K. From nobody Mon Dec 13 18:55:23 2021 Return-Path: <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-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 090253A0DFC for ; Mon, 13 Dec 2021 18:55:22 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=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 Xxhh_4QYYWPh for ; Mon, 13 Dec 2021 18:55:17 -0800 (PST) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868203A0DFF for ; Mon, 13 Dec 2021 18:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639450516; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=7rMH3x05bB3Zdpjf7We/p+W+blCgI6P+o96bmaC4XX0=; b=Nc6uKx2+BxGTBxOgFJ12TI9HPQhW3xtQyR1rXunxXNbMXypOx7rPL7+t91avdFO6 79/KzQsLb5aLiNL5mM9z4KZtI82e19QHsB7Xtwzq1xEUXaPgeVxlQwKQlLTOYlOvqdF H2syzmnV5bdB6ICwyq6jSlOdcipnxWwvfgsWqbKk= From: Kent Watsen Message-ID: <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_91AD5C67-8A3B-42EA-8B30-8A4E55A64681" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 02:55:15 +0000 In-Reply-To: Cc: "maqiufang (A)" , "netmod@ietf.org" To: Andy Bierman References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.48.90 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 02:55:22 -0000 --Apple-Mail=_91AD5C67-8A3B-42EA-8B30-8A4E55A64681 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, > I do not have any problem with containing active and = inactive nodes. > That's what has been in place for over 10 years. That's what is = written in NMDA. For posterity, it=E2=80=99s been =E2=80=9Cin place=E2=80=9D only in = proprietary implementations. It would be nice to resurrect the = =E2=80=9Cconditional-enablement=E2=80=9D draft to have an RFC for it. > I cannot find any RFC text that says has only nodes created = by a client. Really? Interesting. Still, I know it=E2=80=99s a mantra we=E2=80=99ve = held closely for many year, right? > I cannot find any RFC text that says system-injected config is = special, especially since > server implementations exist that treat these edits as just another = client > (although probably a 'root' user client). Very true (and Juergen=E2=80=99s point as well). I=E2=80=99ve seen this = done before. Unhappy results. > Rewriting NMDA and YANG validation to add a new datastore is > a major change that will impede deployment. The IETF already had 1 = "do-over" > because of NMDA. Not so sure a 2nd do-over is going to go over well. I don=E2=80=99t think a =E2=80=9Cmajor=E2=80=9D change is being = discussed: I think it is, effectively: validate (not = ). And note that Section 5.1.4 says: For simple implementations, and are identical. I=E2=80=99d guess that *all* implementations are =E2=80=9Csimple=E2=80=9D = currently. When a server introduces a feature (inactive, template, = etc.) that demands , at that time internal logic is switched = to "validating " vis-a-vis validating . Clients = would also have to make that same switch, to the extent they care about = offline validation at all. As a co-author, I know this was the intention of RFC 8342, which is = supported by, for instance: Section 4.1: o Several implementations have proprietary mechanisms that allow clients to store inactive data in . Inactive data is conceptually removed before validation. o Some implementations have proprietary mechanisms that allow clients to define configuration templates in . These templates are expanded automatically by the system, and the resulting configuration is applied internally. Section 5: // subject to validation Section 5.1.4: is tightly coupled to . Whenever data is written to , the server MUST also immediately update and validate . Of course, some will point to Section 5.1.3: However, MUST always be a valid configuration data tree, as defined in Section=C2=A08.1 of [RFC7950] = . But it has to be obvious that this is a bug. For instance, - YANG defines a leaf is of type union { uint8 | variable } - defines the leaf having value =E2=80=9CMAX_FOOBAR=E2=80=9D=20= with a template that defines MAX_FOOBAR=3D1000. - so, would be syntactically valid but semantically invalid. Or a more egregious example: - YANG defines a "max-elements" value =E2=80=9CMAX_FOOBAR=E2=80=9D - how is this possible when RFC 7950 says max-elements Is a positive integer or the string =E2=80=9Cunbounded=E2=80=9D?= - so now we=E2=80=99re into YANG-next territory as far as templates are concerned, but hang with me a little while longer=E2=80=A6 - has a template that defines MAX_FOOBAR=3D3 - how coulda server validate if =E2=80=99s list contained = less than max-elements? Worse, what if the result of another=20 template added more elements to the list? I may have taken off the flame suit too early ;) K. --Apple-Mail=_91AD5C67-8A3B-42EA-8B30-8A4E55A64681 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Andy,

I do not have any problem with = <running> containing active and inactive nodes.
That's what has been in place for over 10 years. That's what = is written in NMDA.

For posterity, it=E2=80=99s been =E2=80=9Cin = place=E2=80=9D only in proprietary implementations.  It would be = nice to resurrect the =E2=80=9Cconditional-enablement=E2=80=9D draft to = have an RFC for it.


I = cannot find any RFC text that says <running> has only nodes = created by a client.

Really?  Interesting.   Still, I know = it=E2=80=99s a mantra we=E2=80=99ve held closely for many year, = right?


I cannot find any RFC text that = says system-injected config is special, especially since
server implementations exist that treat these edits as just = another client
(although probably a 'root' user = client).

Very true (and Juergen=E2=80=99s point as well). =  I=E2=80=99ve seen this done before.  Unhappy = results.


Rewriting NMDA and YANG validation = to add a new <system> datastore is
a major = change that will impede deployment. The IETF already had 1 = "do-over"
because of NMDA.  Not so sure a 2nd = do-over is going to go over well.

I don=E2=80=99t think a =E2=80=9Cmajor=E2=80=9D = change is being discussed: I think it is, effectively: validate = <intended> (not <running>).

And note that Section 5.1.4 says:

   For =
simple implementations, <running> and <intended> are =
identical.

I=E2=80=99d guess = that *all* implementations are =E2=80=9Csimple=E2=80=9D currently. =  When a server introduces a feature (inactive, template, etc.) that = demands <intended>, at that time internal logic is switched to = "validating <running>" vis-a-vis validating <intended>. =  Clients would also have to make that same switch, to the extent = they care about offline validation at all.



<putting on flame suit>

As a co-author, I know this was the intention = of RFC 8342, which is supported by, for = instance:


Section 4.1:

   o  Several implementations have proprietary mechanisms that allow
      clients to store inactive data in <running>.  Inactive data =
is
      conceptually removed before validation.

   o  Some implementations have proprietary mechanisms that allow
      clients to define configuration templates in <running>.  =
These
      templates are expanded automatically by the system, and the
      resulting configuration is applied internally.


Section =
5:

	=
<intended>   // subject to validation

Section 5.1.4:

  =
 <intended> is tightly coupled to <running>. =
 Whenever data is written
   to <running>, the server =
MUST also immediately update and validate
  =
 <intended>.


<taking off =
flame suit>


Of course, =
some will point to Section 5.1.3:

   However, <running> MUST always be a valid =
configuration data tree,
   as defined in =
Section 8.1 of [RFC7950].


But it has to be obvious that this is a =
bug.  For instance,

  - YANG defines a leaf is of type union { =
uint8 | variable }
  - <running> defines the leaf having value =
=E2=80=9CMAX_FOOBAR=E2=80=9D 
    with a template that =
defines MAX_FOOBAR=3D1000.
  - so, <running> would be =
syntactically valid but
    semantically invalid.

Or a more egregious example:

  - YANG defines a =
"max-elements" value =E2=80=9CMAX_FOOBAR=E2=80=9D
       - how is this possible when RFC 7950 says =
max-elements
        =
  Is a positive integer or the string =E2=80=9Cunbounded=E2=80=9D?<=
/div>
       - so now we=E2=80=99re into YANG-next territory as far =
as
         templates are concerned, but hang with me a =
little
         while longer=E2=80=A6
  - <running> has a =
template that defines MAX_FOOBAR=3D3
  - how coulda server validate if =
<running>=E2=80=99s list contained less
    than max-elements?  =
Worse, what if the result of another 
    template added more =
elements to the list?


I =
may have taken off the flame suit too early  ;)

K.



= --Apple-Mail=_91AD5C67-8A3B-42EA-8B30-8A4E55A64681-- From nobody Mon Dec 13 19:03:29 2021 Return-Path: <0100017db6e5041f-3cc89073-6411-4ada-b1ec-5d8d3d825f1a-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 036793A0E13 for ; Mon, 13 Dec 2021 19:03:27 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 lzhkGpuMsct9 for ; Mon, 13 Dec 2021 19:03:23 -0800 (PST) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D673A0E0B for ; Mon, 13 Dec 2021 19:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639451002; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LshmWJ48kZO4ZvEIo8D8efwQ0T1WqSasrCrOPlsfiRI=; b=A1bQH4J0lB5u5tgEyxmet4YQdKU+9gqeMBI5oMm67G6TB7V/P6HmSmXnk5ggexiz RBGltqo5HbPu80E8HvSoPqTPr4d0y6Jnawcb7tNnofwHR73YBT/uD2gSzh8WZXNdLMG 3O2D7Rg956cHVXtYj32QYrqSGCKEZgVb4fSPnxXA= From: Kent Watsen Message-ID: <0100017db6e5041f-3cc89073-6411-4ada-b1ec-5d8d3d825f1a-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4E593C90-D7FD-427E-83D9-9ADED9973443" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 03:03:22 +0000 In-Reply-To: Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "maqiufang (A)" , "netmod@ietf.org" To: Andy Bierman References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db69159e5-16596fab-ac8f-48b9-8e81-ad5db2e749bf-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.48.110 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 03:03:27 -0000 --Apple-Mail=_4E593C90-D7FD-427E-83D9-9ADED9973443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, >> Andy - about use cases. Here is a problem we're trying to address: >>=20 >> =20 >>=20 >> There are at least several major router implementations that have = this concept of "hidden config" (i.e. list entries that can be = referenced in a leafref by explicit user config, but those list entries = are not returned in a ). =20 >>=20 >>=20 >> Clearly not in compliance with RFC 7950. >=20 > Andy, can you please point to the part in RFC 7950 that says offline = validation must be supported? I believe that this "common = understanding=E2=80=9D actually lacks a basis, and an equally-valid = interoperation is that the must be valid *on the server* = vis-a-vis it actually validating . >=20 >=20 > I think sec. 6.4 and sec. 8 are clear enough how validation of the = datastore is done. > Leafrefs in are not allowed to point to a node outside of = . >=20 I don=E2=80=99t discount the =E2=80=9Caccessible tree=E2=80=9D angle. = The focus on if the server can=E2=80=99t validate vis-a-vis = =E2=80=A6. =20 As an author of NMDA, I know that is was/is the goal to let this be true = - how else could template ever work, right? K. --Apple-Mail=_4E593C90-D7FD-427E-83D9-9ADED9973443 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Andy,

Andy = - about use cases.  Here is a problem we're trying to address:

 

There = are at least several major router implementations that have this concept = of "hidden config" (i.e. list entries that can be referenced in a = leafref by explicit user config, but those list entries are not returned = in a = <get-config>).  


Clearly not in compliance with RFC = 7950.

Andy, = can you please point to the part in RFC 7950 that says offline = validation must be supported?   I believe that this "common = understanding=E2=80=9D actually lacks a basis, and an equally-valid = interoperation is that the <running> must be valid *on the server* = vis-a-vis it actually validating <intended>.


I think sec. 6.4 and sec. 8 are clear = enough how validation of the <running> datastore is = done.
Leafrefs in <running> are not = allowed to point to a node outside of = <running>.


I don=E2=80=99t discount the =E2=80=9Caccessibl= e tree=E2=80=9D angle.  The focus on if the server can=E2=80=99t = validate <running> vis-a-vis <intended>=E2=80=A6. =  

As an = author of NMDA, I know that is was/is the goal to let this be true - how = else could template ever work, right?

K.

= --Apple-Mail=_4E593C90-D7FD-427E-83D9-9ADED9973443-- From nobody Mon Dec 13 19:13:37 2021 Return-Path: <0100017db6ee4952-a5caece3-baaa-4a4e-9fab-db05dc75cce0-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 D47843A0E19 for ; Mon, 13 Dec 2021 19:13:33 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ghRjFZTtVrN4 for ; Mon, 13 Dec 2021 19:13:32 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3053A0E1A for ; Mon, 13 Dec 2021 19:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639451609; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=enIkM5NQYFIM8nFiCzewrqC6eyuBc9wXO+4jYminnA8=; b=Ji3SgraujgqgafAJBiqLIJZSq2mHk3FJZzdZLLJGTNrxStWWAk2xW3FCLJ6FjWRQ dNc1ui7yoXvnXqMrDWWkvICuJ+KNuWLetuHvZxyYCnD6bfZfxiev7bocVSrRDKMGFbG p5SsXM7SbT7baCkpdhNIDTSsL0SJ2okHGz1IOVtg= From: Kent Watsen Message-ID: <0100017db6ee4952-a5caece3-baaa-4a4e-9fab-db05dc75cce0-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1C9113EE-CB7F-43F2-948B-F8AE8CC6D9BD" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 03:13:29 +0000 In-Reply-To: Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "maqiufang (A)" , "netmod@ietf.org" To: Andy Bierman References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <0100017db664515c-d834ffd0-0860-4c60-b9be-0db0e349a69b-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.8.88 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 03:13:34 -0000 --Apple-Mail=_1C9113EE-CB7F-43F2-948B-F8AE8CC6D9BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, >> Legacy clients are failing offline validation today. If running = config has a leafref to system config, and doesn't return = that system config (which it doesn't in some implementations), then the = instance data returned to the client doesn't validate against the YANG = model. These implementations don't have an explicit datastore = today (but they do have these internal semi-hidden referenceable list = entries). >=20 >=20 >=20 > This is an implementation bug. > YANG validation for configuration data nodes is very clear. > It intentionally does not allow any leafrefs to point at data nodes = outside . > Vendors who follow these YANG rules can return a representation of = > that can be validated.=20 lol =E2=80=9Cjunos-defaults=E2=80=9D existed before YANG was a thing = ;) In either case, 3 of the top-5(?) vendors are doing this, not out of = spite, but because business-demands... Andy, how does YumaWorks handle shared-objects, such as those Jason and = I have described? Do your customers populate them in ? If so, = is there an =E2=80=9Cimmutable=E2=80=9D flag to prevent delation? K. --Apple-Mail=_1C9113EE-CB7F-43F2-948B-F8AE8CC6D9BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Andy,

Legacy clients are failing offline = validation today. If running config has a leafref to system config, and = <get-config> doesn't return that system config (which it doesn't = in some implementations), then the instance data returned to the client = doesn't validate against the YANG model.  These implementations = don't have an explicit <system> datastore today (but they do have = these internal semi-hidden referenceable list = entries).



This= is an implementation bug.
YANG validation for = configuration data nodes is very clear.
It = intentionally does not allow any leafrefs to point at data nodes outside = <running>.
Vendors who follow these YANG = rules can return a representation of <running>
that can be = validated. 

lol =  =E2=80=9Cjunos-defaults=E2=80=9D existed before YANG was a = thing  ;)

In either case, 3 of the top-5(?) vendors are doing this, not = out of spite, but because business-demands...

Andy, how does YumaWorks handle = shared-objects, such as those Jason and I have described?  Do your = customers populate them in <running>?  If so, is there an = =E2=80=9Cimmutable=E2=80=9D flag to prevent delation?


K.

= --Apple-Mail=_1C9113EE-CB7F-43F2-948B-F8AE8CC6D9BD-- From nobody Mon Dec 13 19:18: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 D7F3F3A0E1A for ; Mon, 13 Dec 2021 19:18:30 -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.20210112.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 WmXk5PfpfE_C for ; Mon, 13 Dec 2021 19:18:26 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 A6DD03A0E19 for ; Mon, 13 Dec 2021 19:18:25 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id 13so26358103ljj.11 for ; Mon, 13 Dec 2021 19:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GgsWZ8Fq5LZvF0SQKCI70cFbaJc8ofDyT5MaOKF4D7g=; b=PDcdVcoKZsMVQElO+HqUHIP/X4SrPS2zKohdmhqwV3Wg2OlequdAfr9bAnd8uu9ekA NdJSf0ZtTgQJlBgSzSD+TdVxjgdRSYwCDZA9II+xi+Xi7em3nZsGS6PkTKTnd+3znfyh 6fEK6oNY5GXeqsnbfePazMCcdn/Wr91nitsST+gjGdpUjnsSZgS80nNq9iz4DWliz2X9 S/ABZFHjYMgyRvF/0jeavKWL63EmJmJqQctmIPJBaE8HdyvXhuwX0dJB5GCLZCQuPzQD sBhltnmr59IrKDmXzMi6TqPK650JkmJvqn7awaK4It/TQCf0SHP5hsokSt+GQxFpSE0d 0qIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GgsWZ8Fq5LZvF0SQKCI70cFbaJc8ofDyT5MaOKF4D7g=; b=u6WlbQTrHXopSq9FTrTBu0VghQtupJP7uyiVx5FgtxA0gYlR7wbtiiRaLhEHJ9soKl 5fwTaaOVJK0OW7KuHjRkm7WaBIq0C/LjFDM1HG2/YWirtImxY4piJgAD+2DMfvI6ow2P lI7xmXdt2MVnHTg8ONu8XlBPVuzfYqxbN37lU+bx5rk5a/BB4oeLvFvX+7/Y9KTkVqsh YrANFYb3v5iheGTafUgkI5+vrHAneSNaeagR3lZVGkm2O9vNV2Kef9+Ip/U9G149FGtS H+Q2IVLtrHCP3tjuNimBkneOYrsZTBPcfhjPgZKBq83AS1d2MCrDOnF6rmGbrwdRL88j z5zw== X-Gm-Message-State: AOAM532boGcQ0HKe+Q0PHdCxyRnKuHljawsFDz0VUrLTXUfgNLDvbcgo 0XJGs3AoHtX/ERbHUtwtFr6KdORg7khVBsks/doSEw== X-Google-Smtp-Source: ABdhPJyncqP/d7TG5ogyWEhNbBQ0paIRXBevxihYxHz0gTPizKZSx/LK8+YU85lrGVRk0dpVVRyFYOYu4MhVqCgZ55I= X-Received: by 2002:a2e:904b:: with SMTP id n11mr2383558ljg.120.1639451902795; Mon, 13 Dec 2021 19:18:22 -0800 (PST) MIME-Version: 1.0 References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> In-Reply-To: <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> From: Andy Bierman Date: Mon, 13 Dec 2021 19:18:11 -0800 Message-ID: To: Kent Watsen Cc: "maqiufang (A)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004af5fa05d312a433" Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 03:18:31 -0000 --0000000000004af5fa05d312a433 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 13, 2021 at 6:55 PM Kent Watsen wrote: > Hi Andy, > > I do not have any problem with containing active and inactive > nodes. > That's what has been in place for over 10 years. That's what is written i= n > NMDA. > > > For posterity, it=E2=80=99s been =E2=80=9Cin place=E2=80=9D only in propr= ietary implementations. > It would be nice to resurrect the =E2=80=9Cconditional-enablement=E2=80= =9D draft to have an > RFC for it. > > > I cannot find any RFC text that says has only nodes created by = a > client. > > > Really? Interesting. Still, I know it=E2=80=99s a mantra we=E2=80=99ve= held closely for > many year, right? > > No. Quite the opposite. The client only gets access to the config after the device has created an initial configuration, especially interface configuration. The text in RFC 7950 is clear: The accessible tree depends on where the statement with the XPath expression is defined: o If the XPath expression is defined in a substatement to a data node that represents configuration, the accessible tree is the data in the datastore where the context node exists. The root node has all top-level configuration data nodes in all modules as children. The RFC does not need to discuss offline validation because the constraints apply to a single datastore. The original intent (in YANG and NMDA) is that inactive nodes and active nodes can coexist in . I see no reason to change NMDA or YANG and abando= n this approach. IMO distinguishing so-called system config from client config is not a very compelling operational problem to solve. Not so sure it is easy to define a system edit vs. a non-system edit. Andy > I cannot find any RFC text that says system-injected config is special, > especially since > server implementations exist that treat these edits as just another clien= t > (although probably a 'root' user client). > > > Very true (and Juergen=E2=80=99s point as well). I=E2=80=99ve seen this = done before. > Unhappy results. > > > Rewriting NMDA and YANG validation to add a new datastore is > a major change that will impede deployment. The IETF already had 1 > "do-over" > because of NMDA. Not so sure a 2nd do-over is going to go over well. > > > I don=E2=80=99t think a =E2=80=9Cmajor=E2=80=9D change is being discussed= : I think it is, > effectively: validate (not ). > > And note that Section 5.1.4 says: > > > For simple implementations, and are identical. > > > I=E2=80=99d guess that *all* implementations are =E2=80=9Csimple=E2=80=9D= currently. When a > server introduces a feature (inactive, template, etc.) that demands > , at that time internal logic is switched to "validating > " vis-a-vis validating . Clients would also have to > make that same switch, to the extent they care about offline validation a= t > all. > > > > > > As a co-author, I know this was the intention of RFC 8342, which is > supported by, for instance: > > > Section 4.1: > > o Several implementations have proprietary mechanisms that allow > clients to store inactive data in . Inactive data is > conceptually removed before validation. > > o Some implementations have proprietary mechanisms that allow > clients to define configuration templates in . These > templates are expanded automatically by the system, and the > resulting configuration is applied internally. > > > Section 5: > > > // subject to validation > > > Section 5.1.4: > > is tightly coupled to . Whenever data is written > to , the server MUST also immediately update and validate > . > > > > > > Of course, some will point to Section 5.1.3: > > However, MUST always be a valid configuration data tree, > > as defined in Section 8.1 of [RFC7950] . > > > But it has to be obvious that this is a bug. For instance, > > - YANG defines a leaf is of type union { uint8 | variable } > - defines the leaf having value =E2=80=9CMAX_FOOBAR=E2=80=9D > with a template that defines MAX_FOOBAR=3D1000. > - so, would be syntactically valid but > semantically invalid. > > Or a more egregious example: > > - YANG defines a "max-elements" value =E2=80=9CMAX_FOOBAR=E2=80=9D > - how is this possible when RFC 7950 says max-elements > Is a positive integer or the string =E2=80=9Cunbounded=E2=80=9D? > - so now we=E2=80=99re into YANG-next territory as far as > templates are concerned, but hang with me a little > while longer=E2=80=A6 > - has a template that defines MAX_FOOBAR=3D3 > - how coulda server validate if =E2=80=99s list contained less > than max-elements? Worse, what if the result of another > template added more elements to the list? > > > I may have taken off the flame suit too early ;) > > K. > > > > --0000000000004af5fa05d312a433 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= div>


=
No. Quite the opposite. The client only gets access to the config afte= r the device
has created an initial configuration, especially int= erface configuration.

The text in RFC 7950 is clea= r:

=C2=A0 =C2=A0=C2=A0 The accessible tree depends on where the stateme= nt with the XPath
   expression is defined:

   o  If the XPath expression is defined in a substatement to a data
      node that represents configuration, the accessible tree is the
      data in the datastore where the context node exists.  The root
      node has all top-level configuration data nodes in all modules as
      children.

The R= FC does not need to discuss offline validation because the constraints
apply to a single datastore.=C2=A0=C2=A0
<= div class=3D"gmail_quote">
The original= intent (in YANG and NMDA) is that inactive nodes and active nodes
can coexist in <running>. I see no reason to = change NMDA or YANG and abandon
this approa= ch.

IM= O distinguishing so-called system config from client config
is not a very compelling operational problem to solve.
Not so sure it is easy to define a system edit= vs. a non-system edit.


Andy



I cannot find any RFC text that s= ays system-injected config is special, especially since
server im= plementations exist that treat these edits as just another client
(although probably a 'root' user client).
<= /blockquote>

Very true (and Juergen=E2=80=99s point as w= ell).=C2=A0 I=E2=80=99ve seen this done before.=C2=A0 Unhappy results.


Rewriting NMDA and YANG validation to add a new <s= ystem> datastore is
a major change that will impede deployment= . The IETF already had 1 "do-over"
because of NMDA.=C2= =A0 Not so sure a 2nd do-over is going to go over well.

I don=E2=80=99t think a =E2=80=9Cmajor=E2=80= =9D change is being discussed: I think it is, effectively: validate <int= ended> (not <running>).

And note that Sec= tion 5.1.4 says:

   For simple implementations, <running> and <intended> are =
identical.

I=E2=80=99d guess that *all* implementation= s are =E2=80=9Csimple=E2=80=9D currently.=C2=A0 When a server introduces a = feature (inactive, template, etc.) that demands <intended>, at that t= ime internal logic is switched to "validating <running>" vi= s-a-vis validating <intended>.=C2=A0 Clients would also have to make = that same switch, to the extent they care about offline validation at all.<= /div>



<putting on flame= suit>

As a co-author, I know this was the inte= ntion of=C2=A0RFC 8342, which is su= pported by, for instance:


Section 4= .1:

   o  Several implementations have proprietary mechanisms that =
allow
      clients to store inactive data in <running>.  Inactive data is
      conceptually removed before validation.

   o  Some implementations have proprietary mechanisms that allow
      clients to define configuration templates in <running>.  These
      templates are expanded automatically by the system, and the
      resulting configuration is applied internally.


Section 5:<=
/pre>

	<intended>   // subjec=
t to validation
Section 5.1.4:<=
/div>

=C2=A0 =C2=A0<intended> is=
 tightly coupled to <running>.=C2=A0 Whenever data is written<=
/font>
=C2=A0 =C2=A0to &=
lt;running>, the server MUST also immediately update and validate=

=C2=A0 =C2=A0<=
;intended>.
=


<taking off flame suit>


Of course, some will point=
 to Section 5.1.3:

   However, <running> MUST always be a valid con=
figuration data tree,
   as defined in Section=C2=A08.1 of [RFC7950].


But it has to be o=
bvious that this is a bug.  For instance,

  - YANG defines a =
leaf is of type union { uint8 | variable }
  - <running> defines the leaf having value =E2=80=9CMAX_FO=
OBAR=E2=80=9D=C2=A0
=
    with a template that defines MAX_FOOBAR=3D1000.
  - so, <running> would be syntactically valid but=

    semantically invalid.=


Or a more egregious example:

  - YANG defines a "=
;max-elements" value =E2=80=9CMAX_FOOBAR=E2=80=9D
       - how is this possible when R=
FC 7950 says =
max-elements
  =
        Is a positive integer or the string =E2=80=9Cunbounded=E2=80=9D?
       - so now w=
e=E2=80=99re into YANG-next territory as far as
         templates are concerned, but hang=
 with me a little
         while longer=E2=80=A6
  - <running> has a template th=
at defines MAX_FOOBAR=3D3
  - how could=
a server validate if <running>=E2=80=99s list contained less
    than max-elements?  Worse, what if th=
e result of another=C2=A0
    tem=
plate added more elements to the list?


I may h=
ave taken off the flame suit too early  ;)

=
K.



--0000000000004af5fa05d312a433-- From nobody Mon Dec 13 23:33: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 146063A02C1 for ; Mon, 13 Dec 2021 23:33:34 -0800 (PST) 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, 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 (2048-bit key) header.d=4668.se header.b=TxmSmJKX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eYb1Nd3d 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 LTBBu8kKrKSe for ; Mon, 13 Dec 2021 23:33:29 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F76C3A0128 for ; Mon, 13 Dec 2021 23:33:28 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 8C7553200C20; Tue, 14 Dec 2021 02:33:27 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 14 Dec 2021 02:33:27 -0500 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=fm3; bh= 6obH8Lj3+cIMoakpiOunMEZw0ayeXA6Q5l52hJDmUZU=; b=TxmSmJKXuiW+MSIM /QJnh59A4voigW6MrU116ktg0WgHbeO8HplE2cIFSoo0FONl24aciaJuv6MplS56 SjJgB37cx9EKsDskc/lbjY4RLg4WT2qBGv0Tx8FXE2UJeLhS1Wi4aiHBS7f4Qrt7 rA8xtb9dYKXFmYY9mLJx2yj2VqgHK++ehI5LrxbrYkykn6u6dktcozKoYp60wscM j2YLsSUdAu2Ox9YjyrC8pCKHG4piLkvacqEzQfLQTMW6lGNFNmmSvHH5nmT0OVEZ pZ0OuBQ9Qaoev5Hzj7V7Hn5ZvsYh1fQfvu01FeAryjkt/wmok1NRLswvdyGYGk1/ hHjZyA== 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=fm1; bh=6obH8Lj3+cIMoakpiOunMEZw0ayeXA6Q5l52hJDmU ZU=; b=eYb1Nd3dxIE26xrWFW0moccd55vdjpgfG6CvGD3ICDwUR3q/JXpDVTnpI luIShRe4/+w++vQIhtIQZ3spwcYTLdigiKwNYllZiH3jCE5XaBWEJqWOTLbt78hi PPDoa99LaKZ/9cP9OodVcmMYOy3kynfaWXhkQCUnUI5Ikv3EgNORITSB0Gwx0M9C VdrJ28qA9OIJ2grAi9aWluzM/JdhK6ZTx4AFvrxG+3q4K+3Y4CgqieIMsnligLtP /GYtSBkCDRh/NutXv8786uRT1l7ZvREHQAh4Tcc5qKgFkVAdHfqJjKFi3YXimgfV rZYCDaffLy/a8LlmBWAaZjyyv9ntA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrkeelgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepfeehkefgudekfeehieehhf ekgedvffehteevgfeffeeghfdvfeeuleduvddvgfehnecuffhomhgrihhnpehivghtfhdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Dec 2021 02:33:26 -0500 (EST) Date: Tue, 14 Dec 2021 08:33:24 +0100 (CET) Message-Id: <20211214.083324.1824911592330241723.id@4668.se> To: kent@watsen.net Cc: mcr+ietf@sandelman.ca, netmod@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> References: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 14 Dec 2021 07:33:34 -0000 S2VudCBXYXRzZW4gPGtlbnRAd2F0c2VuLm5ldD4gd3JvdGU6DQo+IA0KPiANCj4gPiBPbiBEZWMg MTIsIDIwMjEsIGF0IDU6MTEgUE0sIE1pY2hhZWwgUmljaGFyZHNvbg0KPiA+IDxtY3IraWV0ZkBz YW5kZWxtYW4uY2E+IHdyb3RlOg0KPiA+IA0KPiA+IA0KPiA+IENhcnN0ZW4gQm9ybWFubiA8Y2Fi b0B0emkub3JnPiB3cm90ZToNCj4gPj4gT24gMjAyMS0xMi0xMiwgYXQgMjI6MTcsIE1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0KPiA+PiB3cm90ZToNCj4gPiANCj4g Pj4+IEknbSB3b3JraW5nIG9uIGRyYWZ0LXJpY2hhcmRzb24tYW5pbWEtcmZjODM2NmJpcywgdHJ5 aW5nIHRvIG1ha2UgaXQNCj4gPj4+IFJGQzg3OTEuDQo+ID4+IFvigKZdDQo+ID4+PiBXaGF0IEkg ZG9uJ3Qga25vdyBob3cgdG8gZGVhbCB3aXRoOg0KPiA+IA0KPiA+PiBSRkMgODc5Mj8NCj4gPiAN Cj4gPiBJZiBJIHB1dCBcIGludG8gdGhlIG9yaWdpbmFsIC55YW5nIGZpbGUsIHRoZW4gaXQgd29u J3QgcHJvY2Vzcy4NCj4gPiBTbyBpZiBSRkM4NzkyIGlzIHRoZSBzb2x1dGlvbiwgdGhlbiBJIHRo aW5rIHRoYXQgSSBwcm9iYWJseSBwcmVmZXIgdG8NCj4gPiBoYXZlDQo+ID4gOjppbmNsdWRlIGRv IGl0LiAgT3RoZXJ3aXNlLCBJIGhhdmUgdG8gYWRkIGFub3RoZXIgc3RlcCB0byB0aGUNCj4gPiB3 b3JrZmxvdy4NCj4gPiANCj4gPiBJJ2QgYWxzbyB3YW50IGFzc3VyYW5jZSB0aGF0IHRoZSBZQU5H IG1vZHVsZSBleHRyYWN0b3Iga25vd3MgYWJvdXQNCj4gPiA4NzkyLg0KPiA+IE1heWJlIGdpdmVu IHRoYXQgS2VudCBpcyBhIGxlYWRlciBhdXRob3Igb24gdGhhdC4uLiBpdCdzIGFscmVhZHkgdGFr ZW4NCj4gPiBjYXJlIG9mLg0KPiANCj4gYHB5YW5nYCBhbmQgSSB0aGluayBgeWFuZ2xpbnRgIGFs c28ga25vdyBob3cgdG8gZXh0cmFjdCBmb2xkZWQNCj4gPGFydHdvcms+IGFuZCA8c291cmNlY29k ZT4gZWxlbWVudHMuDQoNCkp1c3QgYSBjb3JyZWN0aW9uOyBweWFuZyBkb2Vzbid0IGV4dHJhY3Qg YW55dGhpbmcsIGJ1dCByZmNzdHJpcCBkb2VzLA0KYW5kIGl0IHN1cHBvcnRzIGZvbGRlZCBhcnR3 b3JrLCBhbmQgaW4gdGhlIGxhdGVzdCBncmVhdGVzdCAxLjMgcmVsZWFzZQ0KaXQgZXZlbiByZWNv bml6ZXMgdGhlIHByb3BlciBSRkM4NzkyLWRlZmluZWQgbWFnaWMgc3RyaW5ncyA7LSkNCg0KDQov bWFydGluDQoNCg0KPiANCj4gVGhhdCBzYWlkLCBJIGhhdmUgbmV2ZXIgbmVlZGVkIHRvIGZvbGQg YSBZQU5HIG1vZHVsZSBpbiBhbiBJLUQuICBBcw0KPiBKdWVyZ2VuIG1lbnRpb25lZCwgWUFOR+KA mXMgYnVpbHQtaW4gbWVjaGFuaXNtcyBoYXZlIGFsd2F5cyBlbmFibGVkIG1lDQo+IHRvIGZpdCB3 aXRoaW4gNjktY29sdW1ucy4NCj4gDQo+IFVuc3VyZSBhYm91dCBtb2R1bGUtZXh0cmFjdG9yLiAg TXkgZ3Vlc3MgaXMgdGhhdCBpdCB3aWxsIGJhcmYgICA7KQ0KPiANCj4gSy4NCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2Qg bWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Mon Dec 13 23:42: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 26E5D3A043F for ; Mon, 13 Dec 2021 23:42:35 -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 WNV1VJlYqOyj for ; Mon, 13 Dec 2021 23:42:30 -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 6800D3A0433 for ; Mon, 13 Dec 2021 23:42:29 -0800 (PST) Received: from localhost (unknown [IPv6:2a01:5e0:29:ffff::82e]) by mail.nic.cz (Postfix) with ESMTPSA id C06D1140538; Tue, 14 Dec 2021 08:42:25 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Michael Richardson Cc: "netmod@ietf.org" In-Reply-To: <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> References: <11003.1639343822@localhost> <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> Mail-Followup-To: Kent Watsen , Michael Richardson , "netmod@ietf.org" Date: Tue, 14 Dec 2021 08:42:25 +0100 Message-ID: <87o85jljj2.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.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 14 Dec 2021 07:42:35 -0000 Kent Watsen writes: >> On Dec 12, 2021, at 5:11 PM, Michael Richardson = wrote: >>=20 >>=20 >> Carsten Bormann wrote: >>> On 2021-12-12, at 22:17, Michael Richardson wro= te: >>=20 >>>> I'm working on draft-richardson-anima-rfc8366bis, trying to make it RF= C8791. >>> [=E2=80=A6] >>>> What I don't know how to deal with: >>=20 >>> RFC 8792? >>=20 >> If I put \ into the original .yang file, then it won't process. >> So if RFC8792 is the solution, then I think that I probably prefer to ha= ve >> ::include do it. Otherwise, I have to add another step to the workflow. >>=20 >> I'd also want assurance that the YANG module extractor knows about 8792. >> Maybe given that Kent is a leader author on that... it's already taken c= are of. > > `pyang` and I think `yanglint` also know how to extract folded = and elements. > > That said, I have never needed to fold a YANG module in an I-D. As Juerg= en mentioned, YANG=E2=80=99s built-in mechanisms have always enabled me to = fit within 69-columns. Indeed. In this case, one can simple break the offending line like this: namespace "urn:ietf:params:xml:ns:yang:iana-voucher-assertion-type"; The conventions of RFC 8792 should be used only where it is absolutely nece= ssary. Lada > > Unsure about module-extractor. My guess is that it will barf ;) > > K. > > > _______________________________________________ > 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 Dec 14 00:18: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 D02F33A0831 for ; Tue, 14 Dec 2021 00:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 BBzCtkJC0mZt for ; Tue, 14 Dec 2021 00:18:11 -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 4A9483A0332 for ; Tue, 14 Dec 2021 00:18:11 -0800 (PST) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JCrmZ1w5gz67Cxd; Tue, 14 Dec 2021 16:15:58 +0800 (CST) Received: from [10.126.174.84] (10.126.174.84) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Tue, 14 Dec 2021 09:17:59 +0100 Message-ID: <3782772c-b5b4-4285-f65e-67b1113e1b07@huawei.com> Date: Tue, 14 Dec 2021 09:17:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-GB To: =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , CC: , , "Eric Vyncke (evyncke)" , =?UTF-8?Q?Slavom=c3=adr_Maz=c3=bar?= , =?UTF-8?Q?Miroslav_Kov=c3=a1=c4=8d?= References: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> <20211214.083324.1824911592330241723.id@4668.se> From: Benoit Claise In-Reply-To: <20211214.083324.1824911592330241723.id@4668.se> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.126.174.84] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To fraeml736-chm.china.huawei.com (10.206.15.217) X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 14 Dec 2021 08:18:17 -0000 Dear all, >> `pyang` and I think `yanglint` also know how to extract folded >> and elements. > Just a correction; pyang doesn't extract anything, but rfcstrip does, > and it supports folded artwork, and in the latest greatest 1.3 release > it even reconizes the proper RFC8792-defined magic strings ;-) Do we have a couple of IETF drafts with long too long lines, next to https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/ ? I would like to make sure that the yangcatalog.org extracts the YANG module(s) correctly. Note: the yangcatalog.org uses xym. Regards, Benoit From nobody Tue Dec 14 00:35: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 D69C83A08B7 for ; Tue, 14 Dec 2021 00:35:44 -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=unavailable 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 1GTQpIC3-g79 for ; Tue, 14 Dec 2021 00:35:32 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60083.outbound.protection.outlook.com [40.107.6.83]) (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 174973A094C for ; Tue, 14 Dec 2021 00:34:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dvNzH7Gkoi7pD0CLfCPVxYeESai4gl4NXKFVwheSFaWMBhgNgKtr3sqBOvUa9+FsMXs5DwRM7PwsLG/MwZBrszqyqi3LiqMyvKiZccbn0baoeVO99WHFsXG3XgI49acZJH7kIRBSjcBDMEKTF1sTBLT3wiuTM31eQKTfq7qFwqRUvxsFKviZ5jORvmWcbFrh26Sqs66QtldY0wUyj7CnTTNF+TxDXVTqOW0h4LTai/s7lsZFs3Ewt9jYtgFJuXKEl/egoMo/Lx0sjfGVVQoEo7ufMb02LiXfuNLJmrmwro1rXFGn1gF+jgkBAHd8AzTFWrvzq3DxRnp1bZo5NJXfUg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rvugWo4gPydshH67nJlV2YL9ULIXd3gGK/ElSwGOoNc=; b=YyKR1+5G+b4UzV3IzM6ryc8FWkKWCJbou19M2pcHJio3Z3lPDVBRf4JbAjj8KkIHvNxfqPmbKaZvI1rE2Ir3JTRCtl3Obe9pLfGCdu5toBp+Xsjiz82kKCDbNRshSZEoft7Clf3YHUtLWWPenIl/QVOLfrd8WiPHlnMauflw9BNz3L0iV3/cEMxzlhP0xTLe0FYrBegM2NuKl+xzsemxhNlCS2CWshV1V0Q8tqSD3uyd2HLTrQRPI4oZM2ZHVaQWW/uI74f7ICa6WoNGXuUQwXWBPFV1z8aYLsBKl+xZe9/+HENssWPD6V15vAoFxgpiMZks3FzbgG+EMNd2BwpSuA== 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=rvugWo4gPydshH67nJlV2YL9ULIXd3gGK/ElSwGOoNc=; b=T3w4tNg3GS6UImBfNFVmNsWsGdTRVQmtAJ35fQavJkFTiXTyw5mnXZPJynIhYbRpquWiXf522i/vkIfcXLnPBFeOmvi7DjkPIva3h/ZEnxuQO1AyFW3uIuCRcNaWIuXZZbfkq35vP5I4BClkAMWTCE3n4wtjvaG1SgnFnON/ppM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0580.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:198::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.12; Tue, 14 Dec 2021 08:34:46 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8%3]) with mapi id 15.20.4778.018; Tue, 14 Dec 2021 08:34:46 +0000 Date: Tue, 14 Dec 2021 09:34:45 +0100 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Kent Watsen Cc: Andy Bierman , Jan Lindblad , "maqiufang (A)" , "netmod@ietf.org" Message-ID: <20211214083445.xnrdaosmnsyxgyax@anna> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Andy Bierman , Jan Lindblad , "maqiufang (A)" , "netmod@ietf.org" References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> X-ClientProxiedBy: AM0PR10CA0046.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::26) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 603b4c5f-ae81-45f5-240e-08d9bedc9571 X-MS-TrafficTypeDiagnostic: AM0P190MB0580:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YL3V9vMjhaiA+hbxwaF1v3D/kDtMQpdOZ6ibSUG51MrBfmhtCr91lbiyLCWo6lNIzVn7Ul/4o3jyao65x75YZYkAI+m/C9icXLRYgfHYycbOwdFiZCsKo8hZJKrawQRuDZ4jrkcYCgO0moZ+J9oqL+blbozURJ2cO7RdTZTsIkq/XQn3Qhf4n0UOVS3BMrfX0QeV/vggQR7LKacJFG6drb7PvHHVqlGSuYde3rOstSI1iZjAWi1QeGzxFCQPjg0FlGNwgzqmnQk8z+P/R3Z2syHSG3HtlIfMFCa2uf3fy2LvRZD/trUdxVS3/auclOT2hDc6DjKMWt4oYyy3w78a4pAIJzi7H1gPWi4YyGSPgqvi7klLLZ97Yzfymii1dQNul/uxsvZU7U0wHH3levbOnX5IlItasgV2lW2N4+QQps35iVAv1oV+k2/xkV0KHT1fevVqbcfaGT57a6HkAfnHciJsH/pJhLXC821X3PDyeqoRzOVoe4wuok+5qBFU4MkyCgoUhjPdRSY80OJWeqq+lCkOP0Doe40xgPBHHH3af0Oeyeyt8zctixR55+MgfbGaOtUBT+3xbrxPWHUt2Ux1A/V3AhP9WXhOutNGz8lixbZcWrZJbE39Vl3LdyxtBpNEBQlBob962XChechF8cdpu/o/X6r79NCLNKSMVq/T7onCgfvTdRg9jsSfWm1Ks3sw0+ljX1/l2TBdVUgMRv6fL8GgKA5M+hLuwgmBfqEon1fpfiqKi0tx4T7PwGEfEyuMFlu5oSW/QOz/tWiXnJMxsXUFyv0FaJ7hcjxNoN4QPoQ= 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:(7916004)(366004)(66556008)(66476007)(5660300002)(85182001)(66946007)(1076003)(40140700001)(3450700001)(6506007)(26005)(33716001)(4326008)(786003)(316002)(52116002)(3716004)(83380400001)(6916009)(9686003)(508600001)(6512007)(6486002)(38100700002)(2906002)(86362001)(186003)(38350700002)(54906003)(85202003)(8676002)(8936002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VHVDdGFJNTZReUhFQk1DblJQblNDUlJpbUlTVTJCMExjMU82T3lvSzRPeE5M?= =?utf-8?B?c3FXSWlxa1lZSkprZE5qbkVwQTFQbW1FVW0rdzNMaTc5MzFnZVNERXlqaXNC?= =?utf-8?B?YjMvdE5rNmZnOFVJc1Z6VlFXaEZuQk9UcCtta0RVaUhoT3U0WTh2aWVIYkRj?= =?utf-8?B?bGJ5UnFicGdSYWlnODdrT2I0aHdhMTAzT3QxbTEvaVQ3K3B0Yy9aaTZDL2s2?= =?utf-8?B?N05oenZJZ0FZMVR6b1VRRE1pYnAzc2pXZXZRVHBJTTJwb241SjUyUDN2ajZJ?= =?utf-8?B?UTd1QVBrVjNFNldaeXJ3K1ZSbXlTMHYxSDdPeTRKbW1YSDZjRloxM2NHS1Y5?= =?utf-8?B?cjBiYll4RnJHUS9WWHI5dkkyM0cxYTNEbHNDcUNHMXNhYmZMeE9USDhKQkg2?= =?utf-8?B?VVVSd29oelowMSsvNTFiQmJjY01ySHFvZjZhZWRjakprREJVTWpBK1FjcEFZ?= =?utf-8?B?Zzc5WkkrNWpYN1FpM2RsVFhCRlZqK2xoZExRbnZpVm1adXpKRitvVFd4SWZy?= =?utf-8?B?bFYrOXZZbm9INmZFV3hYbEs1bnU2aEloUWNuVUx1bFhZbk1QbXI0R2J5VlZB?= =?utf-8?B?dS9td1djMlJ6aGoxZTRWZnMyN1NKVWpjVm1Va3V5NFdCbWZHNitsT0JvMmxk?= =?utf-8?B?NG9PWFpLcDhZaFFPMDhGcGJYUm5UVW5kRTdjYVJVVG5EL21wRmtvN2c4SmJl?= =?utf-8?B?dHorQnhOdmExWnVuOXZrMlA0WUE4K3VSTFh0eWtRNTZwVzFkcHpESGJNZE5T?= =?utf-8?B?L1ZtVTlPd2NWc09jYjBHekdBaDJ6UzBUUXpuNGhFR0FQcmMwMDdIU24ydWF4?= =?utf-8?B?M0xZbTRFUjR6emhLYWY3ZStvVWlJMHhLSkFzRGl1cCthMU1wZXRkTGFmdmU2?= =?utf-8?B?Ky9iMnk1bHV4ajk5U2UwUHBteHlZVCtuUzI1TzhUTlVKVjMxSW94VGNPUW5s?= =?utf-8?B?WEF6a1h6L2FueTVaRDBZNEZzNmRxY0RYMmQ2MmlYL0tGaVFTRHpxQ1pac1A4?= =?utf-8?B?U0x1WVdsMnBkdUlMdWFGcVhxcmZlVWtMTHl6aUNCZUxkSzFHclRyQWdIUGlP?= =?utf-8?B?b3hIVXp0a0ZGRUdyby9TcmIxbnZOWlF2ZkM1VXNmcVhiMjFPQ2luYXJKY3Vz?= =?utf-8?B?dEtwallwM1hYRWgwL005NzYzNlUrN29kRnJ6QlVmM204OS96WVRwdEJiam16?= =?utf-8?B?ZHlLMzNyMTRoRE5kVXhoVmExUDREenBRK21LbHJ4ZTZyV3ZwaEMyd0J3Qk4r?= =?utf-8?B?MWhOOTFiRjZJK2tnY0dtT1JGTXpjS0JWMTM2a0h6TzBqVFkxZ3ZYSm54eEU3?= =?utf-8?B?OHF2SVVab2VhRHRZd0J1YWpKTWlXZ1NmY2ZnbGZ1YnVFZCtVdklXSTh5Nitp?= =?utf-8?B?Qm1qSGh1WVF1bm4rZWdMSnVKRVhRRXNSMzZydWloZDRVdW5PVkh3SjEzWjl2?= =?utf-8?B?ZEQzTDM5SGhCZWFlN1A0TGRxbGw0a2xCZSs3SkowWDFjWHBQdVZkVU9tZkdr?= =?utf-8?B?b25KVXFTSGNTUHYrQ2U0dTZ1WStwc1h2T1ppNlc0REVaejhYaEx5eEoxRkdZ?= =?utf-8?B?VXRZOWJVc2U3UlduTDVVbExVaC9OUTVTa21VSy9rM05sZFd3emFtWEZXK1M3?= =?utf-8?B?cVVyQ2FLazEycVV3VnNFWXdmSWJjWldUNlVNZXBqNDdERSsxRHp4VDlncHZh?= =?utf-8?B?cGE0NVAvTnNvTG50V3kxb0QwWjZyVjNmaUJ0K29MTEhBcVZtZzg5a2VLT3I3?= =?utf-8?B?QTVDNy9KMmZLZ21vR3g0MlRla0tqMjAzMDlEeFBBdzd6cTlJeEc2bnlyYmgr?= =?utf-8?B?M3RoUHFuTDFLRDhIcDl6dDlpaFZJQ3BBVkJSS1ZhdHB4bzAxdlRldVVqVGRB?= =?utf-8?B?RGd2Q1dwODhHY0lnVnU0eE5YbDVwbnBnWmJ5ZUIvdlFXaWxyaFdlMEtoNUxI?= =?utf-8?B?dmwzdkovNFRCeTBHemxwSmRuaVI0cEgzUE9heVQzbHpqTHJ4Ky9najR0bTVz?= =?utf-8?B?ZWlPSmxpOTBEaWV3cTIzY2dpZ1VrUkpBVjlsNmo5TXA0bGg2S2U2RWdjUkJN?= =?utf-8?B?dWFmZkY0cmNmdmptU1R4ZGVWdGV3TGkxVkJ6V1FSSjNZYTdsUmlrVWJjdTFy?= =?utf-8?B?WnFFaUxrU0lSVHV0VlNqTlNsUFg5YU9wakVKUURaa05WcjVuS2JSVTA2MjJl?= =?utf-8?B?a2xUTmY1eXV1MTNDUlE0TTZmTXJ6NFhNbERpemtsQ3REUXRraEpQcmU4WEty?= =?utf-8?Q?9lRBv3ZHwXdmEo44Ba8PUw9oyzs4pwQkLgADqojPxQ=3D?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 603b4c5f-ae81-45f5-240e-08d9bedc9571 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2021 08:34:46.1606 (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: KluzsGM744e8LQeM+b6ImEYJB4F25FtK7EbLPo3xM4Gcv53VLEWMVfjIKrbP9Lj5EeTA6vufc2FdYG+uwmqFy9S5DkoAesfwUiXg+BTZBY4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0580 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 08:35:46 -0000 On Mon, Dec 13, 2021 at 11:44:31PM +0000, Kent Watsen wrote: > Juergen/Andy, > > > > Option #3 > > > > There is a client on the system that makes changes to running just > > like any other remote clients can make changes to running. System > > generate config that is not editable explicit config in running goes > > straight into the applied config in operational. This does not require > > a system datastore (in fact something like a system datastore may > > exist as the _logic_ of the system client, the good old example we had > > is allocting an unused uid for an account that, once allocated, is > > maintained in running). > > > > Juergen, you mentioned this before. I don’t recall if there were any responses, but how would this solution address the various concerns that have been raised? > Well, while doing the NMDA work, we already acknowledged that there are proprietary extensions (like templates or inactive nodes) and hence we moved validation to . Since people felt it was kind of hopeless to standardize templates, we accepted that there is vendor specific magic applied to the config from to become . So from this perspective, merging in some system config is not making things any worse, we already broke the ability to validate a copy of in an interoperable way in the NMDA work. If we accept that there is system configuration one can rely on, then this system configuration obviously flows into . Whether it is possible to standardize this, I do not know, we even failed with inactive in the past. That said, I am not convinced by the proposed with-system parameter. If you retrieve , then you should get and not something that happens to later down the pipeline. If people want offline validation, then they either retrieve and work with that or they have to implement the vendor's magic for merging system configuration, for dealing with inactive nodes, for expanding templates, and whatever comes next. This is bad news for everybody who wants to do validation of config _before_ it is shipped to since these folks have to implement vendor specific logic. This is unfortunate but I believe we started accepting this with NMDA and we accepted it because this is what implementations apparently do... I still believe that good data model design can avoid many of the situations where people believe they need to depend on system configuration. The interface example presented at IETF 112 is a weak example since we rely on lazy name bindings for interfaces, a description configured for an interface "foo" is applied to an interface "foo" if there is one, otherwise it is not applied. You do not need to know whether the system supplies a "foo" interface to validate the config. But then I am sure there are examples where non lazy bindings exist, perhaps hidden deep in some MUST expressions. /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 Tue Dec 14 01:23: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 262373A09AC for ; Tue, 14 Dec 2021 01:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=cesnet.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 na1S7Pz2-cvz for ; Tue, 14 Dec 2021 01:23:08 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66763A09AB for ; Tue, 14 Dec 2021 01:23:07 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 5743260068; Tue, 14 Dec 2021 10:22:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1639473779; bh=FVMG49AtkgdpsG0CJ7Mshg4U060eUV9eG+URE8ImH00=; h=From:To:Date:Subject; b=tuMLv+miayrczO0BzOu3Qq6h35211g77SA4KhZ6AAV0/e6+kYyoU/pSbxmcAjL1g9 mujfPLU54gLr6U+UuckBYbpHAe/K0zcL/TmwtTlezEnvCvqz1r6CHbBi91iNGMQIAJ LUJd1ctVX8PDgxBl+cOmcuQeluZHoj6sBkcPMWKw= From: =?utf-8?q?Michal_Va=C5=A1ko?= To: "netmod" User-Agent: SOGoMail 5.2.0 MIME-Version: 1.0 Date: Tue, 14 Dec 2021 10:22:59 +0100 Message-ID: <5c75-61b86280-7-7ae45880@31357358> X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] Resolving schema node identifier 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, 14 Dec 2021 09:23:13 -0000 Hello, I would like to get some input for a use-case I came across, which to m= e does not seem to have any consistent rules that can be applied. module mod=5Fb { namespace "x:example:mod=5Fb"; prefix "mb"; grouping mylist=5Fwrapper { list mylist { key "name"; unique "value"; leaf name { type string; } leaf value { type uint32; } } } list mylist2 { key "a"; leaf a { type string; } leaf b { type string; } } } module mod=5Fa { namespace "x:example:mod=5Fa"; prefix "ma"; import mod=5Fb { prefix "mb"; } container root { uses mb:mylist=5Fwrapper; } augment /mb:mylist2 { leaf c { type string; } } deviation /mb:mylist2 { deviate add { unique "mb:b c"; } } } The focus is on the "unique" statements and how to resolve non-prefixed= identifiers. RFC 7950 says that the argument is a "list of schema node= identifiers"[1], which use "current module" for non-prefixed identifie= rs[2]. I have asked on this mailing list a few years back what current = module means and the answer I got was the module where the statement is= defined. So let's get to the examples. As they are written, the unique in "mylis= t" should be wrong because the node "value" belongs to the module "mod=5F= a" when the grouping is instantiated there, but unique is defined in th= e module "mod=5Fb". But even if we use the other understanding of current module and interp= ret is as the module of the context node of the statement (corresponds = to the "current()" XPath function), then the other "unique" in the devi= ation cannot be resolved. It is referencing node "c", which belongs to = the module "mod=5Fa" (added by an augment) but the current module would= then be "mod=5Fb". To summarize, if strictly following the specs, the "unique" in the "myl= ist" should probably reference "value" with a prefix, but that is not p= ossible because "mod=5Fa" is not even imported and it generally does no= t make sense. But then I cannot think of any consistent rule to success= fully resolve both "unique" statements in this example. Can anyone help= me with this, please? Finally, I am asking because I am trying to implement this correctly in= yanglint. I have also tried to test these examples with pyang, which, = however, seems to not have any consistent rules applied because it load= s these examples without warnings. No warnings are printed even if the = "unique" in the deviation is changed to "b c", which is definitely wron= g since node "b" belongs to "mod=5Fb" and node "c" belongs to "mod=5Fa"= . Thanks, Michal [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3 [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5 From nobody Tue Dec 14 02:27: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 B4A6F3A0A1D for ; Tue, 14 Dec 2021 02:27:23 -0800 (PST) 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, 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 (2048-bit key) header.d=4668.se header.b=vRUCkGP8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fwb24FUc 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 aUHXrdNbjH6p for ; Tue, 14 Dec 2021 02:27:18 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED433A0768 for ; Tue, 14 Dec 2021 02:27:17 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 6791C32007E8; Tue, 14 Dec 2021 05:27:15 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 14 Dec 2021 05:27:15 -0500 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=fm3; bh= q7PEMP3jA0JgLsITcEs5bNVEX2CFDn30TS3uRzsBKO4=; b=vRUCkGP8XbM8IEkH U8G1uG/UVGRaInnoAUAfOntkjcfvoaT3I4zIUnSK78Zk/sIOBD88x4TlU8lZrdyw SrHUMb3WHGRnSORGuIe6ajYz8h3OyMYF791i7SYp8D0wEaswjt87BwurJhd8i9WM QB7Cl0WcFJOyhDntnTeDWPeHhHKvUUHCmsfGNE803ItRA76KiWSzo3BpKuf23HZS Xfq+fQcC8Utoyk6xrcccgVC8pLYWhCBxaL4jjc6BYI8pl3DV80EPrXNvhm3NBL1D Ur80MLb3u03HXPn0Wlk6JrQFbeeDBOyJYcPAxowUbA297Rwabsdk8qxK907w+n3x fs7V1w== 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=fm1; bh=q7PEMP3jA0JgLsITcEs5bNVEX2CFDn30TS3uRzsBK O4=; b=fwb24FUcknKmgD7+TSKxgncV77oxQmF1qKT/NbvbA6/julvOp/kZOYiVs HN67HTmbNkWgEcfwUShS5kpTyb0+XJKk7/fLsY2x2RTewJCccFj2J1lH89aJvFLo ZmfpGZeCbdrJ2BYKvgrIuJrzkJVh2bvyHtPZax6rnQBy21899GeXX6tQfgfph5CX lQQo/+0SMzRqhNWRBUc5/dYd3grX564Oc0k2gUBV+JM5z5lNL9wYwwxc5BV+XZ7b 5faCaMb83HGAWUQKnhOFLzlS42vwOFD29tv5jueBxshUF92B52x8pRe1gh6BF/kT eXuDeGsp2qQLtCDG9MKAKqudvWTzg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrledtgdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthhqre dtredtleenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpefgffevudevvdfgfeevhfeggf evkeeijedvheevuefhffffveduvdeghfeiueduieenucffohhmrghinhepihgvthhfrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh gsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Dec 2021 05:27:14 -0500 (EST) Date: Tue, 14 Dec 2021 11:27:12 +0100 (CET) Message-Id: <20211214.112712.2013737499563136226.id@4668.se> To: mvasko@cesnet.cz Cc: netmod@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <5c75-61b86280-7-7ae45880@31357358> References: <5c75-61b86280-7-7ae45880@31357358> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Resolving schema node identifier 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, 14 Dec 2021 10:27:24 -0000 Hi, Michal Va=A8ko wrote: > Hello, > = > I would like to get some input for a use-case I came across, which to= > me does not seem to have any consistent rules that can be applied. > = > module mod_b { > namespace "x:example:mod_b"; > prefix "mb"; > = > grouping mylist_wrapper { > list mylist { > key "name"; > unique "value"; > leaf name { > type string; > } > leaf value { > type uint32; > } > } > } > = > list mylist2 { > key "a"; > leaf a { > type string; > } > leaf b { > type string; > } > } > } > = > = > module mod_a { > namespace "x:example:mod_a"; > prefix "ma"; > = > import mod_b { prefix "mb"; } > = > container root { > uses mb:mylist_wrapper; > } > = > augment /mb:mylist2 { > leaf c { > type string; > } > } > = > deviation /mb:mylist2 { > deviate add { > unique "mb:b c"; > } > } > } > = > The focus is on the "unique" statements and how to resolve > non-prefixed identifiers. RFC 7950 says that the argument is a "list > of schema node identifiers"[1], which use "current module" for > non-prefixed identifiers[2]. I have asked on this mailing list a few > years back what current module means and the answer I got was the > module where the statement is defined. > = > So let's get to the examples. As they are written, the unique in > "mylist" should be wrong because the node "value" belongs to the > module "mod_a" when the grouping is instantiated there, but unique is= > defined in the module "mod_b". > = > But even if we use the other understanding of current module and > interpret is as the module of the context node of the statement > (corresponds to the "current()" XPath function), then the other > "unique" in the deviation cannot be resolved. It is referencing node > "c", which belongs to the module "mod_a" (added by an augment) but th= e > current module would then be "mod_b". > = > To summarize, if strictly following the specs, the "unique" in the > "mylist" should probably reference "value" with a prefix, but that is= > not possible because "mod_a" is not even imported and it generally > does not make sense. But then I cannot think of any consistent rule t= o > successfully resolve both "unique" statements in this example. Can > anyone help me with this, please? Compare with this: grouping mylist_wrapper { list mylist { key "name"; unique "value"; must "value > 42"; leaf name { type string; } leaf value { type uint32; } } } I think the rules for the prefixes in "unique" should be the same as for "must". So I think that the correct syntax is to not use any prefix in "unique". And the deviation that adds a unique statement look correct. /martin > Finally, I am asking because I am trying to implement this correctly > in yanglint. I have also tried to test these examples with pyang, > which, however, seems to not have any consistent rules applied becaus= e > it loads these examples without warnings. No warnings are printed eve= n > if the "unique" in the deviation is changed to "b c", which is > definitely wrong since node "b" belongs to "mod_b" and node "c" > belongs to "mod_a". > = > Thanks, > Michal > = > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3 > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5 > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 14 02:33: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 821E63A0A84 for ; Tue, 14 Dec 2021 02:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=cesnet.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 uQGBEhI2zyAj for ; Tue, 14 Dec 2021 02:33:01 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71ED53A0A82 for ; Tue, 14 Dec 2021 02:33:00 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 87B4C60068; Tue, 14 Dec 2021 11:32:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1639477975; bh=jEhqaKbDyMfgYPwU30njOG2MzUeKS4AvvVPcKfF2sl4=; h=From:In-Reply-To:Date:Cc:To:Subject; b=ZHH1oWUFz5ztfYVnspuoAxRM4hUYY/I8JFU77wKUBPKLfVhRCypyDsQDmiARBgXNF VVHoIzMgjGJ2MoCQqJYm9xT7cWXb+w7ea5oeYLpGAEdWsMOWljJSl4AHObVJxbx9fk 3k9a4oKZMxmYxACwmkZ792N20X/Ehn6ZANDFsREo= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <20211214.112712.2013737499563136226.id@4668.se> Content-Type: text/plain; charset="utf-8" X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Tue, 14 Dec 2021 11:32:55 +0100 Cc: netmod@ietf.org To: =?utf-8?q?Martin_Bj=C3=B6rklund?= MIME-Version: 1.0 Message-ID: <72c4-61b87300-1-13e4c040@5935764> User-Agent: SOGoMail 5.2.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] =?utf-8?q?Resolving_schema_node_identifier?= 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, 14 Dec 2021 10:33:07 -0000 > Michal Va=C5=A1ko wrote: > > Hello, > > > I would like to get some input for a use-case I came across, whic= h to> me does not seem to have any consistent rules that can be applied= . > > > module mod=5Fb { > > namespace "x:example:mod=5Fb"; > > prefix "mb"; > > > grouping mylist=5Fwrapper { > > list mylist { > > key "name"; > > unique "value"; > > leaf name { > > type string; > > } > > leaf value { > > type uint32; > > } > > } > > } > > > list mylist2 { > > key "a"; > > leaf a { > > type string; > > } > > leaf b { > > type string; > > } > > } > > } > > > > module mod=5Fa { > > namespace "x:example:mod=5Fa"; > > prefix "ma"; > > > import mod=5Fb { prefix "mb"; } > > > container root { > > uses mb:mylist=5Fwrapper; > > } > > > augment /mb:mylist2 { > > leaf c { > > type string; > > } > > } > > > deviation /mb:mylist2 { > > deviate add { > > unique "mb:b c"; > > } > > } > > } > > > The focus is on the "unique" statements and how to resolve > > non-prefixed identifiers. RFC 7950 says that the argument is a "lis= t > > of schema node identifiers"[1], which use "current module" for > > non-prefixed identifiers[2]. I have asked on this mailing list a fe= w > > years back what current module means and the answer I got was the > > module where the statement is defined. > > > So let's get to the examples. As they are written, the unique in > > "mylist" should be wrong because the node "value" belongs to the > > module "mod=5Fa" when the grouping is instantiated there, but uniqu= e is> defined in the module "mod=5Fb". > > > But even if we use the other understanding of current module and > > interpret is as the module of the context node of the statement > > (corresponds to the "current()" XPath function), then the other > > "unique" in the deviation cannot be resolved. It is referencing nod= e > > "c", which belongs to the module "mod=5Fa" (added by an augment) bu= t the > > current module would then be "mod=5Fb". > > > To summarize, if strictly following the specs, the "unique" in th= e > > "mylist" should probably reference "value" with a prefix, but that = is> not possible because "mod=5Fa" is not even imported and it generall= y > > does not make sense. But then I cannot think of any consistent rule= to > > successfully resolve both "unique" statements in this example. Can > > anyone help me with this, please? > > Compare with this: > > grouping mylist=5Fwrapper { > list mylist { > key "name"; > unique "value"; > must "value > 42"; > leaf name { > type string; > } > leaf value { > type uint32; > } > } > } > > I think the rules for the prefixes in "unique" should be the same as > for "must". So I think that the correct syntax is to not use any > prefix in "unique". > > And the deviation that adds a unique statement look correct. Thanks for the reply but I do not think you have answered my question. = Please formulate a formal rule how to assign modules to non-prefixed id= entifiers, whether they be in "unique", "must", or any other statement = with identifiers. That is what I need to implement it properly and I am= simply not able to come up with any that would be consistent and compl= iant with the specification. > /martin > > > Finally, I am asking because I am trying to implement this correctl= y > > in yanglint. I have also tried to test these examples with pyang, > > which, however, seems to not have any consistent rules applied beca= use > > it loads these examples without warnings. No warnings are printed e= ven > > if the "unique" in the deviation is changed to "b c", which is > > definitely wrong since node "b" belongs to "mod=5Fb" and node "c" > > belongs to "mod=5Fa". > > > Thanks, > > Michal > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3 > > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5 > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 14 02:39: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 F32713A0A8B for ; Tue, 14 Dec 2021 02:39:57 -0800 (PST) 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, 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 (2048-bit key) header.d=4668.se header.b=gTOTyjNG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kiqpmeA3 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 Vmdfbx7vTYM5 for ; Tue, 14 Dec 2021 02:39:52 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262823A0A4C for ; Tue, 14 Dec 2021 02:39:49 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 8ED953200E31; Tue, 14 Dec 2021 05:39:47 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 14 Dec 2021 05:39:47 -0500 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=fm3; bh= sbdKinP9RiCWA93DMm2i6CPIGjo6BTYnAE8NjqL2Rj4=; b=gTOTyjNGwLsONGAv d4EsHp/9xQVa3ysxjCQSfNo8sZuHlFQwyTJNH8l/VXrHrszeukgwBI+heR6r/Syi kQDZ4wZv8Ld05IuazqSTTNCU/IgYUgL6hc184rEcu07gWsFa+ED70z6Gy8wxqHRl 22UGrXum7zET00WQIMiNu6DoiT32tTSKP6KJWplIPRYICO4IlLGHCAELs+Ux412O NP+LRKJBDQGMG5uq2VSg+jEVyJaS08bf6WTaaotrFQd+mTkSL8FzPo7JbgQtwK4t X3klQKaI4pCCg8JK4tjcmTTpujQOTGF2qKh9OqnA1NE7Wvcz6kpY9tXq7uSADiud xb4ufw== 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=fm1; bh=sbdKinP9RiCWA93DMm2i6CPIGjo6BTYnAE8NjqL2R j4=; b=kiqpmeA3tzi0AscXHGmGoJm0uJ+DBNeMOwOxH5Vnp5X6rN+1n+m20Vh5w JfZoxqoRyfAhacXRuIBebv3KD6DX4nqR6P6kjCFKNAHKlUDCNPMCVsLPo8Gn9ph/ i/w+uTA+mEZgMSyl4rEpd1HYtgwD6/6Ym69rNs3uTIFKZJcBK3mJU8r0j7lBrMQV Xa6VgSbnruv+N4YWJbRkI8Drt8jBGptdJsoCnFXzjO4KpChvH+CN67rWevZKlR4T sAjVxNe8qXTT10D/1ET30C71vw/7KXaWvH9sczGJ9X0XxmyJiArXst4ysKIqxZPU ntXRdAVo0gI/JQvw3nExFdJlV8htg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrledtgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthhqre dtredtleenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpefgffevudevvdfgfeevhfeggf evkeeijedvheevuefhffffveduvdeghfeiueduieenucffohhmrghinhepihgvthhfrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh gsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Dec 2021 05:39:46 -0500 (EST) Date: Tue, 14 Dec 2021 11:39:45 +0100 (CET) Message-Id: <20211214.113945.1688569442535282417.id@4668.se> To: mvasko@cesnet.cz Cc: netmod@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <72c4-61b87300-1-13e4c040@5935764> References: <20211214.112712.2013737499563136226.id@4668.se> <72c4-61b87300-1-13e4c040@5935764> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Resolving schema node identifier 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, 14 Dec 2021 10:39:58 -0000 Michal Va=A8ko wrote: > > Michal Va=A8ko wrote: > > > Hello, > > > > I would like to get some input for a use-case I came across, wh= ich to> > > > > me does not seem to have any consistent rules that can be appli= ed. > > > > module mod_b { > > > namespace "x:example:mod_b"; > > > prefix "mb"; > > > > grouping mylist_wrapper { > > > list mylist { > > > key "name"; > > > unique "value"; > > > leaf name { > > > type string; > > > } > > > leaf value { > > > type uint32; > > > } > > > } > > > } > > > > list mylist2 { > > > key "a"; > > > leaf a { > > > type string; > > > } > > > leaf b { > > > type string; > > > } > > > } > > > } > > > > > module mod_a { > > > namespace "x:example:mod_a"; > > > prefix "ma"; > > > > import mod_b { prefix "mb"; } > > > > container root { > > > uses mb:mylist_wrapper; > > > } > > > > augment /mb:mylist2 { > > > leaf c { > > > type string; > > > } > > > } > > > > deviation /mb:mylist2 { > > > deviate add { > > > unique "mb:b c"; > > > } > > > } > > > } > > > > The focus is on the "unique" statements and how to resolve > > > non-prefixed identifiers. RFC 7950 says that the argument is a "l= ist > > > of schema node identifiers"[1], which use "current module" for > > > non-prefixed identifiers[2]. I have asked on this mailing list a = few > > > years back what current module means and the answer I got was the= > > > module where the statement is defined. > > > > So let's get to the examples. As they are written, the unique i= n > > > "mylist" should be wrong because the node "value" belongs to the > > > module "mod_a" when the grouping is instantiated there, but uniqu= e is> > > > defined in the module "mod_b". > > > > But even if we use the other understanding of current module an= d > > > interpret is as the module of the context node of the statement > > > (corresponds to the "current()" XPath function), then the other > > > "unique" in the deviation cannot be resolved. It is referencing n= ode > > > "c", which belongs to the module "mod_a" (added by an augment) bu= t the > > > current module would then be "mod_b". > > > > To summarize, if strictly following the specs, the "unique" in = the > > > "mylist" should probably reference "value" with a prefix, but tha= t is> > > > not possible because "mod_a" is not even imported and it generall= y > > > does not make sense. But then I cannot think of any consistent ru= le to > > > successfully resolve both "unique" statements in this example. Ca= n > > > anyone help me with this, please? > > = > > Compare with this: > > = > > grouping mylist_wrapper { > > list mylist { > > key "name"; > > unique "value"; > > must "value > 42"; > > leaf name { > > type string; > > } > > leaf value { > > type uint32; > > } > > } > > } > > = > > I think the rules for the prefixes in "unique" should be the same a= s > > for "must". So I think that the correct syntax is to not use any > > prefix in "unique". > > = > > And the deviation that adds a unique statement look correct. > = > Thanks for the reply but I do not think you have answered my > question. Please formulate a formal rule how to assign modules to > non-prefixed identifiers, whether they be in "unique", "must", or any= > other statement with identifiers. That is what I need to implement it= > properly and I am simply not able to come up with any that would be > consistent and compliant with the specification. Interpret the unique argument the same way as an XPath expression, and apply (from 6.4.1): o Names without a namespace prefix belong to the same namespace as the identifier of the current node. Inside a grouping, that namespace is affected by where the grouping is used So "value" in the unique statement will refer to "value" in "mod_a" when the grouping is used in "mod_a". /martin > = > > /martin > > = > > > Finally, I am asking because I am trying to implement this correc= tly > > > in yanglint. I have also tried to test these examples with pyang,= > > > which, however, seems to not have any consistent rules applied be= cause > > > it loads these examples without warnings. No warnings are printed= even > > > if the "unique" in the deviation is changed to "b c", which is > > > definitely wrong since node "b" belongs to "mod_b" and node "c" > > > belongs to "mod_a". > > > > Thanks, > > > Michal > > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3= > > > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5 > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 14 02:58: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 66C7B3A074D for ; Tue, 14 Dec 2021 02:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=cesnet.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 YO5262e20v9g for ; Tue, 14 Dec 2021 02:58:39 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698493A002C for ; Tue, 14 Dec 2021 02:58:38 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 1B77B60068; Tue, 14 Dec 2021 11:58:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1639479512; bh=taeHQ8Whf3+9PziGcy6H3FTpMKPUPERz2di4E4LgWRg=; h=From:In-Reply-To:Date:Cc:To:Subject; b=5NUS2FYMOyjhRTX0eSkMpzcDN2TLCslhz1U6X9KZhYODHMlIbznoyns8f4xMi2xn4 oMr4+RaG9eoOY+OiIAY4na3aCxrSl5/PqH/2uPJAjn3Z5w/QCuANPRsR9yFyXn2jU1 oM3DjKgC71s80rVc9JdQ37wYsd7ZgfWtXYu4Cl7Y= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <20211214.113945.1688569442535282417.id@4668.se> Content-Type: text/plain; charset="utf-8" X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Tue, 14 Dec 2021 11:58:32 +0100 Cc: netmod@ietf.org To: =?utf-8?q?Martin_Bj=C3=B6rklund?= MIME-Version: 1.0 Message-ID: <72c4-61b87900-9-13e4c040@5935863> User-Agent: SOGoMail 5.2.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] =?utf-8?q?Resolving_schema_node_identifier?= 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, 14 Dec 2021 10:58:45 -0000 > Michal Va=C5=A1ko wrote: > > > Michal Va=C5=A1ko wrote: > > > > Hello, > > > > > I would like to get some input for a use-case I came across, = which to> > > > > > me does not seem to have any consistent rules that can be app= lied. > > > > > module mod=5Fb { > > > > namespace "x:example:mod=5Fb"; > > > > prefix "mb"; > > > > > grouping mylist=5Fwrapper { > > > > list mylist { > > > > key "name"; > > > > unique "value"; > > > > leaf name { > > > > type string; > > > > } > > > > leaf value { > > > > type uint32; > > > > } > > > > } > > > > } > > > > > list mylist2 { > > > > key "a"; > > > > leaf a { > > > > type string; > > > > } > > > > leaf b { > > > > type string; > > > > } > > > > } > > > > } > > > > > > module mod=5Fa { > > > > namespace "x:example:mod=5Fa"; > > > > prefix "ma"; > > > > > import mod=5Fb { prefix "mb"; } > > > > > container root { > > > > uses mb:mylist=5Fwrapper; > > > > } > > > > > augment /mb:mylist2 { > > > > leaf c { > > > > type string; > > > > } > > > > } > > > > > deviation /mb:mylist2 { > > > > deviate add { > > > > unique "mb:b c"; > > > > } > > > > } > > > > } > > > > > The focus is on the "unique" statements and how to resolve > > > > non-prefixed identifiers. RFC 7950 says that the argument is a = "list > > > > of schema node identifiers"[1], which use "current module" for > > > > non-prefixed identifiers[2]. I have asked on this mailing list = a few > > > > years back what current module means and the answer I got was t= he> > > module where the statement is defined. > > > > > So let's get to the examples. As they are written, the unique= in > > > > "mylist" should be wrong because the node "value" belongs to th= e > > > > module "mod=5Fa" when the grouping is instantiated there, but u= nique is> > > > > defined in the module "mod=5Fb". > > > > > But even if we use the other understanding of current module = and > > > > interpret is as the module of the context node of the statement= > > > > (corresponds to the "current()" XPath function), then the other= > > > > "unique" in the deviation cannot be resolved. It is referencing= node > > > > "c", which belongs to the module "mod=5Fa" (added by an augment= ) but the > > > > current module would then be "mod=5Fb". > > > > > To summarize, if strictly following the specs, the "unique" i= n the > > > > "mylist" should probably reference "value" with a prefix, but t= hat is> > > > > not possible because "mod=5Fa" is not even imported and it gene= rally > > > > does not make sense. But then I cannot think of any consistent = rule to > > > > successfully resolve both "unique" statements in this example. = Can > > > > anyone help me with this, please? > > > > > Compare with this: > > > > > grouping mylist=5Fwrapper { > > > list mylist { > > > key "name"; > > > unique "value"; > > > must "value > 42"; > > > leaf name { > > > type string; > > > } > > > leaf value { > > > type uint32; > > > } > > > } > > > } > > > > > I think the rules for the prefixes in "unique" should be the = same as > > > for "must". So I think that the correct syntax is to not use any= > > > prefix in "unique". > > > > > And the deviation that adds a unique statement look correct. > > > Thanks for the reply but I do not think you have answered my > > question. Please formulate a formal rule how to assign modules to > > non-prefixed identifiers, whether they be in "unique", "must", or a= ny> other statement with identifiers. That is what I need to implement = it> properly and I am simply not able to come up with any that would be= > > consistent and compliant with the specification. > > Interpret the unique argument the same way as an XPath expression, an= d > apply (from 6.4.1): > > o Names without a namespace prefix belong to the same namespace a= s > the identifier of the current node. Inside a grouping, that > namespace is affected by where the grouping is used > > So "value" in the unique statement will refer to "value" in "mod=5Fa"= > when the grouping is used in "mod=5Fa". I see. Okay, this should be possible to implement, thanks. > /martin > > > > > /martin > > > > > > Finally, I am asking because I am trying to implement this = correctly > > > > in yanglint. I have also tried to test these examples with pyan= g,> > > which, however, seems to not have any consistent rules applied = because > > > > it loads these examples without warnings. No warnings are print= ed even > > > > if the "unique" in the deviation is changed to "b c", which is > > > > definitely wrong since node "b" belongs to "mod=5Fb" and node "= c" > > > > belongs to "mod=5Fa". > > > > > Thanks, > > > > Michal > > > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8= .3> > > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5 > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 14 03:03: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 9236E3A0A71 for ; Tue, 14 Dec 2021 03:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=cesnet.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 H3Ti3DRqHWWp for ; Tue, 14 Dec 2021 03:03:13 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F923A0773 for ; Tue, 14 Dec 2021 03:03:12 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id DEA1360068; Tue, 14 Dec 2021 12:03:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1639479789; bh=mkh1TLausjsVVlteTObM8pDS93xtS8nQaRlhQOtk5O0=; h=From:In-Reply-To:Date:Cc:To:Subject; b=fLmASb4Et3n05VQHm4xOXE3LDuMBg2Hmu2SQWY3J3dl5rYajznhBcZlofzpod75OG VB32durWpbP6IVbvrLIvGeIvcI0yGZalnCPMnzpdYzAmgaVotoZELPopVRVD3csGIT RPF6nXcfuFEkAY7UzCNP/ZPwI8C1J19BYLv3h80o= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <72c4-61b87900-9-13e4c040@5935863> Content-Type: text/plain; charset="utf-8" X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Tue, 14 Dec 2021 12:03:09 +0100 Cc: =?utf-8?q?Martin_Bj=C3=B6rklund?= , netmod@ietf.org To: =?utf-8?q?Michal_Va=C5=A1ko?= MIME-Version: 1.0 Message-ID: <4dda-61b87a00-3-65b6b880@176376680> User-Agent: SOGoMail 5.2.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] =?utf-8?q?Resolving_schema_node_identifier?= 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, 14 Dec 2021 11:03:19 -0000 > > Michal Va=C5=A1ko wrote: > > > > Michal Va=C5=A1ko wrote: > > > > > Hello, > > > > > > I would like to get some input for a use-case I came across= , which to> > > > > > > me does not seem to have any consistent rules that can be a= pplied. > > > > > > module mod=5Fb { > > > > > namespace "x:example:mod=5Fb"; > > > > > prefix "mb"; > > > > > > grouping mylist=5Fwrapper { > > > > > list mylist { > > > > > key "name"; > > > > > unique "value"; > > > > > leaf name { > > > > > type string; > > > > > } > > > > > leaf value { > > > > > type uint32; > > > > > } > > > > > } > > > > > } > > > > > > list mylist2 { > > > > > key "a"; > > > > > leaf a { > > > > > type string; > > > > > } > > > > > leaf b { > > > > > type string; > > > > > } > > > > > } > > > > > } > > > > > > > module mod=5Fa { > > > > > namespace "x:example:mod=5Fa"; > > > > > prefix "ma"; > > > > > > import mod=5Fb { prefix "mb"; } > > > > > > container root { > > > > > uses mb:mylist=5Fwrapper; > > > > > } > > > > > > augment /mb:mylist2 { > > > > > leaf c { > > > > > type string; > > > > > } > > > > > } > > > > > > deviation /mb:mylist2 { > > > > > deviate add { > > > > > unique "mb:b c"; > > > > > } > > > > > } > > > > > } > > > > > > The focus is on the "unique" statements and how to resolve > > > > > non-prefixed identifiers. RFC 7950 says that the argument is = a "list > > > > > of schema node identifiers"[1], which use "current module" fo= r > > > > > non-prefixed identifiers[2]. I have asked on this mailing lis= t a few > > > > > years back what current module means and the answer I got was= the> > > module where the statement is defined. > > > > > > So let's get to the examples. As they are written, the uniq= ue in > > > > > "mylist" should be wrong because the node "value" belongs to = the > > > > > module "mod=5Fa" when the grouping is instantiated there, but= unique is> > > > > > defined in the module "mod=5Fb". > > > > > > But even if we use the other understanding of current modul= e and > > > > > interpret is as the module of the context node of the stateme= nt > > > > > (corresponds to the "current()" XPath function), then the oth= er > > > > > "unique" in the deviation cannot be resolved. It is referenci= ng node > > > > > "c", which belongs to the module "mod=5Fa" (added by an augme= nt) but the > > > > > current module would then be "mod=5Fb". > > > > > > To summarize, if strictly following the specs, the "unique"= in the > > > > > "mylist" should probably reference "value" with a prefix, but= that is> > > > > > not possible because "mod=5Fa" is not even imported and it ge= nerally > > > > > does not make sense. But then I cannot think of any consisten= t rule to > > > > > successfully resolve both "unique" statements in this example= . Can > > > > > anyone help me with this, please? > > > > > > Compare with this: > > > > > > grouping mylist=5Fwrapper { > > > > list mylist { > > > > key "name"; > > > > unique "value"; > > > > must "value > 42"; > > > > leaf name { > > > > type string; > > > > } > > > > leaf value { > > > > type uint32; > > > > } > > > > } > > > > } > > > > > > I think the rules for the prefixes in "unique" should be th= e same as > > > > for "must". So I think that the correct syntax is to not use a= ny > > > > prefix in "unique". > > > > > > And the deviation that adds a unique statement look correct= . > > > > Thanks for the reply but I do not think you have answered my > > > question. Please formulate a formal rule how to assign modules to= > > > non-prefixed identifiers, whether they be in "unique", "must", or= any> other statement with identifiers. That is what I need to implemen= t it> properly and I am simply not able to come up with any that would = be > > > consistent and compliant with the specification. > > > > Interpret the unique argument the same way as an XPath expression, = and > > apply (from 6.4.1): > > > > o Names without a namespace prefix belong to the same namespace= as > > the identifier of the current node. Inside a grouping, that > > namespace is affected by where the grouping is used > > > > So "value" in the unique statement will refer to "value" in "mod=5F= a" > > when the grouping is used in "mod=5Fa". > > I see. Okay, this should be possible to implement, thanks. I was too hasty with the reply, this is not working because of the "uni= que" in the deviation I have in the example. What is the "current node"= in that case? I suppose that can only be "mylist2", so the namespace w= ill be that of "mod=5Fb". But this is wrong, the "c" node belongs to "m= od=5Fa", so the "unique" in the deviation would be wrong. > > /martin > > > > > > > /martin > > > > > > > Finally, I am asking because I am trying to implement thi= s correctly > > > > > in yanglint. I have also tried to test these examples with py= ang,> > > which, however, seems to not have any consistent rules applie= d because > > > > > it loads these examples without warnings. No warnings are pri= nted even > > > > > if the "unique" in the deviation is changed to "b c", which i= s > > > > > definitely wrong since node "b" belongs to "mod=5Fb" and node= "c" > > > > > belongs to "mod=5Fa". > > > > > > Thanks, > > > > > Michal > > > > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7= .8.3> > > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5= > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 14 03:42: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 CBC003A0AFF for ; Tue, 14 Dec 2021 03:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, 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 e8h-H8u4AA2e for ; Tue, 14 Dec 2021 03:42:45 -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 D2EDE3A0AFA for ; Tue, 14 Dec 2021 03:42:43 -0800 (PST) Received: from [IPV6:2a01:5e0:29:ffff::82e] (unknown [IPv6:2a01:5e0:29:ffff::82e]) by mail.nic.cz (Postfix) with ESMTPSA id 5E830140538; Tue, 14 Dec 2021 12:42:39 +0100 (CET) Message-ID: <782d3d25-4388-1c2b-6e8e-39d99a1ff82f@nic.cz> Date: Tue, 14 Dec 2021 12:42:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: =?UTF-8?Q?Michal_Va=c5=a1ko?= Cc: netmod@ietf.org References: <4dda-61b87a00-3-65b6b880@176376680> From: Ladislav Lhotka Organization: CZ.NIC In-Reply-To: <4dda-61b87a00-3-65b6b880@176376680> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Resolving schema node identifier 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, 14 Dec 2021 11:42:50 -0000 On 14. 12. 21 12:03, Michal Vaško wrote: >>> Michal Vaško wrote: >>>>> Michal Vaško wrote: >>>>>> Hello, >>>>>>> I would like to get some input for a use-case I came across, which to> >>>>>>> me does not seem to have any consistent rules that can be applied. >>>>>>> module mod_b { >>>>>> namespace "x:example:mod_b"; >>>>>> prefix "mb"; >>>>>>> grouping mylist_wrapper { >>>>>> list mylist { >>>>>> key "name"; >>>>>> unique "value"; >>>>>> leaf name { >>>>>> type string; >>>>>> } >>>>>> leaf value { >>>>>> type uint32; >>>>>> } >>>>>> } >>>>>> } >>>>>>> list mylist2 { >>>>>> key "a"; >>>>>> leaf a { >>>>>> type string; >>>>>> } >>>>>> leaf b { >>>>>> type string; >>>>>> } >>>>>> } >>>>>> } >>>>>>>> module mod_a { >>>>>> namespace "x:example:mod_a"; >>>>>> prefix "ma"; >>>>>>> import mod_b { prefix "mb"; } >>>>>>> container root { >>>>>> uses mb:mylist_wrapper; >>>>>> } >>>>>>> augment /mb:mylist2 { >>>>>> leaf c { >>>>>> type string; >>>>>> } >>>>>> } >>>>>>> deviation /mb:mylist2 { >>>>>> deviate add { >>>>>> unique "mb:b c"; >>>>>> } >>>>>> } >>>>>> } >>>>>>> The focus is on the "unique" statements and how to resolve >>>>>> non-prefixed identifiers. RFC 7950 says that the argument is a "list >>>>>> of schema node identifiers"[1], which use "current module" for >>>>>> non-prefixed identifiers[2]. I have asked on this mailing list a few >>>>>> years back what current module means and the answer I got was the> > > module where the statement is defined. >>>>>>> So let's get to the examples. As they are written, the unique in >>>>>> "mylist" should be wrong because the node "value" belongs to the >>>>>> module "mod_a" when the grouping is instantiated there, but unique is> >>>>>> defined in the module "mod_b". >>>>>>> But even if we use the other understanding of current module and >>>>>> interpret is as the module of the context node of the statement >>>>>> (corresponds to the "current()" XPath function), then the other >>>>>> "unique" in the deviation cannot be resolved. It is referencing node >>>>>> "c", which belongs to the module "mod_a" (added by an augment) but the >>>>>> current module would then be "mod_b". >>>>>>> To summarize, if strictly following the specs, the "unique" in the >>>>>> "mylist" should probably reference "value" with a prefix, but that is> >>>>>> not possible because "mod_a" is not even imported and it generally >>>>>> does not make sense. But then I cannot think of any consistent rule to >>>>>> successfully resolve both "unique" statements in this example. Can >>>>>> anyone help me with this, please? >>>>>>> Compare with this: >>>>>>> grouping mylist_wrapper { >>>>> list mylist { >>>>> key "name"; >>>>> unique "value"; >>>>> must "value > 42"; >>>>> leaf name { >>>>> type string; >>>>> } >>>>> leaf value { >>>>> type uint32; >>>>> } >>>>> } >>>>> } >>>>>>> I think the rules for the prefixes in "unique" should be the same as >>>>> for "must". So I think that the correct syntax is to not use any >>>>> prefix in "unique". >>>>>>> And the deviation that adds a unique statement look correct. >>>>> Thanks for the reply but I do not think you have answered my >>>> question. Please formulate a formal rule how to assign modules to >>>> non-prefixed identifiers, whether they be in "unique", "must", or any> other statement with identifiers. That is what I need to implement it> properly and I am simply not able to come up with any that would be >>>> consistent and compliant with the specification. >>> >>> Interpret the unique argument the same way as an XPath expression, and >>> apply (from 6.4.1): >>> >>> o Names without a namespace prefix belong to the same namespace as >>> the identifier of the current node. Inside a grouping, that >>> namespace is affected by where the grouping is used >>> >>> So "value" in the unique statement will refer to "value" in "mod_a" >>> when the grouping is used in "mod_a". >> >> I see. Okay, this should be possible to implement, thanks. > > I was too hasty with the reply, this is not working because of the "unique" in the deviation I have in the example. What is the "current node" in that case? I suppose that can only be "mylist2", so the namespace will be that of "mod_b". But this is wrong, the "c" node belongs to "mod_a", so the "unique" in the deviation would be wrong. Yes, this is unclear. I guess the only chance is to define the current node to be the (anonymous) root of the module "mod_a". A similar situation can happen inside a refine statement. Lada > >>> /martin >>> >>>>>> /martin >>>>>>>> Finally, I am asking because I am trying to implement this correctly >>>>>> in yanglint. I have also tried to test these examples with pyang,> > > which, however, seems to not have any consistent rules applied because >>>>>> it loads these examples without warnings. No warnings are printed even >>>>>> if the "unique" in the deviation is changed to "b c", which is >>>>>> definitely wrong since node "b" belongs to "mod_b" and node "c" >>>>>> belongs to "mod_a". >>>>>>> Thanks, >>>>>> Michal >>>>>>> [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3> > > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5 >>>>>>> _______________________________________________ >>>>>> 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 Tue Dec 14 04:01: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 655C63A0B38 for ; Tue, 14 Dec 2021 04:01:23 -0800 (PST) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=4668.se header.b=fqaSwelj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hoQR7TEy 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 3ztEbR8tAO7w for ; Tue, 14 Dec 2021 04:01:18 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25FF3A0B37 for ; Tue, 14 Dec 2021 04:01:16 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E36545C023D; Tue, 14 Dec 2021 07:01:15 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 14 Dec 2021 07:01:15 -0500 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=fm3; bh= G3GZQ3Kmvjvu63R9xdGGfMMl9h5aP4DMKvTs41agsNg=; b=fqaSweljxs7ShbRk QznObAG8iNBXyX5D8RuWdJNKKg1sI0fN5RuxRDSvAXB/2D/ggWpSzMf+9iwIZww5 0GG0tjBVPTWTLjfgPNJ3G+0PKHpJYFBD4zV6v7yMkg95rG4dou1YdmXO3pa0d5MP CM52FievM0yUCNfLZVIm+pRjDXRLS21UoJfwtlmrOoMt/J2Zk5EaE4ay+9BQiam3 wdnPIJ8YyFVsc/HnBmbHgo2HfwFGYXmHWyglxlCXQgh2TXGwp+IH9jse4x96vLhP H5Ex6C1us5mgausWnCbvK46BjcnSkXZ1FfC27n9ha6NlHQ/N9u6S42xttILFODUM 5Yb+cQ== 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=fm1; bh=G3GZQ3Kmvjvu63R9xdGGfMMl9h5aP4DMKvTs41ags Ng=; b=hoQR7TEyhqmU+RN2zn9Osvgt/PRTXB5M7oZCuDst7UGNSOWuTsAZdc5JB cHfYkxoGfmur6JuSNS4KkPK5uySXJPtjwZXHppgb2f6lg+frOx6xs6R2yVxQcSjx yxBHjeJ3/hETZYvRqbx/fUOlqkLmeAgYXkbwkGswcwQK3qpLMqOvDaipWqHOBLgJ hWtTcBWsXtIbRB1iLZuWqmB+tLe+I8/uO958YXjsplMA9/FkrI/HhsqDpGDhmVkT Srb3ZhZbdeOgaYsUQjvhKgqTEJDh6KAhAY2XKM3pDeUcHnzOenvCz0nESxmZ1Z5w 3fx5eIMhq0VLtJKnrdN1bJ/wse6rg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrledtgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthhqre dtredtleenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpefgffevudevvdfgfeevhfeggf evkeeijedvheevuefhffffveduvdeghfeiueduieenucffohhmrghinhepihgvthhfrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh gsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Dec 2021 07:01:15 -0500 (EST) Date: Tue, 14 Dec 2021 13:01:13 +0100 (CET) Message-Id: <20211214.130113.868744002798503822.id@4668.se> To: mvasko@cesnet.cz Cc: netmod@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <4dda-61b87a00-3-65b6b880@176376680> References: <72c4-61b87900-9-13e4c040@5935863> <4dda-61b87a00-3-65b6b880@176376680> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Resolving schema node identifier 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, 14 Dec 2021 12:01:24 -0000 Michal Va=A8ko wrote: > > > Michal Va=A8ko wrote: > > > > > Michal Va=A8ko wrote: > > > > > > Hello, > > > > > > > I would like to get some input for a use-case I came acro= ss, which > > > > > > > to> > > > > > > > me does not seem to have any consistent rules that can be= applied. > > > > > > > module mod_b { > > > > > > namespace "x:example:mod_b"; > > > > > > prefix "mb"; > > > > > > > grouping mylist_wrapper { > > > > > > list mylist { > > > > > > key "name"; > > > > > > unique "value"; > > > > > > leaf name { > > > > > > type string; > > > > > > } > > > > > > leaf value { > > > > > > type uint32; > > > > > > } > > > > > > } > > > > > > } > > > > > > > list mylist2 { > > > > > > key "a"; > > > > > > leaf a { > > > > > > type string; > > > > > > } > > > > > > leaf b { > > > > > > type string; > > > > > > } > > > > > > } > > > > > > } > > > > > > > > module mod_a { > > > > > > namespace "x:example:mod_a"; > > > > > > prefix "ma"; > > > > > > > import mod_b { prefix "mb"; } > > > > > > > container root { > > > > > > uses mb:mylist_wrapper; > > > > > > } > > > > > > > augment /mb:mylist2 { > > > > > > leaf c { > > > > > > type string; > > > > > > } > > > > > > } > > > > > > > deviation /mb:mylist2 { > > > > > > deviate add { > > > > > > unique "mb:b c"; > > > > > > } > > > > > > } > > > > > > } > > > > > > > The focus is on the "unique" statements and how to resolv= e > > > > > > non-prefixed identifiers. RFC 7950 says that the argument i= s a "list > > > > > > of schema node identifiers"[1], which use "current module" = for > > > > > > non-prefixed identifiers[2]. I have asked on this mailing l= ist a few > > > > > > years back what current module means and the answer I got w= as the> > > > > > > > > module where the statement is defined. > > > > > > > So let's get to the examples. As they are written, the un= ique in > > > > > > "mylist" should be wrong because the node "value" belongs t= o the > > > > > > module "mod_a" when the grouping is instantiated there, but= unique > > > > > > is> > > > > > > defined in the module "mod_b". > > > > > > > But even if we use the other understanding of current mod= ule and > > > > > > interpret is as the module of the context node of the state= ment > > > > > > (corresponds to the "current()" XPath function), then the o= ther > > > > > > "unique" in the deviation cannot be resolved. It is referen= cing node > > > > > > "c", which belongs to the module "mod_a" (added by an augme= nt) but > > > > > > the > > > > > > current module would then be "mod_b". > > > > > > > To summarize, if strictly following the specs, the "uniqu= e" in the > > > > > > "mylist" should probably reference "value" with a prefix, b= ut that > > > > > > is> > > > > > > not possible because "mod_a" is not even imported and it ge= nerally > > > > > > does not make sense. But then I cannot think of any consist= ent rule > > > > > > to > > > > > > successfully resolve both "unique" statements in this examp= le. Can > > > > > > anyone help me with this, please? > > > > > > > Compare with this: > > > > > > > grouping mylist_wrapper { > > > > > list mylist { > > > > > key "name"; > > > > > unique "value"; > > > > > must "value > 42"; > > > > > leaf name { > > > > > type string; > > > > > } > > > > > leaf value { > > > > > type uint32; > > > > > } > > > > > } > > > > > } > > > > > > > I think the rules for the prefixes in "unique" should be = the same > > > > > > > as > > > > > for "must". So I think that the correct syntax is to not use= any > > > > > prefix in "unique". > > > > > > > And the deviation that adds a unique statement look corre= ct. > > > > > Thanks for the reply but I do not think you have answered my > > > > question. Please formulate a formal rule how to assign modules = to > > > > non-prefixed identifiers, whether they be in "unique", "must", = or any> > > > > other statement with identifiers. That is what I need to implem= ent it> > > > > properly and I am simply not able to come up with any that woul= d be > > > > consistent and compliant with the specification. > > > = > > > Interpret the unique argument the same way as an XPath expression= , and > > > apply (from 6.4.1): > > > = > > > o Names without a namespace prefix belong to the same namespa= ce as > > > the identifier of the current node. Inside a grouping, tha= t > > > namespace is affected by where the grouping is used > > > = > > > So "value" in the unique statement will refer to "value" in "mod_= a" > > > when the grouping is used in "mod_a". > > = > > I see. Okay, this should be possible to implement, thanks. > = > I was too hasty with the reply, this is not working because of the > "unique" in the deviation I have in the example. What is the "current= > node" in that case? I suppose that can only be "mylist2", so the > namespace will be that of "mod_b". But this is wrong, the "c" node > belongs to "mod_a", so the "unique" in the deviation would be wrong. Right; I was thinking that since "c" didn't have a prefix, it would belong to "mod_a", and thus work as expected. I think it is ok to solve this by requiring a prefix in this case. /martin > = > > > /martin > > > = > > > > > > /martin > > > > > > > > Finally, I am asking because I am trying to implement t= his > > > > > > > > correctly > > > > > > in yanglint. I have also tried to test these examples with = pyang,> > > > > > > > > which, however, seems to not have any consistent rules ap= plied > > > > > > because > > > > > > it loads these examples without warnings. No warnings are p= rinted > > > > > > even > > > > > > if the "unique" in the deviation is changed to "b c", which= is > > > > > > definitely wrong since node "b" belongs to "mod_b" and node= "c" > > > > > > belongs to "mod_a". > > > > > > > Thanks, > > > > > > Michal > > > > > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section= -7.8.3> > > > > > > > > > [2] https://datatracker.ietf.org/doc/html/rfc7950#secti= on-6.5 > > > > > > > _______________________________________________ > > > > > > 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 Dec 14 04:14:28 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 B36633A0B5B for ; Tue, 14 Dec 2021 04:14:25 -0800 (PST) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=4668.se header.b=PfHWBc5N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=R7w8p29x 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 Fv2sOh8WDnRU for ; Tue, 14 Dec 2021 04:14:20 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616A13A0B59 for ; Tue, 14 Dec 2021 04:14:20 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 77E455C03A2; Tue, 14 Dec 2021 07:14:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 14 Dec 2021 07:14:19 -0500 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=fm3; bh= glmrwsf4TG0GzE3ui2Ot7GOMWgildvUwO5e62/lRgRo=; b=PfHWBc5NgthNReqg /CL/WsUCl8wOhADNAuAUWFscDuXU7QUYFjRaW/r7ptYEPq/x0lHazZfR4NqJAHJh hpJojcCEIYZZGMouYi3Zluxvpy7bhT9pD/RorwSdcwIDHPAyiHaFR3L8B3G3H3VV yPQRr/UCMNkj9+eQZUZeB7AMAgoZwUZacHNBYn0TLVYg3QsupeRM1x0bOUhBxeJV T6rq2d3xPTmzRVzx3Ytmz0ZqHffILeG8VVoK7a4tN/2Kgjvg1UghUMTrjSGwH0ka KbWYGodlZweKr+lxOVDMZSnmeaTAR6d2mCLBx9BRZBsMVjWcyNHXSDhTGcPETyas Iv7rCQ== 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=fm1; bh=glmrwsf4TG0GzE3ui2Ot7GOMWgildvUwO5e62/lRg Ro=; b=R7w8p29xt33EvB4lQNNPw22tdz3U/dGIF24Dm0PztBJ5612Dnknsw7el5 AyUIOrBAN+gzC7QkeK2gtE91g4ON/zUqVEKalOee3fl7kfW+L3fNair6ViW2BddY AdoIFtIS+SGcmssIP5kXqrjVDefF7cvsGHbbiTEJ58FcJvU+bQY9vGwrYnvdEogf vAzDcv+rDN46pdixMR45EKKdVV5lv1dBef6FcZVGOVmpLtjAzQy4J56tM6eNf2Kg G8BVXjvE67vfCMK7c8spG15dTdj0xXtvrz0nqA5uDFn3PABnjTVIZXDGsMRfaoXu mQSp/k1GYXJEeB3hECXzYF+pnitig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrledtgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeefheekgfdukeefheeihefhke egvdffheetvefgfeefgefhvdefueeluddvvdfgheenucffohhmrghinhepihgvthhfrdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh gsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Dec 2021 07:14:18 -0500 (EST) Date: Tue, 14 Dec 2021 13:14:17 +0100 (CET) Message-Id: <20211214.131417.1201606442961003687.id@4668.se> To: kent+ietf@watsen.net Cc: andy@yumaworks.com, maqiufang1=40huawei.com@dmarc.ietf.org, netmod@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> References: <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 12:14:26 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+IEhpIEFu ZHksDQoNCj4gPiBJIGNhbm5vdCBmaW5kIGFueSBSRkMgdGV4dCB0aGF0IHNheXMgc3lzdGVtLWlu amVjdGVkIGNvbmZpZyBpcw0KPiA+IHNwZWNpYWwsIGVzcGVjaWFsbHkgc2luY2UNCj4gPiBzZXJ2 ZXIgaW1wbGVtZW50YXRpb25zIGV4aXN0IHRoYXQgdHJlYXQgdGhlc2UgZWRpdHMgYXMganVzdCBh bm90aGVyDQo+ID4gY2xpZW50DQo+ID4gKGFsdGhvdWdoIHByb2JhYmx5IGEgJ3Jvb3QnIHVzZXIg Y2xpZW50KS4NCj4gDQo+IFZlcnkgdHJ1ZSAoYW5kIEp1ZXJnZW7igJlzIHBvaW50IGFzIHdlbGwp LiAgSeKAmXZlIHNlZW4gdGhpcyBkb25lIGJlZm9yZS4NCj4gVW5oYXBweSByZXN1bHRzLg0KDQpD YW4geW91IGVsYWJvcmF0ZSBvbiB0aGlzLCBvciBzZW5kIGEgcG9pbnRlciBpZiBpdCBoYXMgYmVl biBkb2N1bWVudGVkDQpzb21ld2hlcmU/DQoNCkkgd2lsbCBhbHNvIGFkZCBhICsxIHRvIGxldHRp bmcgdGhlIHN5c3RlbSAiYWN0IGFzIGEgY2xpZW50IiBhbmQgcHV0DQpkYXRhIGludG8gcnVubmlu Zy4gIFRoaXMgaXMgd2hhdCB3ZSBkbyBpbiBvdXIgY3VycmVudCBwcm9qZWN0Lg0KDQpBIGZldyBv dGhlciBjb21tZW50cy4NCg0KVGhlIG5hbWUgInN5c3RlbSIgZm9yIHRoaXMgbmV3IHByb3Bvc2Vk IGRhdGFzdG9yZSBpcyBwZXJoYXBzIG5vdCB0aGUNCmJlc3QsIHNpbmNlIFJGQyA4MzQyIGFscmVh ZHkgZGVmaW5lcyB0aGlzIHRlcm0sIGFuZCBhc3NvY2lhdGVkDQpzZW1hbnRpY3MuDQoNCklmIHRo ZSBuZXcgcHJvcG9zZWQgZGF0YXN0b3JlIGlzIHN1cHBvc2VkIHRvIGFkZCBzdGF0aWMgZGF0YSBs aWtlDQoiYnVpbHQtaW4gcHJvZmlsZXMgYW5kIHBvbGljaWVzIiwgaXQgaXMgcmF0aGVyIGxpbWl0 ZWQsIGNvbXBhcmVkIHRvDQoic3lzdGVtIGNvbmZpZyIgYXMgZGVmaW5lZCBpbiBSRkMgODM0Mi4g IFRoZSByZWFzb24gaXMgdGhhdCBzeXN0ZW0NCmNvbmZpZyBjYW4gYmUgaW5qZWN0ZWQgYXQgdmFy aW91cyBsZXZlbHMgaW4gdGhlIGNvbmZpZyBoaWVyYXJjaHk7DQpzcGVjaWZpY2FsbHkgYWxzbyB1 bmRlciB1c2VyLWRlZmluZWQgbGlzdCBlbnRyaWVzLiAgIEFuZCBpZiB0aGlzIGlzDQppbmRlZWQg dGhlIHVzZSBjYXNlIHlvdSAoYXMgaW4gYWxsIHByb3BvbmVudHMgb2YgdGhlIHByb3Bvc2FsKSBo YXZlIGluDQptaW5kLCBJIHRoaW5rIHRoZSBzb2x1dGlvbiB3aXRoIGFkZGluZyB0aGlzIHRvIDxy dW5uaW5nPiB3b3Jrcy4gIChCdXQNCkkgYW0gY3VyaW91cyB0byBoZWFyIHlvdXIgZXhwZXJpZW5j ZSBvZiB0aGlzKS4NCg0KDQo+IDxwdXR0aW5nIG9uIGZsYW1lIHN1aXQ+DQo+IA0KPiBBcyBhIGNv LWF1dGhvciwgSSBrbm93IHRoaXMgd2FzIHRoZSBpbnRlbnRpb24gb2YgUkZDIDgzNDIsIHdoaWNo IGlzDQo+IHN1cHBvcnRlZCBieSwgZm9yIGluc3RhbmNlOg0KPiANCj4gDQo+IFNlY3Rpb24gNC4x Og0KPiANCj4gICAgbyAgU2V2ZXJhbCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBwcm9wcmlldGFyeSBt ZWNoYW5pc21zIHRoYXQgYWxsb3cNCj4gICAgICAgY2xpZW50cyB0byBzdG9yZSBpbmFjdGl2ZSBk YXRhIGluIDxydW5uaW5nPi4gIEluYWN0aXZlIGRhdGEgaXMNCj4gICAgICAgY29uY2VwdHVhbGx5 IHJlbW92ZWQgYmVmb3JlIHZhbGlkYXRpb24uDQo+IA0KPiAgICBvICBTb21lIGltcGxlbWVudGF0 aW9ucyBoYXZlIHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMgdGhhdCBhbGxvdw0KPiAgICAgICBjbGll bnRzIHRvIGRlZmluZSBjb25maWd1cmF0aW9uIHRlbXBsYXRlcyBpbiA8cnVubmluZz4uICBUaGVz ZQ0KPiAgICAgICB0ZW1wbGF0ZXMgYXJlIGV4cGFuZGVkIGF1dG9tYXRpY2FsbHkgYnkgdGhlIHN5 c3RlbSwgYW5kIHRoZQ0KPiAgICAgICByZXN1bHRpbmcgY29uZmlndXJhdGlvbiBpcyBhcHBsaWVk IGludGVybmFsbHkuDQoNClJpZ2h0LCBhbmQgaW4gYm90aCBjYXNlcywgdGhlIGlkZWEgd2FzIHRo YXQgPHJ1bm5pbmc+IGNvbnRhaW5zIGFsbA0KZGF0YSBuZWVkZWQgZm9yIHRoZSB0cmFuc2Zvcm1h dGlvbiBpbnRvIDxpbnRlbmRlZD4uICBTbyBhIGNsaWVudCB0aGF0DQp3YW50cyB0byBkbyAib2Zm bGluZSIgdmFsaWRhdGlvbiB3b3VsZCBuZWVkIHRoZSBkYXRhICsgdGhlDQp0cmFuc2Zvcm1hdGlv biBhbGdvcml0aG1zLiAgQnV0IG5vIGFkZGl0aW9uYWwgZGF0YS4NCg0KDQovbWFydGluDQoNCg0K DQo+IA0KPiBTZWN0aW9uIDU6DQo+IA0KPiAJPGludGVuZGVkPiAgIC8vIHN1YmplY3QgdG8gdmFs aWRhdGlvbg0KPiANCj4gU2VjdGlvbiA1LjEuNDoNCj4gDQo+ICAgIDxpbnRlbmRlZD4gaXMgdGln aHRseSBjb3VwbGVkIHRvIDxydW5uaW5nPi4gIFdoZW5ldmVyIGRhdGEgaXMgd3JpdHRlbg0KPiAg ICB0byA8cnVubmluZz4sIHRoZSBzZXJ2ZXIgTVVTVCBhbHNvIGltbWVkaWF0ZWx5IHVwZGF0ZSBh bmQgdmFsaWRhdGUNCj4gICAgPGludGVuZGVkPi4NCj4gDQo+IA0KPiA8dGFraW5nIG9mZiBmbGFt ZSBzdWl0Pg0KPiANCj4gDQo+IE9mIGNvdXJzZSwgc29tZSB3aWxsIHBvaW50IHRvIFNlY3Rpb24g NS4xLjM6DQo+IA0KPiAgICBIb3dldmVyLCA8cnVubmluZz4gTVVTVCBhbHdheXMgYmUgYSB2YWxp ZCBjb25maWd1cmF0aW9uIGRhdGEgdHJlZSwNCj4gICAgYXMgZGVmaW5lZCBpbiBTZWN0aW9uwqA4 LjEgb2YgW1JGQzc5NTBdDQo+ICAgIDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL3JmYzc5NTAjc2VjdGlvbi04LjE+Lg0KPiANCj4gQnV0IGl0IGhhcyB0byBiZSBvYnZpb3Vz IHRoYXQgdGhpcyBpcyBhIGJ1Zy4gIEZvciBpbnN0YW5jZSwNCj4gDQo+ICAgLSBZQU5HIGRlZmlu ZXMgYSBsZWFmIGlzIG9mIHR5cGUgdW5pb24geyB1aW50OCB8IHZhcmlhYmxlIH0NCj4gICAtIDxy dW5uaW5nPiBkZWZpbmVzIHRoZSBsZWFmIGhhdmluZyB2YWx1ZSDigJxNQVhfRk9PQkFS4oCdIA0K PiAgICAgd2l0aCBhIHRlbXBsYXRlIHRoYXQgZGVmaW5lcyBNQVhfRk9PQkFSPTEwMDAuDQo+ICAg LSBzbywgPHJ1bm5pbmc+IHdvdWxkIGJlIHN5bnRhY3RpY2FsbHkgdmFsaWQgYnV0DQo+ICAgICBz ZW1hbnRpY2FsbHkgaW52YWxpZC4NCj4gDQo+IE9yIGEgbW9yZSBlZ3JlZ2lvdXMgZXhhbXBsZToN Cj4gDQo+ICAgLSBZQU5HIGRlZmluZXMgYSAibWF4LWVsZW1lbnRzIiB2YWx1ZSDigJxNQVhfRk9P QkFS4oCdDQo+ICAgICAgICAtIGhvdyBpcyB0aGlzIHBvc3NpYmxlIHdoZW4gUkZDIDc5NTAgc2F5 cyBtYXgtZWxlbWVudHMNCj4gICAgICAgICAgIElzIGEgcG9zaXRpdmUgaW50ZWdlciBvciB0aGUg c3RyaW5nIOKAnHVuYm91bmRlZOKAnT8NCj4gICAgICAgIC0gc28gbm93IHdl4oCZcmUgaW50byBZ QU5HLW5leHQgdGVycml0b3J5IGFzIGZhciBhcw0KPiAgICAgICAgICB0ZW1wbGF0ZXMgYXJlIGNv bmNlcm5lZCwgYnV0IGhhbmcgd2l0aCBtZSBhIGxpdHRsZQ0KPiAgICAgICAgICB3aGlsZSBsb25n ZXLigKYNCj4gICAtIDxydW5uaW5nPiBoYXMgYSB0ZW1wbGF0ZSB0aGF0IGRlZmluZXMgTUFYX0ZP T0JBUj0zDQo+ICAgLSBob3cgY291bGRhIHNlcnZlciB2YWxpZGF0ZSBpZiA8cnVubmluZz7igJlz IGxpc3QgY29udGFpbmVkIGxlc3MNCj4gICAgIHRoYW4gbWF4LWVsZW1lbnRzPyAgV29yc2UsIHdo YXQgaWYgdGhlIHJlc3VsdCBvZiBhbm90aGVyIA0KPiAgICAgdGVtcGxhdGUgYWRkZWQgbW9yZSBl bGVtZW50cyB0byB0aGUgbGlzdD8NCj4gDQo+IA0KPiBJIG1heSBoYXZlIHRha2VuIG9mZiB0aGUg ZmxhbWUgc3VpdCB0b28gZWFybHkgIDspDQo+IA0KPiBLLg0KPiANCj4gDQo+IA0K From nobody Tue Dec 14 04:23: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 5FBF43A0B98 for ; Tue, 14 Dec 2021 04:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=cesnet.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 hx69fFb36GYm for ; Tue, 14 Dec 2021 04:23:36 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E762A3A0B91 for ; Tue, 14 Dec 2021 04:23:34 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 551A760068; Tue, 14 Dec 2021 13:23:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1639484609; bh=SU0fcT2ZlrUeBxSnGyZ/xUrf6PS8WB+sApSprmGFnE0=; h=From:In-Reply-To:Date:Cc:To:Subject; b=Mc4dw9bUGG7l1GoNm9930ujnzHsp5Zk7toiH1Jo04hhT1NWxDDzPCmiSeha1U3NeC z1OHXaSoEWtfvYd2U6oZQhlgZ2r0txKpN6k9j4zwti7PYe7jKGOnnWlTcMbqAWGO3h E634OOjgLDh83kIolpEDjovfhrfGqIKH67M2RCnQ= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <20211214.130113.868744002798503822.id@4668.se> Content-Type: text/plain; charset="utf-8" X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Tue, 14 Dec 2021 13:23:29 +0100 Cc: netmod@ietf.org To: =?utf-8?q?Martin_Bj=C3=B6rklund?= MIME-Version: 1.0 Message-ID: <72c4-61b88d00-f-13e4c040@5935962> User-Agent: SOGoMail 5.2.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] =?utf-8?q?Resolving_schema_node_identifier?= 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, 14 Dec 2021 12:23:42 -0000 > Michal Va=C5=A1ko wrote: > > > > Michal Va=C5=A1ko wrote: > > > > > > Michal Va=C5=A1ko wrote: > > > > > > > Hello, > > > > > > > > I would like to get some input for a use-case I came ac= ross, which > > > > > > > > to> > > > > > > > > me does not seem to have any consistent rules that can = be applied. > > > > > > > > module mod=5Fb { > > > > > > > namespace "x:example:mod=5Fb"; > > > > > > > prefix "mb"; > > > > > > > > grouping mylist=5Fwrapper { > > > > > > > list mylist { > > > > > > > key "name"; > > > > > > > unique "value"; > > > > > > > leaf name { > > > > > > > type string; > > > > > > > } > > > > > > > leaf value { > > > > > > > type uint32; > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > list mylist2 { > > > > > > > key "a"; > > > > > > > leaf a { > > > > > > > type string; > > > > > > > } > > > > > > > leaf b { > > > > > > > type string; > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > module mod=5Fa { > > > > > > > namespace "x:example:mod=5Fa"; > > > > > > > prefix "ma"; > > > > > > > > import mod=5Fb { prefix "mb"; } > > > > > > > > container root { > > > > > > > uses mb:mylist=5Fwrapper; > > > > > > > } > > > > > > > > augment /mb:mylist2 { > > > > > > > leaf c { > > > > > > > type string; > > > > > > > } > > > > > > > } > > > > > > > > deviation /mb:mylist2 { > > > > > > > deviate add { > > > > > > > unique "mb:b c"; > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > The focus is on the "unique" statements and how to reso= lve > > > > > > > non-prefixed identifiers. RFC 7950 says that the argument= is a "list > > > > > > > of schema node identifiers"[1], which use "current module= " for > > > > > > > non-prefixed identifiers[2]. I have asked on this mailing= list a few > > > > > > > years back what current module means and the answer I got= was the> > > > > > > > > > module where the statement is defined. > > > > > > > > So let's get to the examples. As they are written, the = unique in > > > > > > > "mylist" should be wrong because the node "value" belongs= to the > > > > > > > module "mod=5Fa" when the grouping is instantiated there,= but unique > > > > > > > is> > > > > > > > defined in the module "mod=5Fb". > > > > > > > > But even if we use the other understanding of current m= odule and > > > > > > > interpret is as the module of the context node of the sta= tement > > > > > > > (corresponds to the "current()" XPath function), then the= other > > > > > > > "unique" in the deviation cannot be resolved. It is refer= encing node > > > > > > > "c", which belongs to the module "mod=5Fa" (added by an a= ugment) but > > > > > > > the > > > > > > > current module would then be "mod=5Fb". > > > > > > > > To summarize, if strictly following the specs, the "uni= que" in the > > > > > > > "mylist" should probably reference "value" with a prefix,= but that > > > > > > > is> > > > > > > > not possible because "mod=5Fa" is not even imported and i= t generally > > > > > > > does not make sense. But then I cannot think of any consi= stent rule > > > > > > > to > > > > > > > successfully resolve both "unique" statements in this exa= mple. Can > > > > > > > anyone help me with this, please? > > > > > > > > Compare with this: > > > > > > > > grouping mylist=5Fwrapper { > > > > > > list mylist { > > > > > > key "name"; > > > > > > unique "value"; > > > > > > must "value > 42"; > > > > > > leaf name { > > > > > > type string; > > > > > > } > > > > > > leaf value { > > > > > > type uint32; > > > > > > } > > > > > > } > > > > > > } > > > > > > > > I think the rules for the prefixes in "unique" should b= e the same > > > > > > > > as > > > > > > for "must". So I think that the correct syntax is to not u= se any > > > > > > prefix in "unique". > > > > > > > > And the deviation that adds a unique statement look cor= rect. > > > > > > Thanks for the reply but I do not think you have answered m= y > > > > > question. Please formulate a formal rule how to assign module= s to > > > > > non-prefixed identifiers, whether they be in "unique", "must"= , or any> > > > > > other statement with identifiers. That is what I need to impl= ement it> > > > > > properly and I am simply not able to come up with any that wo= uld be > > > > > consistent and compliant with the specification. > > > > > > > Interpret the unique argument the same way as an XPath ex= pression, and > > > > apply (from 6.4.1): > > > > > > > o Names without a namespace prefix belong to the same= namespace as > > > > the identifier of the current node. Inside a grouping, t= hat > > > > namespace is affected by where the grouping is used > > > > > > > So "value" in the unique statement will refer to "value" = in "mod=5Fa" > > > > when the grouping is used in "mod=5Fa". > > > > > I see. Okay, this should be possible to implement, thanks. > > > I was too hasty with the reply, this is not working because of th= e > > "unique" in the deviation I have in the example. What is the "curre= nt> node" in that case? I suppose that can only be "mylist2", so the > > namespace will be that of "mod=5Fb". But this is wrong, the "c" nod= e > > belongs to "mod=5Fa", so the "unique" in the deviation would be wro= ng. > > Right; I was thinking that since "c" didn't have a prefix, it would > belong to "mod=5Fa", and thus work as expected. > > I think it is ok to solve this by requiring a prefix in this case. What you are saying is that you would be fine with the deviation not wo= rking with no prefix in the example and stick to the rule of using the = current (context) node to get modules for non-prefixed identifiers? @Lada You seem to suggest some special handling of paths in deviations = (or what exactly)? Neither really seem like a proper solution and, more importantly, inter= preting "unique" paths (non-prefixed identifiers) according to XPath co= ntradicts what I was told those few years back (I will try to find the = mailing list communication if necessary), which is that for "schema nod= e identifiers" the current module is the module where the statements ar= e "physically" written, not that of the current node. We keep hitting these problems because the use-cases vary greatly and t= he most complex ones were probably not anticipated when writing the spe= cs. Still, the code must handle all the use-cases somehow and we have h= uge problems with that. I would appreciate any exact rules that we can agree on. Michal > > > > > /martin > > > > > > > > > > /martin > > > > > > > > > Finally, I am asking because I am trying to implement= this > > > > > > > > > correctly > > > > > > > in yanglint. I have also tried to test these examples wit= h pyang,> > > > > > > > > > which, however, seems to not have any consistent rules = applied > > > > > > > because > > > > > > > it loads these examples without warnings. No warnings are= printed > > > > > > > even > > > > > > > if the "unique" in the deviation is changed to "b c", whi= ch is > > > > > > > definitely wrong since node "b" belongs to "mod=5Fb" and = node "c" > > > > > > > belongs to "mod=5Fa". > > > > > > > > Thanks, > > > > > > > Michal > > > > > > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#secti= on-7.8.3> > > > > > > > > > > [2] https://datatracker.ietf.org/doc/html/rfc7950#sec= tion-6.5 > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F > > > > > > > netmod mailing list > > > > > > > netmod@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 14 05:04: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 079D93A0C2D for ; Tue, 14 Dec 2021 05:04:54 -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, 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 SlhkqD25ZhfN for ; Tue, 14 Dec 2021 05:04:49 -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 1E41D3A0C27 for ; Tue, 14 Dec 2021 05:04:48 -0800 (PST) Received: from localhost (unknown [IPv6:2a01:5e0:29:ffff::82e]) by mail.nic.cz (Postfix) with ESMTPSA id 4A3CD140A72; Tue, 14 Dec 2021 14:04:43 +0100 (CET) From: Ladislav Lhotka To: Michal =?utf-8?Q?Va=C5=A1ko?= , Martin =?utf-8?Q?Bj?= =?utf-8?Q?=C3=B6rklund?= Cc: netmod@ietf.org In-Reply-To: <72c4-61b88d00-f-13e4c040@5935962> References: <72c4-61b88d00-f-13e4c040@5935962> Mail-Followup-To: Michal =?utf-8?Q?Va=C5=A1ko?= , Martin =?utf-8?Q?Bj=C3=B6rklund?= , netmod@ietf.org Date: Tue, 14 Dec 2021 14:04:42 +0100 Message-ID: <87lf0nl4lx.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.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Resolving schema node identifier 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, 14 Dec 2021 13:04:54 -0000 Michal Va=C5=A1ko writes: >> Michal Va=C5=A1ko wrote: >> > > > Michal Va=C5=A1ko wrote: >> > > > > > Michal Va=C5=A1ko wrote: >> > > > > > > Hello, >> > > > > > > > I would like to get some input for a use-case I came acros= s, which >> > > > > > > > to> >> > > > > > > > me does not seem to have any consistent rules that can be = applied. >> > > > > > > > module mod_b { >> > > > > > > namespace "x:example:mod_b"; >> > > > > > > prefix "mb"; >> > > > > > > > grouping mylist_wrapper { >> > > > > > > list mylist { >> > > > > > > key "name"; >> > > > > > > unique "value"; >> > > > > > > leaf name { >> > > > > > > type string; >> > > > > > > } >> > > > > > > leaf value { >> > > > > > > type uint32; >> > > > > > > } >> > > > > > > } >> > > > > > > } >> > > > > > > > list mylist2 { >> > > > > > > key "a"; >> > > > > > > leaf a { >> > > > > > > type string; >> > > > > > > } >> > > > > > > leaf b { >> > > > > > > type string; >> > > > > > > } >> > > > > > > } >> > > > > > > } >> > > > > > > > > module mod_a { >> > > > > > > namespace "x:example:mod_a"; >> > > > > > > prefix "ma"; >> > > > > > > > import mod_b { prefix "mb"; } >> > > > > > > > container root { >> > > > > > > uses mb:mylist_wrapper; >> > > > > > > } >> > > > > > > > augment /mb:mylist2 { >> > > > > > > leaf c { >> > > > > > > type string; >> > > > > > > } >> > > > > > > } >> > > > > > > > deviation /mb:mylist2 { >> > > > > > > deviate add { >> > > > > > > unique "mb:b c"; >> > > > > > > } >> > > > > > > } >> > > > > > > } >> > > > > > > > The focus is on the "unique" statements and how to resolve >> > > > > > > non-prefixed identifiers. RFC 7950 says that the argument is= a "list >> > > > > > > of schema node identifiers"[1], which use "current module" f= or >> > > > > > > non-prefixed identifiers[2]. I have asked on this mailing li= st a few >> > > > > > > years back what current module means and the answer I got wa= s the> > >> > > > > > > > module where the statement is defined. >> > > > > > > > So let's get to the examples. As they are written, the uni= que in >> > > > > > > "mylist" should be wrong because the node "value" belongs to= the >> > > > > > > module "mod_a" when the grouping is instantiated there, but = unique >> > > > > > > is> >> > > > > > > defined in the module "mod_b". >> > > > > > > > But even if we use the other understanding of current modu= le and >> > > > > > > interpret is as the module of the context node of the statem= ent >> > > > > > > (corresponds to the "current()" XPath function), then the ot= her >> > > > > > > "unique" in the deviation cannot be resolved. It is referenc= ing node >> > > > > > > "c", which belongs to the module "mod_a" (added by an augmen= t) but >> > > > > > > the >> > > > > > > current module would then be "mod_b". >> > > > > > > > To summarize, if strictly following the specs, the "unique= " in the >> > > > > > > "mylist" should probably reference "value" with a prefix, bu= t that >> > > > > > > is> >> > > > > > > not possible because "mod_a" is not even imported and it gen= erally >> > > > > > > does not make sense. But then I cannot think of any consiste= nt rule >> > > > > > > to >> > > > > > > successfully resolve both "unique" statements in this exampl= e. Can >> > > > > > > anyone help me with this, please? >> > > > > > > > Compare with this: >> > > > > > > > grouping mylist_wrapper { >> > > > > > list mylist { >> > > > > > key "name"; >> > > > > > unique "value"; >> > > > > > must "value > 42"; >> > > > > > leaf name { >> > > > > > type string; >> > > > > > } >> > > > > > leaf value { >> > > > > > type uint32; >> > > > > > } >> > > > > > } >> > > > > > } >> > > > > > > > I think the rules for the prefixes in "unique" should be t= he same >> > > > > > > > as >> > > > > > for "must". So I think that the correct syntax is to not use = any >> > > > > > prefix in "unique". >> > > > > > > > And the deviation that adds a unique statement look correc= t. >> > > > > > Thanks for the reply but I do not think you have answered my >> > > > > question. Please formulate a formal rule how to assign modules to >> > > > > non-prefixed identifiers, whether they be in "unique", "must", o= r any> >> > > > > other statement with identifiers. That is what I need to impleme= nt it> >> > > > > properly and I am simply not able to come up with any that would= be >> > > > > consistent and compliant with the specification. >> > > > > > > Interpret the unique argument the same way as an XPath expre= ssion, and >> > > > apply (from 6.4.1): >> > > > > > > o Names without a namespace prefix belong to the same na= mespace as >> > > > the identifier of the current node. Inside a grouping, that >> > > > namespace is affected by where the grouping is used >> > > > > > > So "value" in the unique statement will refer to "value" in = "mod_a" >> > > > when the grouping is used in "mod_a". >> > > > > I see. Okay, this should be possible to implement, thanks. >> > > I was too hasty with the reply, this is not working because of the >> > "unique" in the deviation I have in the example. What is the "current>= node" in that case? I suppose that can only be "mylist2", so the >> > namespace will be that of "mod_b". But this is wrong, the "c" node >> > belongs to "mod_a", so the "unique" in the deviation would be wrong. >>=20 >> Right; I was thinking that since "c" didn't have a prefix, it would >> belong to "mod_a", and thus work as expected. >>=20 >> I think it is ok to solve this by requiring a prefix in this case. > > What you are saying is that you would be fine with the deviation not work= ing with no prefix in the example and stick to the rule of using the curren= t (context) node to get modules for non-prefixed identifiers? > > @Lada You seem to suggest some special handling of paths in deviations (o= r what exactly)? Not really. If we wanted to extend the rule from sec. 6.4.1 that Martin cit= ed to deviations, the only candidate for the "current node" is the root nod= e. On the other hand, sec. 6.4.1 is about XPath context, and the argument of "= unique" contains schema node identifiers, i.e. NOT XPath. > > Neither really seem like a proper solution and, more importantly, interpr= eting "unique" paths (non-prefixed identifiers) according to XPath contradi= cts what I was told those few years back (I will try to find the mailing li= st communication if necessary), which is that for "schema node identifiers"= the current module is the module where the statements are "physically" wri= tten, not that of the current node. > > We keep hitting these problems because the use-cases vary greatly and the= most complex ones were probably not anticipated when writing the specs. St= ill, the code must handle all the use-cases somehow and we have huge proble= ms with that. > > I would appreciate any exact rules that we can agree on. The existing rules in RFC 7950 seem unclear/contradictory. This is in sec. 7.12 on "grouping": Identifiers appearing inside the grouping are resolved relative to the scope in which the grouping is defined, not where it is used. Prefix mappings, type names, grouping names, and extension usage are evaluated in the hierarchy where the "grouping" statement appears. And this is then in sec. 7.13 on "uses": The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, at which point they are bound to the namespace of the current module. Lada > > Michal > >> > > > > /martin >> > > > > > > > > > /martin >> > > > > > > > > Finally, I am asking because I am trying to implement th= is >> > > > > > > > > correctly >> > > > > > > in yanglint. I have also tried to test these examples with p= yang,> > >> > > > > > > > which, however, seems to not have any consistent rules app= lied >> > > > > > > because >> > > > > > > it loads these examples without warnings. No warnings are pr= inted >> > > > > > > even >> > > > > > > if the "unique" in the deviation is changed to "b c", which = is >> > > > > > > definitely wrong since node "b" belongs to "mod_b" and node = "c" >> > > > > > > belongs to "mod_a". >> > > > > > > > Thanks, >> > > > > > > Michal >> > > > > > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-= 7.8.3> > >> > > > > > > > > [2] https://datatracker.ietf.org/doc/html/rfc7950#sectio= n-6.5 >> > > > > > > > _______________________________________________ >> > > > > > > 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 --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 14 05:38: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 6CEB03A0C43 for ; Tue, 14 Dec 2021 05:38:04 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 n32uHu-7GEgX for ; Tue, 14 Dec 2021 05:37:59 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 59CBC3A0C3E for ; Tue, 14 Dec 2021 05:37:59 -0800 (PST) Received: from [192.168.1.116] (213-67-237-150-no99.tbcn.telia.com [213.67.237.150]) by mail.tail-f.com (Postfix) with ESMTPSA id 0C1661AE02BB; Tue, 14 Dec 2021 14:37:53 +0100 (CET) From: Jan Lindblad Message-Id: <820E796B-DC1D-485D-9525-4B2958CBFC8C@tail-f.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_579170C4-BAF7-425A-84D0-FBAF675F015E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 14 Dec 2021 14:37:52 +0100 In-Reply-To: <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> Cc: Andy Bierman , "maqiufang (A)" , "netmod@ietf.org" To: Kent Watsen References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 13:38:05 -0000 --Apple-Mail=_579170C4-BAF7-425A-84D0-FBAF675F015E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kent, all, > Of course, some will point to Section 5.1.3: >=20 > However, MUST always be a valid configuration data tree, > as defined in Section=C2=A08.1 of [RFC7950] = . >=20 > But it has to be obvious that this is a bug. For instance, >=20 > - YANG defines a leaf is of type union { uint8 | variable } > - defines the leaf having value =E2=80=9CMAX_FOOBAR=E2=80=9D= =20 > with a template that defines MAX_FOOBAR=3D1000. > - so, would be syntactically valid but > semantically invalid. I must confess I raised my eyebrows a little when I saw this. Well, I = have often heard server implementors pick some of their least favorite = sentences out of an RFC and say that "this is obviously a bug". Still, = it's quite another thing when something like that is coming from someone = so deeply knowledgeable and immersed in IETF and the WG as Kent.=20 Kent, may I ask that you clarify if you do mean what you said, and if = you do, if that would be a statement from a contributor or chair? In my opinion, if the statement above in section 5.1.3 (and you will = find similar language in 7950) collides with the template example you = gave, may I suggest the possibility that there could be something wrong = with that example rather than the RFCs? /jan --Apple-Mail=_579170C4-BAF7-425A-84D0-FBAF675F015E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kent,= all,





= --Apple-Mail=_579170C4-BAF7-425A-84D0-FBAF675F015E-- From nobody Tue Dec 14 05:49: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 F1DD73A0CC2 for ; Tue, 14 Dec 2021 05:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=cesnet.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 WY-qn9s807_N for ; Tue, 14 Dec 2021 05:49:42 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CE33A0CBF for ; Tue, 14 Dec 2021 05:49:40 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id E94F060068; Tue, 14 Dec 2021 14:49:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1639489775; bh=EsYyRsL4HhpAHxLNZodlVw7MH1z5/CoKE5niWuMFW90=; h=From:In-Reply-To:Date:Cc:To:Subject; b=H7o3YrfZKg+KBWF5KnE7++EkBkckpXn0CebolpqfXko85fU2ns6srJVgY9rhQzQMW pxAMclcQx/ImgnqHD4Jo7W89KWTSlsWcKybOVwLiMWMNGEvp3Le/cfDzr/WrV0Tihh Lk9SrtJph2YTwy8w7GCKMSPKIG+sMNUIp/0ovbSg= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <87lf0nl4lx.fsf@nic.cz> Content-Type: text/plain; charset="utf-8" X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Tue, 14 Dec 2021 14:49:35 +0100 Cc: =?utf-8?q?Martin_Bj=C3=B6rklund?= , netmod@ietf.org To: "Ladislav Lhotka" MIME-Version: 1.0 Message-ID: <782-61b8a100-1d-5ac03300@25969637> User-Agent: SOGoMail 5.2.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] =?utf-8?q?Resolving_schema_node_identifier?= 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, 14 Dec 2021 13:49:47 -0000 > Michal Va=C5=A1ko writes: > > >> Michal Va=C5=A1ko wrote: > >> > > > Michal Va=C5=A1ko wrote: > >> > > > > > Michal Va=C5=A1ko wrote: > >> > > > > > > Hello, > >> > > > > > > > I would like to get some input for a use-case I came= across, which > >> > > > > > > > to> > >> > > > > > > > me does not seem to have any consistent rules that c= an be applied. > >> > > > > > > > module mod=5Fb { > >> > > > > > > namespace "x:example:mod=5Fb"; > >> > > > > > > prefix "mb"; > >> > > > > > > > grouping mylist=5Fwrapper { > >> > > > > > > list mylist { > >> > > > > > > key "name"; > >> > > > > > > unique "value"; > >> > > > > > > leaf name { > >> > > > > > > type string; > >> > > > > > > } > >> > > > > > > leaf value { > >> > > > > > > type uint32; > >> > > > > > > } > >> > > > > > > } > >> > > > > > > } > >> > > > > > > > list mylist2 { > >> > > > > > > key "a"; > >> > > > > > > leaf a { > >> > > > > > > type string; > >> > > > > > > } > >> > > > > > > leaf b { > >> > > > > > > type string; > >> > > > > > > } > >> > > > > > > } > >> > > > > > > } > >> > > > > > > > > module mod=5Fa { > >> > > > > > > namespace "x:example:mod=5Fa"; > >> > > > > > > prefix "ma"; > >> > > > > > > > import mod=5Fb { prefix "mb"; } > >> > > > > > > > container root { > >> > > > > > > uses mb:mylist=5Fwrapper; > >> > > > > > > } > >> > > > > > > > augment /mb:mylist2 { > >> > > > > > > leaf c { > >> > > > > > > type string; > >> > > > > > > } > >> > > > > > > } > >> > > > > > > > deviation /mb:mylist2 { > >> > > > > > > deviate add { > >> > > > > > > unique "mb:b c"; > >> > > > > > > } > >> > > > > > > } > >> > > > > > > } > >> > > > > > > > The focus is on the "unique" statements and how to r= esolve > >> > > > > > > non-prefixed identifiers. RFC 7950 says that the argum= ent is a "list > >> > > > > > > of schema node identifiers"[1], which use "current mod= ule" for > >> > > > > > > non-prefixed identifiers[2]. I have asked on this mail= ing list a few > >> > > > > > > years back what current module means and the answer I = got was the> > > >> > > > > > > > module where the statement is defined. > >> > > > > > > > So let's get to the examples. As they are written, t= he unique in > >> > > > > > > "mylist" should be wrong because the node "value" belo= ngs to the > >> > > > > > > module "mod=5Fa" when the grouping is instantiated the= re, but unique > >> > > > > > > is> > >> > > > > > > defined in the module "mod=5Fb". > >> > > > > > > > But even if we use the other understanding of curren= t module and > >> > > > > > > interpret is as the module of the context node of the = statement > >> > > > > > > (corresponds to the "current()" XPath function), then = the other > >> > > > > > > "unique" in the deviation cannot be resolved. It is re= ferencing node > >> > > > > > > "c", which belongs to the module "mod=5Fa" (added by a= n augment) but > >> > > > > > > the > >> > > > > > > current module would then be "mod=5Fb". > >> > > > > > > > To summarize, if strictly following the specs, the "= unique" in the > >> > > > > > > "mylist" should probably reference "value" with a pref= ix, but that > >> > > > > > > is> > >> > > > > > > not possible because "mod=5Fa" is not even imported an= d it generally > >> > > > > > > does not make sense. But then I cannot think of any co= nsistent rule > >> > > > > > > to > >> > > > > > > successfully resolve both "unique" statements in this = example. Can > >> > > > > > > anyone help me with this, please? > >> > > > > > > > Compare with this: > >> > > > > > > > grouping mylist=5Fwrapper { > >> > > > > > list mylist { > >> > > > > > key "name"; > >> > > > > > unique "value"; > >> > > > > > must "value > 42"; > >> > > > > > leaf name { > >> > > > > > type string; > >> > > > > > } > >> > > > > > leaf value { > >> > > > > > type uint32; > >> > > > > > } > >> > > > > > } > >> > > > > > } > >> > > > > > > > I think the rules for the prefixes in "unique" shoul= d be the same > >> > > > > > > > as > >> > > > > > for "must". So I think that the correct syntax is to no= t use any > >> > > > > > prefix in "unique". > >> > > > > > > > And the deviation that adds a unique statement look = correct. > >> > > > > > Thanks for the reply but I do not think you have answere= d my > >> > > > > question. Please formulate a formal rule how to assign mod= ules to > >> > > > > non-prefixed identifiers, whether they be in "unique", "mu= st", or any> > >> > > > > other statement with identifiers. That is what I need to i= mplement it> > >> > > > > properly and I am simply not able to come up with any that= would be > >> > > > > consistent and compliant with the specification. > >> > > > > > > Interpret the unique argument the same way as an XPath= expression, and > >> > > > apply (from 6.4.1): > >> > > > > > > o Names without a namespace prefix belong to the s= ame namespace as > >> > > > the identifier of the current node. Inside a grouping= , that > >> > > > namespace is affected by where the grouping is used > >> > > > > > > So "value" in the unique statement will refer to "valu= e" in "mod=5Fa" > >> > > > when the grouping is used in "mod=5Fa". > >> > > > > I see. Okay, this should be possible to implement, thanks.= > >> > > I was too hasty with the reply, this is not working because of= the > >> > "unique" in the deviation I have in the example. What is the "cu= rrent> node" in that case? I suppose that can only be "mylist2", so the= > >> > namespace will be that of "mod=5Fb". But this is wrong, the "c" = node > >> > belongs to "mod=5Fa", so the "unique" in the deviation would be = wrong. > >> > >> Right; I was thinking that since "c" didn't have a prefix, it woul= d > >> belong to "mod=5Fa", and thus work as expected. > >> > >> I think it is ok to solve this by requiring a prefix in this case.= > > > > What you are saying is that you would be fine with the deviation no= t working with no prefix in the example and stick to the rule of using = the current (context) node to get modules for non-prefixed identifiers?= > > > > @Lada You seem to suggest some special handling of paths in deviati= ons (or what exactly)? > > Not really. If we wanted to extend the rule from sec. 6.4.1 that Mart= in cited to deviations, the only candidate for the "current node" is th= e root node. > > On the other hand, sec. 6.4.1 is about XPath context, and the argumen= t of "unique" contains schema node identifiers, i.e. NOT XPath. > > > > > Neither really seem like a proper solution and, more importantly, i= nterpreting "unique" paths (non-prefixed identifiers) according to XPat= h contradicts what I was told those few years back (I will try to find = the mailing list communication if necessary), which is that for "schema= node identifiers" the current module is the module where the statement= s are "physically" written, not that of the current node. > > > > We keep hitting these problems because the use-cases vary greatly a= nd the most complex ones were probably not anticipated when writing the= specs. Still, the code must handle all the use-cases somehow and we ha= ve huge problems with that. > > > > I would appreciate any exact rules that we can agree on. > > The existing rules in RFC 7950 seem unclear/contradictory. > > This is in sec. 7.12 on "grouping": > > Identifiers appearing inside the grouping are resolved relative to= > the scope in which the grouping is defined, not where it is used. > Prefix mappings, type names, grouping names, and extension usage > are evaluated in the hierarchy where the "grouping" statement > appears. > > And this is then in sec. 7.13 on "uses": > > The identifiers defined in the grouping are not bound to a namespa= ce > until the contents of the grouping are added to the schema tree vi= a a > "uses" statement that does not appear inside a "grouping" statemen= t, > at which point they are bound to the namespace of the current modu= le. I always understood this in the way that all the explicitly mentioned s= tatements (prefix mappings, type names, grouping names, and extension u= sage) are evaluated in the context of the grouping whereas anything els= e in the context of where the grouping is used. But it is definitely le= ft for interpretation what includes "prefix mappings", I assumed the "s= chema node identifiers" that we have talked about, which are the argume= nts for "unique", "deviation", "augment" and so on. I also assumed it d= oes not include XPath expressions since they have their own rules (argu= ments of statements "path" in leafref, "must", and "when"). But these section are definitely also relevant to the original problem.= Michal > >> > > > > /martin > >> > > > > > > > > > /martin > >> > > > > > > > > Finally, I am asking because I am trying to implem= ent this > >> > > > > > > > > correctly > >> > > > > > > in yanglint. I have also tried to test these examples = with pyang,> > > >> > > > > > > > which, however, seems to not have any consistent rul= es applied > >> > > > > > > because > >> > > > > > > it loads these examples without warnings. No warnings = are printed > >> > > > > > > even > >> > > > > > > if the "unique" in the deviation is changed to "b c", = which is > >> > > > > > > definitely wrong since node "b" belongs to "mod=5Fb" a= nd node "c" > >> > > > > > > belongs to "mod=5Fa". > >> > > > > > > > Thanks, > >> > > > > > > Michal > >> > > > > > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#se= ction-7.8.3> > > >> > > > > > > > > [2] https://datatracker.ietf.org/doc/html/rfc7950#= section-6.5 > >> > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F > >> > > > > > > netmod mailing list > >> > > > > > > netmod@ietf.org > >> > > > > > > https://www.ietf.org/mailman/listinfo/netmod > >> > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F > >> > > netmod mailing list > >> > > netmod@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/netmod > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > 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 Dec 14 06:01: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 58D833A0CD6 for ; Tue, 14 Dec 2021 06:01: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, 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 3ScGLUjDWPb8 for ; Tue, 14 Dec 2021 06:00:58 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D9A253A0CDB for ; Tue, 14 Dec 2021 06:00:57 -0800 (PST) Received: from [192.168.1.116] (213-67-237-150-no99.tbcn.telia.com [213.67.237.150]) by mail.tail-f.com (Postfix) with ESMTPSA id 776021AE02BB; Tue, 14 Dec 2021 15:00:56 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Jan Lindblad In-Reply-To: <0100017db61dcda1-eab8e8d2-350a-4aed-aea0-7b59a8d08a85-000000@email.amazonses.com> Date: Tue, 14 Dec 2021 15:00:56 +0100 Cc: "maqiufang (A)" , "Belotti, Sergio (Nokia - IT/Vimercate)" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <43AEE016-650D-488F-A763-EB64FD6505D3@tail-f.com> References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <0100017db61dcda1-eab8e8d2-350a-4aed-aea0-7b59a8d08a85-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 14:01:02 -0000 Kent, >> Here you are introducing two concepts that the RFCs (6020, 7950, = 8342) are never mentioning: online and offline validation. Then you say = that because the RFCs don't talk about these concepts, the behavior is = undefined. I strongly disagree. The RFCs talk about validation, and = describes the rules for how that happens. These rules always apply, = regardless of online, offline or the phase of the moon. >=20 > Look, specs are very simple: stuff is written down in black and white = and either it=E2=80=99s there or not. In this case, the fact remains = that there is no document I can point to that says offline validation is = a thing. =20 Absolutely. Today the words written down in the specs are only talking = about one kind of validation.=20 Offline validation is not a concept I have been using. It's not used in = the RFCs. If you think this concept has merit, it would be good if you = took the time to define it. And if you also think the RFCs that = currently do not use it, should use it, then by all means suggest = changes. > It is also notable that RFC 8341 say nothing about the fact that = clients effected by NACM may not be able to pass validation (it=E2=80=99s = not even mentioned). That a client with insufficient privileges may have trouble = understanding or controlling a server is no surprise to me. I don't = quite see why you think this observation is relevant for the discussion = about whether a datastore is valid or not? >> If you think the online and offline validation concepts have merit, I = would like to see proper definitions of them, and how you would like to = modify the existing RFCs with respect to these concepts. It might also = be a good idea to update the proposed draft, which currently does not = mention these concepts. >=20 > This is part of the discussion we=E2=80=99re having now. The outcome = of which may trigger clarifications to some RFCs. All fine = suggestions, but replace =E2=80=9Cyou=E2=80=9D with =E2=80=9Cfolks=E2=80=9D= , as it=E2=80=99s not on my shoulders to do any of this. Ok, fair enough. To whom it may concern: Regarding "offline validation" or "online = validation", please note that these concepts are yet undefined in any = RFCs or drafts (as far as I'm aware). If you intend to use these = concepts, please be so kind as to either define or point to definitions = of them. >> The added value and the core essence of YANG is enabling us to reason = about configurations and compute configuration changes without = necessarily asking the server if a configuration is valid by "trial and = error". This is possible because a YANG model is a detailed and = reasonably complete description of the management interface. Introducing = changes to YANG that breaks this basic premise would be dumbing down = YANG, and I can't see the benefit with this change, or how this would be = compatible with YANG 1.0, or 1.1 rules. >=20 > I never said offline validation shouldn=E2=80=99t be possible. = Rather, please know that, NACM aside, my understanding of the goal of = the draft is that offline validation *is* supported...but it entails = clients merging their view of with the server=E2=80=99s = before doing the validation (i.e., alone may not be = enough, see Subject line). Good news is that, since is = effectively static, no new round-trips are incurred. Good to hear. My preference would be that the validation rules already = established in 6020, 7950 and 8342 stay close to what they are. If we = decide to accommodate further use cases, that should be allowed by = clients that flag awareness of extended mechanisms. Old, unaware servers = and clients should be able to continue staying true to their legacy. >>> In the meanwhile, can we discuss the issues around a legacy client = failing an offline validation? In this case, a production deployment = must have 1) deployed devices that support , 2) deployed at = least one client that supports , and 3) decided to let clients = start pushing config using . While in the pre-production = testing phase, it would be quickly discovered that all legacy clients = need to be updated. By the time of going to production, the deployment = should have all the clients updated, so it seems that only the forgotten = (relatively insignificant) clients might have an offline validation of = failure. Is this a fair assessment? >>=20 >> 1) agreed, without devices that support the system datastore, no = problem >> 2,3) well, a "client" in this case could very well be a CLI operator = or other management interface. Even in highly automated networks, CLI = operators are still common >=20 > Sure, but there=E2=80=99s no impact to CLI operators as they=E2=80=99re = effectively getting server-side validation all the time. Just saying = that CLI-ops don=E2=80=99t seem to be effected by any of this, right? Well, I'm not worried about the CLI users getting trouble. I'm worried = that CLI users would cause trouble for automation clients, by for = example referencing something out of the system datastore. The next time = someone does a get-config towards running, it might not be valid any = longer, with the RFCs' definition of valid. Best Regards, /jan From nobody Tue Dec 14 06:53:43 2021 Return-Path: <0100017db96f3f9f-f5f7b212-671d-4626-870c-7d21d4122613-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 3A8303A0D5D for ; Tue, 14 Dec 2021 06:53:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=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 ZxSWbeZqh797 for ; Tue, 14 Dec 2021 06:53:37 -0800 (PST) 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 21AB03A0D64 for ; Tue, 14 Dec 2021 06:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639493615; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=udbUzfBOQOLp9ooJ6a4x92j5iJNfQBxpe/GIwdyrWCI=; b=e60P/yQ8kNbkusrW1gSx0npDAMkVzXqkq57AFe31wAk+evRXCMSpEAlhIcqjqmJM Sr4wOH+f8mo7gfM2yT8+2R5aEIXGYYH71YaXQDfpx/NGrQWGgHIEcHXWDDjV45tbXUq bnSZB5BIcJzgHPs3jmS9T+UjJgcDqsaJ0mn7x6Kc= From: Kent Watsen Message-ID: <0100017db96f3f9f-f5f7b212-671d-4626-870c-7d21d4122613-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CC1C0590-1947-419F-B7AC-AEACF684CCC7" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 14:53:35 +0000 In-Reply-To: <820E796B-DC1D-485D-9525-4B2958CBFC8C@tail-f.com> Cc: Andy Bierman , "maqiufang (A)" , "netmod@ietf.org" To: Jan Lindblad References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <820E796B-DC1D-485D-9525-4B2958CBFC8C@tail-f.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.48.92 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 14:53:42 -0000 --Apple-Mail=_CC1C0590-1947-419F-B7AC-AEACF684CCC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jan, >> Of course, some will point to Section 5.1.3: >>=20 >> However, MUST always be a valid configuration data tree, >> as defined in Section=C2=A08.1 of [RFC7950] = . >>=20 >> But it has to be obvious that this is a bug. For instance, >>=20 >> - YANG defines a leaf is of type union { uint8 | variable } >> - defines the leaf having value =E2=80=9CMAX_FOOBAR=E2=80=9D= =20 >> with a template that defines MAX_FOOBAR=3D1000. >> - so, would be syntactically valid but >> semantically invalid. >=20 > I must confess I raised my eyebrows a little when I saw this. Well, I = have often heard server implementors pick some of their least favorite = sentences out of an RFC and say that "this is obviously a bug". Still, = it's quite another thing when something like that is coming from someone = so deeply knowledgeable and immersed in IETF and the WG as Kent.=20 I apologize if I=E2=80=99ve done or said anything to offend you. = Please, let=E2=80=99s keep the discussion on the level. Regarding raised eyebrows, did you catch that the value =E2=80=9C1000=E2=80= =9D doesn=E2=80=99t fit into a uint8? The point was/is that validation = might miss that error without template expansion. In this case, = pyang/yanglint validation on (unexpanded) would pass, but I = don=E2=80=99t think that we would want to settle for that, right? = Again, it was the intention of the authors that validation is moved to = ; Rob, Juergen, Martin, and I have all affirmed this = understanding recently. I think that the quoted s5.1.3 line above = escaped scrutiny, as well perhaps some text missing in Section 6.1 (to = replace or extend =E2=80=9Crunning=E2=80=9D with =E2=80=9Cintended"). I = recall that the authors were drawing a fine line bridging being = compatible with RFC 7950 and this intention. I think that an Errata on = RFC 8342 may be warranted here, but I=E2=80=99m unsure what it might say = just yet. > Kent, may I ask that you clarify if you do mean what you said, and if = you do, if that would be a statement from a contributor or chair? All my responses on this thread to this point, and in general, unless = explicitly called out with an =E2=80=9Cas co-chair=E2=80=9D designation, = are from me as a contributor. I do try to put a =E2=80=9Cas a = contributor=E2=80=9D on my messages for brevity, but it is easy to = forget sometimes.=20 K. --Apple-Mail=_CC1C0590-1947-419F-B7AC-AEACF684CCC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jan,

Of course, some will point to =
Section 5.1.3:

   However, <running> MUST always =
be a valid configuration data tree,
   as defined in Section 8.1 of [RFC7950].


But it has to be obvious that this is a =
bug.  For instance,

  - YANG defines a leaf is of type union { =
uint8 | variable }
  - <running> defines the leaf having value =
=E2=80=9CMAX_FOOBAR=E2=80=9D 
    with a template that =
defines MAX_FOOBAR=3D1000.
  - so, <running> would be =
syntactically valid but
    semantically =
invalid.

I must confess I raised = my eyebrows a little when I saw this. Well, I have often heard server = implementors pick some of their least favorite sentences out of an RFC = and say that "this is obviously a bug". Still, it's quite another thing = when something like that is coming from someone so deeply knowledgeable = and immersed in IETF and the WG as = Kent. 


Regarding raised = eyebrows, did you catch that the value =E2=80=9C1000=E2=80=9D doesn=E2=80=99= t fit into a uint8?  The point was/is that validation might miss = that error without template expansion.  In this case, = pyang/yanglint validation on (unexpanded) <running> would pass, = but I don=E2=80=99t think that we would want to settle for that, right? =  Again, it was the intention of the authors that validation is = moved to <intended>; Rob, Juergen, Martin, and I have all affirmed = this understanding recently.  I think that the quoted s5.1.3 line = above escaped scrutiny, as well perhaps some text missing in Section 6.1 (to replace or extend = =E2=80=9Crunning=E2=80=9D with =E2=80=9Cintended").  I recall that = the authors were drawing a fine line bridging being compatible with RFC = 7950 and this intention.  I think that an Errata on RFC 8342 may be = warranted here, but I=E2=80=99m unsure what it might say just = yet.


Kent, may I ask that you clarify if you do mean what you = said, and if you do, if that would be a statement from a contributor or = chair?



K.

= --Apple-Mail=_CC1C0590-1947-419F-B7AC-AEACF684CCC7-- From nobody Tue Dec 14 07:31:26 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 60BA43A0DDF for ; Tue, 14 Dec 2021 07:31:24 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 W6BO9FjDLk3V for ; Tue, 14 Dec 2021 07:31:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D554A3A0D64 for ; Tue, 14 Dec 2021 07:31:19 -0800 (PST) Received: from [192.168.1.116] (213-67-237-150-no99.tbcn.telia.com [213.67.237.150]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F11D1AE02BB; Tue, 14 Dec 2021 16:31:15 +0100 (CET) From: Jan Lindblad Message-Id: <14FDF607-D2B5-4FF6-9071-63AB2D1B022A@tail-f.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4CF51AAB-32C2-4C41-AD6D-D578C14E596D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 14 Dec 2021 16:31:14 +0100 In-Reply-To: <0100017db96f3f9f-f5f7b212-671d-4626-870c-7d21d4122613-000000@email.amazonses.com> Cc: Andy Bierman , "maqiufang (A)" , "netmod@ietf.org" To: Kent Watsen References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <820E796B-DC1D-485D-9525-4B2958CBFC8C@tail-f.com> <0100017db96f3f9f-f5f7b212-671d-4626-870c-7d21d4122613-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 15:31:25 -0000 --Apple-Mail=_4CF51AAB-32C2-4C41-AD6D-D578C14E596D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Kent, >>> Of course, some will point to Section 5.1.3: >>>=20 >>> However, MUST always be a valid configuration data = tree, >>> as defined in Section=C2=A08.1 of [RFC7950] = . >>>=20 >>> But it has to be obvious that this is a bug. For instance, >>>=20 >>> - YANG defines a leaf is of type union { uint8 | variable } >>> - defines the leaf having value =E2=80=9CMAX_FOOBAR=E2=80=9D= =20 >>> with a template that defines MAX_FOOBAR=3D1000. >>> - so, would be syntactically valid but >>> semantically invalid. >>=20 >> I must confess I raised my eyebrows a little when I saw this. Well, I = have often heard server implementors pick some of their least favorite = sentences out of an RFC and say that "this is obviously a bug". Still, = it's quite another thing when something like that is coming from someone = so deeply knowledgeable and immersed in IETF and the WG as Kent.=20 >=20 > I apologize if I=E2=80=99ve done or said anything to offend you. = Please, let=E2=80=99s keep the discussion on the level. I'm not offended in any way. It was certainly my intention keep things = perfectly level and impersonal. If that's not how it came through, I'm = truly sorry. > Regarding raised eyebrows, did you catch that the value =E2=80=9C1000=E2= =80=9D doesn=E2=80=99t fit into a uint8? Of course. My raised eyebrow was regarding how you, being both deeply = knowledgeable and chair, could dismiss clear statements in RFCs as = "obvious that this is a bug." The RFCs are documents that we have = agreed. Agreeing is not an easy process, so we should be proud over what = we have. While RFCs may have bugs, holes and shortcomings, I think = treating RFCs with some respect is in order. We don't want to undermine = their authority, or make people believe they can ignore a few rules that = are unpleasant to them ("obviously a bug") and still call themselves = compliant. > The point was/is that validation might miss that error without = template expansion. In this case, pyang/yanglint validation on = (unexpanded) would pass, but I don=E2=80=99t think that we = would want to settle for that, right? Again, it was the intention of = the authors that validation is moved to ; Rob, Juergen, = Martin, and I have all affirmed this understanding recently. I think = that the quoted s5.1.3 line above escaped scrutiny, as well perhaps some = text missing in Section 6.1 (to replace or extend =E2=80=9Crunning=E2=80=9D= with =E2=80=9Cintended"). I recall that the authors were drawing a = fine line bridging being compatible with RFC 7950 and this intention. I = think that an Errata on RFC 8342 may be warranted here, but I=E2=80=99m = unsure what it might say just yet. I agree that your example is at odds with a whole collection of RFCs. = But instead of thinking all the RFCs are in error, my conclusion is that = the example you give is not supported yet. We can work on making = templates usable within the YANG framework, but just as you already = recognized above, it doesn't fit in without further work. >> Kent, may I ask that you clarify if you do mean what you said, and if = you do, if that would be a statement from a contributor or chair? >=20 > All my responses on this thread to this point, and in general, unless = explicitly called out with an =E2=80=9Cas co-chair=E2=80=9D designation, = are from me as a contributor. I do try to put a =E2=80=9Cas a = contributor=E2=80=9D on my messages for brevity, but it is easy to = forget sometimes.=20 Thanks Kent. I do appreciate all you do for the WG. /jan --Apple-Mail=_4CF51AAB-32C2-4C41-AD6D-D578C14E596D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Kent,

Of course, some will point to =
Section 5.1.3:

   However, <running> MUST always =
be a valid configuration data tree,
   as defined in Section 8.1 of [RFC7950].


But it has to be obvious that this is a =
bug.  For instance,

  - YANG defines a leaf is of type union { =
uint8 | variable }
  - <running> defines the leaf having value =
=E2=80=9CMAX_FOOBAR=E2=80=9D 
    with a template that =
defines MAX_FOOBAR=3D1000.
  - so, <running> would be =
syntactically valid but
    semantically =
invalid.

I must confess I raised = my eyebrows a little when I saw this. Well, I have often heard server = implementors pick some of their least favorite sentences out of an RFC = and say that "this is obviously a bug". Still, it's quite another thing = when something like that is coming from someone so deeply knowledgeable = and immersed in IETF and the WG as = Kent. 

I = apologize if I=E2=80=99ve done or said anything to offend you. =  Please, let=E2=80=99s keep the discussion on the = level.


Regarding raised eyebrows, did you catch that the value = =E2=80=9C1000=E2=80=9D doesn=E2=80=99t fit into a = uint8?


 The point was/is that validation might miss that error = without template expansion.  In this case, pyang/yanglint = validation on (unexpanded) <running> would pass, but I don=E2=80=99t= think that we would want to settle for that, right?  Again, it was = the intention of the authors that validation is moved to = <intended>; Rob, Juergen, Martin, and I have all affirmed this = understanding recently.  I think that the quoted s5.1.3 line above = escaped scrutiny, as well perhaps some text missing in = Section 6.1 (to replace or extend =E2=80=9Crunning=E2=80=9D with = =E2=80=9Cintended").  I recall that the authors were drawing a fine = line bridging being compatible with RFC 7950 and this intention.  I = think that an Errata on RFC 8342 may be warranted here, but I=E2=80=99m = unsure what it might say just = yet.


Kent, may I ask that you clarify if you do = mean what you said, and if you do, if that would be a statement from a = contributor or chair?

All my responses on this = thread to this point, and in general, unless explicitly called out with = an =E2=80=9Cas co-chair=E2=80=9D designation, are from me as a = contributor.  I do try to put a =E2=80=9Cas a contributor=E2=80=9D = on my messages for brevity, but it is easy to forget = sometimes. 



= --Apple-Mail=_4CF51AAB-32C2-4C41-AD6D-D578C14E596D-- From nobody Tue Dec 14 07:48:50 2021 Return-Path: <0100017db9a1b326-435aaca2-ed95-44fb-80e3-d00056ab3f07-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 73E543A059F for ; Tue, 14 Dec 2021 07:48:48 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 tc0eZdrBnOK9 for ; Tue, 14 Dec 2021 07:48:43 -0800 (PST) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E423A03C9 for ; Tue, 14 Dec 2021 07:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639496922; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=8+BNidZ9Rlcw4MPjLWsL6Y53GvDIjKIZUvOu7YwSYhY=; b=CC/CHnYyuKVw03G/v9ykq+QLIRaCkQ0TmRGLH29itJ7kzQ3H6QaChtB61k6TCTyx MJ43BA7hzoS/baG/L0b/vz078FWIq1MK9VVmp/Z+lqpk4vkZFPf3rZpxVF3K+fv+Goh yLy5KyTbEkTL7WrybWG7KKWiF+XD++KlmAhS8DGg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: <43AEE016-650D-488F-A763-EB64FD6505D3@tail-f.com> Date: Tue, 14 Dec 2021 15:48:42 +0000 Cc: "maqiufang (A)" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017db9a1b326-435aaca2-ed95-44fb-80e3-d00056ab3f07-000000@email.amazonses.com> References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <0100017db61dcda1-eab8e8d2-350a-4aed-aea0-7b59a8d08a85-000000@email.amazonses.com> <43AEE016-650D-488F-A763-EB64FD6505D3@tail-f.com> To: Jan Lindblad X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.48.94 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 15:48:49 -0000 Hi Jan, >> It is also notable that RFC 8341 say nothing about the fact that = clients effected by NACM may not be able to pass validation (it=E2=80=99s = not even mentioned). >=20 > That a client with insufficient privileges may have trouble = understanding or controlling a server is no surprise to me. I don't = quite see why you think this observation is relevant for the discussion = about whether a datastore is valid or not? It=E2=80=99s related to if offline validation can succeed or not. = Effectively, all but the "recovery session=E2=80=9D clients will not be = able to offline-validate an update to prior to pushing config = to the server. That RFC 8341 doesn=E2=80=99t even mention this fact = suggests that =E2=80=9Cvalidation=E2=80=9D is a concept that only = manifests in servers. Just pointing to evidence of precedence is all. Of course, I strongly support client-validation prior to push. My = recommendation is that clients, when interacting with an NMDA-server, = learn how to =E2=80=9Ccook=E2=80=9D and validate that instead = of just . The question is what to do about legacy clients? =20 First, we need to discuss what an =E2=80=9Caware=E2=80=9D (i.e., not = =E2=80=9Clegacy=E2=80=9D) client is. It seems that =E2=80=9Cawareness" = would have to be more than just understanding that exists; = the client would also have to understand each =E2=80=9Ccooking=E2=80=9D = step (pruning inactive nodes, expanding templates, merging system nodes, = etc.) the server supports. There would need to be a client- = compatibility check such that, if the client doesn=E2=80=99t understand = all of the steps, then it must NOT proceed (aside: this reminds me of = the =E2=80=9Ccritical=E2=80=9D extension that Lada and I discussed = before). Actually, we might consider reversing the handshake and = instead have the client present to the server a list of all the = =E2=80=9Ccritical=E2=80=9D things it understands and for the server to = effectively drop the client if it=E2=80=99s missing anything, since = clients cannot predict what new critical things may arise, there could = be no false-positives. Warning, we=E2=80=99re deep into NETCONF-next = and RESTCONF-next territory here. It might turn out that the server, once upgraded to support =E2=80=9Cnext=E2= =80=9D stuff, can ONLY interact with next-clients. If so, there would = be never be a mix of legacy and not-legacy clients, and thus this entire = hybrid-client compatibility concern disappears. K. // contributor From nobody Tue Dec 14 08:20: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 49A943A0E31 for ; Tue, 14 Dec 2021 08:20:14 -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=unavailable 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 L117TqqP5CxT for ; Tue, 14 Dec 2021 08:20:09 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30049.outbound.protection.outlook.com [40.107.3.49]) (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 A0CCA3A0E2D for ; Tue, 14 Dec 2021 08:20:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KxUg6UlaEARtZIzW8psYN14pPCLQau9dAZELQTuzsTOcpDFLhvZURpT9zweTzTo/LT5yjyj0Bzg5L7eZVJ3/7YXPNBlhpJeZhHNyvhQ3z6XLrX8wuvCmpBjRbZ1rg0O4w7xYgyhs1cH3K35xKdtwgGWH+npc/S4cNM+pmcZiykfLpFGZtLgRAYn/w5NFw/btT/Gklb+JkvN58tnSKCyaPcLNEj65fjm3kidQCTXDvj0nXVe0Xns3lzXWf8bdmNwyJWOxkWjibJTWmIex9DaeVZSKuqz9iWISUeY6E3j6VK/L/2CqYb5uQVGe1SKm901cNzxWevXidHqzpD6uzWPhmg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=u2YzBAysKrSg49CCeJYoZKjO3D0V31IIQNCTK84rd5Q=; b=bqta/eJboyxPbvfHcOJ6dxf3tw+JbeUrvG1fFJ/q9FSjzCpBQS8c5Lttj9rlBLj/im8zOjlKAXOPe5XevmnwTgQXc82gjUeCh89XlIh7RLNO5KVl6sb0bws+XEzPwONEG0ATB2jEt4eULvFq267KjoaO0JhewsssSGC/6HaJxQMBY9EUL32STJqswZU87m+f8kGvpHDz8fh9YLJesb07JD1bp9p+FLyhWBbdHP0oXghrJhn6HjLSCN69ySSCoXKyqopmM7IVIdSVZOlUQc2HUt3b2WJpsfUKQ94U/zLZUyKbKsSdiINjp3U8WufGgZw1W+wc8AsG19HFgc5N10ALaA== 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=u2YzBAysKrSg49CCeJYoZKjO3D0V31IIQNCTK84rd5Q=; b=tyObuOxsVFj+xqWILNZq0X0LsfIQ2t3USddyQ73W4HuAdUHfCbnTfHBNxG7T5t59Hz9JGScNMD51h8Te0naYbvo5uBggUabmSPBTxJ+DixFT6E5XOFbAbuYHZN7oo+oermBmyBEroqdG5LdCK5wAmGoDrs7c2vYtg7vSQWNIRqY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1555.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3b6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.16; Tue, 14 Dec 2021 16:20:03 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8%3]) with mapi id 15.20.4778.018; Tue, 14 Dec 2021 16:20:03 +0000 Date: Tue, 14 Dec 2021 17:20:02 +0100 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Martin =?utf-8?Q?Bj=C3=B6rklund?= Cc: kent+ietf@watsen.net, maqiufang1=40huawei.com@dmarc.ietf.org, netmod@ietf.org Message-ID: <20211214162002.fwhuhe4cemyp5osy@anna> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin =?utf-8?Q?Bj=C3=B6rklund?= , kent+ietf@watsen.net, maqiufang1=40huawei.com@dmarc.ietf.org, netmod@ietf.org References: <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <20211214.131417.1201606442961003687.id@4668.se> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211214.131417.1201606442961003687.id@4668.se> X-ClientProxiedBy: AM3PR05CA0098.eurprd05.prod.outlook.com (2603:10a6:207:1::24) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 37ccde65-dc96-41cc-67b7-08d9bf1d9534 X-MS-TrafficTypeDiagnostic: AM9P190MB1555:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZKFpXjqUg4LOsVYWcongE0RbISgBQeiOxPL03ZnlJU1rF9C+pJIzKouYhOwSjQYxxsAg1/BuL5pButEVQFaHHUOiwks/BTiOmj6v+mBcVNI7r1VxVQERF7krVnczDQkHyDhRt8hVV3jE6iedc9CgPaSiNcnAKEQSLgLs6HxPKRNS8GQ6kazLgY2MbnP1iOdPAfJfs89pv3j5nMU9j3dHiSlQYn+1Wh+gTmByePDk3uuU5enjzvlEhuBbwTVC7bEmU9+bg7hI7gn7ifjvkuAYn062JEpWBxdjqzVcOhOKq/LDf20ObO5LAHv/Ix4Jci7IGqlaHiLLk2zgum3IuUaUiL1T4atdyNgyfibi76/YUfuOkDULNaNNg//Lagit5+ubwZXe/wf5FS9TpHDlzuOcD6aOFH8DxjegwO+ALRPFSvwCJy/s06HScrwn6y2XkQcoU1qBr0uQzF+W4puRdlr3nrrGzwC8WfT+DB3OtHqlJfpG5VFFXv4MGG3ws5JpdpWe3+K/d2anbjJRD+v+/E4jqfTNi/Fsa+rlwfkZZJjk+QFsWGxiEx8kpjEQd82VfeJ4Oy7WGbjeOlsz1zRbIen3eBIptV1qvU8Ctx/I3eg9uBLd/Yc4Zl8MxD0iqnsMiMik+7dbHJG5TLKR/sqWWmv7z8BfFaQES29wXguT+c2VZ3K7Mnxh9FLrKYsbTgOScvkFXHNVfV3BwNvNOhpefElASXb546MCbPmNrEPSKILf3yNSAXz4MVDWbyu2wHTeXJumxcAeI1hEA0eC3ZFUYtPxb16DtSPxi86dArygfGTEpHk= 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:(7916004)(366004)(40140700001)(66556008)(66946007)(26005)(4744005)(1076003)(5660300002)(38100700002)(33716001)(85182001)(38350700002)(2906002)(6506007)(186003)(66476007)(9686003)(8676002)(4326008)(52116002)(3450700001)(6512007)(86362001)(85202003)(8936002)(498600001)(6486002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?KzNyWmcxYzlPU3dMeVZXcWppZHFZMFNFOVNhWEdNYXdkYm9JaGgwNFlkdGh1?= =?utf-8?B?bFB1MFZKVjJocXkxL1ZiaVI3RmlXVTBLYXZDb2RHZ3VyZnZEbGg5dE5XQ2x5?= =?utf-8?B?Z2VCOGp5WFJjN09CalpPZHRXT25ja0RteUtmQW9kaXdZWlJoclJmbkc5djVW?= =?utf-8?B?VVh4dmZuaXJVTjNGU2pjT1JMZVJKOWtpckQxTGZjZ1J6ODFIYnM2R3JrOVFh?= =?utf-8?B?aGw1L3AvanBvczZSNFA4dU0yR2RIYzZmTzRXUURXR1JmMmxZbTd2akZyMk92?= =?utf-8?B?akpZVmdLVWZ6VXR1ZWg5ejVhdGYyNEZTWThPcWtZZEkyeGJnWGtBYUhUbzhZ?= =?utf-8?B?Ti9LbkN3ZEFQV0FZQzNYWW5YYjMvVExpVTNrRm95b3ZSb3BYT1Jza21oTnc4?= =?utf-8?B?VWhkUG9JR2lMMzlSOEhBb1ZtNWRkc2RVdnNwSmlSZVhBRDcxMTlJM1V3c1d5?= =?utf-8?B?eXFUUDlhKzZxU0NyK0pGdVFFNnFqSmQ4cUdiTGpPQk44Nm9BSWowZm9NYkhw?= =?utf-8?B?dTZUSHltWkVwV3FvVnUyMUZSYS9tM3UweXo5djUwS05sVkJCK1hxeFAxTTY4?= =?utf-8?B?Wlczc1pWUi9KVjBLYkJleFhnNGdVaUxBUHd5blFFZXJ6RjVidXpHUkZKOVE2?= =?utf-8?B?VFI2UWF1ajE4VWNuWXluMkJORE1Ob3ZFYUF1MDZkZjh4WUZEZnk1MVF2OE5q?= =?utf-8?B?c2hsYjNrZCtQNElTTCt6SG4vbmtDQTg3VjNKZXhUZlkrZjV2UnFIVkJrUXhE?= =?utf-8?B?MEszb3FjUXE0QXlBWEZvdjhMYTlkeStSTzZBMGNsZnNnTC9zQ2pMMk4vVlBH?= =?utf-8?B?ZVhGa0RSUTlNT25wdmdJeDE2Wk9ud3VQYVJpczlEZ1YyN24wK2liWHgvaTlW?= =?utf-8?B?cnl5QnduN3M4dkQ1cERjTjUvYS9TVE95aVdVWDBmempvNDBZdDRFa0UvUnBT?= =?utf-8?B?OXV6QmhMVS9UWEpUYml4TytzQVM5a243azRiSGdaMUJyczIvMjRpeTEzVXpo?= =?utf-8?B?MjZpeXNFb0VheHZrNFYwZXdpekxEMmRPYTZ1Ujkyd2ZYaHhWNTlNL3Zxd3pC?= =?utf-8?B?T29qV2ZXWnRRVk1XcnowU1JwS0I4aUl2N2NKSkNqeW9tdEJXSXByUkVqR3hv?= =?utf-8?B?ZHVncENjTmgybFJKUmlma2JkK0puSUZaeVViZkZQYlFNckNmWW5ydDB3b3NE?= =?utf-8?B?UzdzNlNDRzBYMmw1TStscDJ1SDhLRlhEQ2NBVER0TXBSWlV6RE45K1dKN2g1?= =?utf-8?B?VXc1ZVdlYWtjWXNIVkF6N3IrSUM1alVONTRNbVM1RzI0QVlZSDlSbldLOFA3?= =?utf-8?B?UUlhUVR3RS9ybjcva1l3VDUxWWExRFBxeTBkenk1N1JuS0tWR2pEcUZhWkdt?= =?utf-8?B?Qzg0NUQvQmFlVlh2MnBrdFRhWUFiaFVBZGFkblhwQ0tHbVBrQ3o5VHR6S1ds?= =?utf-8?B?VWc2dy9LQjQ4Ymdkdk4yTGl2bHBkZUNFV1RzN3V6K1hodjN3d0J6cEZlNzVE?= =?utf-8?B?QkR1NEVqVXRFNWM4dXhhVE5mbE1DeFVKSXlnRGFidnFSTlM5OFlnZDRZUHZh?= =?utf-8?B?ZUxTQk8vWHRuTFFDK0YxeGRMQmxtc1gxMmhIOVN1SU8rb2tJSmtldml0cG9X?= =?utf-8?B?RDBuenltK0FRSXpGNmp6bXJxK0t6bWtCTFpUb3ZERXJOdlJKTFM4ZmxENHV5?= =?utf-8?B?RVpsUkRUbHdzR0haRWkvLzJjZ2pzNmY0ZFNGVnVDcTR3NHJBKzRYQ1prd1I3?= =?utf-8?B?ZFdvTmpvMkh3REtzOEdHd3hFS3YzVEFQMTQ1T1c4ZmN6Y0tyWVU5LzR5S2dM?= =?utf-8?B?ekZqelRCd1YyWUxSZjdHa3ZFbVZlZWl3bWQrbjllcCt1MUpicEF2Wm5CY3hD?= =?utf-8?B?SkpSK2Jrc0Jrekt6b1lrOGs1QUtmOHNMRE5OVzFCSWRwVnJxNkl6RlpuUGxa?= =?utf-8?B?QVN2TDk4TDgvMmh4akdNYStBM1RKS2JtL3NBUVdldWhNRnlsQ3hMemJoSkFi?= =?utf-8?B?SWwwOXRQU1VmaVZjOXUyZjdpYzhyaExBRWxnUVI0d0ZQVFpOcDc5WDlzeHZC?= =?utf-8?B?VDRyTk5aVUxrZHNQOGFzR0s3dVZLTEIxTWVmekt5QmI1OS9YeGM5ZDdEakIv?= =?utf-8?B?U05scEswVWM5QjBwWXE4ajUwVU9SYUZ2bnYrNVVpUkhkRzJBMW0wemNScldK?= =?utf-8?B?aExiOVB3bkd3U3pSK25QNXZNMk1aZFNRKzdqRTVUT3VsOWNKT2grcmVBR2Y1?= =?utf-8?Q?91XPrrWXwC3iieZPy846LNl/e5kuOLlmaUajsIxkm8=3D?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 37ccde65-dc96-41cc-67b7-08d9bf1d9534 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2021 16:20:02.9238 (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: /84ay8+JqAaP1bJNxzQkv/wNRE8fvNHuI3jpgJdOANted0vUQw4sbYmaLnDFCIkmkFrX3JoNBsPgQcTMOS5W6rPHJzJwaEJVN4EKb6owX2g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1555 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 16:20:14 -0000 On Tue, Dec 14, 2021 at 01:14:17PM +0100, Martin Björklund wrote: > > Right, and in both cases, the idea was that contains all > data needed for the transformation into . So a client that > wants to do "offline" validation would need the data + the > transformation algorithms. But no additional data. > Having to know proprietary transformation algorithms really kills the idea of interoperable offline validation. It does not really get any worse if transformation algorithms merge in additional definitions. /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 Tue Dec 14 09:10:46 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 CDB523A0E8A for ; Tue, 14 Dec 2021 09:10:44 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 dD9737X83D4p for ; Tue, 14 Dec 2021 09:10:38 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AFF043A0E8F for ; Tue, 14 Dec 2021 09:10:38 -0800 (PST) Received: from [192.168.1.116] (213-67-237-150-no99.tbcn.telia.com [213.67.237.150]) by mail.tail-f.com (Postfix) with ESMTPSA id F14FC1AE02BB; Tue, 14 Dec 2021 18:10:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Jan Lindblad In-Reply-To: <0100017db9a1b326-435aaca2-ed95-44fb-80e3-d00056ab3f07-000000@email.amazonses.com> Date: Tue, 14 Dec 2021 18:10:36 +0100 Cc: "maqiufang (A)" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <531EFE43-2B41-4EC8-8FAD-18B1AD4E1477@tail-f.com> References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <0100017db61dcda1-eab8e8d2-350a-4aed-aea0-7b59a8d08a85-000000@email.amazonses.com> <43AEE016-650D-488F-A763-EB64FD6505D3@tail-f.com> <0100017db9a1b326-435aaca2-ed95-44fb-80e3-d00056ab3f07-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 17:10:45 -0000 Kent, all, >>> It is also notable that RFC 8341 say nothing about the fact that = clients effected by NACM may not be able to pass validation (it=E2=80=99s = not even mentioned). >>=20 >> That a client with insufficient privileges may have trouble = understanding or controlling a server is no surprise to me. I don't = quite see why you think this observation is relevant for the discussion = about whether a datastore is valid or not? >=20 > It=E2=80=99s related to if offline validation can succeed or not. = Effectively, all but the "recovery session=E2=80=9D clients will not be = able to offline-validate an update to prior to pushing config = to the server. I'm not sure why you say so. In my field experience, NACM is seldom, if = ever, an issue for validation. Clients may have a full or partial view = of the server, but even when partial, I can't recall seeing a case where = that subset has been broken from a validity standpoint. Whoever is = responsible for the deployment makes sure the client sees what it needs = to see, and that that in itself is a consistent, valid (subset of) = running. > That RFC 8341 doesn=E2=80=99t even mention this fact suggests that = =E2=80=9Cvalidation=E2=80=9D is a concept that only manifests in = servers. Just pointing to evidence of precedence is all. I disagree :-) I don't think this is something we have agreed, and I = don't see the point with this stance. In what way is the world a better = place if we take this "suggestion" seriously? > Of course, I strongly support client-validation prior to push. My = recommendation is that clients, when interacting with an NMDA-server, = learn how to =E2=80=9Ccook=E2=80=9D and validate that instead = of just . Great. While it sounds very nice to be able to validate both running and = intended properly, establishing agreement on one particular industry = wide recipe for how to cook running into intended sounds hard, and at = the very least some way off. Even if we would agree on the cooking, I = still think running needs to remain valid(*). Running is the interface = that clients can interact with, and they should have a clear definition = of what the contract looks like without spending an hour in the kitchen. *) Validity, as defined today, concerns running. It does not involve = resolving templates etc. While intended should also be validated, as = mentioned in 8342, there are no clear rules for how that validation = should happen. Clearly it would be possible for a client to come up with = a config that is valid in running, but gibberish in intended. The server = is, already today, free to reject such a config. That this final part of = the validation cannot happen in running is no argument for not = validating running, and allowing running to violate the YANG constraints = defined for it. > The question is what to do about legacy clients? =20 >=20 > First, we need to discuss what an =E2=80=9Caware=E2=80=9D (i.e., not = =E2=80=9Clegacy=E2=80=9D) client is. It seems that =E2=80=9Cawareness" = would have to be more than just understanding that exists; = the client would also have to understand each =E2=80=9Ccooking=E2=80=9D = step (pruning inactive nodes, expanding templates, merging system nodes, = etc.) the server supports. There would need to be a client- = compatibility check such that, if the client doesn=E2=80=99t understand = all of the steps, then it must NOT proceed (aside: this reminds me of = the =E2=80=9Ccritical=E2=80=9D extension that Lada and I discussed = before). Actually, we might consider reversing the handshake and = instead have the client present to the server a list of all the = =E2=80=9Ccritical=E2=80=9D things it understands and for the server to = effectively drop the client if it=E2=80=99s missing anything, since = clients cannot predict what new critical things may arise, there could = be no false-positives. Warning, we=E2=80=99re deep into NETCONF-next = and RESTCONF-next territory here. Yes, if we agree to let legacy clients and servers behave as specified = in the RFCs, we could come up with very creative things for "aware" = systems. Some of that might be in *-next territory, but much of it could = also happen today, as long as we have mutual consent from the = participants. > It might turn out that the server, once upgraded to support =E2=80=9Cnex= t=E2=80=9D stuff, can ONLY interact with next-clients. If so, there = would be never be a mix of legacy and not-legacy clients, and thus this = entire hybrid-client compatibility concern disappears. Even if I think the industry usually goes for evolution rather than = revolution, I'm fine with that. As long as we get some value return for = the work, and it doesn't break what's out there already, it's worth = discussing. /jan From nobody Tue Dec 14 11:43:56 2021 Return-Path: <0100017dba78eea9-e62c4e7a-dca7-4a6a-b231-e4924c07ec14-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 4BB933A0827 for ; Tue, 14 Dec 2021 11:43:54 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ywPZebQeB-QC for ; Tue, 14 Dec 2021 11:43:49 -0800 (PST) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062033A07A0 for ; Tue, 14 Dec 2021 11:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639511028; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=PNr21UEX9VONu4c4EcFTScsTzVv2Ov9Yo7I6RhO5GEk=; b=Ajoc6+zisOl83BJNLOIuQCLONiKy6E3lqHqNoFZ4zsrUZQFWLfX566i4nR0Nj2CZ yeeMgWfq24GvMDlAP5LM9Y4aL37byoXc25bgBBZLyjyCunaC+hpi0pYYHSHUikyYcnt njRLq38kA95VsnJCCmlvHtXug4cI1K2lKnB2SPlk= From: Kent Watsen Message-ID: <0100017dba78eea9-e62c4e7a-dca7-4a6a-b231-e4924c07ec14-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AACAFF17-0F4E-4DD7-BCA4-81B4CE0D14CE" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 14 Dec 2021 19:43:47 +0000 In-Reply-To: <20211214162002.fwhuhe4cemyp5osy@anna> Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "maqiufang (A)" , "netmod@ietf.org" To: Juergen Schoenwaelder References: <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <20211214.131417.1201606442961003687.id@4668.se> <20211214162002.fwhuhe4cemyp5osy@anna> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.14-54.240.48.110 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 19:43:55 -0000 --Apple-Mail=_AACAFF17-0F4E-4DD7-BCA4-81B4CE0D14CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Right, and in both cases, the idea was that contains all >> data needed for the transformation into . So a client that >> wants to do "offline" validation would need the data + the >> transformation algorithms. But no additional data. >>=20 >=20 > Having to know proprietary transformation algorithms really kills the > idea of interoperable offline validation. It does not really get any > worse if transformation algorithms merge in additional definitions. Of the three transform algs under discussion (pruning inactive, merging = system, and expanding templates), only the last may be proprietary and, = even then, nothing is stopping IETF from standardizing one or a few well = known templating mechanisms. K. --Apple-Mail=_AACAFF17-0F4E-4DD7-BCA4-81B4CE0D14CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Right, = and in both cases, the idea was that <running> contains all
data needed for the transformation into <intended>. =  So a client that
wants to do "offline" validation = would need the data + the
transformation algorithms. =  But no additional data.


Having to know proprietary transformation algorithms really = kills the
idea of = interoperable offline validation. It does not really get any
worse if transformation = algorithms merge in additional definitions.


Of the three transform = algs under discussion (pruning inactive, merging system, and expanding = templates), only the last may be proprietary and, even then, nothing is = stopping IETF from standardizing one or a few well known templating = mechanisms.

K.

= --Apple-Mail=_AACAFF17-0F4E-4DD7-BCA4-81B4CE0D14CE-- From nobody Tue Dec 14 14:29: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 D3E8C3A0AA6 for ; Tue, 14 Dec 2021 14:29:12 -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, 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=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 0LSv5spifONW for ; Tue, 14 Dec 2021 14:29:08 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20609.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::609]) (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 5912E3A0A00 for ; Tue, 14 Dec 2021 14:29:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VRrrbG1KSuD5YXmKxkA1ACoqNZinGD4QLTsA/Wy3ZOBVZnUoAJYK8RgAVTK2SlylTx2lpVK8UIHN6RKIG3WApTakmVOjqt1fX5nfcOifvFgIA83zUgQkMieFXf0Vb5g3z3I/uzhL5ktrV2GhNzq6xwnkRWxyefROMxtlBQGvXZ0uBB/G9K/UhbyuU4WYE1z96HtcVtSy0kgLwZKRH4bBPFqmBR02IgzaxGdAR9mXzmFPkabOzRgzAv8rFIMTF4eCmzpTSFGRfBa5sGuREtyI8zsnksuk09koUDo/sjrcxnqvwMllHo0hPRiuCGRlX6KlGdFYQypsEs2N+3OJAElzrQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yLl6Dv9lUIlUCsd6wHwUT4JOolDhezyxNDNOxmqajUY=; b=DqYMWjD5gnd2mzzTSfdc86mhYcPnu7FYcvLW6HW5ojCz6IPwcYAA7v+WDciQR9Joi7+/JpNPOaz+7xNaJh6qssxoGOgXfc8/bbtJJFmr8NTOt1+T8TzGx9OslsOwJL/0yy+qgU1l8BYQxNGX4RYOkiWkR+DCZJ/9E4k7AqdsENJcZOXoOXe8H06NaMd61Mh5f1GQVFU5in6jzG/ju34tMKVOakqsILd5VMzStSiefc1nEXSRsXHPDiG1WktXQtDV7Tb1XpffYy/65Q/u3VCnidkNCWqdZpTrv9fiBtYCpBj/MFfFP+vyowxSZM+BEiAsvIopYznEpoCr7FyXpZe0xw== 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=yLl6Dv9lUIlUCsd6wHwUT4JOolDhezyxNDNOxmqajUY=; b=Dch8WP+LC3RG2U4ggRxdqfJ8cglCtJy1lD1rXI9K//rDd3pp/EUPzwQKogG+jql3efU56JKi9zxFM/xwr5vpCQXt6eK/8FOVcPoo2McrBfYH2bIE/WQ8U9ITCd5yFbWgZc0dBUYIYOV7GJ431+3kDRlI4ndkIxEzdcTW0BZjnYQ= Authentication-Results: dkim=none (message not signed) header.d=none;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.4778.12; Tue, 14 Dec 2021 22:29:02 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8%3]) with mapi id 15.20.4778.018; Tue, 14 Dec 2021 22:29:01 +0000 Date: Tue, 14 Dec 2021 23:29:00 +0100 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Kent Watsen Cc: Martin =?utf-8?Q?Bj=C3=B6rklund?= , "maqiufang (A)" , "netmod@ietf.org" Message-ID: <20211214222900.xhiiqv7y6m4vhezf@anna> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Martin =?utf-8?Q?Bj=C3=B6rklund?= , "maqiufang (A)" , "netmod@ietf.org" References: <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <20211214.131417.1201606442961003687.id@4668.se> <20211214162002.fwhuhe4cemyp5osy@anna> <0100017dba78eea9-e62c4e7a-dca7-4a6a-b231-e4924c07ec14-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0100017dba78eea9-e62c4e7a-dca7-4a6a-b231-e4924c07ec14-000000@email.amazonses.com> X-ClientProxiedBy: AM4PR0101CA0073.eurprd01.prod.exchangelabs.com (2603:10a6:200:41::41) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bb630fa3-9efa-4d04-3cba-08d9bf5120fb X-MS-TrafficTypeDiagnostic: AM9P190MB1346:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0pmghTcL66kGcMkT8lExfZDN0pBFXRTkPLIjf+1lcc1NBPzrV2oRYCKnSh5NLh1T0JEEitJ3Ljgk+yeclSBGEa65BbCsClg6pB+8WqBCixFvDcoN3XR1lvHW24rTrm3OTAgXWJMlMgfZsE2XXVcLpIDnr7nBYWYdNp+aMEklTpUj6MRW24UNlK1eaV2OeigmjKA2Dis1dvpRQMNnH3iftPyc4FQqQmwefYqTO1MSY+Q2vskqpq1cPi2cdf3PZhbxUFwL7vkHiKgiWIMwJApDkHlzDSfbmftJYJrrHrhNb494uZIx/xL0ND8VYqp/B9xM31MyJlNzbEghfzm1/O0ieqawtz+b//VxHTuzH8Sut5tzx/qtznkQWVpDEE511cjLnqU62dXZEuuLVThaf5dC/EsBw6hny6z4OqmCKWqqbRpxv1ANTocTRoZ4xLbzXUdZkr2yIuLjYsaNk/3m4IVnBdEWYPmbmOvrtnLtfLq+uLo8rrvIhxdlHmId6wipX3DzuK/Q8T3rgl99tnwMgR10v+AdURDevBmCdN2nj/dZ222U2OCKWEFrvh7TW5moPWFUH/zTbHvy6RawQOO8/F+Jtj9mhgtocUX/fz/WdgP48gvwGO15UAqgK1o1TzYddHKorrGx+dHd52ai0bsK/nkgc7daIcv4vbBxLJ7EU3BiUA4K+btm646zlzjcAMLp6o84id/TR/mtFg+jLXUVa0FKdb3WX+N7dgantQQjOvQR0UZLHlE8/0AGDwSAqAAW1e/w5IEU7Ydpsi8AkrKxubnctUWbXwS7b6Ql1Vl6tDKh/Ro= 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:(7916004)(366004)(9686003)(8676002)(8936002)(40140700001)(52116002)(6512007)(786003)(186003)(1076003)(4326008)(66946007)(85182001)(5660300002)(508600001)(38350700002)(54906003)(38100700002)(316002)(86362001)(6486002)(85202003)(3450700001)(26005)(66476007)(83380400001)(33716001)(66556008)(2906002)(6506007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VFRhOEQ3Tml1SzhJRnlBZGN5eWxweDdxdVRaSEQ1Mi9nK3krS01QcDJGMWpj?= =?utf-8?B?M09sakRvN3pnSDdJdmRUaS9ENTV5VkRMWDYxeHpId1htYXpqalI0QW9ONW84?= =?utf-8?B?R3ZwVkRQZmNkc2h4cXMyT1lieEQ5eEpUc1JZRDFmZTkrTHI2R1lRVnI4cnVR?= =?utf-8?B?WERXR3grSjBLOWk4WVV3QjA1cnRlQnM2VDV3STVLQmNmTEI4Rk41UTcrbTNN?= =?utf-8?B?cWg5Z2F0YXdDKzhZbGdPcDVTV0FGQ0FOdHNTK3VXdElnU1dCVnRjMCtnak1K?= =?utf-8?B?YVU0MDZ4M3V3MjZBWmlBQ2QwQTl1NzhkQk9maUtVcktqY1YzWml3bXIwcm1K?= =?utf-8?B?bFArdUIvY2Y2RmpHaDJzeVZpVEZVL09QaGFQNWRuMkNGUUo5TFRjZk10WFNF?= =?utf-8?B?M250UVFIckJNSWw0c2pIdkMzTjhROEhFWkRIR2NCQlUwa0ZMeDhLbG5vYUc3?= =?utf-8?B?L0htV1loTngzNW1kMTNDc1BHL3hqWW9xVzdJZEUwbmpDeEFJa1N6OFFoN3B6?= =?utf-8?B?Rk1CSnpnL24zOGdvVzFjWUJPd3Uya0ExeVpJc1gySm0xcGxHZzZDMG56anNh?= =?utf-8?B?RzVGeVdTTW9BczBaUmY5WmE4YjZ3S3c1aUxJcXhYbWppNndEK2hXa25QaWFL?= =?utf-8?B?N3BOQTN5RXAvcWl1ekhXUFNBOEtyd0RvanZtQnNjV2ZVakFlVEN5dnU0QkFC?= =?utf-8?B?UnVPdGZWVC8wVFRhckFXZmw4MTAwMTV1RXFQc05TTDcwcHZIaERrK0w3YUNv?= =?utf-8?B?dmwrb0wrMGM2RituTEZBcStXSnBVMC9OVmxGR3JBUy95dkw5U1llaGFaMUll?= =?utf-8?B?YW1IUGU2UmZ5M1lUUXJ0QzdyV3NTKzBKUmdOZ1FDdnRZNXNoMjlnNUhNU1Qr?= =?utf-8?B?SjZmcjlNMHN1WXV5OUE0bmg0c0ttUFRUM2U4WGYydVRkUlNPL2FsU1ZjclBF?= =?utf-8?B?LzJhaW9QeDVXVnpPUHZLU1pNR2JuVFV6TmYydjBoRFVGaEkyREMyL2h6bVha?= =?utf-8?B?VURaei9BdWNqY1l5MzJXR25hcE12YUVIaW1wUFoyenl0Ky9GaThrNWMxbFM1?= =?utf-8?B?T0QyZ1NlT2ROaVpvbXF3TmdFOXlBbGU3ZW5yVXloSkQ1NmJiN2h1NnIyejQw?= =?utf-8?B?eVl1bzV3alZubzZUTTh1NGZBTWJuZU9nVmkyTGQwMWIvejlQQklKaWNPY2Y4?= =?utf-8?B?Z3o3S2hPcENhakNSeWNlYXRiczd6dWxOTWh5SkZWbG1qVmVWb3ovQTNvRk9k?= =?utf-8?B?UFdvMDc4Y0lWcC9UVlJHQzUwb2RyR1QzOU1FR3ZHL0JBcXRSbzNtUWtIQ3Rq?= =?utf-8?B?OWd1TlRjMDJjdWpCNkgvNjAycGxBTmR5N1hMa0RKYjVTRWdSSGJjRDZXaUlo?= =?utf-8?B?Q294eFpMbkVPZmd6WWpRdEVwUlEzTGZyWWU5TW5XUHk4NDExUzNwdG1oVlhm?= =?utf-8?B?Y0lMcVNVTk1WanJSeHQyQlBQNFZMUlFxL1BJU3A0b2JkaU9LWlVrSXFhRjhP?= =?utf-8?B?T2EvSHg4WVN1SFA4U2lESVVzaHovdzU3NGxFSlVPbi9HTTlSM21IMnFDMGFh?= =?utf-8?B?RTFiUFc2ZmE2cGtqV1FyVzcvVkt5SHhKQjM5MStQRkdndXk2R3VubEFGVXgr?= =?utf-8?B?TzdsaURrN0F3cXdUd002Uk91OUUzY3hCYlNDalRGeDFCSTJyUUh6NFNGTTdr?= =?utf-8?B?a2Zod0N1U29YMVFOdWxVRC9yeWtNWGhJaUtEQ0ZPWVBsSHpqVTVJSGZXNFNS?= =?utf-8?B?SzBkVHhTNVNjUWFuUU9DUXVCRWhNbDNMdUo5UFJBM3czYUtKaTJaaHRtdUJP?= =?utf-8?B?VVhxaWQ2TU94TkdGVUFQWC9CcWxYdS94WEpOQ0FxKzBHY2xXT1NoVnZoeERS?= =?utf-8?B?OWlSK1ZzYlRNcW0vbUZEd3BEWkx5aUhENjYxbXZ6Wlp3UGlicDVobU5HOWNS?= =?utf-8?B?NFRZclpIZXZZOHN3K05kRUFCUmY3OW54T3FsamlYRS9FWEdMOWx3Y3ZGVDM1?= =?utf-8?B?V04weVJWY0dnMFovc05WMmEvMWN0LzNTMHhQMENMdlhUWnhFTlcwYVNGNEI4?= =?utf-8?B?Q2RVN2U3NzFKQVFhZXFuRzhVdmE4UFIraDdVbXdJaEJJZk9CaCs4Zk9wWHJF?= =?utf-8?B?K0xmNTNnVGp6SjJ1RS9tMGNYLzBQZ3NNZGxQdFB4MW1BVTEyVzhBYWdGM0xt?= =?utf-8?B?eGVsbzdhOEw0ZXczc25aQUtEc0k0ZkJyYXVRSDEzVDZwRjRHN2tMajRqL1ho?= =?utf-8?B?TFFaYWlQOFdPVEVMT1Rla0NydXJ3PT0=?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: bb630fa3-9efa-4d04-3cba-08d9bf5120fb X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2021 22:29:01.8426 (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: vh35NW1JThm10cO3YWkdoboTxELLfJim4fWZhDMuCd1+OqCEjGuyp9k8SFTbjelUcext2ew78AYbwrl2IEO7+1JUx+p/6o9mtHfOFItWtdk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1346 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 14 Dec 2021 22:29:13 -0000 On Tue, Dec 14, 2021 at 07:43:47PM +0000, Kent Watsen wrote: > > > >> Right, and in both cases, the idea was that contains all > >> data needed for the transformation into . So a client that > >> wants to do "offline" validation would need the data + the > >> transformation algorithms. But no additional data. > >> > > > > Having to know proprietary transformation algorithms really kills the > > idea of interoperable offline validation. It does not really get any > > worse if transformation algorithms merge in additional definitions. > > > Of the three transform algs under discussion (pruning inactive, merging system, and expanding templates), only the last may be proprietary and, even then, nothing is stopping IETF from standardizing one or a few well known templating mechanisms. > I doubt that existing implementations will converge to a standard solution (which will take years to define); it seems the window of opportunity for standards in this space is closed. /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 Tue Dec 14 22:44: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 18F893A077D for ; Tue, 14 Dec 2021 22:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 kLxfpeEKlZ8Z for ; Tue, 14 Dec 2021 22:44:00 -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 41F9E3A0769 for ; Tue, 14 Dec 2021 22:44:00 -0800 (PST) Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JDQZs2NQTz686pl for ; Wed, 15 Dec 2021 14:39:33 +0800 (CST) Received: from dggpemm500002.china.huawei.com (7.185.36.229) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 15 Dec 2021 07:43:56 +0100 Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm500002.china.huawei.com (7.185.36.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 15 Dec 2021 14:43:54 +0800 Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2308.020; Wed, 15 Dec 2021 14:43:54 +0800 From: "Fengchong (frank)" To: "netmod@ietf.org" Thread-Topic: Can a derived type of instance-identifier change the require-instance property? Thread-Index: AdfxfoXmnyMTI+cqSsqXjnW0EeTltw== Date: Wed, 15 Dec 2021 06:43:54 +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.113.80] Content-Type: multipart/alternative; boundary="_000_d8b97db34e6840f0ac079f970b7ea216huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Can a derived type of instance-identifier change the require-instance property? 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, 15 Dec 2021 06:44:04 -0000 --_000_d8b97db34e6840f0ac079f970b7ea216huaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGFuZCBtYXJ0aW4sDQoNCklmIEkgaGF2ZSBkZWZpbmVkIGEgdHlwZWRlZiBhDQp0eXBl ZGVmIGEgew0KICB0eXBlIGluc3RhbmNlLWlkZW50aWZpZXIgew0KICAgICAgcmVxdWlyZS1pbnN0 YW5jZSBmYWxzZTsNCiAgfQ0KfQ0KDQpBbmQgdGhlbiBJIGRlZmluZSBhbm90aGVyIHR5cGVkZWYg Yg0KDQp0eXBlZGVmIGIgew0KICB0eXBlIGEgew0KICAgIHJlcXVpcmUtaW5zdGFuY2UgdHJ1ZTsN CiAgfQ0KDQp9DQoNCklzIGl0IGNvcnJlY3Q/DQoNClRoZSBzYW1lIHNjZW5hcmlvIGlzIGxlYWZy ZWYuDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32z97T2reiy824+MnP w+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+9a5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw /MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQtcTQxc+i oaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2x vtPKvP6joQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBmb3Ig dGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1 c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVk aW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkIHJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUt bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHBob25lIG9yIGVtYWls IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCg== --_000_d8b97db34e6840f0ac079f970b7ea216huaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all and martin,

 

If I have defined a typedef a

typedef a {

  type instance-identifier= {

      = require-instance false;<= /p>

  }

}

 

And then I define another typed= ef b

 

typedef b {

  type a {

    require-instance true;

  }

 

}

 

Is it correct?

 

The same scenario is leafref.

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA= =B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB= =CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2= =C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA= =CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB= =B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9= =A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB= =C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5= =E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD= =B1=BE=D3=CA=BC=FE=A3=A1

This e-mail and its attachments contain confidentia= l information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein= in any way (including, but not limited to, total or partial disclosure, re= production, or dissemination) by persons other than the intended recipient(= s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediate= ly and delete it!<= /o:p>

 

--_000_d8b97db34e6840f0ac079f970b7ea216huaweicom_-- From nobody Wed Dec 15 02:10:28 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 5BB563A0E22 for ; Wed, 15 Dec 2021 02:10:25 -0800 (PST) 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, 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 (2048-bit key) header.d=4668.se header.b=BvU9gEm2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QHvvDFJF 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 W-COLqBnUOBi for ; Wed, 15 Dec 2021 02:10:20 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5113B3A0E1D for ; Wed, 15 Dec 2021 02:10:19 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2F8A15C04A1; Wed, 15 Dec 2021 05:10:18 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 15 Dec 2021 05:10:18 -0500 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=fm3; bh= QtQw3re6Gcse9KNzod6z17cxvYyv4jCeJEts469D1TI=; b=BvU9gEm2BL/HV+NS jAo4lZiaov9XlyhershKU4DGQJE4o5RV8+X6bvRI3buoqKLrRgYMkP9tRuoix4KN QXA+jOFsX2UiJj8PwLM5CxV4S1o8XyDZX8ANafoZiHmz6Qda0ROb5KnrNro9XLeh 5zKv6WyWP39wOQjWnzaxbQJAqHpcTp5r+enPpwoRzfAa8Fef6ZYLCUvsItwR8kZc FMLZ1QNZ3Q4g1Ng3i9MuJ+lsaxrSE9PgXYtQC5AKs92NJJt7wRDXJoA3FqFfQbd3 6QJIMWMpkdBa4lv7xGywDFqaCjrR9y7+8Ae6/Eibu5ofnqrMREh7oKz6lwcPXd55 lK1m0Q== 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=fm1; bh=QtQw3re6Gcse9KNzod6z17cxvYyv4jCeJEts469D1 TI=; b=QHvvDFJFsJGY0HWOFozWVf56z1gl9GjX22zOKj6y6iJ9beScjK4j7drdC DClJhNDxPi4oNJoYVJBcoWIeZPYDt1/qea+07Ml31riKDVuULjCc7xi9mIaBBQsA d+Jbog6rsT/YnyzA7jUbLmYRBB34NEbc6kZAt3Q1fB4x+6zuI6V0AUWsOz/vvAK1 T/IX/Yr3kcGTg0Oi+lR63AWoMTu5IZHwW/yKKeFQLNUcnCRhAhhSLuwwCdN7njRe rGyz7pnHHPctQBKmP8rwMaVmJ9xGwNJnTAfWfc03c9xs9/cHRyx5e+dyHjQhpb5+ PUeZnzeW6w7V50dvf/sPklVzo3OUQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrledvgddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeehteegtdffgfegffekvdejke evleetuedutddtfffhlefgtedvveehvdeguedtudenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Dec 2021 05:10:17 -0500 (EST) Date: Wed, 15 Dec 2021 11:10:15 +0100 (CET) Message-Id: <20211215.111015.709232990008645044.id@4668.se> To: frank.fengchong=40huawei.com@dmarc.ietf.org Cc: 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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] Can a derived type of instance-identifier change the require-instance property? 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, 15 Dec 2021 10:10:26 -0000 SGksDQoNCg0KIkZlbmdjaG9uZyBcKGZyYW5rXCkiIDxmcmFuay5mZW5nY2hvbmc9NDBodWF3ZWku Y29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gSGkgYWxsIGFuZCBtYXJ0aW4sDQo+IA0KPiBJ ZiBJIGhhdmUgZGVmaW5lZCBhIHR5cGVkZWYgYQ0KPiB0eXBlZGVmIGEgew0KPiAgIHR5cGUgaW5z dGFuY2UtaWRlbnRpZmllciB7DQo+ICAgICAgIHJlcXVpcmUtaW5zdGFuY2UgZmFsc2U7DQo+ICAg fQ0KPiB9DQo+IA0KPiBBbmQgdGhlbiBJIGRlZmluZSBhbm90aGVyIHR5cGVkZWYgYg0KPiANCj4g dHlwZWRlZiBiIHsNCj4gICB0eXBlIGEgew0KPiAgICAgcmVxdWlyZS1pbnN0YW5jZSB0cnVlOw0K PiAgIH0NCj4gDQo+IH0NCj4gDQo+IElzIGl0IGNvcnJlY3Q/DQoNClllcy4gIEhvd2V2ZXIsIGl0 IGlzIG5vdCBjbGVhciBpZiB0aGlzIGlzIGFsbG93ZWQ6DQoNCiAgIHR5cGVkZWYgYyB7DQogICAg IHR5cGUgYiB7DQogICAgICAgcmVxdWlyZS1pbnN0YW5jZSBmYWxzZTsNCiAgICAgfQ0KICAgfQ0K DQpOb3RlIGhvdyBzZWN0aW9uIDcuNCBpbiBSRkMgNzk1MCBzYXlzOg0KDQogICBUaGUgInR5cGUi IHN0YXRlbWVudCB0YWtlcyBhcyBhbiBhcmd1bWVudCBhIHN0cmluZyB0aGF0IGlzIHRoZSBuYW1l DQogICBvZiBhIFlBTkcgYnVpbHQtaW4gdHlwZSAoc2VlIFNlY3Rpb24gOSkgb3IgYSBkZXJpdmVk IHR5cGUgKHNlZQ0KICAgU2VjdGlvbiA3LjMpLCBmb2xsb3dlZCBieSBhbiBvcHRpb25hbCBibG9j ayBvZiBzdWJzdGF0ZW1lbnRzIHRoYXQgaXMNCiAgIHVzZWQgdG8gcHV0IGZ1cnRoZXIgcmVzdHJp Y3Rpb25zIG9uIHRoZSB0eXBlLg0KICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl4N Cg0KVGhpcyBpbXBsaWVzIHRoYXQgYSBzdWJ0eXBlIGNhbm5vdCBleHBhbmQgdGhlIHZhbHVlIHNw YWNlLCB3aGljaCB3b3VsZA0KbWFrZSAiYyIgYWJvdmUgaWxsZWdhbC4NCg0KVGhpcyB3YXMgdGhl IGludGVudGlvbiwgYnV0IGl0IGNvdWxkIGJlIG1hZGUgbW9yZSBjbGVhci4gIEluIG1hbnkNCm90 aGVyIGNhc2VzIGl0IGlzIGV4cGxpY2l0bHkgbWVudGlvbmVkLCBlLmcuIGluIDkuNC41Og0KDQog ICBJZiBhIHBhdHRlcm4gcmVzdHJpY3Rpb24gaXMgYXBwbGllZCB0byBhIHR5cGUgdGhhdCBpcyBh bHJlYWR5DQogICBwYXR0ZXJuLXJlc3RyaWN0ZWQsIHZhbHVlcyBtdXN0IG1hdGNoIGFsbCBwYXR0 ZXJucyBpbiB0aGUgYmFzZSB0eXBlLA0KICAgaW4gYWRkaXRpb24gdG8gdGhlIG5ldyBwYXR0ZXJu cy4NCg0KPiBUaGUgc2FtZSBzY2VuYXJpbyBpcyBsZWFmcmVmLg0KDQpTYW1lIGFuc3dlciBhcyBh Ym92ZS4NCg0KDQovbWFydGluDQoNCg0KDQo+IOacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWN juS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWd gOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgeatouS7u+S9leWFtuS7luS6uuS7peS7 u+S9leW9ouW8j+S9v+eUqO+8iOWMheaLrOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOaz hOmcsuOAgeWkjeWItuOAgeaIluaVo+WPke+8ieacrOmCruS7tuS4reeahOS/oeaBr+OAguWmguae nOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eUteivneaIlumCruS7tumAmuef peWPkeS7tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gQ0KPiBUaGlzIGUtbWFpbCBhbmQgaXRzIGF0 dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3 aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRy ZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwg b3IgcGFydGlhbCBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5 IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGlzIHByb2hpYml0 ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCj4g DQo= From nobody Wed Dec 15 08:25: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 0EC783A089E for ; Wed, 15 Dec 2021 08:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 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=-1.852, 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=hq.sk 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 Q6wDxj4JMlCX for ; Wed, 15 Dec 2021 08:25:15 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964E53A089B for ; Wed, 15 Dec 2021 08:25:12 -0800 (PST) Received: from [192.168.1.147] (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 89A0F24427C; Wed, 15 Dec 2021 17:25:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1639585507; bh=cKw30X9kPNS1ojD7vRlWDkUug6ac7J02MbKy3otZApc=; h=Date:Subject:To:References:From:In-Reply-To; b=NvUEuVV6oeeOYa/ilWYS2kpnyBsAtzxvDIAkCzAVK2qlxKKDEZEVzdJSOuWe9w6Eg OpyzamPcQna1SNPZ2RGlvKzeB3iLBpam+y/XD8GD/2AAYaUwREQQ651WW34JH4xBpQ WzVGB/FzMgvv9RkF5z6GL76RTC3Kbl5idSZR4tRI= Message-ID: <4edae53a-4e7d-0547-4d3e-a8134ba572e3@hq.sk> Date: Wed, 15 Dec 2021 17:25:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: =?UTF-8?Q?Michal_Va=c5=a1ko?= , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , netmod@ietf.org References: <72c4-61b88d00-f-13e4c040@5935962> <87lf0nl4lx.fsf@nic.cz> From: Robert Varga In-Reply-To: <87lf0nl4lx.fsf@nic.cz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------IHLQ9AvhHE9MRmWeZkP7CcB3" Archived-At: Subject: Re: [netmod] Resolving schema node identifier 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, 15 Dec 2021 16:25:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------IHLQ9AvhHE9MRmWeZkP7CcB3 Content-Type: multipart/mixed; boundary="------------H9foeKL9yMT32jv10K9PBsl0"; protected-headers="v1" From: Robert Varga To: =?UTF-8?Q?Michal_Va=c5=a1ko?= , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , netmod@ietf.org Message-ID: <4edae53a-4e7d-0547-4d3e-a8134ba572e3@hq.sk> Subject: Re: [netmod] Resolving schema node identifier References: <72c4-61b88d00-f-13e4c040@5935962> <87lf0nl4lx.fsf@nic.cz> In-Reply-To: <87lf0nl4lx.fsf@nic.cz> --------------H9foeKL9yMT32jv10K9PBsl0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTQvMTIvMjAyMSAxNDowNCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPiBNaWNoYWwg VmHFoWtvIDxtdmFza29AY2VzbmV0LmN6PiB3cml0ZXM6DQo+IA0KPj4+IE1pY2hhbCBWYcWh a28gPG12YXNrb0BjZXNuZXQuY3o+IHdyb3RlOg0KPj4+Pj4+IE1pY2hhbCBWYcWha28gPG12 YXNrb0BjZXNuZXQuY3o+IHdyb3RlOg0KPj4+Pj4+Pj4gTWljaGFsIFZhxaFrbyA8bXZhc2tv QGNlc25ldC5jej4gd3JvdGU6DQoNCltzbmlwXQ0KDQo+Pj4+Pj4+Pj4+PiBtb2R1bGUgbW9k X2Egew0KPj4+Pj4+Pj4+ICAgICAgbmFtZXNwYWNlICJ4OmV4YW1wbGU6bW9kX2EiOw0KPj4+ Pj4+Pj4+ICAgICAgcHJlZml4ICJtYSI7DQo+Pj4+Pj4+Pj4+ICAgICAgaW1wb3J0IG1vZF9i IHsgcHJlZml4ICJtYiI7IH0NCj4+Pj4+Pj4+Pj4gICAgICBjb250YWluZXIgcm9vdCB7DQo+ Pj4+Pj4+Pj4gICAgICAgICAgdXNlcyBtYjpteWxpc3Rfd3JhcHBlcjsNCj4+Pj4+Pj4+PiAg ICAgIH0NCj4+Pj4+Pj4+Pj4gICAgICBhdWdtZW50IC9tYjpteWxpc3QyIHsNCj4+Pj4+Pj4+ PiAgICAgICAgICBsZWFmIGMgew0KPj4+Pj4+Pj4+ICAgICAgICAgICAgICB0eXBlIHN0cmlu ZzsNCj4+Pj4+Pj4+PiAgICAgICAgICB9DQo+Pj4+Pj4+Pj4gICAgICB9DQo+Pj4+Pj4+Pj4+ ICAgICAgZGV2aWF0aW9uIC9tYjpteWxpc3QyIHsNCj4+Pj4+Pj4+PiAgICAgICAgICBkZXZp YXRlIGFkZCB7DQo+Pj4+Pj4+Pj4gICAgICAgICAgICAgIHVuaXF1ZSAibWI6YiBjIjsNCj4+ Pj4+Pj4+PiAgICAgICAgICB9DQo+Pj4+Pj4+Pj4gICAgICB9DQo+Pj4+Pj4+Pj4gfQ0KDQpb c25pcF0NCg0KPj4gSSB3b3VsZCBhcHByZWNpYXRlIGFueSBleGFjdCBydWxlcyB0aGF0IHdl IGNhbiBhZ3JlZSBvbi4NCj4gDQo+IFRoZSBleGlzdGluZyBydWxlcyBpbiBSRkMgNzk1MCBz ZWVtIHVuY2xlYXIvY29udHJhZGljdG9yeS4NCj4gDQo+IFRoaXMgaXMgaW4gc2VjLiA3LjEy IG9uICJncm91cGluZyI6DQo+IA0KPiAgICAgSWRlbnRpZmllcnMgYXBwZWFyaW5nIGluc2lk ZSB0aGUgZ3JvdXBpbmcgYXJlIHJlc29sdmVkIHJlbGF0aXZlIHRvDQo+ICAgICB0aGUgc2Nv cGUgaW4gd2hpY2ggdGhlIGdyb3VwaW5nIGlzIGRlZmluZWQsIG5vdCB3aGVyZSBpdCBpcyB1 c2VkLg0KPiAgICAgUHJlZml4IG1hcHBpbmdzLCB0eXBlIG5hbWVzLCBncm91cGluZyBuYW1l cywgYW5kIGV4dGVuc2lvbiB1c2FnZQ0KPiAgICAgYXJlIGV2YWx1YXRlZCBpbiB0aGUgaGll cmFyY2h5IHdoZXJlIHRoZSAiZ3JvdXBpbmciIHN0YXRlbWVudA0KPiAgICAgYXBwZWFycy4N Cj4gDQo+IEFuZCB0aGlzIGlzIHRoZW4gaW4gc2VjLiA3LjEzIG9uICJ1c2VzIjoNCj4gDQo+ ICAgICBUaGUgaWRlbnRpZmllcnMgZGVmaW5lZCBpbiB0aGUgZ3JvdXBpbmcgYXJlIG5vdCBi b3VuZCB0byBhIG5hbWVzcGFjZQ0KPiAgICAgdW50aWwgdGhlIGNvbnRlbnRzIG9mIHRoZSBn cm91cGluZyBhcmUgYWRkZWQgdG8gdGhlIHNjaGVtYSB0cmVlIHZpYSBhDQo+ICAgICAidXNl cyIgc3RhdGVtZW50IHRoYXQgZG9lcyBub3QgYXBwZWFyIGluc2lkZSBhICJncm91cGluZyIg c3RhdGVtZW50LA0KPiAgICAgYXQgd2hpY2ggcG9pbnQgdGhleSBhcmUgYm91bmQgdG8gdGhl IG5hbWVzcGFjZSBvZiB0aGUgY3VycmVudCBtb2R1bGUuDQoNCkp1c3QgbXkgLjAyRVVSLCBp biBPcGVuRGF5bGlnaHQgd2UgZGVhbCB3aXRoIHRoaXMgcGFydGljdWxhciBjYXNlIGluIHR3 byANCnN0ZXBzOg0KDQoxLiB0aGUgYXJndW1lbnQgdG8gdW5pcXVlIGlzIGludGVycHJldGVk IGluIHNjb3BlIG9mIG1vZF9hLCBoZW5jZSAibWI6YiANCmMiIGludGVycHJldHMgdGhlIHNh bWUgYXMgIm1iOmIgbWE6YyIsIGp1c3QgYXMgaXQgd291bGQgaW4gYW55IG90aGVyIA0KZGVj bGFyYXRpb24gc2l0ZQ0KDQoyLiBpbiB0aGUgcGFydGljdWxhciBjYXNlIG9mICJkZXZpYXRl IGFkZCIsIHRoZSBzdGF0ZW1lbnQgaXMgdGhlbiBjb3BpZWQgDQp2ZXJiYXRpbSB0byBkZXZp YXRpb24gdGFyZ2V0IHNpdGUNCg0KaS5lLiB0aGlzIHdvcmtzIHNpbWlsYXIgdG8gaG93IGFu IGF1Z21lbnQgd291bGQgd29yayAtLSBhbmQgaGVuY2UgdGhlIA0KcXVvdGVkIGV4YW1wbGUg d29ya3MgYXMgb25lIHdvdWxkIGV4cGVjdCBmcm9tIGp1c3QgYSBjdXJzb3J5IGdsYW5jZSBh dCANCnRoZSBtb2RlbCB3aXRob3V0IGdpdmluZyBpdCBhIHNlY29uZCB0aG91Z2h0IDopDQoN ClJlZ2FyZHMsDQpSb2JlcnQNCg== --------------H9foeKL9yMT32jv10K9PBsl0-- --------------IHLQ9AvhHE9MRmWeZkP7CcB3 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE9xJg9S8sgC+6qlK6U310SwoeP0UFAmG6FuIFAwAAAAAACgkQU310SwoeP0U1 hg/+OOQJulfQRTE1Jc53643oKJnPTwMnXLxNA51XUfFAqVE4by/1dKNGSSMrC7hPNIgpIujrdHLl sL0Ej+PQrHW3yVKByh7Jfs/VGvNsmuWLB4aXajam3SsT1CfR/6PBYYWU6WQOYYmVvGN1hxYQXHfK iyN2h3j5zjw9ckG966ekwh8bTflPLsJ9cWsnMGFshYuPJlFTCfE7TJ1TXr2r721pVk+STIBvw0E8 Zt9VQFIjBht0xijXULrEOISf5hVyDderCsPtuN4IinSx1XogEOKV/s256DZNKezEU/egIMIWF3p/ TwHqDB1WeYYuda9rd4t3a0UyIHzP25TipfbezlL3XKNLGufGHkPaNdqBBNRHFAsonVPwmzNlEuJ4 ke8CCsHs7E9pnqZd93M4OoGr2OzmBa9Js7Nk5FYgoGiUSv2btagpKASebQIJ9SKEl0nzhA3b3UlL 31HQ5cDYDbrEj1hE4XnOWqPOnVRrnLg/ZjRpEDJBC+e4bWCio4Fno6lUnm6l7c1uhJU6Ud1MQeO9 FB5Q672M2uTt0rZxP5igw97NEIL8zwJYy1wHMmidHpGsW9YuOA8D93LNeekfEDHxfmtKb7ObZmdH /fiYnbeya7ebvOjrk0pfEZUh9sUD648rXftEyqDPZ7QANpUYJHL/JCT0YPdSA1cmZsiHJHDXR32X hEY= =JhYL -----END PGP SIGNATURE----- --------------IHLQ9AvhHE9MRmWeZkP7CcB3-- From nobody Thu Dec 16 03:27:41 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 3EE473A0CCD for ; Thu, 16 Dec 2021 03:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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=cesnet.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 jBm64HP1ipLh for ; Thu, 16 Dec 2021 03:27:34 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7053A0CB8 for ; Thu, 16 Dec 2021 03:27:33 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 3DE1E60068; Thu, 16 Dec 2021 12:27:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1639654046; bh=Hqi373yeYE/Zv5sHhY/uAyp5XcQvrYxy3V9lKRnOBXg=; h=From:In-Reply-To:Date:Cc:To:Subject; b=kQAHWYesNhr2MhHufAf5oeMjD2vwD+dMX4mVoHztg+HacR4GNy3woguZJB+cLLKQy 6L2rvmWvk5ykiCprAUJ0q4AIgshuJ5zCqUbndIfV9Cj2j6u8fGj5Przh98m8xukMN6 uowbawZ5oaNVHlnKUucQ/fRzhs/bbWXngs8NJsi0= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <4edae53a-4e7d-0547-4d3e-a8134ba572e3@hq.sk> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Thu, 16 Dec 2021 12:27:26 +0100 Cc: =?utf-8?q?Martin_Bj=C3=B6rklund?= , netmod@ietf.org To: "Robert Varga" MIME-Version: 1.0 Message-ID: User-Agent: SOGoMail 5.2.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] =?utf-8?q?Resolving_schema_node_identifier?= 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, 16 Dec 2021 11:27:39 -0000 > On 14/12/2021 14:04, Ladislav Lhotka wrote: > > Michal Va=C5=A1ko writes: > > > >>> Michal Va=C5=A1ko wrote: > >>>>>> Michal Va=C5=A1ko wrote: > >>>>>>>> Michal Va=C5=A1ko wrote: > > [snip] > > >>>>>>>>>>> module mod=5Fa { > >>>>>>>>> namespace "x:example:mod=5Fa"; > >>>>>>>>> prefix "ma"; > >>>>>>>>>> import mod=5Fb { prefix "mb"; } > >>>>>>>>>> container root { > >>>>>>>>> uses mb:mylist=5Fwrapper; > >>>>>>>>> } > >>>>>>>>>> augment /mb:mylist2 { > >>>>>>>>> leaf c { > >>>>>>>>> type string; > >>>>>>>>> } > >>>>>>>>> } > >>>>>>>>>> deviation /mb:mylist2 { > >>>>>>>>> deviate add { > >>>>>>>>> unique "mb:b c"; > >>>>>>>>> } > >>>>>>>>> } > >>>>>>>>> } > > [snip] > > >> I would appreciate any exact rules that we can agree on. > > > > The existing rules in RFC 7950 seem unclear/contradictory. > > > > This is in sec. 7.12 on "grouping": > > > > Identifiers appearing inside the grouping are resolved relative= to > > the scope in which the grouping is defined, not where it is use= d. > > Prefix mappings, type names, grouping names, and extension usag= e > > are evaluated in the hierarchy where the "grouping" statement > > appears. > > > > And this is then in sec. 7.13 on "uses": > > > > The identifiers defined in the grouping are not bound to a name= space > > until the contents of the grouping are added to the schema tree= via a > > "uses" statement that does not appear inside a "grouping" state= ment, > > at which point they are bound to the namespace of the current m= odule. > > Just my .02EUR, in OpenDaylight we deal with this particular case in = two > steps: > > 1. the argument to unique is interpreted in scope of mod=5Fa, hence "= mb:b > c" interprets the same as "mb:b ma:c", just as it would in any other = > declaration site > > 2. in the particular case of "deviate add", the statement is then cop= ied > verbatim to deviation target site > > i.e. this works similar to how an augment would work -- and hence the= > quoted example works as one would expect from just a cursory glance a= t > the model without giving it a second thought :) Thanks, we will have to come up with our own solution as well. If I und= erstood properly, you are technically adding the prefix when it is miss= ing. That should be fine for "unique" but generally impossible to do fo= r "must", for example. We have tried similar solutions but were not rel= iable enough and it seems there is no reliable solution even in theory = based on this discussion, unfortunately. Regards, Michal From nobody Thu Dec 16 05:30: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 99F8C3A0EA4 for ; Thu, 16 Dec 2021 05:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 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=-1.852, 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=hq.sk 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 rNTim3Sxcr_n for ; Thu, 16 Dec 2021 05:30:23 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC2C3A0EA0 for ; Thu, 16 Dec 2021 05:30:21 -0800 (PST) Received: from [192.168.1.147] (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id D18842439CB; Thu, 16 Dec 2021 14:30:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1639661416; bh=NwzXYpAe5TvdgD+qWgfdHxe5cr2sD1jdTMGwWp0AgEA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=pRUiiMnIiiLjXGs9wrCweIWGqV45Ufv1e+zkJBlvqU91XVZ6j5RV+kZQYjg+oA5JN g2EU7Wc0QXYFnKiTV8BaraVDgK7AugD4xXmb3L6watj+oYgdPOfh4QJZqtpoJX2bKp CcN9kuwz1fJIYr89PBF7TSR2DLq28e8wcyFPfohw= Message-ID: Date: Thu, 16 Dec 2021 14:30:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: =?UTF-8?Q?Michal_Va=c5=a1ko?= Cc: =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , netmod@ietf.org References: From: Robert Varga In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------bPt3FoBbCe3RL22JMX0i8N4O" Archived-At: Subject: Re: [netmod] Resolving schema node identifier 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, 16 Dec 2021 13:30:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------bPt3FoBbCe3RL22JMX0i8N4O Content-Type: multipart/mixed; boundary="------------0z8CzK63mkawY8Kh1Y4pM9Ed"; protected-headers="v1" From: Robert Varga To: =?UTF-8?Q?Michal_Va=c5=a1ko?= Cc: =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , netmod@ietf.org Message-ID: Subject: Re: [netmod] Resolving schema node identifier References: In-Reply-To: --------------0z8CzK63mkawY8Kh1Y4pM9Ed Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTYvMTIvMjAyMSAxMjoyNywgTWljaGFsIFZhxaFrbyB3cm90ZToNCj4+IE9uIDE0LzEy LzIwMjEgMTQ6MDQsIExhZGlzbGF2IExob3RrYSB3cm90ZToNCg0KW3NuaXBdDQoNCj4+Pg0K Pj4+IFRoZSBleGlzdGluZyBydWxlcyBpbiBSRkMgNzk1MCBzZWVtIHVuY2xlYXIvY29udHJh ZGljdG9yeS4NCj4+Pg0KPj4+IFRoaXMgaXMgaW4gc2VjLiA3LjEyIG9uICJncm91cGluZyI6 DQo+Pj4NCj4+PiAgICAgIElkZW50aWZpZXJzIGFwcGVhcmluZyBpbnNpZGUgdGhlIGdyb3Vw aW5nIGFyZSByZXNvbHZlZCByZWxhdGl2ZSB0bw0KPj4+ICAgICAgdGhlIHNjb3BlIGluIHdo aWNoIHRoZSBncm91cGluZyBpcyBkZWZpbmVkLCBub3Qgd2hlcmUgaXQgaXMgdXNlZC4NCj4+ PiAgICAgIFByZWZpeCBtYXBwaW5ncywgdHlwZSBuYW1lcywgZ3JvdXBpbmcgbmFtZXMsIGFu ZCBleHRlbnNpb24gdXNhZ2UNCj4+PiAgICAgIGFyZSBldmFsdWF0ZWQgaW4gdGhlIGhpZXJh cmNoeSB3aGVyZSB0aGUgImdyb3VwaW5nIiBzdGF0ZW1lbnQNCj4+PiAgICAgIGFwcGVhcnMu DQo+Pj4NCj4+PiBBbmQgdGhpcyBpcyB0aGVuIGluIHNlYy4gNy4xMyBvbiAidXNlcyI6DQo+ Pj4NCj4+PiAgICAgIFRoZSBpZGVudGlmaWVycyBkZWZpbmVkIGluIHRoZSBncm91cGluZyBh cmUgbm90IGJvdW5kIHRvIGEgbmFtZXNwYWNlDQo+Pj4gICAgICB1bnRpbCB0aGUgY29udGVu dHMgb2YgdGhlIGdyb3VwaW5nIGFyZSBhZGRlZCB0byB0aGUgc2NoZW1hIHRyZWUgdmlhIGEN Cj4+PiAgICAgICJ1c2VzIiBzdGF0ZW1lbnQgdGhhdCBkb2VzIG5vdCBhcHBlYXIgaW5zaWRl IGEgImdyb3VwaW5nIiBzdGF0ZW1lbnQsDQo+Pj4gICAgICBhdCB3aGljaCBwb2ludCB0aGV5 IGFyZSBib3VuZCB0byB0aGUgbmFtZXNwYWNlIG9mIHRoZSBjdXJyZW50IG1vZHVsZS4NCj4+ DQo+PiBKdXN0IG15IC4wMkVVUiwgaW4gT3BlbkRheWxpZ2h0IHdlIGRlYWwgd2l0aCB0aGlz IHBhcnRpY3VsYXIgY2FzZSBpbiB0d28NCj4+IHN0ZXBzOg0KPj4NCj4+IDEuIHRoZSBhcmd1 bWVudCB0byB1bmlxdWUgaXMgaW50ZXJwcmV0ZWQgaW4gc2NvcGUgb2YgbW9kX2EsIGhlbmNl ICJtYjpiDQo+PiBjIiBpbnRlcnByZXRzIHRoZSBzYW1lIGFzICJtYjpiIG1hOmMiLCBqdXN0 IGFzIGl0IHdvdWxkIGluIGFueSBvdGhlcg0KPj4gZGVjbGFyYXRpb24gc2l0ZQ0KPj4NCj4+ IDIuIGluIHRoZSBwYXJ0aWN1bGFyIGNhc2Ugb2YgImRldmlhdGUgYWRkIiwgdGhlIHN0YXRl bWVudCBpcyB0aGVuIGNvcGllZA0KPj4gdmVyYmF0aW0gdG8gZGV2aWF0aW9uIHRhcmdldCBz aXRlDQo+Pg0KPj4gaS5lLiB0aGlzIHdvcmtzIHNpbWlsYXIgdG8gaG93IGFuIGF1Z21lbnQg d291bGQgd29yayAtLSBhbmQgaGVuY2UgdGhlDQo+PiBxdW90ZWQgZXhhbXBsZSB3b3JrcyBh cyBvbmUgd291bGQgZXhwZWN0IGZyb20ganVzdCBhIGN1cnNvcnkgZ2xhbmNlIGF0DQo+PiB0 aGUgbW9kZWwgd2l0aG91dCBnaXZpbmcgaXQgYSBzZWNvbmQgdGhvdWdodCA6KQ0KPiANCj4g VGhhbmtzLCB3ZSB3aWxsIGhhdmUgdG8gY29tZSB1cCB3aXRoIG91ciBvd24gc29sdXRpb24g YXMgd2VsbC4gSWYgSSB1bmRlcnN0b29kIHByb3Blcmx5LCB5b3UgYXJlIHRlY2huaWNhbGx5 IGFkZGluZyB0aGUgcHJlZml4IHdoZW4gaXQgaXMgbWlzc2luZy4gVGhhdCBzaG91bGQgYmUg ZmluZSBmb3IgInVuaXF1ZSIgYnV0IGdlbmVyYWxseSBpbXBvc3NpYmxlIHRvIGRvIGZvciAi bXVzdCIsIGZvciBleGFtcGxlLiBXZSBoYXZlIHRyaWVkIHNpbWlsYXIgc29sdXRpb25zIGJ1 dCB3ZXJlIG5vdCByZWxpYWJsZSBlbm91Z2ggYW5kIGl0IHNlZW1zIHRoZXJlIGlzIG5vIHJl bGlhYmxlIHNvbHV0aW9uIGV2ZW4gaW4gdGhlb3J5IGJhc2VkIG9uIHRoaXMgZGlzY3Vzc2lv biwgdW5mb3J0dW5hdGVseS4NCg0KVGhhdCdzIHRydWUsIGJ1dCB0aGVuICdtdXN0JyB0YWtl cyBhbiBYUGF0aCwgYW5kIHRoZSBydWxlcyBmb3IgaGFuZGxpbmcgDQp0aGF0IGFyZSB1bmFt YmlndW91cyAoYXMgcGVyIHNlY3Rpb24gNi40LjEpLiBJbiB0aGlzIHBhcnRpY3VsYXIgY2Fz ZToNCg0KLSB1bnByZWZpeGVkIG5hbWVzIHdvdWxkIHByb3BhZ2F0ZSB0byB0aGUgZGV2aWF0 ZWQgbGlzdCB1bnByZWZpeGVkIHdvdWxkIA0KYmUgYm91bmQgdG8gdGhlIGxpc3QncyBuYW1l c3BhY2UNCi0gcHJlZml4ZWQgbmFtZXMgd291bGQgYmUgYm91bmQgYXQgdGhlIGRlY2xhcmF0 aW9uIHNpdGUsIGkuZS4gdW5kZXIgDQpkZXZpYXRlLCBhbmQgd291bGQgYmUgcHJvcGFnYXRl ZCBhcy1pcyB0byB0aGUgZGV2aWF0ZWQgbGlzdA0KDQpSZWdhcmRzLA0KUm9iZXJ0DQo= --------------0z8CzK63mkawY8Kh1Y4pM9Ed-- --------------bPt3FoBbCe3RL22JMX0i8N4O Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE9xJg9S8sgC+6qlK6U310SwoeP0UFAmG7P2YFAwAAAAAACgkQU310SwoeP0UQ fg//TSD7TNr3gMc4VwpD60VTVYIk1yWml8OQeIzBFE2pfeaHWynzukSAyBahtuvTXWZP59KJ/4ZF bEtSt4pEprj5F4Smr/PQw7kr5oqKkzTdZvG9LU2TzDg+UKyPrQH+Oqt68Fho1e/CytO4UGlZkL2N zcjGgdyK7ZOC5uhtqorpQ6HQy5tznQ5ZiRfrAo4pav8qu9p4T96/ZHT2kFdNaayMTVkRJhTGegre +WXcFNQ3xd40MbtY4YNAfPXhNrf0EQrBFIB/NxM7J/d+XJ/eg4YCg+wyXkN+n6wH82OLZ8oKzxWn EJ0IsWPf0Fuiqc19WPPS6GNST4Wbb+qu7I5oOuuimT+o0N4/3IG9rUKeCykNW7f0xN13Zz0rWNna 5KR8PlOFQRykDTfEeJy740P5YdnBEAHG24VgjyolxQ4fj1YmaXIbuA5jIyMPonpZ9zF4kNnLbcMx mRWA2IjPr/3JLzC8JeVX8oN6Ing64y9q++riBiqvCNJpJmickaBqcsbZ1fp7Wz0eggXAth4TmYOO 490dnJvXfkxiWnqj0DnzTsRQhqFtHI9RFRXYYAM2w3c1qy2Z/mHE5hzEW8Uv+FwmDRAC/jafj168 y0MhfTb4YAhmoa7CXxXQfxW8QuJxItIFjSgJk8s9YVeZ19aQkYEY1VeirLem4kujNBTYeMg2EpPJ lWY= =cCEE -----END PGP SIGNATURE----- --------------bPt3FoBbCe3RL22JMX0i8N4O-- From nobody Thu Dec 16 10:47: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 3E48E3A0DE2 for ; Thu, 16 Dec 2021 10:47:40 -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.20210112.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 JHqQ57sphfTg for ; Thu, 16 Dec 2021 10:47:31 -0800 (PST) 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 2D0EA3A0DFC for ; Thu, 16 Dec 2021 10:47:30 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id m12so39943338ljj.6 for ; Thu, 16 Dec 2021 10:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YnyZFzvD2kDxe6kY/SqmuC7QOfHTe5K9vk3kvE5wuHA=; b=6X7GXk55NyCQCeqGYo4k9psW/Fq1iFwxhSTU1c2EIfjvldIe/bJTkbEac93DdVUSiu +bZgIxbXxTG3S6Mu25hRH5hgPDMZyeq0oUZ0jMXxHS/Bg+CeH60euMSvcDITFp1IhQ8r b0U2/V/rJK85cCtlZ6+y1uLKsukkp2Zuq0yAFTnTHq/YsxR8KQl1DHn0NlmpVuu6NhrD M76meIFnVnEf4y42JPy5EeYMZ0XdHNmIq5Lfv+4eCgRUWMqjzp+yWjYVJ23oKO6O0Nya nA5XDJ4cNMEgrS0+3bQvZaPbQJMio4vFAIgoQubQYZqWdLz1m2BDFU1aD2vMOFY11i04 SSgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YnyZFzvD2kDxe6kY/SqmuC7QOfHTe5K9vk3kvE5wuHA=; b=sSx3OVudTqD454rqoRCeq7FGiLysZOeofB6lQCz2Fw8BYkqa8zC+IGjPNJS6Ais2Pz EfkGbYsU2RVmtaxugRvr8ypM4bXD/WldBWEc8Ocxcox7dYKGoAX4zjhk7iDQErWsSLOD VeEfMe/RroGbuvggRnPfUNcpVExN2Rc0Yh57/7Q5MvHGfDxK+SQP+Y5lWw3YpBzwr1P4 U9A3hCphdfp83oD1vh5Qn+zo64YeJQldubPRfonDZWGcN3LhRVUJDnuOIaf5WC5h7xxL NcEevqieB5XjvhU251ckathbxIYq05J82jPY2w6i5afKQpJAxNyaDAH7BreHFZLBP5q4 Qpeg== X-Gm-Message-State: AOAM530NgypINxMhfLCH03udlZyrX1UUVxi8UOtP3z24NQVrNEM853DR Va0ohc87yI1M+3795BIurPv+FmtGYLoLCG64AXVNKu94flXEDQ== X-Google-Smtp-Source: ABdhPJyN6SAZmccWr/WFqTA+1AhiPTJGSpXwWvOFtKToSp2+9lA2ELp+ihzKIxl6i5npZ2J9ps+vgUlLEgeWN0800IM= X-Received: by 2002:a2e:720f:: with SMTP id n15mr16307069ljc.167.1639680446916; Thu, 16 Dec 2021 10:47:26 -0800 (PST) MIME-Version: 1.0 References: <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <20211214.131417.1201606442961003687.id@4668.se> <20211214162002.fwhuhe4cemyp5osy@anna> <0100017dba78eea9-e62c4e7a-dca7-4a6a-b231-e4924c07ec14-000000@email.amazonses.com> <20211214222900.xhiiqv7y6m4vhezf@anna> In-Reply-To: <20211214222900.xhiiqv7y6m4vhezf@anna> From: Andy Bierman Date: Thu, 16 Dec 2021 10:47:15 -0800 Message-ID: To: Juergen Schoenwaelder , Kent Watsen , =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , "maqiufang (A)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000957fad05d347da5c" Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 16 Dec 2021 18:47:41 -0000 --000000000000957fad05d347da5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 14, 2021 at 2:29 PM J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Dec 14, 2021 at 07:43:47PM +0000, Kent Watsen wrote: > > > > > > >> Right, and in both cases, the idea was that contains all > > >> data needed for the transformation into . So a client tha= t > > >> wants to do "offline" validation would need the data + the > > >> transformation algorithms. But no additional data. > > >> > > > > > > Having to know proprietary transformation algorithms really kills the > > > idea of interoperable offline validation. It does not really get any > > > worse if transformation algorithms merge in additional definitions. > > > > > > Of the three transform algs under discussion (pruning inactive, merging > system, and expanding templates), only the last may be proprietary and, > even then, nothing is stopping IETF from standardizing one or a few well > known templating mechanisms. > > > > I doubt that existing implementations will converge to a standard > solution (which will take years to define); it seems the window of > opportunity for standards in this space is closed. > > I am still looking for a meaningful problem statement that addresses operational problems. Working on architecture for the sake of elegance is not interesting to me. The problem seems to be that the WG incorrectly assumed that all these unspecified proprietary mechanisms could be represented as YANG data, conforming to specific YANG modules. This data MUST always be valid in both and . Clearly it was a mistake to assume that these proprietary mechanisms could be ignored for the purpose of YANG validation. It should be obvious that if this data cannot be properly represented in then moving the data to does not help at all. In fact, it makes the problem even worse, because the protocol operations are designed to work on 1 datastore at a time. Offline validation based on multiple retrievals will require long-lived locks, or just be wrong due to time skew. I do not understand the use-case for a leafref that points at instances that do not exist in . It seems like a simple "enabled" leaf allows the unused instance to exist in but be disabled. YANG validation is constrained to a single datastore. It would be very disruptive to change this now. > /js > > Andy > -- > 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 > --000000000000957fad05d347da5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 14, 2021 at 2:29 PM J=C3= =BCrgen Sch=C3=B6nw=C3=A4lder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Dec 14, 2021 at = 07:43:47PM +0000, Kent Watsen wrote:
>
>
> >> Right, and in both cases, the idea was that <running> c= ontains all
> >> data needed for the transformation into <intended>.=C2= =A0 So a client that
> >> wants to do "offline" validation would need the dat= a + the
> >> transformation algorithms.=C2=A0 But no additional data.
> >>
> >
> > Having to know proprietary transformation algorithms really kills= the
> > idea of interoperable offline validation. It does not really get = any
> > worse if transformation algorithms merge in additional definition= s.
>
>
> Of the three transform algs under discussion (pruning inactive, mergin= g system, and expanding templates), only the last may be proprietary and, e= ven then, nothing is stopping IETF from standardizing one or a few well kno= wn templating mechanisms.
>

I doubt that existing implementations will converge to a standard
solution (which will take years to define); it seems the window of
opportunity for standards in this space is closed.



I am still looking for = a meaningful problem statement that addresses operational problems.
Working on architecture for the sake of elegance is not interesting to m= e.

The problem seems to be that the WG incorrectly= assumed that=C2=A0 all these unspecified proprietary mechanisms
= could be represented as YANG data, conforming to specific YANG modules. Thi= s data MUST always be valid
in both <running> and <inten= ded>. Clearly it was a mistake to assume that these proprietary mechanis= ms
could be ignored for the purpose of YANG validation.

It should be obvious that if this data cannot be properly r= epresented in <running>
then moving the data to <system&= gt; does not help at all.=C2=A0 In fact, it makes the problem
eve= n worse, because the protocol operations are designed to work on 1 datastor= e at a time.
Offline validation based on multiple retrievals will= require long-lived locks, or just be wrong
due to time skew.

I do not understand the use-case for a leafref that p= oints at instances that do not exist in <running>.
It seems= like a simple "enabled" leaf allows the unused instance to exist= in <running> but be disabled.
YANG validation is constrain= ed to a single datastore. It would be very disruptive to change this now.

=C2=A0
/js


Andy
=C2=A0
--
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
--000000000000957fad05d347da5c-- From nobody Fri Dec 17 04:31: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 12CF73A0BDA for ; Fri, 17 Dec 2021 04:31:24 -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, 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=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 HZFSDTQXm8p1 for ; Fri, 17 Dec 2021 04:31:19 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0203.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1e::203]) (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 854623A0BB6 for ; Fri, 17 Dec 2021 04:31:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j65WUQG+dcDgtgmOk8aSu4Xg9gLnSna+bA1i0EVwOv1NoWIoUpmDweaQvRAQtNGC0sULM18J4Lu8eDc+NVojunstQamgJB3hl3pRlzj2GtG+fuCQg1stKu/wVimJnsiM/d6V/Tpb4yeETrjbNVKwQC2bnliVIhs478ICGIG63HKm4mx37l+stTd+BL11jXUaa5kQSiUjUCfuIcZsoKRf5JPp6T9Zk9j4O7so02E7YjJ/M/Qeu0bWD3/Bidq1UW2+iZXbLZLJz/JyyVPaTU0A33lm4TzGKMGhCoYpwjIJ5cBvcBDuR0oPVlmPrvgPVUZaLVrVm5eIo/erHqJa5ig+ug== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZKbm516VoPp+HJnqPAqOxqCWKPADKd8cdob859xBa/4=; b=iuJ8zTwVlsv/gWDQYmVbcsOguIk1ql2FYlrq9+kYYuhBzW0+GyOiKesnFawpe/d4MlwCJKrP71wmikQuaCmCYwLcMiB/Qf2g/OcNRq+OkHufcnD2/yUnNT2xMX40Nr7R9QHDZ/ZPI2zwAxaAGPKpzi9wpJnFTusJG2W4w/Wo/2KClB6P5w3bHjcDZJjlU6u4K9GLt/jKcfjxJBLRvHe2v5b5VxbWLilyPBNEg0O601wynacOw4VUQV8zTDpLMbRpmKWadq9n3wY8JwcfZ4ZPNVrx7fHZptwvjkSfxFKT6yz6+L+RnEJrOjILpwQqCOL6cd13F66cFcarv5vbyZDljA== 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=ZKbm516VoPp+HJnqPAqOxqCWKPADKd8cdob859xBa/4=; b=Y0xJa49gWEYLtl/6cDmnfk3OVEjsV6iX7fH7uQjjTVigjBTveoi5MmNmMwNfsgd86jFO0mFhAz/y2e/jR8pTOWnjesAz0UduouocNiC6Vg7JjTRVHpbNzUHYzsbmnZRl9VZID4IbX2iHAE+51+C+ZECDpetaxiqyFPGa8cFhPDg= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by DB6PR07MB3222.eurprd07.prod.outlook.com (2603:10a6:6:17::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.8; Fri, 17 Dec 2021 12:31:13 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::719a:2b70:b9fd:d912]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::719a:2b70:b9fd:d912%5]) with mapi id 15.20.4823.008; Fri, 17 Dec 2021 12:31:13 +0000 From: tom petch To: Benoit Claise , =?iso-8859-1?Q?Martin_Bj=F6rklund?= , "kent@watsen.net" CC: "Eric Vyncke (evyncke)" , "netmod@ietf.org" Thread-Topic: [netmod] too long lines from IANA module inclusion Thread-Index: AQHX8IzHmPC3spTH10SI3D6P7GWbN6wxmKcAgAAMcICABPun0g== Date: Fri, 17 Dec 2021 12:31:13 +0000 Message-ID: References: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> <20211214.083324.1824911592330241723.id@4668.se> <3782772c-b5b4-4285-f65e-67b1113e1b07@huawei.com> In-Reply-To: <3782772c-b5b4-4285-f65e-67b1113e1b07@huawei.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: f47629a0-6c6f-528e-f5cc-e662f5a514c1 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 63cb775e-e638-464c-1db3-08d9c1591d19 x-ms-traffictypediagnostic: DB6PR07MB3222:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SrlerGxSET6vLZeI597eTpwM1JtAhY4sh2Dl6NJG8KVWCCIMEHvy3fYCIenaXpkVCG+6vBVqIah0bJjPa2bBa9qsqqGgWivuCXhDSblfdYmwXCuPVYAtWPcq4+2vLfloRaVEjsTLddKsqQzbRqgkNwN4oPC4t8zNeDj/XmpM5y4lGUY4sISNO+Hpz1qM10MrCPArLhE3YqlMvd9EC9v6uqnHuk/HoixBOH1+AIei7DeSqstk3j5ll/AXAtiFvqVAtLQxXDf9xSagNnKdPOSJNAK0vpcD5jj/OB6ZZRCIceyQJ/18dX2m8dqIxLwbdp09SwhShY8H3BHsIZdNJR5Xv7MENqCN4TaJt4uYLCgFGkogLU39zytBVdLIGF7C2NgvfTTn0g5isN5Jvlm+lyg5IDh0K+nxqWACINoZCJ8bVzfg823vj8td9K8YpI2DPRC/cUjfHAfIdC/mRQ5bloNlxDXA48KfIyavHVebeEu1vqh7+2yosupdB7hf41AalTpyJUOT6LhgymGjOKfPJqLTnct3Qx9nZt+2GaiuOPbHPHc4Vxv19+J5oy0m3AFq/fegZwdzqJLovCA9jCX3JgjzCxHGW5yMayqOJutqLFoiKgjMN8brEGHllvCzlMM/Oc+RQ6VT9XUXbSUPWzC6JfsntbDe7sF4TDE3HPvUSmH/EIOmHhCFgPmQNUWyDaTr1XnY7l2qqM1iYWW9Fqxik/GwJdu5ym4y+a0TdmlDQk8VDx4mpLXMwuiuAoAeBItnR/qkE7g+/2/BArXdQnZBDrh/5ZhmtSlh227hgeoqqTAX7GZncNRDR2KICrRpc9498vF6L/UJggtvxbKvhhluvgCtyg== 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:(13230001)(4636009)(366004)(55016003)(82960400001)(110136005)(38100700002)(54906003)(122000001)(2906002)(38070700005)(186003)(76116006)(26005)(316002)(4326008)(33656002)(8676002)(8936002)(66476007)(64756008)(66556008)(66446008)(91956017)(66946007)(4744005)(5660300002)(508600001)(966005)(9686003)(71200400001)(52536014)(83380400001)(86362001)(7696005)(6506007)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?cL3a2h9fjxtFGneuxdOOE8qqV9+TL8WQW20PSXuhkNMlWcE3onozCxEFTV?= =?iso-8859-1?Q?rYqHgpD7fTv1nDXFlIUWwsZd+Lo//lVF1JnAL8C9NHEAEGy+ACGz9wDF7S?= =?iso-8859-1?Q?ErD2a+eojyPn7gSGBLl/QqJ37MFEAwFWGgPmKdIDQJ/DjoZB2qt4UoXcB5?= =?iso-8859-1?Q?cJTcPqsFwUZREo3STFrZrELxEYPf+ERqrfQTbN8+AUIW9hVXrQdSBj53E0?= =?iso-8859-1?Q?Jsb9E2UykUa+BbCJt1i+GDNl2W1MJ12dPdU+FdWaHri5S5cyQRCKR6ttYC?= =?iso-8859-1?Q?nRWQaGakUYcuk4zLFeqnzLfDaa1BSmtVwgXXcIaUQfLvqD81Xp2n0tgJ3x?= =?iso-8859-1?Q?NCpUdiQ6PY+5GdrWiXdchAWZot8ORZoTeBUYEMv0EmwUwD9T8jjxVIW51t?= =?iso-8859-1?Q?4U4hSEhBA+Lycm3v9TDTUWRzNbjj/a++T5FgpfOxFQ3YP2bL7vBqCGZ7iq?= =?iso-8859-1?Q?Ldwr9gSzriuExmjPuwLQnHK27XjVigjlrXwMHVPq2Qp0H2omXm+62vKJOp?= =?iso-8859-1?Q?lP9UPDbswtvuzpKBQdxygIGHouVgRlIInA327RJJiMAo4n+hTu+uTHsFEZ?= =?iso-8859-1?Q?02oNsvVDjkkBT0OBN62lUxdKYp0GzpsZeBytktzKsqdWGeBwmWiIRdKYmX?= =?iso-8859-1?Q?JmTUrAMHm9/viZ1/jt088O8CbZT/K+kUEEYMLG0QB7KF+fd1gaJ0IzijWg?= =?iso-8859-1?Q?Trb1pUW/SBVmkpZ3n/hf9EHyPZumUnc+3GNNWnXe2tLhkOUI7Amg53UMdn?= =?iso-8859-1?Q?sOI5DEpYmFH6mruPQfyAR+JGL4klC98cl+ja0c/0LzcB+kFLAFudaijXgH?= =?iso-8859-1?Q?ULIULSiFzuh5TQXdYjwlGvJc0EGd/t1Td42KtG8CAmtuoPKG2KIP31geuu?= =?iso-8859-1?Q?x3fPlCJoFSbLc1Z2n7xUvI8HkgjsZIKTr8a+Aeo32WCwUKz1TwdmFFt5+W?= =?iso-8859-1?Q?oSuuoOa6Pj8jPY3hPjzf0bmApt4hzT/Yhh0EmOnf19JKODPYzakz/jQdtc?= =?iso-8859-1?Q?qgCeyOBQDB6dxZmp6I7XKxlrMqnJCk67fHf+ooCWVWCRvGmQ79xRweq7o3?= =?iso-8859-1?Q?DqTwOtizWGZ0vGzfcskh1IjHztcuMipFX6YxZEpJ0Tkx1s20GC8USBIv25?= =?iso-8859-1?Q?zumkwkjbWItDsEw2EfUZsssSjI3E8g3WuXYtCGFazINPr5qpJ45Ay2i0hW?= =?iso-8859-1?Q?GOBMVGlsxkUIMFE8cpzZ+DJpnUnqLJvCy8PihFrG2zj/giBv9NcyB0+oSW?= =?iso-8859-1?Q?qEVT3pvpGM6w9+JWuAaGwraxR3Hc5mSFmITni9ExIH19XUPjW1JWhU3brK?= =?iso-8859-1?Q?f16p6N6Z1kIMG++J9clTbyzFLzK+S1gMccVzXocAlr70Evxn6agHjic9XC?= =?iso-8859-1?Q?ut+9Fg5TKhI5gtCzBe5JepqUqtfrN0U+v7wNsad4EcMKRxUIQf6gmXeknH?= =?iso-8859-1?Q?e1I0hWZ2L+q//BQME2gZcv9YRNHXaNIQGSwr+ysYbdcT9F6XiezAtXHa1k?= =?iso-8859-1?Q?sV4MUSEZV6u+GE4QGt5TH4IIxgGOn7UD3YVBgIjBfY3p01nTfdolEWaXBf?= =?iso-8859-1?Q?4tDhekaAIdYC767yvHNa4XxryltuMY6u7zhRvgvVzTf8PtpzZmwXW0hySx?= =?iso-8859-1?Q?G4IBcgg23JEpZQGakFUxQaGDt/9oHnRz9IgSBr/0TuRiWUHkUfah4qBg?= =?iso-8859-1?Q?=3D=3D?= 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: 63cb775e-e638-464c-1db3-08d9c1591d19 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2021 12:31:13.3290 (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: 2ImIJSbI6WHuhyEIrpklQ77jKJJ4me9WHyDfTmOFqoPsB35ZOpySbPTubiCITbo42DromH+UwQ2KE13c6NwIUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3222 Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 17 Dec 2021 12:31:24 -0000 Trimming the cc:=0A= =0A= From: netmod on behalf of Benoit Claise =0A= Sent: 14 December 2021 08:17=0A= =0A= Dear all,=0A= >> `pyang` and I think `yanglint` also know how to extract folded=0A= >> and elements.=0A= > Just a correction; pyang doesn't extract anything, but rfcstrip does,=0A= > and it supports folded artwork, and in the latest greatest 1.3 release=0A= > it even reconizes the proper RFC8792-defined magic strings ;-)=0A= Do we have a couple of IETF drafts with long too long lines, next to=0A= https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/ ?=0A= I would like to make sure that the yangcatalog.org extracts the YANG=0A= module(s) correctly.=0A= Note: the yangcatalog.org uses xym.=0A= =0A= =0A= =0A= Benoit=0A= =0A= I find I2NSF a fruitful source of problems =0A= =0A= draft-ietf-i2nsf-monitoring-data-model-07.txt=0A= has a line of 104ch and somewhere, there or in the early TEAS modules I saw= a 130ch line.=0A= =0A= Tom Petch=0A= =0A= Regards, Benoit=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Fri Dec 17 06:52:20 2021 Return-Path: <0100017dc8e0fcbd-8899bb50-f0bf-4537-a87b-64eb82d9664a-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 6626D3A1158 for ; Fri, 17 Dec 2021 06:52: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 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 ImYZS_CPtjQN for ; Fri, 17 Dec 2021 06:52:13 -0800 (PST) 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 207A43A118E for ; Fri, 17 Dec 2021 06:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639752727; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=kZ6RyDggiFDrFJYZIDD9D6BLBQcLjMlquOihBG0tVuY=; b=cJVIFqlMIQwHMTiY95McOYnpRSQmScsIKDDFFrkZvmKTDOY25IqVCgw7Yqa7kluM iQIYWzug4XqgVmiEgrh3UKi3qIzJzSFS08+VNHY09jMhjMdRX5oKlHAIbrFFJl/HJ1g 3mm0gQycNdBjSpBAD+I3d9luP7CRcYm/GzbV3dGA= From: Kent Watsen Message-ID: <0100017dc8e0fcbd-8899bb50-f0bf-4537-a87b-64eb82d9664a-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A404D447-FC49-4148-A5DC-981C76CAE243" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 17 Dec 2021 14:52:07 +0000 In-Reply-To: <3782772c-b5b4-4285-f65e-67b1113e1b07@huawei.com> Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , Michael Richardson , "Eric Vyncke (evyncke)" , =?utf-8?Q?Slavom=C3=ADr_Maz=C3=BAr?= , =?utf-8?Q?Miroslav_Kov=C3=A1=C4=8D?= , "netmod@ietf.org" To: Benoit Claise References: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> <20211214.083324.1824911592330241723.id@4668.se> <3782772c-b5b4-4285-f65e-67b1113e1b07@huawei.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.17-54.240.48.92 Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 17 Dec 2021 14:52:19 -0000 --Apple-Mail=_A404D447-FC49-4148-A5DC-981C76CAE243 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Benoit, >>> `pyang` and I think `yanglint` also know how to extract folded >>> and elements. >> Just a correction; pyang doesn't extract anything, but rfcstrip does, >> and it supports folded artwork, and in the latest greatest 1.3 = release >> it even reconizes the proper RFC8792-defined magic strings ;-) > Do we have a couple of IETF drafts with long too long lines, next to = https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/ ? > I would like to make sure that the yangcatalog.org extracts the YANG = module(s) correctly. > Note: the yangcatalog.org uses xym. Firstly, I need to echo Martin=E2=80=99s correction, it=E2=80=99s = `rfcstrip` (not `pyang`) that has the support for RFC 8792. I knew it = was one of Martin=E2=80=99s projects, and `pyang` came to mind first... Answering your question, RFC 8792 itself has some examples, as does = draft-ietf-netconf-sztp-csr (which is about to exit IESG review). That = said, in both cases, the YANG modules themselves are not subjected to = wrapping, just the examples are. Kent --Apple-Mail=_A404D447-FC49-4148-A5DC-981C76CAE243 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Benoit,

`pyang` and I think `yanglint` also know how to extract = folded
<artwork> and <sourcecode> elements.
Just a correction; pyang doesn't extract = anything, but rfcstrip does,
and it supports folded = artwork, and in the latest greatest 1.3 release
it even = reconizes the proper RFC8792-defined magic strings ;-)
Do we have a couple of IETF drafts with long too = long lines, next to https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366= bis/ ?
I would like to make sure that the yangcatalog.org extracts = the YANG module(s) correctly.
Note: the yangcatalog.org uses = xym.

Firstly, I need to echo = Martin=E2=80=99s correction, it=E2=80=99s `rfcstrip` (not `pyang`) that = has the support for RFC 8792.  I knew it was one of Martin=E2=80=99s = projects, and `pyang` came to mind first...

Answering your question, RFC 8792 itself has some = examples, as does draft-ietf-netconf-sztp-csr (which is about to exit = IESG review).  That said, in both cases, the YANG modules = themselves are not subjected to wrapping, just the examples = are.

Kent


= --Apple-Mail=_A404D447-FC49-4148-A5DC-981C76CAE243-- From nobody Fri Dec 17 07:11:27 2021 Return-Path: <0100017dc8f257bb-06dfa1ba-4c38-4db6-92eb-ce299024e9e2-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 017813A1190 for ; Fri, 17 Dec 2021 07:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 rGPAM-Ez4HoS for ; Fri, 17 Dec 2021 07:11:13 -0800 (PST) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73DE33A11F8 for ; Fri, 17 Dec 2021 07:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639753865; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=eHMIGMhS/PAlJOpmzxsERBGBbjIno/p2FMb4dYc6pV0=; b=ikSDvAlWuazdgdq9eQCokYDThLtmdswUGhFLCcNpa1mA6Rs9HnPyjoLZosbK/uAE cuP4WHUHr0zl4x38hhMElNZBbs+j4GtDuj3xBTOsEdzNZRjbU5U0xjU/0PafT0eegkG 7+76EFo5WC9T++KZ1MZNteZnjP4cBqReCM0g//g0= From: Kent Watsen Message-ID: <0100017dc8f257bb-06dfa1ba-4c38-4db6-92eb-ce299024e9e2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_561EDD35-F744-4ECA-BEC2-1468E6E59B9B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 17 Dec 2021 15:11:05 +0000 In-Reply-To: Cc: "maqiufang (A)" , "netmod@ietf.org" To: Andy Bierman References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.17-54.240.48.110 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 17 Dec 2021 15:11:17 -0000 --Apple-Mail=_561EDD35-F744-4ECA-BEC2-1468E6E59B9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andy, et. al.,=20 >> I cannot find any RFC text that says has only nodes created = by a client. >=20 > Really? Interesting. Still, I know it=E2=80=99s a mantra we=E2=80=99v= e held closely for many year, right? >=20 > No. Quite the opposite. There was a brouhaha back when I proposed the "keystore=E2=80=9D draft = have an =E2=80=9Caction=E2=80=9D called =E2=80=9Cgenerate-private-key=E2=80= =9D that would insert the generated key into . Claims were = made by prominent members of this list that it=E2=80=99s bad form for = anything but a client to edit . =20 As a result, extensive effort was spent defining a mechanism enabling = the generated key to be returned in the RPC-reply in an encrypted form = (such that only the server that generated the key could decrypt it), all = so the client could immediately return it to the server via a config = push in order to preserve the sanctity of client read-backs. If current claims were true then, why didn=E2=80=99t someone just say = it=E2=80=99s okay since the server is acting like a client under the = hood? K. --Apple-Mail=_561EDD35-F744-4ECA-BEC2-1468E6E59B9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Andy,= et. al., 


I cannot find any RFC text that = says <running> has only nodes created by a = client.

Really?  Interesting.   = Still, I know it=E2=80=99s a mantra we=E2=80=99ve held closely for many = year, right?

No. Quite the opposite. =  <snip>

There was a brouhaha back when I proposed the = "keystore=E2=80=9D draft have an =E2=80=9Caction=E2=80=9D called = =E2=80=9Cgenerate-private-key=E2=80=9D that would insert the generated = key into <running>.  Claims were made by prominent members of = this list that it=E2=80=99s bad form for anything but a client to edit = <running>.  

As a result, = extensive effort was spent defining a mechanism enabling the generated = key to be returned in the RPC-reply in an encrypted form (such that only = the server that generated the key could decrypt it), all so the client = could immediately return it to the server via a config push in order to = preserve the sanctity of client read-backs.

If current claims were true then, why didn=E2=80=99t= someone just say it=E2=80=99s okay since the server is acting like a = client under the hood?

K.

= --Apple-Mail=_561EDD35-F744-4ECA-BEC2-1468E6E59B9B-- From nobody Fri Dec 17 07:38: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 CEAF53A11D7; Fri, 17 Dec 2021 07:38:17 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 emVJplNw8vVl; Fri, 17 Dec 2021 07:38:12 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF693A11C8; Fri, 17 Dec 2021 07:38:12 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JFtRN1R40zDCcK; Fri, 17 Dec 2021 16:38:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <0100017dc8e0fcbd-8899bb50-f0bf-4537-a87b-64eb82d9664a-000000@email.amazonses.com> Date: Fri, 17 Dec 2021 16:38:07 +0100 Cc: Benoit Claise , "netmod@ietf.org" , Michael Richardson , =?utf-8?Q?Slavom=C3=ADr_Maz=C3=BAr?= , =?utf-8?Q?Miroslav_Kov=C3=A1=C4=8D?= , "Eric Vyncke (evyncke)" , rfc-markdown@ietf.org X-Mao-Original-Outgoing-Id: 661448287.335117-3f16815271243274d5fbedd9031bd32a Content-Transfer-Encoding: quoted-printable Message-Id: References: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> <20211214.083324.1824911592330241723.id@4668.se> <3782772c-b5b4-4285-f65e-67b1113e1b07@huawei.com> <0100017dc8e0fcbd-8899bb50-f0bf-4537-a87b-64eb82d9664a-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 17 Dec 2021 15:38:18 -0000 Now you made me curious. No RFCs use RFC 8792 encoding yet (except for RFC 8792 itself), as you = said. I-Ds: "Grant Negotiation and Authorization Protocol", Justin Richer, Aaron Parecki, Fabien Imbault, 2021-10-25, = (Using this for JSON text.) "Problem Details for HTTP APIs", Mark Nottingham, Erik Wilde, Sanjay = Dalal, 2021-10-13, (Using this for JSON text containing a json-schema.org description.) "HTTP Message Signatures", Annabelle Backman, Justin Richer, Manu = Sporny, 2021-08-13, (Using this for examples of Signature-Input, Signature.) draft-ietf-netconf-crypto-types-21.txt, = draft-ietf-netconf-http-client-server-08.txt, = draft-ietf-netconf-https-notif-09.txt, = draft-ietf-netconf-keystore-23.txt, = draft-ietf-netconf-netconf-client-server-24.txt, = draft-ietf-netconf-notification-capabilities-21.txt, = draft-ietf-netconf-restconf-client-server-24.txt, = draft-ietf-netconf-ssh-client-server-26.txt, = draft-ietf-netconf-tls-client-server-26.txt, = draft-ietf-netconf-trust-anchors-16.txt, = draft-ietf-netmod-yang-instance-file-format-21.txt) (Tons of netconf drafts, apparently using this mainly for XML examples = =E2=80=94 I didn=E2=80=99t check all of those.) "Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request", Kent Watsen, Russ Housley, = Sean Turner, 2021-12-03, (As mentioned, for a YANG tree, HTTP requests, JSON text.) "A Layer 2 VPN Network YANG Model", samier barguil, Oscar de Dios, = Mohamed Boucadair, Luis Munoz, 2021-11-22, (YANG JSON instances, again.) "A Layer 3 VPN Network YANG Model", samier barguil, Oscar de Dios, = Mohamed Boucadair, Luis Munoz, Alejandro Aguado, 2021-10-08, (Overly long HTTP requests.) "Structured Data for Filtered DNS", Dan Wing, Tirumaleswar Reddy.K, = Neil Cook, Mohamed Boucadair, 2021-10-13, (JSON.) "List Pagination for YANG-driven Protocols", Kent Watsen, Qin WU, Olof Hagsand, Hongwei Li, Per Andersson, 2021-10-25, "NETCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, = Olof Hagsand, Hongwei Li, Per Andersson, 2021-10-25, "RESTCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, = Olof Hagsand, Hongwei Li, Per Andersson, 2021-10-25, (HTTP requests, some XML.) And, crucially for an implementer, no =E2=80=98\\=E2=80=99 wrapping, = except (unnecessarily!) in draft-ietf-netconf-ssh-client-server-21.txt = (apparently fixed in later versions.) The form =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: '\' line wrapping = per RFC 8792 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (15 equals signs left, 16 equals signs right) seems to be the favorite = lead-in; however, draft-wing-dnsop-structured-dns-error-page-01.txt had = a version indented by 2 characters that has 14+15 accordingly. About 5 = % 10+11, apparently before RFC 8792 was published so there was less = space.) Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn=E2=80=99t = have any =E2=80=9C=3D=3D=3D=E2=80=9C decoration, though. (Why the heck = was this left open as a choice for the author? I like =E2=80=9C%%%=E2=80=9D= decoration instead, should I use that as a personal fashion statement?) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 17 08:31:33 2021 Return-Path: <0100017dc93be244-843adcee-efda-49d4-9814-fbf91153126b-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 E14BC3A0793; Fri, 17 Dec 2021 08:31:30 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 UMpo2KVeinBH; Fri, 17 Dec 2021 08:31:26 -0800 (PST) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5513A078F; Fri, 17 Dec 2021 08:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639758685; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ezijLfQKhQdIBzmCmWmlbWctjMPUh1edGRGe9KRqFko=; b=U7YKMDGepktz8bUnQorpfKwLwZWsV6bPxneo89hoojZU+DqkLKxEZ0uuvv2oUpAs 0VGFFdfMlYt9ptAaeurBvQx4cvmxVM7yUcHQVsl8l9m/dvecTioHb1eUp3qz4pvHcNT JuDa8u1iveGpbUXTY2ID6e8sJWPw1INGDawwD6Qk= From: Kent Watsen Message-ID: <0100017dc93be244-843adcee-efda-49d4-9814-fbf91153126b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_535612DE-D426-46B9-98B6-2329B17BFD53" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 17 Dec 2021 16:31:24 +0000 In-Reply-To: Cc: "netmod@ietf.org" , Benoit Claise , =?utf-8?Q?Slavom=C3=ADr_Maz=C3=BAr?= , =?utf-8?Q?Miroslav_Kov=C3=A1=C4=8D?= , rfc-markdown@ietf.org, Michael Richardson , "Eric Vyncke (evyncke)" To: Carsten Bormann References: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> <20211214.083324.1824911592330241723.id@4668.se> <3782772c-b5b4-4285-f65e-67b1113e1b07@huawei.com> <0100017dc8e0fcbd-8899bb50-f0bf-4537-a87b-64eb82d9664a-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.17-54.240.48.93 Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 17 Dec 2021 16:31:31 -0000 --Apple-Mail=_535612DE-D426-46B9-98B6-2329B17BFD53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > (15 equals signs left, 16 equals signs right) seems to be the favorite = lead-in; however, draft-wing-dnsop-structured-dns-error-page-01.txt had = a version indented by 2 characters that has 14+15 accordingly. About 5 = % 10+11, apparently before RFC 8792 was published so there was less = space.) Undoubtedly because it is the rfcfold = (https://github.com/ietf-tools/rfcfold) default. The goal is to hit = column-69 so as to provide a visual scanning aid. > Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn=E2=80=99t= have any =E2=80=9C=3D=3D=3D=E2=80=9C decoration, though. (Why the heck = was this left open as a choice for the author? I like =E2=80=9C%%%=E2=80=9D= decoration instead, should I use that as a personal fashion statement?) Because sometimes it is desirable for the bracketing to match the native = file commenting syntax (e.g., =E2=80=9C#=E2=80=9C for shell/Python, = =E2=80=9C//=E2=80=9C for C++, =E2=80=9C;=E2=80=9D for ABNF, etc.) K. --Apple-Mail=_535612DE-D426-46B9-98B6-2329B17BFD53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

(15 equals signs left, 16 equals signs right) seems to be the = favorite lead-in; however, = draft-wing-dnsop-structured-dns-error-page-01.txt had a version indented = by 2 characters that has 14+15 accordingly.  About 5 % 10+11, = apparently before RFC 8792 was published so there was less = space.)

Undoubtedly because it is the rfcfold (https://github.com/ietf-tools/rfcfold) default.  The = goal is to hit column-69 so as to provide a visual scanning = aid.


Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) = didn=E2=80=99t have any =E2=80=9C=3D=3D=3D=E2=80=9C decoration, though. =  (Why the heck was this left open as a choice for the author? =  I like =E2=80=9C%%%=E2=80=9D decoration instead, should I use that = as a personal fashion statement?)

Because sometimes it is desirable for the = bracketing to match the native file commenting syntax (e.g., =E2=80=9C#=E2= =80=9C for shell/Python, =E2=80=9C//=E2=80=9C for C++, =E2=80=9C;=E2=80=9D= for ABNF, etc.)

K.

= --Apple-Mail=_535612DE-D426-46B9-98B6-2329B17BFD53-- From nobody Fri Dec 17 08:45: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 3BFCE3A07A4 for ; Fri, 17 Dec 2021 08:45:30 -0800 (PST) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=qwla/MeS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TCOL5TCi 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 UsCGKTTR6IcG for ; Fri, 17 Dec 2021 08:45:25 -0800 (PST) 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 913873A07A9 for ; Fri, 17 Dec 2021 08:45:23 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5CE0A5C022C; Fri, 17 Dec 2021 11:45:22 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 17 Dec 2021 11:45:22 -0500 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=fm3; bh= pkZoIOpPbfJSu8Yg3b2G0n0BR9QfxsHcE2P1hE0yi64=; b=qwla/MeSdiPJggNr 2vK+IP5wfNgX/gOXgTHKGqr6zAnUvSO/qe7r93GK+KMQCXip0I32JtVprL+NYZzD 52hNRe7+5VDsLB+eRQRBrGN3sWW76hqRClLFNN/fSdrnrqQZzVc6ZIzeVqZtYETd GaZdROqJ36Gc0eK9Cn14NyLdOksRWFKVGVbhLdI7r2KELeuhwkrHNwGyajWS1VTV L77tGp8ED0YS2a+xg1sSSmerv2UA5X0FhHt/AiLpzSHH6VdY17J3aKi+j3l1bD6g QZREUjRn9VsGG10c1AiJXHlZDlFQb6Z0+8bTPCy7mHZLHrN3zZezz2WfWlRjB4xd bFhwBA== 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=fm1; bh=pkZoIOpPbfJSu8Yg3b2G0n0BR9QfxsHcE2P1hE0yi 64=; b=TCOL5TCiflZW22X8/Nnt/yq1SLhFSitoRnNkIo6R6hmvnU2xER42M+rRw xEnv/MAoenT1ByfokXJLus3fs760D5/io9vWBwRINh2BNGuRtvt1LFzsRaEhmAvP xzlQ66fptXuLToO6+v2z0MDctDPsOzpDXzXktSaBHgQCT/dNca6xdtlw7c+VSBlI M8UVDu9JYFR05s2Q12s49BMnycxM4tfSmM0TlUrInCenth43ka7HIiftDsW91LCo 9QryfiEShFTn6JJGAgxmM615GmyWSK+m9/p6R3JYD25HrFB46ltgQLWndRUz7L08 /FVUYRP0QyJERXefNH6Zpp/9f/2Ng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleeigdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeehteegtdffgfegffekvdejke evleetuedutddtfffhlefgtedvveehvdeguedtudenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 17 Dec 2021 11:45:20 -0500 (EST) Date: Fri, 17 Dec 2021 17:45:17 +0100 (CET) Message-Id: <20211217.174517.1431385358151692156.id@4668.se> To: kent+ietf@watsen.net Cc: andy@yumaworks.com, maqiufang1=40huawei.com@dmarc.ietf.org, netmod@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <0100017dc8f257bb-06dfa1ba-4c38-4db6-92eb-ce299024e9e2-000000@email.amazonses.com> References: <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <0100017dc8f257bb-06dfa1ba-4c38-4db6-92eb-ce299024e9e2-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 17 Dec 2021 16:45:30 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+IEFuZHks IGV0LiBhbC4sIA0KPiANCj4gDQo+ID4+IEkgY2Fubm90IGZpbmQgYW55IFJGQyB0ZXh0IHRoYXQg c2F5cyA8cnVubmluZz4gaGFzIG9ubHkgbm9kZXMgY3JlYXRlZA0KPiA+PiBieSBhIGNsaWVudC4N Cj4gPiANCj4gPiBSZWFsbHk/ICBJbnRlcmVzdGluZy4gIFN0aWxsLCBJIGtub3cgaXTigJlzIGEg bWFudHJhIHdl4oCZdmUgaGVsZCBjbG9zZWx5DQo+ID4gZm9yIG1hbnkgeWVhciwgcmlnaHQ/DQo+ ID4gDQo+ID4gTm8uIFF1aXRlIHRoZSBvcHBvc2l0ZS4gIDxzbmlwPg0KPiANCj4gVGhlcmUgd2Fz IGEgYnJvdWhhaGEgYmFjayB3aGVuIEkgcHJvcG9zZWQgdGhlICJrZXlzdG9yZeKAnSBkcmFmdCBo YXZlIGFuDQo+IOKAnGFjdGlvbuKAnSBjYWxsZWQg4oCcZ2VuZXJhdGUtcHJpdmF0ZS1rZXnigJ0g dGhhdCB3b3VsZCBpbnNlcnQgdGhlIGdlbmVyYXRlZA0KPiBrZXkgaW50byA8cnVubmluZz4uICBD bGFpbXMgd2VyZSBtYWRlIGJ5IHByb21pbmVudCBtZW1iZXJzIG9mIHRoaXMNCj4gbGlzdCB0aGF0 IGl04oCZcyBiYWQgZm9ybSBmb3IgYW55dGhpbmcgYnV0IGEgY2xpZW50IHRvIGVkaXQgPHJ1bm5p bmc+Lg0KDQpUaGUgcHJvYmxlbSB3aXRoIGFuIGFjdGlvbiB0aGF0IGlzIHN1cHBvc2VkIHRvIG1v ZGlmeSB0aGUgcnVubmluZw0KY29uZmlnIGlzIHRoYXQgaXQgYWxzbyBoYXMgdG8gYmUgcHJlcGFy ZWQgdG8gaGFuZGxlIHN5c3RlbXMgd2l0aA0KPGNhbmRpZGF0ZT4sIGhhbmRsZSBsb2NrcyBldGMu ICBBbmQgaWYgeW91IGRvbid0IGhhdmUgPGNhbmRpZGF0ZT4geW91DQptYXkgd2FudCB0byBhZGQg dGhlIHByaXZhdGUta2V5IHRvZ2V0aGVyIHdpdGggb3RoZXIgZGF0YSBpbiBvbmUgZ287DQp0aGlz IGlzIG5vdCBwb3NzaWJsZSBpZiBpdCB3YXMgYWRkZWQgYnkgYW4gYWN0aW9uLg0KDQpGb3IgdGhl IHB1cnBvc2Ugb2YgYWRkaW5nICJidWlsdC1pbiBsaXN0IGluc3RhbmNlcyIgKHdoaWNoIHNlZW1z IHRvIGJlDQp0aGUgdXNlIGNhc2UgZm9yIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiksIEkgdGhpbmsg dGhlIGZhY3RvcnktZGVmYXVsdA0KZGF0YXN0b3JlIGNhbiBiZSB1c2VkLiAgKHRoaXMgaXMgYWN0 dWFsbHkgYmV0dGVyIHRoYW4gdGhlIHNlcnZlcg0KImFjdGluZyBhcyBhIGNsaWVudCIpLg0KDQoN Ci9tYXJ0aW4NCg0KDQo+IA0KPiBBcyBhIHJlc3VsdCwgZXh0ZW5zaXZlIGVmZm9ydCB3YXMgc3Bl bnQgZGVmaW5pbmcgYSBtZWNoYW5pc20gZW5hYmxpbmcNCj4gdGhlIGdlbmVyYXRlZCBrZXkgdG8g YmUgcmV0dXJuZWQgaW4gdGhlIFJQQy1yZXBseSBpbiBhbiBlbmNyeXB0ZWQgZm9ybQ0KPiAoc3Vj aCB0aGF0IG9ubHkgdGhlIHNlcnZlciB0aGF0IGdlbmVyYXRlZCB0aGUga2V5IGNvdWxkIGRlY3J5 cHQgaXQpLA0KPiBhbGwgc28gdGhlIGNsaWVudCBjb3VsZCBpbW1lZGlhdGVseSByZXR1cm4gaXQg dG8gdGhlIHNlcnZlciB2aWEgYQ0KPiBjb25maWcgcHVzaCBpbiBvcmRlciB0byBwcmVzZXJ2ZSB0 aGUgc2FuY3RpdHkgb2YgY2xpZW50IHJlYWQtYmFja3MuDQo+IA0KPiBJZiBjdXJyZW50IGNsYWlt cyB3ZXJlIHRydWUgdGhlbiwgd2h5IGRpZG7igJl0IHNvbWVvbmUganVzdCBzYXkgaXTigJlzDQo+ IG9rYXkgc2luY2UgdGhlIHNlcnZlciBpcyBhY3RpbmcgbGlrZSBhIGNsaWVudCB1bmRlciB0aGUg aG9vZD8NCj4gDQo+IEsuDQo+IA0K From nobody Fri Dec 17 09:12: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 CFACE3A0866; Fri, 17 Dec 2021 09:12:52 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 KhByEFKaFFht; Fri, 17 Dec 2021 09:12:48 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700883A086F; Fri, 17 Dec 2021 09:12:47 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JFwXW6gzHzDCbW; Fri, 17 Dec 2021 18:12:43 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <0100017dc93be244-843adcee-efda-49d4-9814-fbf91153126b-000000@email.amazonses.com> Date: Fri, 17 Dec 2021 18:12:43 +0100 Cc: "netmod@ietf.org" , Benoit Claise , =?utf-8?Q?Slavom=C3=ADr_Maz=C3=BAr?= , =?utf-8?Q?Miroslav_Kov=C3=A1=C4=8D?= , rfc-markdown@ietf.org, Michael Richardson , "Eric Vyncke (evyncke)" X-Mao-Original-Outgoing-Id: 661453963.289202-ad4f3007dc7d02d7e7014cc53b683a28 Content-Transfer-Encoding: quoted-printable Message-Id: <9B95F768-DA2B-48CA-A66F-F406AECFCE08@tzi.org> References: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> <20211214.083324.1824911592330241723.id@4668.se> <3782772c-b5b4-4285-f65e-67b1113e1b07@huawei.com> <0100017dc8e0fcbd-8899bb50-f0bf-4537-a87b-64eb82d9664a-000000@email.amazonses.com> <0100017dc93be244-843adcee-efda-49d4-9814-fbf91153126b-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 17 Dec 2021 17:12:53 -0000 On 2021-12-17, at 17:31, Kent Watsen wrote: >=20 >> Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn=E2=80=99= t have any =E2=80=9C=3D=3D=3D=E2=80=9C decoration, though. (Why the = heck was this left open as a choice for the author? I like =E2=80=9C%%%=E2= =80=9D decoration instead, should I use that as a personal fashion = statement?) >=20 > Because sometimes it is desirable for the bracketing to match the = native file commenting syntax (e.g., =E2=80=9C#=E2=80=9C for = shell/Python, =E2=80=9C//=E2=80=9C for C++, =E2=80=9C;=E2=80=9D for = ABNF, etc.) But those tools never see that header. (Or are there examples where you can safely feed a folded block to a = tool?) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 17 09:21:33 2021 Return-Path: <0100017dc969ae58-dd8363d6-f0e4-4da1-8291-3a5b16eccb07-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 F3BD33A0886; Fri, 17 Dec 2021 09:21:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 P7GRXUqc7zWb; Fri, 17 Dec 2021 09:21:27 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A593A07B7; Fri, 17 Dec 2021 09:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639761686; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=UKrX83+Rhqtx2gF4USR1pLJibTIhyx/kFRZTIz+EhUo=; b=ezLNdcz93XLay5D6/NwNVV9sfih6G2utS7EGj9yv60eipQCSWZ7AmY/VkaFMmZkv HWVXaCImJ6VgqWmlj6ybagUQAKVbMnLj09NGohs9ZBdpITN4PGkC54LdIKNBou4yrIV dQlUfXEA10TwLRUBlaQipNk3YDJk2C5EuoRnNyv4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: <9B95F768-DA2B-48CA-A66F-F406AECFCE08@tzi.org> Date: Fri, 17 Dec 2021 17:21:26 +0000 Cc: "netmod@ietf.org" , Benoit Claise , =?utf-8?Q?Slavom=C3=ADr_Maz=C3=BAr?= , =?utf-8?Q?Miroslav_Kov=C3=A1=C4=8D?= , rfc-markdown@ietf.org, Michael Richardson , "Eric Vyncke (evyncke)" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017dc969ae58-dd8363d6-f0e4-4da1-8291-3a5b16eccb07-000000@email.amazonses.com> References: <43BBAD20-D816-4D01-8326-1D67185CCC19@tzi.org> <24856.1639347093@localhost> <0100017db6a106f8-a9773885-6347-4fd6-a2d6-69ec6941bc7b-000000@email.amazonses.com> <20211214.083324.1824911592330241723.id@4668.se> <3782772c-b5b4-4285-f65e-67b1113e1b07@huawei.com> <0100017dc8e0fcbd-8899bb50-f0bf-4537-a87b-64eb82d9664a-000000@email.amazonses.com> <0100017dc93be244-843adcee-efda-49d4-9814-fbf91153126b-000000@email.amazonses.com> <9B95F768-DA2B-48CA-A66F-F406AECFCE08@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.17-54.240.8.88 Archived-At: Subject: Re: [netmod] too long lines from IANA module inclusion 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, 17 Dec 2021 17:21:32 -0000 Hi Carsten, >>> Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn=E2=80=99= t have any =E2=80=9C=3D=3D=3D=E2=80=9C decoration, though. (Why the = heck was this left open as a choice for the author? I like =E2=80=9C%%%=E2= =80=9D decoration instead, should I use that as a personal fashion = statement?) >>=20 >> Because sometimes it is desirable for the bracketing to match the = native file commenting syntax (e.g., =E2=80=9C#=E2=80=9C for = shell/Python, =E2=80=9C//=E2=80=9C for C++, =E2=80=9C;=E2=80=9D for = ABNF, etc.) >=20 > But those tools never see that header. > (Or are there examples where you can safely feed a folded block to a = tool?) Not always. The draft specifically allows for manual/smart folding to = give better results than simple automation: See = https://datatracker.ietf.org/doc/html/rfc8792#section-9.3 for more = examples. K. From nobody Fri Dec 17 09:28:00 2021 Return-Path: <0100017dc96f8f98-8c0cebc9-6ef4-4618-ab39-aef0a103c49c-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 0131D3A088A for ; Fri, 17 Dec 2021 09:27:58 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 XRGurbzxMJe3 for ; Fri, 17 Dec 2021 09:27:53 -0800 (PST) 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 091233A07B7 for ; Fri, 17 Dec 2021 09:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1639762071; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=yPkb6ejtJFCxs7p+5BE9qDsVdoAKGv9weVC2Iu5IlSo=; b=CvQvKSLTJ+QzoJ4lxji3eC6HAE0naeVVSjK3VqEY0s1jyOr4BILBJ2Zwxh8IbRXe scU+F3QJ0+vOjqJZERq8M02jUoxw794oaE4AuGjPJWwOe2IPh2uPBD1aEhSxGp/uwYi EGIvsxd3DTSjqMCZAdzypu+xUGc23BnF+a3hHr98= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: <20211217.174517.1431385358151692156.id@4668.se> Date: Fri, 17 Dec 2021 17:27:51 +0000 Cc: Andy Bierman , maqiufang1=40huawei.com@dmarc.ietf.org, "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017dc96f8f98-8c0cebc9-6ef4-4618-ab39-aef0a103c49c-000000@email.amazonses.com> References: <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <0100017dc8f257bb-06dfa1ba-4c38-4db6-92eb-ce299024e9e2-000000@email.amazonses.com> <20211217.174517.1431385358151692156.id@4668.se> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.17-54.240.48.92 Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 17 Dec 2021 17:27:58 -0000 >>>> I cannot find any RFC text that says has only nodes = created >>>> by a client. >>>=20 >>> Really? Interesting. Still, I know it=E2=80=99s a mantra we=E2=80=99= ve held closely >>> for many year, right? >>>=20 >>> No. Quite the opposite. >>=20 >> There was a brouhaha back when I proposed the "keystore=E2=80=9D = draft have an >> =E2=80=9Caction=E2=80=9D called =E2=80=9Cgenerate-private-key=E2=80=9D = that would insert the generated >> key into . Claims were made by prominent members of this >> list that it=E2=80=99s bad form for anything but a client to edit = . >=20 > The problem with an action that is supposed to modify the running > config is that it also has to be prepared to handle systems with > , handle locks etc. And if you don't have you > may want to add the private-key together with other data in one go; > this is not possible if it was added by an action. If the RPC/action backend were a client, then that client would be = subject to locks/etc. too and, if unable to acquire after some timeout = amount of time, could return an RPC-error, right? But, again, I thought = the hesitation surrounded client read backs, perhaps I misunderstood at = the time... > For the purpose of adding "built-in list instances" (which seems to be > the use case for the proposed solution), I think the factory-default > datastore can be used. (this is actually better than the server > "acting as a client"). Two issues: 1) those nodes need to be immutable. (See separate thread with = =E2=80=9Cimmutable=E2=80=9D in Subject line) 2) there are many hundreds of such objects in JUNOS. It would be a lot = of clutter in . K. From nobody Fri Dec 17 10:06: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 5661F3A04BC for ; Fri, 17 Dec 2021 10:06:16 -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.20210112.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 qppp-XaXn0cs for ; Fri, 17 Dec 2021 10:06:11 -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 46BCE3A0483 for ; Fri, 17 Dec 2021 10:06:11 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id l7so4660967lja.2 for ; Fri, 17 Dec 2021 10:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ARE/M2C7BcVNil5mMSCRATeS8VXg7uQ01M/QkHXOm3A=; b=Cxwty9TY2NQHvLdfyFCKXB4EckYject0fzhhpuhUlow8VkLsWOMtpfXbKOeT7Gt4Lu viDV5Yn1d+iDzwWSMUVkOsxvv+Tf8/PQc1+kD4sgNfFSbJ5JO6/EkLO6DBa0NcdYDgwa QkHmfbmghnol7+SlFR3UNyXwqb9Sa08RWg8eRLv72caw46UpgnCgKnvD3cL+Eq/NUWqj aEjkiuAmcw7XhiIYUHlTETRiFbA04fUwnHiCjCBRkKlW0fPn1cYzYqzISHM03rIHMZUg rBnpYfppH8LOmTkCJ8LDOWm2oHAstjBSew2DyqY9270W1TZinVlRC3yIdD6LR+PpyxNg 8YKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ARE/M2C7BcVNil5mMSCRATeS8VXg7uQ01M/QkHXOm3A=; b=ff7xQikEuXHPpCeS/BFPGYaWl0KSnJ5eJkSvyaeEMcshTnwrQalHeoYokd/zT70Z7E /jVbJnyUU9pYGfKr8rbYxf2g6JoFqa4oQ5vFUwQP7Ks8PTZzoBgVAb8LICCCNWGze74M HWLyXQ0Gy7IuQzDxoxCyrD+S4hYde625R28YqyfP5Yp0CbEdFy1esJ3/vLU58dX+cQk/ A2orwwXUUOS71bw97PoBI7AUamXjYQn0NlmpjI7b4ZziHm7YmldKiRkV664boHsPXRpg Qwfp6YxaPSEGFAvQFZS1fmPAo24BSPdN+G5cHWHSYmqzb2DbDjGuKiNHxg3dayB7hnqr MbfA== X-Gm-Message-State: AOAM5323s6IE0jgVK2Yd4R3ZHLPl1h7xYPJStBY+8Z5Hh0qYgAGsMrBT 1YrvlU9gmzJtHvUYW4b087s8iLAeh0JO3yUBPpZwEQ== X-Google-Smtp-Source: ABdhPJwTNajavCkxmD2X87dfyxGfSJwqv9UR2KGidFz7bDh3COyR0hpdJbCWoLIjhFLO9UrgnxBIyZxD9yVasMVx+Ns= X-Received: by 2002:a05:651c:90:: with SMTP id 16mr3661776ljq.1.1639764367815; Fri, 17 Dec 2021 10:06:07 -0800 (PST) MIME-Version: 1.0 References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <0100017dc8f257bb-06dfa1ba-4c38-4db6-92eb-ce299024e9e2-000000@email.amazonses.com> In-Reply-To: <0100017dc8f257bb-06dfa1ba-4c38-4db6-92eb-ce299024e9e2-000000@email.amazonses.com> From: Andy Bierman Date: Fri, 17 Dec 2021 10:05:56 -0800 Message-ID: To: Kent Watsen Cc: "maqiufang (A)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a8cab005d35b640e" Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 17 Dec 2021 18:06:17 -0000 --000000000000a8cab005d35b640e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 17, 2021 at 7:11 AM Kent Watsen wrote: > Andy, et. al., > > > I cannot find any RFC text that says has only nodes created by = a >> client. >> >> >> Really? Interesting. Still, I know it=E2=80=99s a mantra we=E2=80=99v= e held closely >> for many year, right? >> > > No. Quite the opposite. > > > There was a brouhaha back when I proposed the "keystore=E2=80=9D draft ha= ve an > =E2=80=9Caction=E2=80=9D called =E2=80=9Cgenerate-private-key=E2=80=9D th= at would insert the generated key > into . Claims were made by prominent members of this list that > it=E2=80=99s bad form for anything but a client to edit . > > As a result, extensive effort was spent defining a mechanism enabling the > generated key to be returned in the RPC-reply in an encrypted form (such > that only the server that generated the key could decrypt it), all so the > client could immediately return it to the server via a config push in ord= er > to preserve the sanctity of client read-backs. > > If current claims were true then, why didn=E2=80=99t someone just say it= =E2=80=99s okay > since the server is acting like a client under the hood? > Maybe not a lot of non-security people were following the thread. IMO a better design would have been to introduce a "secure-NV-storage" concept. The keys are never exposed. Only labels are exposed and the client can store a reference to the key in . Maybe Juergen proposed this idea. YANG-based management assumes that the conceptual API for a YANG device can be described by all the [module, revision, features, deviations] tuples (YANG library). There was an original assumption that could contain all the information to describe this "real API". The original design was too simplistic so NMDA introduced and datastores. Now no longer represents the "real API". It now contains some or all of the information required to produce the real API, which is now deemed to be . Not one of the mechanisms to transform into is standardized. Now + ??? is a combination of the real API and the "proprietary setup API". It has never been true that is always valid. In hindsight, that MUST is really a SHOULD, post-NMDA. Inactive nodes cannot be counted against constraints (e.g. must, min/max-elements, unique). Constraints on config templates do not address the needed constraints on the expanded data. IMO it is too late "fix" by placing any restrictions on the contents or who can edit it. NMDA (wisely) did not do it. A "system edit" is difficult to describe, especially in a controller-driven bootstrap framework. The immuable issue is just hidden access control, so tag data nodes with new metadata to expose that. > K. > Andy --000000000000a8cab005d35b640e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 17, 2021 at 7:11 AM Kent = Watsen <kent+ietf@watsen.net> wrote:
Andy, et. al.,=C2=A0

=

<= div>
I cannot find any RFC text that says <running> has only node= s created by a client.

<= div>Really?=C2=A0 Interesting. =C2=A0 Still, I know it=E2=80=99s a mantra w= e=E2=80=99ve held closely for many year, right?

No. Quite the opposite. =C2=A0<snip>






The original design was too simplistic so NMDA introduced <intended&g= t; and <operational> datastores.
Now <running> no lon= ger=C2=A0represents the "real API". It now contains some or all o= f the information required
to produce the real API, which is now = deemed to be <intended>.

Not one of the mech= anisms to transform <running> into <intended> is standardized.<= /div>
Now <running>=C2=A0+ ??? is a combination of the real API a= nd the "proprietary setup API".

It has n= ever been true that <running> is always valid. In hindsight, that MUS= T is really a SHOULD, post-NMDA.
Inactive nodes cannot be counted= against constraints=C2=A0(e.g. must, min/max-elements, unique).
= Constraints on config templates do not address the needed constraints on th= e expanded data.

IMO it is too late "fix= " <running> by placing any restrictions on the contents or who c= an edit it.
NMDA (wisely) did not do it.=C2=A0 A "system edi= t" is difficult to describe,
especially in a controller-driv= en bootstrap framework.=C2=A0 The immuable issue
is just hidden a= ccess control, so tag data nodes with new metadata to expose that.



=
K.


<= div>Andy
=C2=A0
--000000000000a8cab005d35b640e-- From nobody Fri Dec 17 11:51: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 A00E53A0983 for ; Fri, 17 Dec 2021 11:51:08 -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, 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 4PCGgjh_Lh5A for ; Fri, 17 Dec 2021 11:51:02 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2100.outbound.protection.outlook.com [40.107.92.100]) (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 344313A0981 for ; Fri, 17 Dec 2021 11:51:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JsDN1nslr+9J5bpIRMNxZeZMOOTc9HknbmiFW5P6p3HNcOb2XIzBtnLs8hxdt0p2mlCltbbS0RQFoEIUG0HzkN4j3yatkqhdtJQQMBztH9K4cQeB7JkBiQw1kiCGg5SW8Y/htIqzZPevXGm6EGyyxsygduAZkcuqCQB5uDndxiSiz3EWVJN+4sKxCHxxloBafKkMhq38y6hwp5wzUBCu4zDFOt3uuxx7G7BWXVg/lnrEHhMBROzu2UQaoFFtXzeOfjGo2eemsZMw8fADwk+qGTbTbHhIzqlWj6gOGJrjx7m1630tkCiYeFFSGPinQuH9C7LTNbN03Z/Eterysy45rw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UQGkD1kne4MVQTYYcwlycb4k6QHnrBzXr5qkFgixLlw=; b=ee2AVBAuPTheyTmezfV7wJi+faGz0jxQ9RWDXVPSWxfSty8vTSVHdWRKE2xGLDsp8ywZiK4LQw8UM9fhiL8uS7F/Q4RXVvcm4XVkJLV5tzF7xAghCZoZvAL2mQ5u9dxJRnDSG2UtNeChIvyOvoGxfLpDWjlzCFl+1yAns+3eSNHJn0847H2MbZwjfZAmPcSdQ0lYGT2chgc+pu9lJCQEiLqXzEYgk1C6ueU7b14gHEUUh40uZuklMezIo1fW44Y3LfeyErR7lwRwdgoNbQn0rCElDtZH16LaiHzC9wfLMt1wbc8YbdciDgyELIlX9MofTsgsR1PFg8oewoO36dwa9g== 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=UQGkD1kne4MVQTYYcwlycb4k6QHnrBzXr5qkFgixLlw=; b=M3v7tnHQyqD3eLqlcjgLzlWj9ClJBpp3YQgQ4pQWwm1t9ciGEQszShNVyJkhGXnhbmN/X0+nAFBuqrsyYht5DzCX6zKFfg3BXkolCy70HOhZJMRMZl8wkgR2Ma1w7xpiEenjfyzXM9lzrwGlUkb1TJYOIOOpYi+Ezyr2VJnTYrI= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6058.namprd08.prod.outlook.com (2603:10b6:5:10e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.17; Fri, 17 Dec 2021 19:50:54 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4778.018; Fri, 17 Dec 2021 19:50:54 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-12-14 Thread-Index: Adfzf1XDpVI0uDRBSFuJ8f0pP+vREA== Date: Fri, 17 Dec 2021 19:50:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: daa3a601-8f24-4d99-ff53-08d9c196893f x-ms-traffictypediagnostic: DM6PR08MB6058:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WUayq/hVxX9ew6KIv2m9045BHsfC1D+KDIl2hxORIuAZXsMqYARfLYWg3e8S4iZjbm0uTFTGD9b+iuhp+0eaY+jB1aRbclOgf8XjrEctxVJNKd+rqF6lNX2+PQvatwXV/tuvaOU7Zi/pm/wRC3TkrcuHhv4wVJKIJ+aB+L3X4ksPI/dSnUQa0ARnvId+jy+f81eUQDxqRqnQV1Y6en/rrESWJj6x0RMAdFzYWQ6HapCVGLVvKvvV47m/17tBnelfyX9JtRcjMzdA53biV7hM1BltGeUALZAmqOG+1MMfNoeF/ngeclsmqmyLLvy2PRQZhlgNqzKIkmYd0hUm6gU5WJM9VpjOYWU8W59j4WJMpiP2OFXNOU67lc5bsVwcSqjVZSZ6WTWcgbA0u4joNKZnFKY1Fm4kXx2R6Tyrd49oLRHaAqw7L497csSSZazj+aOM4UX+7wkUxjSVmq8yKR867F8LLoFir8UlJjpKiv5l5aHrvOjvSe3lVtVuRoiez53nXdCvUKRSKv0TVFXtctlNC9z5VaM+8WMtICqP3cXzqSh7a+edXk91iJ0OD47YAPmBJGKN7051H6HC3LQJCgxByFY/8OaubTOEA/dzx9g3+m7n3eAIQNMB1lvpV0RzghyZJQ6D6farrOPrAnHY0Mrn+xtXMAmCvlo842HKtv/x/1l9S3l3rkcP6lNOp22ONItvWs6N1Qp3citqdpYR91quA+xkp1E80XpxSvAoYyNctPWFBlF2lJ9FSFbRZXrfCQBN5TQq4pJEriirO9WhJoczUGyRaymtR0rLhve4EjKCQIw= 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)(366004)(64756008)(66476007)(66556008)(66446008)(8936002)(7696005)(52536014)(166002)(16799955002)(5660300002)(2906002)(6916009)(8676002)(38070700005)(122000001)(38100700002)(82960400001)(316002)(40140700001)(186003)(33656002)(9686003)(76116006)(86362001)(508600001)(966005)(66946007)(55016003)(83380400001)(4001150100001)(6506007)(26005)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?rnN0UWkeQr+IVmQ39NanYXDEKGOxj03P0YkURMkJczN6qXDXS02Yxx2Q+6db?= =?us-ascii?Q?cIZdp1LLUuR8/0RJc0dsYtseM4JqqHvb2ixah1ZJb8WK6au6unu/C+UUpT6V?= =?us-ascii?Q?7u08HV2TbnPHE6f4PgHmolVruMPY20Wmvje7IyNE/sLP/zuTPgJUvWgXuZMt?= =?us-ascii?Q?wxGoXy9cnoxa6pzp1Kx0hIkNKRLNPacrZZiLIULIX030GrFbjZPNPJKNPR4x?= =?us-ascii?Q?o43wks9YW6hZ5z5q9LH620XBdU4xkoQ8zDBjopNbVgz/NGX528ampP1g9hfn?= =?us-ascii?Q?wBUyTEyLvw7fjEFVMVNiDNL+WaH670vBf9scLKkMorVHwnprbira7t26uSOe?= =?us-ascii?Q?fkqYsCEcDWQrpvMEMBuqnVyWfV952WkhXgFcxBYuNpYRvfIHdFBj9k5J2rpf?= =?us-ascii?Q?nblSae6YB4aLwrcx+diHQE2OOkCqAxXf259mMtx9wqrYkaQxU+nv05OtKx7N?= =?us-ascii?Q?kMe/HAosTCb+tW3YRVFSDyFYdm0czqQmrLDQKPwXeTMjnAvwBB/hYMpETJEa?= =?us-ascii?Q?bfAQjIjXDLixBI514WH/tz+f/ONNSSbSnwVOsroLDvqv1exyzAkZHcdLxj0Y?= =?us-ascii?Q?YZZrtTnT1Woj4auaH2y4Ofo0gwBkRx2OwmegyEZtQcXWfLmvJUzWGzERR/D6?= =?us-ascii?Q?AFIw/8zq8YzdITnjC9GGaN0PG6oPkEx0WskLORazKARhyBHPPqQEmDeB3H2H?= =?us-ascii?Q?UliUhB7A4YutcdcX+fNXCBRv9XNx4ziptnH0LiYGYcyF1DKJF4Wl1rv+cG0K?= =?us-ascii?Q?tjCuOOhSQ2BL1h5wUVt3tDSlKYTURbYZXeasM96CBCAx3xRLrvy2CsT32+d1?= =?us-ascii?Q?hoR9wXN8DFcKGYqJFQf+3A23Ef54idbHpmyUWQABjWvaCAk7QDwi8Bf7IkdT?= =?us-ascii?Q?M4FdBGedIn/Zd4CszyRY6knuAceNSfrRFc7+fvtHE6THLpUIiSE4fbVer/dX?= =?us-ascii?Q?D5i29l1NrJ+DmL5CbWCpdzbcP1laG5nL49Vmqv8anc7QOsSh60/mtDpIQbDh?= =?us-ascii?Q?9Ig0a0ofjkDD8R7JiRtN1q7U4CIB8U1xD+mj/9u1TnaA8ACLNFZ03+nB9JPH?= =?us-ascii?Q?gXA3PvJ4OdXoP45gFiLaNRKJcHk/A6B/pty9tQySERXQWcsa8iQvgGd9nKFg?= =?us-ascii?Q?HNKvejAbykEJP3sSXK158KcwmOEJKNPBWe9xT0y4JnRGtORj2E7eBrxyphpQ?= =?us-ascii?Q?E2xWgx99EErueJPhJ1RDNLqRDQDS4cKooNA16AY1MqwsPD99bAXvmcqI5Pz3?= =?us-ascii?Q?ng6tym2i283n0E+yKPaf820khk1Z9HnFY4Dm3yxTP3IIx2FmDyKdTU/TROCs?= =?us-ascii?Q?kCIgA6kEMoj8FQccMfxCd90/W2K9jX+y/enhuZ4rBqr7uc960d+XV0CNhxme?= =?us-ascii?Q?2ixGulAU7T0eztjtUBzsT39rLH+3zzX9aLqDEkPtTxlDwHZ/M2YhV1HCK7e2?= =?us-ascii?Q?SVvvNrq11/Kk4BFmWwGw6dP+mZGQHCLYflwpI6EXBRH/7pdBcc2u4++A/xLB?= =?us-ascii?Q?U9T5pf1h/mXX4RKCfuz8ad6JBmtfhYP8C8KI4sQmQVaAZ5fGD+ev4Ym0Nem8?= =?us-ascii?Q?fnR5XaMkQxXnCOkDAEPCMHGUwBQM4+JYGWKxw/qLyfLFyV3s8qqgtU79no5M?= =?us-ascii?Q?/w=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084B21E3367723B982AA1B69B789DM6PR08MB5084namp_" 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: daa3a601-8f24-4d99-ff53-08d9c196893f X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2021 19:50:54.0174 (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: pJ10MZpeABJnSzg8c87sigNjfIgErq+qTZY0Y6PAdJLCxNlE5SGjFEI3PXpz+JilhPHjuFXmBx6stIG5sA6hgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6058 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-12-14 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, 17 Dec 2021 19:51:09 -0000 --_000_DM6PR08MB5084B21E3367723B982AA1B69B789DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-12-14 Jason: announce Dec 21 and 28 weekly calls are cancelled The primary discussions were around issues #67/#69 - relationship between P= ackages and yang-library (two options compared: p-02 and J1). Some notes fr= om the discussion: - unclear exactly how schema mount information would compare between option= s p-02 and J1 (we decided to defer this discussion and come back if needed) - union of packages must be equivalent schema to union of all module-sets. = Need to make sure this is clear in Packages draft. - people may augment library, then they would have to augment packages - overloading module-sets may be confusing (not heirarchical, whereas packa= ges is intended to be heirarchical) - in the packages draft we'll need to give example module & package discove= ry (library in 2 variants, netconf monitoring) We concluded that we should continue with the current packages draft and no= t switch directions to option "J1". There wasn't enough clear advantage to = J1 that we could identify after some analysis and discussion. But the analy= sis/comparison raised a few issues that we need to tackle & clarify in the = packages draft (especially an example walk-through of client workflow/behav= ior for discovery). Action items remaining from previous meetings: #29: TBD (package deviation example) #30: Jason #32: TBD (what does metadata mean) #38: Rob #57: TBD (schema mount) #63: Reshad #64: Jason #65: Balazs #66: Jason #67/#69: Jan #70: (deviations in Pkg): Jan #74: (JTS review comments): TBD. Jason to update with various decisions #76: Reshad to refresh on this and we'll discuss in future meetings #82: Bo - done/closed #84: Jason - done/closed #97: (submodules) Jason #105: (remove previous-version & nbc-changes) Bo New issue (Bo): use "version" for packages everywhere in the draft, not "re= vision" (but keep "revision" for modules). Note that packages will still u= se a "revision-label" and a "revision-label-scheme". Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 161 096 5630 Meeting password: semver? Occurs every Tuesday effective Tuesday, November 16, 2021 from 9:00 AM to 1= 0:00 AM, (UTC-05:00) Eastern Time (US & Canada) 9:00 AM | (UTC-05:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dme2c6491ebcc37b8127c1244d244d2754 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1610965630## Call-in toll number (US/Canada) --_000_DM6PR08MB5084B21E3367723B982AA1B69B789DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-12-14

 

Jason: announce Dec 21 and 28 weekly calls are cance= lled

 

The primary discussions were around issues #67/#69 -= relationship between Packages and yang-library (two options compared: p-02= and J1). Some notes from the discussion:

- unclear exactly how schema mount information would= compare between options p-02 and J1 (we decided to defer this discussion a= nd come back if needed)

- union of packages must be equivalent schema to uni= on of all module-sets. Need to make sure this is clear in Packages draft.

- people may augment library, then they would have t= o augment packages

- overloading module-sets may be confusing (not heir= archical, whereas packages is intended to be heirarchical)

- in the packages draft we'll need to give example m= odule & package discovery (library in 2 variants, netconf monitoring)

 

We concluded that we should continue with the curren= t packages draft and not switch directions to option "J1". There = wasn't enough clear advantage to J1 that we could identify after some analy= sis and discussion. But the analysis/comparison raised a few issues that we need to tackle & clarify in the packages d= raft (especially an example walk-through of client workflow/behavior for di= scovery).

 

Action items remaining from previous meetings:<= /o:p>

 

#29: TBD (package deviation example)

#30: Jason

#32: TBD (what does metadata mean)

#38: Rob

#57: TBD (schema mount)

#63: Reshad

#64: Jason

#65: Balazs

#66: Jason

#67/#69: Jan

#70: (deviations in Pkg): Jan

#74: (JTS review comments): TBD. Jason to update wit= h various decisions

#76: Reshad to refresh on this and we'll discuss in = future meetings

#82: Bo - done/closed

#84: Jason - done/closed

#97: (submodules) Jason

#105: (remove previous-version & nbc-changes) Bo=

New issue (Bo): use "version" for packages= everywhere in the draft, not "revision" (but keep "revision= " for modules).  Note that packages will still use a "revisi= on-label" and a "revision-label-scheme".

 

Jason

 

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

Weekly webex call details:

 

Meeting number (access code): 161 096 5630

Meeting password: semver?

 

Occurs every Tuesday effective Tuesday, November 16,= 2021 from 9:00 AM to 10:00 AM, (UTC-05:00) Eastern Time (US & Canada)

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

 

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

Tap to join from a mobile device (attendees only)

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

--_000_DM6PR08MB5084B21E3367723B982AA1B69B789DM6PR08MB5084namp_-- From nobody Fri Dec 17 11:55: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 661923A09A6 for ; Fri, 17 Dec 2021 11:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 7qM7hmOOrB2I for ; Fri, 17 Dec 2021 11:55:24 -0800 (PST) Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08on2107.outbound.protection.outlook.com [40.107.100.107]) (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 835B53A09A4 for ; Fri, 17 Dec 2021 11:55:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lH90/S60r5OYdOeypnNGya+k5Zs3dsqCb07jrSMwdG+BMq8hgWW7Pdai+j/FogUmUzZPGJyFsA5cdiZsUDO7dN4KuEIF4kcvk8LaXW6ro7WWeC6Q4x9xpTpAGFrlpmKpBZfbg1kgARdovT7N+r1cQrEXbWCkARLJQwQB/gCYLeMQbr+k20n5ENQR8+te4yHt8u9ZDPsBdOI1SrHa8Z8mNxPoTWeJtJrBxARP2hOLbxrMcubSxIzd9MxPOnhyv5jtOc4nnNNfQqf0M2kiLBY8wuzdLK25DiceVr+qYHYlujPjx6agKmGfebCTmdTZBH0T8WKz82T5I6Ib612h7Akn/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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IoOjdJLyMofcIZQH0c3FUvvey5R07ANvi2vRbP5me6E=; b=Clf1K2nJ0QJFo8kIH0te+bu89yARY05cD7vlIPxscfjNZMuyfun8Smazs65puar5m0ReXrBXhWNtl7Ndsj4jYr3X7DTvgWPCrYqBBYt9BUAhAYh4SFIEP4C8qlAw47zL5E2RUVqdXBUCnDRO1rcn6HJGPaG+p7gSZsJzbsBBnTOtXFwUlLSMcVF8XXno6qZ7sJbjxAv3vq8OOtv9t/IhacQZe7wMFKDxUJ32+sNwn/3QfxhFUaOxtO9lLO0UC3omvv0rnAGlXzqhghXjulNxifYwk7+oUS7sTzwGthy8ZfUwKsIOdSSVptbvZ/493jFJQ5dIvLSJaOYHYJgWwNo8PQ== 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=IoOjdJLyMofcIZQH0c3FUvvey5R07ANvi2vRbP5me6E=; b=Oc+yTROGWl2xggR1/Zn01y+NmiVRwSj3iVCyD6+k5hngiQiE1ThnHpbTj43WZm0xOm300WVXAWx0p8QvIxWGLb9fotULpKwPDATHrOUOCOKORkO8FNMDSnaFgrEnK2jR7uFhSB8iA/5NOdDqGqFF2HCoI6pRSxPQVhnR9wLSV0M= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB2634.namprd08.prod.outlook.com (2603:10b6:3:cc::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.15; Fri, 17 Dec 2021 19:55:21 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::9137:a61c:2b1:ce22%6]) with mapi id 15.20.4778.018; Fri, 17 Dec 2021 19:55:21 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning weekly calls cancelled Dec 21 and 28 Thread-Index: Adfzf+L0dURWq6yyS3iWC61cPrGQfw== Date: Fri, 17 Dec 2021 19:55:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: abd70716-275d-49e4-d576-08d9c197286c x-ms-traffictypediagnostic: DM5PR08MB2634:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:534; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6BHjWOpZRPAczNPCFnSqX2z9tI87krjNadxU5sZ6cZ8K7/uly6p5EBMCLyA+tJw1klHrbcOSnsChWys9ze/lZ3n1R+ch2rS+dHFYZBOfx2YJcfQJ0/+8mw0z/+iqpMOoqSKpbn8WUtZ7ypdKMCCbqgds6nb856VnJT6EeD70n9XMnVlDuxwcC6JhSwlTWlrmQvXMElHImIZgD5cgX2YY/Mht8gBrPc5vRInRl2O6+ZOWtU4GvOO+nsXMFg+A0r6najUCbZC3azZcJ19W+mtciJfMJF7coVv1sMakRiNr3OPCESU/SyzcUrpCXT2MQ5lgaX5AJO62Yw30BawqDcVzKdqcBM0Ntdc821eZnLUndCyF9/Ma4WY3+wcTMHrx/k+6WFSkvCA/KzAF0UO8dlKw4PNlnd61Ec/MD6Fj1ps6LN8TGQzvrzAXyAAaa/t44ofawCfuslI5Sg15b7DkS2fY5SBVenfNSjzFxz9Uti5N1HRJxSBiiPFzyRNmIXDlCYkZY216b8KJTdA+ohaszw1hV5ZXRh8GkgRjapaTw0z0yjQ/rYeBp3DGjrfDGnibH95fUd9fGyVxlS50RYrc+QusYY4CkJPsb2+5zjU9zk0FBaOSAMeL69jx8lkusWdZ211QuZ5pyjXH3N0+3FnlnhRee/T2vhtzs4QnGe6xE9FqnC3QzSrKl8rxkXO3iMsWS1q9ps1+rsZTT12K5rm6MrSakzpioB7LwrcajqarbGAKpMfOwsqEf/Bx4T+HoaJ2fC3SiyH6OTq8PIuMbRKD/NNDsRbh8Ce4MkelsB6eut7I9gc= 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)(366004)(16799955002)(83380400001)(52536014)(508600001)(6506007)(166002)(6916009)(2906002)(966005)(5660300002)(66556008)(7696005)(122000001)(64756008)(71200400001)(186003)(316002)(66446008)(66946007)(66476007)(9686003)(8676002)(33656002)(82960400001)(38100700002)(86362001)(4744005)(76116006)(26005)(55016003)(8936002)(38070700005)(40140700001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ikL7zFLfeh+01f9tDGdajvk3MVFv7GjL1y3K2l3ix2AgViUTXIJ1D4bujyBk?= =?us-ascii?Q?d/MT5hqKd5yryWZR5tKJ78bdUxP/ARH/LCf2CoH8qsOi2ZqitHc+7fSTfoKU?= =?us-ascii?Q?uf8mG/Zv0asHY80EzWcRzl9Nl3gMXoNoCxDvFNsr8SqdZPmO6hnAtYNzq7s9?= =?us-ascii?Q?OnGGnUFd25XAWibM4ICE3mhNq+etUgXT45A9i4XBbu4RtutJA0JB90fjtdZ4?= =?us-ascii?Q?TEelNatlVOHwtRI+YvH0JfElQ4OjaTHtZbCwEtYcDB24/r1VVZTn7nBMWiZw?= =?us-ascii?Q?vDyQQl3La4/yB/uiKvvR7/PR1DouDdEYleojVkDtwu1kSbcFWLTm6MP13JKT?= =?us-ascii?Q?qddbjVAf9arjBaJLBU1Gia1+qBBGnhCow0KuBNOf5fQu1hND5fvvJXqzgfPr?= =?us-ascii?Q?Fj2mVvouBJ+RbyG2ScN2HuD5aR5mXLqrXX/QKNSLVkyMlQD/LvDqUtpTfNjq?= =?us-ascii?Q?fTFvesA5k+j0HuyXgcpMEEJRytoCAxAODlHc4sdJXthxpgfqwC8pWiFe5UYZ?= =?us-ascii?Q?rdpSoqugliFox/0G9MpiwOUtRcwzRJQzPtTcXqvoUPmI5t0J+ZNQPerb6SHB?= =?us-ascii?Q?Khao6mvPrTcPzttOSHMzRzdhUVt7tvB7Y/NSbpu9DKfY12Zaozs496A+v+/x?= =?us-ascii?Q?xu1FbMzD/p+KnlAAOul5SQHaaNpdALgHtAa4AoLgCQ9CXEB2Jam0KwSU6Mob?= =?us-ascii?Q?docg5BmFkM5s25XH+e8uWuilZDIk41roYNo7bRWg9/uIGxgQCFL0G1yv/34A?= =?us-ascii?Q?Hf40H4UYfkyYXDN8dJc8fzf8Ls4gxCuOVghX3Twmt7NL5XrLNYzjhQHsdRMI?= =?us-ascii?Q?HUr3DoZOuz56uebTANDS4mKP6nZtcKa/TMglJdgxB1mNjH/CjlZ7tfegMaw6?= =?us-ascii?Q?X4tEA6Gzhm5UmEk/lizt9dNQzLU0HriI8tQ2J+oKvmvynMc8wtnMJaeAXZS/?= =?us-ascii?Q?QRaCFclKJVYQnevokMUyH7CFoupxt/M/42pPYrVWYHkVw7nHBhZspXxUAFOE?= =?us-ascii?Q?o6VmIXPsiu0/7C3twJB1dEOQbbtrg5qF4iRpbDnSU8i4YYmrIop+cfKrW0bN?= =?us-ascii?Q?Jcoh7sGKGM5m3rAcCpapBKNrH94Mb4EEqIKffmRkdGdHqSi3EO2Ys1a6HZJT?= =?us-ascii?Q?RPmuSLQXCKhFmSInIxH8VFKpQ4O69glqtpNgxyLT7+Z7q+QCOXhsoOLKlkcF?= =?us-ascii?Q?ci6FVLcuCOOqfjo8xOuV/ZkbtJwm5ZIU8ySRpJTgTAbxH45+bulzinyUNO++?= =?us-ascii?Q?QNclCbV7ZjHzb0CTlBrqm65MZH6Xsz9SDOZMusMYbFxEDk/hZk3IejkXe8LH?= =?us-ascii?Q?0IONLhK0j7WdUGpx15SgXZXkyCWzTQ2JIbYfQiODo3+9miZfxiA+tHaCHKKP?= =?us-ascii?Q?8pyVbCrobXjLip0JtkJMhvdhy0fp6xiofKtJj3ivA8XQPN2H50PxHQr+jTJ7?= =?us-ascii?Q?pVjrRVN+9PK3K+F/r6pLkCcaFkTvQaCTdSklKRGG63fUbUdirbGGSdzuQX4+?= =?us-ascii?Q?Xuqpz84maiRLkACIzaT4ThQq0Iks7yt+jis6kLv9HVO+A8lUFWscIjB0GQCA?= =?us-ascii?Q?4fcPxE3AaKuLAhjGPQKzBW6fzeNjCWHmmdYB7yqs6WfYDZVcWPOeIb57wmTp?= =?us-ascii?Q?Ng=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084A9E10D7057A6CE9878C59B789DM6PR08MB5084namp_" 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: abd70716-275d-49e4-d576-08d9c197286c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2021 19:55:21.0580 (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: pT/rMiCMwpdpLMlWMjucStn42gJCByQvEU7M6UEDsmpsHue/ncJu/618ggdMsUotszg0Sohf8a3XxQ3bTkgU0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2634 Archived-At: Subject: [netmod] YANG Versioning weekly calls cancelled Dec 21 and 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: Fri, 17 Dec 2021 19:55:30 -0000 --_000_DM6PR08MB5084A9E10D7057A6CE9878C59B789DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The YANG Versioning weekly calls are cancelled Tues Dec 21 and 28. We'll re= sume on Tues Jan 4. As always, everyone is welcome. Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 161 096 5630 Meeting password: semver? Occurs every Tuesday effective Tuesday, November 16, 2021 from 9:00 AM to 1= 0:00 AM, (UTC-05:00) Eastern Time (US & Canada) 9:00 AM | (UTC-05:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dme2c6491ebcc37b8127c1244d244d2754 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1610965630## Call-in toll number (US/Canada) --_000_DM6PR08MB5084A9E10D7057A6CE9878C59B789DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The YANG Versioning weekly calls are cancelled Tues = Dec 21 and 28. We'll resume on Tues Jan 4. As always, everyone is welcome.<= o:p>

 

Jason

 

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

Weekly webex call details:

 

Meeting number (access code): 161 096 5630

Meeting password: semver?

 

Occurs every Tuesday effective Tuesday, November 16,= 2021 from 9:00 AM to 10:00 AM, (UTC-05:00) Eastern Time (US & Canada)

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

 

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

Tap to join from a mobile device (attendees only)

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

 

 

--_000_DM6PR08MB5084A9E10D7057A6CE9878C59B789DM6PR08MB5084namp_-- From nobody Fri Dec 17 22:47: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 DBA353A0C3E for ; Fri, 17 Dec 2021 22:47:29 -0800 (PST) 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, HTML_MESSAGE=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 IZgD0qRFGUR8 for ; Fri, 17 Dec 2021 22:47:24 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 80FEA3A0C3B for ; Fri, 17 Dec 2021 22:47:24 -0800 (PST) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id DFE057D001; Sat, 18 Dec 2021 06:47:22 +0000 (UTC) From: Christian Hopps Message-Id: <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_73D51FBB-488F-45BA-A9FA-49E613EC91C4" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Date: Sat, 18 Dec 2021 01:47:21 -0500 In-Reply-To: Cc: Christian Hopps , Juergen Schoenwaelder , Ladislav Lhotka To: "netmod@ietf.org" References: <20150624145325.GB38016@elstar.local> X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: Subject: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 18 Dec 2021 06:47:30 -0000 --Apple-Mail=_73D51FBB-488F-45BA-A9FA-49E613EC91C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I was just going over json encoding of YANG, and got to the empty leaf = encoding and it's odd use of "[null]" rather than just "null". I read = the explanation, but had a hard time believing what it said. So, running = code time. The first thing I tried was Python to see if something weird = happened: In [1]: import json In [2]: json.loads('{"foo": null}') Out[2]: {'foo': None} Nope, seems fine. Then checked the "definitive source" for json, = javascript: js> JSON.parse("{\"foo\": 1, \"bar\": null}") ({foo:1, bar:null}) Seems fine here too..=20 So I went searching the mailing list and found this: > On Jun 29, 2015, at 5:49 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: ... >> - I am not sure I understand the argument why [null] is better than >> null for the empty type. Perhaps it is but the text does not really >> tell me. >=20 > "foo": null >=20 > may sometimes appear as if the "foo" instance is not present at all - = in > some languages this is probably more serious than in others. This is = how > it works in Python: >=20 >>>> import json >>>> obj =3D json.loads('{"foo": null, "bar": [null]}') >>>> "YES" if obj["foo"] else "NO" > 'NO' >>>> "YES" if obj["bar"] else "NO" > 'YES' >=20 > So the special value "[null]" seems safer and it cannot appear in any > other context. The justifying example here is, unfortunately, wrong. One does not = (normally) check for the presence of a dictionary item in python by = trying to access the value of that item (which is what the code above is = doing). The standard python code to check for the presence of an item is = as follows, and it works fine with a "null" json value: In [1]: import json In [2]: o =3D json.loads('{"foo": null}') In [3]: o Out[3]: {'foo': None} In [4]: "YES" if "foo" in o else "NO" Out[4]: 'YES' Indeed in python if you try and check for a missing item the way the = email above describes, and the item is missing, an exception is raised: In [5]: o["bar"] = --------------------------------------------------------------------------= - KeyError Traceback (most recent call = last) One *could* catch the "KeyError" to check for missing items which will = also work using "null" son values for empty leafs, but the more common = form is "if key in dict" in my experience. Furthermore, using "access the value" for presence check will also = "fail" for zero values and for empty strings, but we don't have odd = encodings for integers or strings... In [1]: import json In [2]: o =3D json.loads('{"foo": 0, "bar": ""}') In [3]: o Out[3]: {'foo': 0, 'bar': ''} In [4]: "YES" if o["foo"] else "NO" Out[4]: 'NO' In [5]: "YES" if o["bar"] else "NO" Out[5]: 'NO' Point being, evaluating an items value is not the right way to check for = "presence", it's the way to check the "value" of the item. An empty leaf = has no value so it's basically never correct to try to access that value = in code. Javascript is basically the same as python here: js> o =3D JSON.parse('{"foo": null}') ({foo:null}) js> if ("foo" in o) { "YES" } else { "NO" } "YES" So, do we think it would it ever be possible to change (fix) this = encoding oddity? Thanks, Chris. --Apple-Mail=_73D51FBB-488F-45BA-A9FA-49E613EC91C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

I was just going over json encoding of = YANG, and got to the empty leaf encoding and it's odd use of "[null]" = rather than just "null". I read the explanation, but had a hard time = believing what it said. So, running code time. The first thing I tried = was Python to see if something weird happened:

In [1]: import json
In [2]: json.loads('{"foo": = null}')
Out[2]: {'foo': None}

Nope, seems fine. Then = checked the "definitive source" for json, javascript:

js> JSON.parse("{\"foo\": 1, \"bar\": = null}")
({foo:1, bar:null})

Seems fine here too.. 

So I went searching the = mailing list and found this:

On Jun 29, 2015, at 5:49 AM, Ladislav Lhotka <lhotka@nic.cz> = wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = writes:
...
- I = am not sure I understand the argument why [null] is better = than
 null for the empty type. Perhaps it is but the text = does not really
 tell me.

"foo": null

may sometimes appear as = if the "foo" instance is not present at all - in
some languages this is = probably more serious than in others. This is how
it works in = Python:

import = json
obj =3D = json.loads('{"foo": null, "bar": = [null]}')
"YES" if obj["foo"] else = "NO"
'NO'
"YES" if obj["bar"] else = "NO"
'YES'

So the special value = "[null]" seems safer and it cannot appear in any
other = context.

The justifying = example here is, unfortunately, wrong. One does not (normally) check for = the presence of a dictionary item in python by trying to access the = value of that item (which is what the code above is doing). The standard = python code to check for the presence of an item is as follows, and it = works fine with a "null" json value:

In [1]: import = json
In [2]: o =3D json.loads('{"foo": = null}')
In [3]: o
Out[3]: {'foo': = None}
In [4]: "YES" if "foo" in o else = "NO"
Out[4]: 'YES'

Indeed in python if you try and = check for a missing item the way the email above describes, and the item = is missing, an exception is raised:

In [5]: o["bar"]
---------------------------------------------------------------= ------------
KeyError         =                     =      Traceback (most recent call = last)

One *could* catch the "KeyError" to = check for missing items which will also work using "null" son values for = empty leafs, but the more common form is "if key in dict" in my = experience.

Furthermore, using "access the value" for presence check will = also "fail" for zero values and for empty strings, but we don't have odd = encodings for integers or strings...

In [1]: import json
In [2]: o =3D json.loads('{"foo": 0, = "bar": ""}')
In [3]: o
Out[3]: {'foo': 0, 'bar': = ''}
In [4]: = "YES" if o["foo"] else "NO"
Out[4]: = 'NO'
In [5]: = "YES" if o["bar"] else "NO"
Out[5]: = 'NO'

Point being, evaluating an items value is not the right way = to check for "presence", it's the way to check the "value" of the item. = An empty leaf has no value so it's basically never correct to try to = access that value in code.

Javascript is basically the same as python here:

js> = o =3D JSON.parse('{"foo": null}')
({foo:null})
js> = if ("foo" in o) { "YES" } else { "NO" }
"YES"

So, do we think it = would it ever be possible to change (fix) this encoding = oddity?

Thanks,
Chris.

= --Apple-Mail=_73D51FBB-488F-45BA-A9FA-49E613EC91C4-- From nobody Sat Dec 18 00:20: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 DCAC63A074D for ; Sat, 18 Dec 2021 00:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 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, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=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=lear.ch 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 K7hxWGxXvvmg for ; Sat, 18 Dec 2021 00:20:26 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 809223A074B for ; Sat, 18 Dec 2021 00:20:24 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BI8KKoP1198230 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 18 Dec 2021 09:20:20 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639815621; bh=u1ympgzwjsGZTaHTSCsGqPlrILDG6EeI5iCgpD85jOs=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=JK+x1yHgb4BSXBVLy3pzhVeggEz8tTU5z1f2cz32pYEpryMOIatKT0GBGSzHSKhTy BMJXPLCx8Gs+FCBVmHvqH5j308mMpkIFWyirGpVGlUWTHqsBbWztCT31gu+aqMy48i MujyP+bkC6lD+aZaIyNdPmzPdstk4FNgFvSzRlcI= Message-ID: <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> Date: Sat, 18 Dec 2021 09:20:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Christian Hopps , "netmod@ietf.org" Cc: Ladislav Lhotka References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> From: Eliot Lear In-Reply-To: <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------hLGf7z3YQBUwDEJjcdqwyEl9" Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 18 Dec 2021 08:20:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------hLGf7z3YQBUwDEJjcdqwyEl9 Content-Type: multipart/mixed; boundary="------------6r9umz9x6r0ytmV7D0rYYhxb"; protected-headers="v1" From: Eliot Lear To: Christian Hopps , "netmod@ietf.org" Cc: Ladislav Lhotka Message-ID: <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> In-Reply-To: <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> --------------6r9umz9x6r0ytmV7D0rYYhxb Content-Type: multipart/alternative; boundary="------------UZYUPJws6AmHVBbh9lLSpfbv" --------------UZYUPJws6AmHVBbh9lLSpfbv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 UG9zc2libHkuwqAgVGhlIGlzc3VlIHdpdGggZml4aW5nIGl0IGlzIHRoYXQgaXQgd291bGQg Y3JlYXRlIGFuIGFtYmlndWl0eSANCmJldHdlZW4gbnVsbCBhbmQgW8KgIG51bGwgXS7CoCBJ IGFtIG5vdCBzdXJlIGhvdyBvZnRlbiBbIG51bGwgXSB3b3VsZCBub3QgDQpoYXZlIHRoYXQg c2VtYW50aWMgZXF1aXZhbGVuY2UgaW4gZWFybGllciB3b3JrLiBUaGlzIGlzIGZ1cnRoZXIg DQpjb21wbGljYXRlZCBieSBhIGxhY2sgb2Ygc2VsZi1kZXNjcmlwdGl2ZSB2ZXJzaW9uaW5n IGluIFlBTkcgc2VyaWFsaXphdGlvbnMuDQoNClN0aWxsIGl0IHNlZW1zIGxpa2UgdGhlIHJp Z2h0IHRoaW5nIHRvIGRvLCBpbiBvcmRlciB0byBmYWxsIGludG8gbGluZSANCndpdGggdGhl IHRhcmdldCBsYW5ndWFnZSBzcGVjLg0KDQpFbGlvdA0KDQpPbiAxOC4xMi4yMSAwNzo0Nywg Q2hyaXN0aWFuIEhvcHBzIHdyb3RlOg0KPiBIaSwNCj4NCj4gSSB3YXMganVzdCBnb2luZyBv dmVyIGpzb24gZW5jb2Rpbmcgb2YgWUFORywgYW5kIGdvdCB0byB0aGUgZW1wdHkgbGVhZiAN Cj4gZW5jb2RpbmcgYW5kIGl0J3Mgb2RkIHVzZSBvZiAiW251bGxdIiByYXRoZXIgdGhhbiBq dXN0ICJudWxsIi4gSSByZWFkIA0KPiB0aGUgZXhwbGFuYXRpb24sIGJ1dCBoYWQgYSBoYXJk IHRpbWUgYmVsaWV2aW5nIHdoYXQgaXQgc2FpZC4gU28sIA0KPiBydW5uaW5nIGNvZGUgdGlt ZS4gVGhlIGZpcnN0IHRoaW5nIEkgdHJpZWQgd2FzIFB5dGhvbiB0byBzZWUgaWYgDQo+IHNv bWV0aGluZyB3ZWlyZCBoYXBwZW5lZDoNCj4NCj4gICAgIEluIFsxXTogaW1wb3J0IGpzb24N Cj4gICAgIEluIFsyXToganNvbi5sb2FkcygneyJmb28iOiBudWxsfScpDQo+ICAgICBPdXRb Ml06IHsnZm9vJzogTm9uZX0NCj4NCj4gTm9wZSwgc2VlbXMgZmluZS4gVGhlbiBjaGVja2Vk IHRoZSAiZGVmaW5pdGl2ZSBzb3VyY2UiIGZvciBqc29uLCANCj4gamF2YXNjcmlwdDoNCj4N Cj4gICAgIGpzPiBKU09OLnBhcnNlKCJ7XCJmb29cIjogMSwgXCJiYXJcIjogbnVsbH0iKQ0K PiAgICAgKHtmb286MSwgYmFyOm51bGx9KQ0KPg0KPg0KPiBTZWVtcyBmaW5lIGhlcmUgdG9v Li4NCj4NCj4gU28gSSB3ZW50IHNlYXJjaGluZyB0aGUgbWFpbGluZyBsaXN0IGFuZCBmb3Vu ZCB0aGlzOg0KPg0KPj4gICAgIE9uIEp1biAyOSwgMjAxNSwgYXQgNTo0OSBBTSwgTGFkaXNs YXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+ICAgICBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JpdGVz Og0KPiAgICAgLi4uDQo+Pj4gICAgIC0gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhl IGFyZ3VtZW50IHdoeSBbbnVsbF0gaXMgYmV0dGVyIHRoYW4NCj4+PiAgICAgwqBudWxsIGZv ciB0aGUgZW1wdHkgdHlwZS4gUGVyaGFwcyBpdCBpcyBidXQgdGhlIHRleHQgZG9lcyBub3Qg cmVhbGx5DQo+Pj4gICAgIMKgdGVsbCBtZS4NCj4+DQo+PiAgICAgImZvbyI6IG51bGwNCj4+ DQo+PiAgICAgbWF5IHNvbWV0aW1lcyBhcHBlYXIgYXMgaWYgdGhlICJmb28iIGluc3RhbmNl IGlzIG5vdCBwcmVzZW50IGF0DQo+PiAgICAgYWxsIC0gaW4NCj4+ICAgICBzb21lIGxhbmd1 YWdlcyB0aGlzIGlzIHByb2JhYmx5IG1vcmUgc2VyaW91cyB0aGFuIGluIG90aGVycy4gVGhp cw0KPj4gICAgIGlzIGhvdw0KPj4gICAgIGl0IHdvcmtzIGluIFB5dGhvbjoNCj4+DQo+Pj4+ PiAgICAgaW1wb3J0IGpzb24NCj4+Pj4+ICAgICBvYmogPSBqc29uLmxvYWRzKCd7ImZvbyI6 IG51bGwsICJiYXIiOiBbbnVsbF19JykNCj4+Pj4+ICAgICAiWUVTIiBpZiBvYmpbImZvbyJd IGVsc2UgIk5PIg0KPj4gICAgICdOTycNCj4+Pj4+ICAgICAiWUVTIiBpZiBvYmpbImJhciJd IGVsc2UgIk5PIg0KPj4gICAgICdZRVMnDQo+Pg0KPj4gICAgIFNvIHRoZSBzcGVjaWFsIHZh bHVlICJbbnVsbF0iIHNlZW1zIHNhZmVyIGFuZCBpdCBjYW5ub3QgYXBwZWFyIGluIGFueQ0K Pj4gICAgIG90aGVyIGNvbnRleHQuDQo+DQo+IFRoZSBqdXN0aWZ5aW5nIGV4YW1wbGUgaGVy ZSBpcywgdW5mb3J0dW5hdGVseSwgd3JvbmcuIE9uZSBkb2VzIG5vdCANCj4gKG5vcm1hbGx5 KSBjaGVjayBmb3IgdGhlIHByZXNlbmNlIG9mIGEgZGljdGlvbmFyeSBpdGVtIGluIHB5dGhv biBieSANCj4gdHJ5aW5nIHRvIGFjY2VzcyB0aGUgdmFsdWUgb2YgdGhhdCBpdGVtICh3aGlj aCBpcyB3aGF0IHRoZSBjb2RlIGFib3ZlIA0KPiBpcyBkb2luZykuIFRoZSBzdGFuZGFyZCBw eXRob24gY29kZSB0byBjaGVjayBmb3IgdGhlIHByZXNlbmNlIG9mIGFuIA0KPiBpdGVtIGlz IGFzIGZvbGxvd3MsIGFuZCBpdCB3b3JrcyBmaW5lIHdpdGggYSAibnVsbCIganNvbiB2YWx1 ZToNCj4NCj4gICAgIEluIFsxXTogaW1wb3J0IGpzb24NCj4gICAgIEluIFsyXTogbyA9IGpz b24ubG9hZHMoJ3siZm9vIjogbnVsbH0nKQ0KPiAgICAgSW4gWzNdOiBvDQo+ICAgICBPdXRb M106IHsnZm9vJzogTm9uZX0NCj4gICAgIEluIFs0XTogIllFUyIgaWYgImZvbyIgaW4gbyBl bHNlICJOTyINCj4gICAgIE91dFs0XTogJ1lFUycNCj4NCj4gSW5kZWVkIGluIHB5dGhvbiBp ZiB5b3UgdHJ5IGFuZCBjaGVjayBmb3IgYSBtaXNzaW5nIGl0ZW0gdGhlIHdheSB0aGUgDQo+ IGVtYWlsIGFib3ZlIGRlc2NyaWJlcywgYW5kIHRoZSBpdGVtIGlzIG1pc3NpbmcsIGFuIGV4 Y2VwdGlvbiBpcyByYWlzZWQ6DQo+DQo+ICAgICBJbiBbNV06IG9bImJhciJdDQo+ICAgICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgIEtleUVycm9yIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxs DQo+ICAgICBsYXN0KQ0KPg0KPg0KPiBPbmUgKmNvdWxkKiBjYXRjaCB0aGUgIktleUVycm9y IiB0byBjaGVjayBmb3IgbWlzc2luZyBpdGVtcyB3aGljaCB3aWxsIA0KPiBhbHNvIHdvcmsg dXNpbmcgIm51bGwiIHNvbiB2YWx1ZXMgZm9yIGVtcHR5IGxlYWZzLCBidXQgdGhlIG1vcmUg Y29tbW9uIA0KPiBmb3JtIGlzICJpZiBrZXkgaW4gZGljdCIgaW4gbXkgZXhwZXJpZW5jZS4N Cj4NCj4gRnVydGhlcm1vcmUsIHVzaW5nICJhY2Nlc3MgdGhlIHZhbHVlIiBmb3IgcHJlc2Vu Y2UgY2hlY2sgd2lsbCBhbHNvIA0KPiAiZmFpbCIgZm9yIHplcm8gdmFsdWVzIGFuZCBmb3Ig ZW1wdHkgc3RyaW5ncywgYnV0IHdlIGRvbid0IGhhdmUgb2RkIA0KPiBlbmNvZGluZ3MgZm9y IGludGVnZXJzIG9yIHN0cmluZ3MuLi4NCj4NCj4gICAgIEluIFsxXTogaW1wb3J0IGpzb24N Cj4gICAgIEluIFsyXTogbyA9IGpzb24ubG9hZHMoJ3siZm9vIjogMCwgImJhciI6ICIifScp DQo+ICAgICBJbiBbM106IG8NCj4gICAgIE91dFszXTogeydmb28nOiAwLCAnYmFyJzogJyd9 DQo+ICAgICBJbiBbNF06ICJZRVMiIGlmIG9bImZvbyJdIGVsc2UgIk5PIg0KPiAgICAgT3V0 WzRdOiAnTk8nDQo+ICAgICBJbiBbNV06ICJZRVMiIGlmIG9bImJhciJdIGVsc2UgIk5PIg0K PiAgICAgT3V0WzVdOiAnTk8nDQo+DQo+DQo+IFBvaW50IGJlaW5nLCBldmFsdWF0aW5nIGFu IGl0ZW1zIHZhbHVlIGlzIG5vdCB0aGUgcmlnaHQgd2F5IHRvIGNoZWNrIA0KPiBmb3IgInBy ZXNlbmNlIiwgaXQncyB0aGUgd2F5IHRvIGNoZWNrIHRoZSAidmFsdWUiIG9mIHRoZSBpdGVt LiBBbiANCj4gZW1wdHkgbGVhZiBoYXMgbm8gdmFsdWUgc28gaXQncyBiYXNpY2FsbHkgbmV2 ZXIgY29ycmVjdCB0byB0cnkgdG8gDQo+IGFjY2VzcyB0aGF0IHZhbHVlIGluIGNvZGUuDQo+ DQo+IEphdmFzY3JpcHQgaXMgYmFzaWNhbGx5IHRoZSBzYW1lIGFzIHB5dGhvbiBoZXJlOg0K Pg0KPiAgICAganM+IG8gPSBKU09OLnBhcnNlKCd7ImZvbyI6IG51bGx9JykNCj4gICAgICh7 Zm9vOm51bGx9KQ0KPiAgICAganM+IGlmICgiZm9vIiBpbiBvKSB7ICJZRVMiIH0gZWxzZSB7 ICJOTyIgfQ0KPiAgICAgIllFUyINCj4NCj4NCj4gU28sIGRvIHdlIHRoaW5rIGl0IHdvdWxk IGl0IGV2ZXIgYmUgcG9zc2libGUgdG8gY2hhbmdlIChmaXgpIHRoaXMgDQo+IGVuY29kaW5n IG9kZGl0eT8NCj4NCj4gVGhhbmtzLA0KPiBDaHJpcy4NCj4NCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcg bGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg== --------------UZYUPJws6AmHVBbh9lLSpfbv Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Possibly.=C2=A0 The issue with fixing it is that it would create a= n ambiguity between null and [=C2=A0 null ].=C2=A0 I am not sure how = often [ null ] would not have that semantic equivalence in earlier work.=C2= =A0 This is further complicated by a lack of self-descriptive versioning in YANG serializations.

Still it seems like the right thing to do, in order to fall into line with the target language spec.

Eliot

On 18.12.21 07:47, Christian Hopps wrote:
Hi,

I was just going over json encoding of YANG, and go= t to the empty leaf encoding and it's odd use of "[null]" rather than just "null". I read the explanation, but had a hard time believing what it said. So, running code time. The first thing I tried was Python to see if something weird happened:

In [1]: i= mport json
In [2]: json.loads('{"foo": null}')
Out[2]: {'foo': None}

Nope, seems fine. Then checked the "definitive source" for json, javascript:

js> JSON.parse("{\"foo\": 1, \"bar\": null}")
({foo:1, bar:null})

Seems fine here too..=C2=A0

So I went searching the mailing list and found this:

On Jun 29, 2015, at 5:49= AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Juergen Schoenwaelder &l= t;= j.schoenwaelder@jacobs-university.de> writes:
...
- I am not sure I understand the argument why [null] is better than
=C2=A0null for the empty type. Perhaps it is b= ut the text does not really
=C2=A0tell me.

"foo": null
=

may sometimes appear as = if the "foo" instance is not present at all - in
some languages this is probably more serious than in others. This is how
it works in Python:

import json
obj =3D json.loads('{"foo": null, "bar": [null]}')
"YES" if obj["foo"= ] else "NO"
'NO'
"YES" if obj["bar"= ] else "NO"
'YES'

So the special value "[null]" seems safer and it cannot appear in any
other context.
The justifying example here is, unfortunately, wrong. One does not (normally) check for the presence of a dictionary item in python by trying to access the value of that item (which is what the code above is doing). The standard python code to check for the presence of an item is as follows, and it works fine with a "null" json value:

In [1]: import json
In [2]: o =3D json.loads('{"foo": null}')
In [3]: o
Out[3]: {'foo': None}
In [4]: "YES" if "foo" in o else "NO"=
Out[4]: 'YES'

Indeed in python if you try and check for a missing item the way the email above describes, and the item is missing, an exception is raised:

In [5]:= o["bar"]
-------= --------------------------------------------------------------------
KeyErro= r =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=A0Traceback (most recent call last)

One *could* catch the "KeyError" to check for missing items which will also work using "null" son values for empty leafs, but the more common form is "if key in dict" in my experience.

Furthermore, using "access the value" for presence check will also "fail" for zero values and for empty strings, but we don't have odd encodings for integers or strings...

In [1= ]: import json
In [2= ]: o =3D json.loads('{"foo": 0, "bar": ""}')
In [3= ]: o
Out[3= ]: {'foo': 0, 'bar': ''}
In [4= ]: "YES" if o["foo"] else "NO"
Out[4= ]: 'NO'
In [5= ]: "YES" if o["bar"] else "NO"
Out[5= ]: 'NO'

Point being, evaluating an items value is not the right way to check for "presence", it's the way to check the "value" of the item. An empty leaf has no value so it's basically never correct to try to access that value in code.<= /div>

Javascript is basically the same as python here= :

js>= ; o =3D JSON.parse('{"foo": null}')
({foo= :null})
js>= ; if ("foo" in o) { "YES" } else { "NO" }
"YES"=

So, do we think it would it ever be possible to= change (fix) this encoding oddity?

Thanks,
Chris.


____________________________=
___________________
netmod mailing list
net=
mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------UZYUPJws6AmHVBbh9lLSpfbv-- --------------6r9umz9x6r0ytmV7D0rYYhxb-- --------------hLGf7z3YQBUwDEJjcdqwyEl9 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG9mcMFAwAAAAAACgkQh7ZrRtnSejOu gggAjGVGHIV7pvzLpMNq8kGHMuSdB7aVek63TgHmTQzud+WmzlvvNaQo4kotv5lWqwbeeqZV1+te 1A/HkzeKj9xE5dGFNeQ2yFA/4tMBG24TV0LqoKTBYKU2BrmNCqa+F3KEbi++0zCIlNkAh1pJwDUz vKk9PyHNE0rFee3mRQsYatGsBKvxCELIBJ+6b8vppJ3/Mv6/k7jyMrpu4g7383ZyN89X0gVNk974 0IYpV8Kv0+zPQzLni5fL5iqOn5MEUV4fBqG/Pt+M7Qw34TesfwVaW7XAXkH8lgwq6SMZeI4/Bggs Os11V165zuEZcoZSPysbuTf5PT8/44rCopBkJPNIHg== =1mj9 -----END PGP SIGNATURE----- --------------hLGf7z3YQBUwDEJjcdqwyEl9-- From nobody Sat Dec 18 00:54: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 AF1453A08C5 for ; Sat, 18 Dec 2021 00:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 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, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=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=lear.ch 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 yXvSp7Iw9o12 for ; Sat, 18 Dec 2021 00:54:19 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 C12DE3A08C4 for ; Sat, 18 Dec 2021 00:54:18 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BI8sDHU1214630 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 18 Dec 2021 09:54:14 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639817654; bh=LK7pMny2GWktNextU7mP6aqbgneYHLOXqvJqp2AAH8k=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=MhthYR916RabG2V2otzCrUuscxtnERd5Qx8ZUefPZhENH2zVNkvMku4ngugc9oKdg DYV7VrFZj0UezWMgCI8Jkk8XTiVUmZkaxzLejkQzodq+JiyGiGBR31MJK4e3q06FyP SyhBCKK3DdZAEwkMmZ0N4sO8a4EdDGP9JpeWoXLc= Message-ID: <39dd4f17-a537-d20b-ba83-5252686f7b5e@lear.ch> Date: Sat, 18 Dec 2021 09:54:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US From: Eliot Lear To: Christian Hopps , "netmod@ietf.org" Cc: Ladislav Lhotka References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> In-Reply-To: <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------djoaD8y7iylXLozqroz2xkJy" Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 18 Dec 2021 08:54:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------djoaD8y7iylXLozqroz2xkJy Content-Type: multipart/mixed; boundary="------------y40Q0yBv9sA8O4ca93wvOUSI"; protected-headers="v1" From: Eliot Lear To: Christian Hopps , "netmod@ietf.org" Cc: Ladislav Lhotka Message-ID: <39dd4f17-a537-d20b-ba83-5252686f7b5e@lear.ch> Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> In-Reply-To: <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> --------------y40Q0yBv9sA8O4ca93wvOUSI Content-Type: multipart/alternative; boundary="------------9oYsFrHb3OL3h9zV0MquDl8W" --------------9oYsFrHb3OL3h9zV0MquDl8W Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SnVzdCBmb2xsb3dpbmcgdGhpcyB1cCwgSSBzZWUgaW4gbXkgb3duIHdvcmsgaXQgb2NjdXJz IGEgbGl0dGxlIGJpdCwgc28gDQppdCBpcyBvdXQgdGhlcmUuwqAgSXQgZG9lc24ndCBjcmVh dGUgYW1iaWd1aXRpZXMsIHRobywgYmVjYXVzZSBpdCBpcyB1c2VkIA0KaW4gbnVsbC12YWx1 ZWQgbGVhZnMuwqAgSXQganVzdCBjcmVhdGVzIHN5bnRheCBicmVha2FnZS7CoCBTb21lIHBh cnNlcnMgDQp3aWxsIGhhdmUgYSBwcm9ibGVtIHdpdGggcmVjb2duaXppbmcgYSBuYWtlZCBu dWxsIGFzIHZhbGlkLsKgIE9uIHRoZSANCm90aGVyIGhhbmQsIGluIHRoZSBjYXNlIG9mIE1V RCwgd2Ugc2VwYXJhdGVseSBhZGRlZCB2ZXJzaW9uaW5nIGludG8gdGhlIA0KbW9kZWwsIHNv IHdlIGNvdWxkIGJ1bXAgdGhpcyBpZiB0aGUgc2VyaWFsaXphdGlvbiB1cGRhdGVzLg0KDQpP biAxOC4xMi4yMSAwOToyMCwgRWxpb3QgTGVhciB3cm90ZToNCj4NCj4gUG9zc2libHkuwqAg VGhlIGlzc3VlIHdpdGggZml4aW5nIGl0IGlzIHRoYXQgaXQgd291bGQgY3JlYXRlIGFuIA0K PiBhbWJpZ3VpdHkgYmV0d2VlbiBudWxsIGFuZCBbwqAgbnVsbCBdLsKgIEkgYW0gbm90IHN1 cmUgaG93IG9mdGVuIFsgbnVsbCANCj4gXSB3b3VsZCBub3QgaGF2ZSB0aGF0IHNlbWFudGlj IGVxdWl2YWxlbmNlIGluIGVhcmxpZXIgd29yay7CoCBUaGlzIGlzIA0KPiBmdXJ0aGVyIGNv bXBsaWNhdGVkIGJ5IGEgbGFjayBvZiBzZWxmLWRlc2NyaXB0aXZlIHZlcnNpb25pbmcgaW4g WUFORyANCj4gc2VyaWFsaXphdGlvbnMuDQo+DQo+IFN0aWxsIGl0IHNlZW1zIGxpa2UgdGhl IHJpZ2h0IHRoaW5nIHRvIGRvLCBpbiBvcmRlciB0byBmYWxsIGludG8gbGluZSANCj4gd2l0 aCB0aGUgdGFyZ2V0IGxhbmd1YWdlIHNwZWMuDQo+DQo+IEVsaW90DQo+DQo+IE9uIDE4LjEy LjIxIDA3OjQ3LCBDaHJpc3RpYW4gSG9wcHMgd3JvdGU6DQo+PiBIaSwNCj4+DQo+PiBJIHdh cyBqdXN0IGdvaW5nIG92ZXIganNvbiBlbmNvZGluZyBvZiBZQU5HLCBhbmQgZ290IHRvIHRo ZSBlbXB0eSANCj4+IGxlYWYgZW5jb2RpbmcgYW5kIGl0J3Mgb2RkIHVzZSBvZiAiW251bGxd IiByYXRoZXIgdGhhbiBqdXN0ICJudWxsIi4gSSANCj4+IHJlYWQgdGhlIGV4cGxhbmF0aW9u LCBidXQgaGFkIGEgaGFyZCB0aW1lIGJlbGlldmluZyB3aGF0IGl0IHNhaWQuIFNvLCANCj4+ IHJ1bm5pbmcgY29kZSB0aW1lLiBUaGUgZmlyc3QgdGhpbmcgSSB0cmllZCB3YXMgUHl0aG9u IHRvIHNlZSBpZiANCj4+IHNvbWV0aGluZyB3ZWlyZCBoYXBwZW5lZDoNCj4+DQo+PiAgICAg SW4gWzFdOiBpbXBvcnQganNvbg0KPj4gICAgIEluIFsyXToganNvbi5sb2FkcygneyJmb28i OiBudWxsfScpDQo+PiAgICAgT3V0WzJdOiB7J2Zvbyc6IE5vbmV9DQo+Pg0KPj4gTm9wZSwg c2VlbXMgZmluZS4gVGhlbiBjaGVja2VkIHRoZSAiZGVmaW5pdGl2ZSBzb3VyY2UiIGZvciBq c29uLCANCj4+IGphdmFzY3JpcHQ6DQo+Pg0KPj4gICAgIGpzPiBKU09OLnBhcnNlKCJ7XCJm b29cIjogMSwgXCJiYXJcIjogbnVsbH0iKQ0KPj4gICAgICh7Zm9vOjEsIGJhcjpudWxsfSkN Cj4+DQo+Pg0KPj4gU2VlbXMgZmluZSBoZXJlIHRvby4uDQo+Pg0KPj4gU28gSSB3ZW50IHNl YXJjaGluZyB0aGUgbWFpbGluZyBsaXN0IGFuZCBmb3VuZCB0aGlzOg0KPj4NCj4+PiAgICAg T24gSnVuIDI5LCAyMDE1LCBhdCA1OjQ5IEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBu aWMuY3o+IHdyb3RlOg0KPj4+ICAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JpdGVzOg0KPj4gICAgIC4uLg0KPj4+ PiAgICAgLSBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgYXJndW1lbnQgd2h5IFtu dWxsXSBpcyBiZXR0ZXIgdGhhbg0KPj4+PiAgICAgwqBudWxsIGZvciB0aGUgZW1wdHkgdHlw ZS4gUGVyaGFwcyBpdCBpcyBidXQgdGhlIHRleHQgZG9lcyBub3QNCj4+Pj4gICAgIHJlYWxs eQ0KPj4+PiAgICAgwqB0ZWxsIG1lLg0KPj4+DQo+Pj4gICAgICJmb28iOiBudWxsDQo+Pj4N Cj4+PiAgICAgbWF5IHNvbWV0aW1lcyBhcHBlYXIgYXMgaWYgdGhlICJmb28iIGluc3RhbmNl IGlzIG5vdCBwcmVzZW50IGF0DQo+Pj4gICAgIGFsbCAtIGluDQo+Pj4gICAgIHNvbWUgbGFu Z3VhZ2VzIHRoaXMgaXMgcHJvYmFibHkgbW9yZSBzZXJpb3VzIHRoYW4gaW4gb3RoZXJzLg0K Pj4+ICAgICBUaGlzIGlzIGhvdw0KPj4+ICAgICBpdCB3b3JrcyBpbiBQeXRob246DQo+Pj4N Cj4+Pj4+PiAgICAgaW1wb3J0IGpzb24NCj4+Pj4+PiAgICAgb2JqID0ganNvbi5sb2Fkcygn eyJmb28iOiBudWxsLCAiYmFyIjogW251bGxdfScpDQo+Pj4+Pj4gICAgICJZRVMiIGlmIG9i alsiZm9vIl0gZWxzZSAiTk8iDQo+Pj4gICAgICdOTycNCj4+Pj4+PiAgICAgIllFUyIgaWYg b2JqWyJiYXIiXSBlbHNlICJOTyINCj4+PiAgICAgJ1lFUycNCj4+Pg0KPj4+ICAgICBTbyB0 aGUgc3BlY2lhbCB2YWx1ZSAiW251bGxdIiBzZWVtcyBzYWZlciBhbmQgaXQgY2Fubm90IGFw cGVhcg0KPj4+ICAgICBpbiBhbnkNCj4+PiAgICAgb3RoZXIgY29udGV4dC4NCj4+DQo+PiBU aGUganVzdGlmeWluZyBleGFtcGxlIGhlcmUgaXMsIHVuZm9ydHVuYXRlbHksIHdyb25nLiBP bmUgZG9lcyBub3QgDQo+PiAobm9ybWFsbHkpIGNoZWNrIGZvciB0aGUgcHJlc2VuY2Ugb2Yg YSBkaWN0aW9uYXJ5IGl0ZW0gaW4gcHl0aG9uIGJ5IA0KPj4gdHJ5aW5nIHRvIGFjY2VzcyB0 aGUgdmFsdWUgb2YgdGhhdCBpdGVtICh3aGljaCBpcyB3aGF0IHRoZSBjb2RlIGFib3ZlIA0K Pj4gaXMgZG9pbmcpLiBUaGUgc3RhbmRhcmQgcHl0aG9uIGNvZGUgdG8gY2hlY2sgZm9yIHRo ZSBwcmVzZW5jZSBvZiBhbiANCj4+IGl0ZW0gaXMgYXMgZm9sbG93cywgYW5kIGl0IHdvcmtz IGZpbmUgd2l0aCBhICJudWxsIiBqc29uIHZhbHVlOg0KPj4NCj4+ICAgICBJbiBbMV06IGlt cG9ydCBqc29uDQo+PiAgICAgSW4gWzJdOiBvID0ganNvbi5sb2FkcygneyJmb28iOiBudWxs fScpDQo+PiAgICAgSW4gWzNdOiBvDQo+PiAgICAgT3V0WzNdOiB7J2Zvbyc6IE5vbmV9DQo+ PiAgICAgSW4gWzRdOiAiWUVTIiBpZiAiZm9vIiBpbiBvIGVsc2UgIk5PIg0KPj4gICAgIE91 dFs0XTogJ1lFUycNCj4+DQo+PiBJbmRlZWQgaW4gcHl0aG9uIGlmIHlvdSB0cnkgYW5kIGNo ZWNrIGZvciBhIG1pc3NpbmcgaXRlbSB0aGUgd2F5IHRoZSANCj4+IGVtYWlsIGFib3ZlIGRl c2NyaWJlcywgYW5kIHRoZSBpdGVtIGlzIG1pc3NpbmcsIGFuIGV4Y2VwdGlvbiBpcyByYWlz ZWQ6DQo+Pg0KPj4gICAgIEluIFs1XTogb1siYmFyIl0NCj4+ICAgICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+ICAgICBLZXlFcnJvciDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoFRyYWNlYmFjayAobW9zdCByZWNlbnQNCj4+ICAgICBjYWxs IGxhc3QpDQo+Pg0KPj4NCj4+IE9uZSAqY291bGQqIGNhdGNoIHRoZSAiS2V5RXJyb3IiIHRv IGNoZWNrIGZvciBtaXNzaW5nIGl0ZW1zIHdoaWNoIA0KPj4gd2lsbCBhbHNvIHdvcmsgdXNp bmcgIm51bGwiIHNvbiB2YWx1ZXMgZm9yIGVtcHR5IGxlYWZzLCBidXQgdGhlIG1vcmUgDQo+ PiBjb21tb24gZm9ybSBpcyAiaWYga2V5IGluIGRpY3QiIGluIG15IGV4cGVyaWVuY2UuDQo+ Pg0KPj4gRnVydGhlcm1vcmUsIHVzaW5nICJhY2Nlc3MgdGhlIHZhbHVlIiBmb3IgcHJlc2Vu Y2UgY2hlY2sgd2lsbCBhbHNvIA0KPj4gImZhaWwiIGZvciB6ZXJvIHZhbHVlcyBhbmQgZm9y IGVtcHR5IHN0cmluZ3MsIGJ1dCB3ZSBkb24ndCBoYXZlIG9kZCANCj4+IGVuY29kaW5ncyBm b3IgaW50ZWdlcnMgb3Igc3RyaW5ncy4uLg0KPj4NCj4+ICAgICBJbiBbMV06IGltcG9ydCBq c29uDQo+PiAgICAgSW4gWzJdOiBvID0ganNvbi5sb2FkcygneyJmb28iOiAwLCAiYmFyIjog IiJ9JykNCj4+ICAgICBJbiBbM106IG8NCj4+ICAgICBPdXRbM106IHsnZm9vJzogMCwgJ2Jh cic6ICcnfQ0KPj4gICAgIEluIFs0XTogIllFUyIgaWYgb1siZm9vIl0gZWxzZSAiTk8iDQo+ PiAgICAgT3V0WzRdOiAnTk8nDQo+PiAgICAgSW4gWzVdOiAiWUVTIiBpZiBvWyJiYXIiXSBl bHNlICJOTyINCj4+ICAgICBPdXRbNV06ICdOTycNCj4+DQo+Pg0KPj4gUG9pbnQgYmVpbmcs IGV2YWx1YXRpbmcgYW4gaXRlbXMgdmFsdWUgaXMgbm90IHRoZSByaWdodCB3YXkgdG8gY2hl Y2sgDQo+PiBmb3IgInByZXNlbmNlIiwgaXQncyB0aGUgd2F5IHRvIGNoZWNrIHRoZSAidmFs dWUiIG9mIHRoZSBpdGVtLiBBbiANCj4+IGVtcHR5IGxlYWYgaGFzIG5vIHZhbHVlIHNvIGl0 J3MgYmFzaWNhbGx5IG5ldmVyIGNvcnJlY3QgdG8gdHJ5IHRvIA0KPj4gYWNjZXNzIHRoYXQg dmFsdWUgaW4gY29kZS4NCj4+DQo+PiBKYXZhc2NyaXB0IGlzIGJhc2ljYWxseSB0aGUgc2Ft ZSBhcyBweXRob24gaGVyZToNCj4+DQo+PiAgICAganM+IG8gPSBKU09OLnBhcnNlKCd7ImZv byI6IG51bGx9JykNCj4+ICAgICAoe2ZvbzpudWxsfSkNCj4+ICAgICBqcz4gaWYgKCJmb28i IGluIG8pIHsgIllFUyIgfSBlbHNlIHsgIk5PIiB9DQo+PiAgICAgIllFUyINCj4+DQo+Pg0K Pj4gU28sIGRvIHdlIHRoaW5rIGl0IHdvdWxkIGl0IGV2ZXIgYmUgcG9zc2libGUgdG8gY2hh bmdlIChmaXgpIHRoaXMgDQo+PiBlbmNvZGluZyBvZGRpdHk/DQo+Pg0KPj4gVGhhbmtzLA0K Pj4gQ2hyaXMuDQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --------------9oYsFrHb3OL3h9zV0MquDl8W Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Just following this up, I see in my own work it occurs a little bit, so it is out there.=C2=A0 It doesn't create ambiguities, tho, because it is used in null-valued leafs.=C2=A0 It just creates synt= ax breakage.=C2=A0 Some parsers will have a problem with recognizing a= naked null as valid.=C2=A0 On the other hand, in the case of MUD, w= e separately added versioning into the model, so we could bump this if the serialization updates.

On 18.12.21 09:20, Eliot Lear wrote:

Possibly.=C2=A0 The issue with fixing it is that it would create= an ambiguity between null and [=C2=A0 null ].=C2=A0 I am not sure ho= w often [ null ] would not have that semantic equivalence in earlier work.=C2=A0 This is further complicated by a lack of self-descrip= tive versioning in YANG serializations.

Still it seems like the right thing to do, in order to fall into line with the target language spec.

Eliot

On 18.12.21 07:47, Christian Hopps wrote:
Hi,

I was just going over json encoding of YANG, and got to the empty leaf encoding and it's odd use of "[null]" rather than just "null". I read the explanation, but had a hard time believing what it said. So, running code time. The first thing I tried was Python to see if something weird happened:

In [1]:= import json
In [2]:= json.loads('{"foo": null}')
Out[2]:= {'foo': None}

Nope, seems fine. Then checked the "definitive source" for json, javascript:

js> JSON.parse("{\"foo\": 1, \"bar\": null}")
({foo:1= , bar:null})

Seems fine here too..=C2=A0

So I went searching the mailing list and found this:

On Jun 29, 2015, at 5:= 49 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
...
- I am not sure I understand the argument why [null] is better than
=C2=A0null for the empty type. Perhap= s it is but the text does not really
=C2=A0tell me.

"foo": null

may sometimes appear a= s if the "foo" instance is not present at all - in
some languages this is= probably more serious than in others. This is how
it works in Python:

import json
obj =3D json.loads('{"foo": null, "bar": [null]}')
"YES" if obj["fo= o"] else "NO"
'NO'
"YES" if obj["ba= r"] else "NO"
'YES'

So the special value "[null]" seems safer and it cannot appear in any
other context.
The justifying example here is, unfortunately, wrong. One does not (normally) check for the presence of a dictionary item in python by trying to access the value of that item (which is what the code above is doing). The standard python code to check for the presence of an item is as follows, and it works fine with a "null" json value:

In [1]: import json
In [2]: o =3D json.loads('{"foo": null}')
In [3]: o
Out[3]: {'foo': None}=
In [4]: "YES" if "foo" in o else "NO"
Out[4]: 'YES'

Indeed in python if you try and check for a missing item the way the email above describes, and the item is missing, an exception is raised:

In [5= ]: o["bar"]
-----= ----------------------------------------------------------------------
KeyEr= ror =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=A0Traceback (most r= ecent call last)

One *could* catch the "KeyError" to check for= missing items which will also work using "null" son values for empty leafs, but the more common form is "if key in dict" in my experience.

Furthermore, using "access the value" for presence check will also "fail" for zero values and for empty strings, but we don't have odd encodings for integers or strings...

In = [1]: import json
In = [2]: o =3D json.loads('{"foo": 0, "bar": ""}')
In = [3]: o
Out= [3]: {'foo': 0, 'bar': ''}
In = [4]: "YES" if o["foo"] else "NO"
Out= [4]: 'NO'
In = [5]: "YES" if o["bar"] else "NO"
Out= [5]: 'NO'

Point being, evaluating an items value is not= the right way to check for "presence", it's the way to check the "value" of the item. An empty leaf has no value so it's basically never correct to try to access that value in code.

Javascript is basically the same as python here:

js&= gt; o =3D JSON.parse('{"foo": null}')
({f= oo:null})
js&= gt; if ("foo" in o) { "YES" } else { "NO" }
"YE= S"

So, do we think it would it ever be possible to change (fix) this encoding oddity?

Thanks,
Chris.


__________________________=
_____________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/netmod


____________________________=
___________________
netmod mailing list
net=
mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------9oYsFrHb3OL3h9zV0MquDl8W-- --------------y40Q0yBv9sA8O4ca93wvOUSI-- --------------djoaD8y7iylXLozqroz2xkJy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG9obMFAwAAAAAACgkQh7ZrRtnSejMs kgf/YwR4WBKhjzU0wUJH5YK1V0aD0gKcT/+GIEwKDJ68i6vNg78rcTXxWZToPIBLKxl/b3dxBE8X WQAY60/sjeHLQaGtqbTV7Ug2T2oCEZaPeeeWESMorMfLoL0yheTjrjx1r/S4U6In7XW3IqUX+PO4 wCwveheiLeQqHvPU/QXEdW149ejtrps67dh703yZNmWtbPaffN9uH3FdQb+84q0yQGjR0WZhk6nc thT5h3dF0tNdePnAOzVroi/bbts733MCXqv4w0A8rZFSbKuN809AgCgpsJEF1y+AP4Xz8hXWA0LL lEltjog3n7GlKdwJFiV3/C6gdsW/Yk4JOlag1ottnw== =H8Am -----END PGP SIGNATURE----- --------------djoaD8y7iylXLozqroz2xkJy-- From nobody Sat Dec 18 04:59:26 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 D6B733A0E42 for ; Sat, 18 Dec 2021 04:59:24 -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, 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 iNyo7PyEKc6V for ; Sat, 18 Dec 2021 04:59:20 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7983A0E45 for ; Sat, 18 Dec 2021 04:59:19 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JGQsZ2VfLzDCr8; Sat, 18 Dec 2021 13:59:14 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> Date: Sat, 18 Dec 2021 13:59:13 +0100 Cc: Christian Hopps , "netmod@ietf.org" , Ladislav Lhotka X-Mao-Original-Outgoing-Id: 661525153.649452-d7f66617d3ba8d1fc38565dc77718287 Content-Transfer-Encoding: quoted-printable Message-Id: <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 18 Dec 2021 12:59:25 -0000 On 2021-12-18, at 09:20, Eliot Lear wrote: >=20 > Still it seems like the right thing to do, in order to fall into line = with the target language spec. But that=E2=80=99s not what YANG was designed for. YANG is a data modeling language, which incidentally has a couple of = representation formats (YANG-XML, YANG-JSON, YANG-CBOR). There is no intention for the YANG generic data model (the set of all = data models YANG can express) to cover the generic data model of the = representation format. While RFC 8791 (and before it RFC 8040) extended YANG to be able to = describe data in flight, there is no intention that YANG can be used to = describe the entire expressibility of the representation format. We = have Relax-NG, CDDL, and a few other modeling approaches if we need = that. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Dec 18 05:35: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 AB1203A0E71 for ; Sat, 18 Dec 2021 05:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 S_ccXsjksLFq for ; Sat, 18 Dec 2021 05:35:44 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 73A933A0E70 for ; Sat, 18 Dec 2021 05:35:44 -0800 (PST) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 38B347D002; Sat, 18 Dec 2021 13:35:43 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Christian Hopps In-Reply-To: <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> Date: Sat, 18 Dec 2021 08:35:41 -0500 Cc: Christian Hopps , Eliot Lear , "netmod@ietf.org" , Ladislav Lhotka Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 18 Dec 2021 13:35:50 -0000 > On Dec 18, 2021, at 7:59 AM, Carsten Bormann wrote: >=20 > On 2021-12-18, at 09:20, Eliot Lear wrote: >>=20 >> Still it seems like the right thing to do, in order to fall into line = with the target language spec. >=20 > But that=E2=80=99s not what YANG was designed for. > YANG is a data modeling language, which incidentally has a couple of = representation formats (YANG-XML, YANG-JSON, YANG-CBOR). > There is no intention for the YANG generic data model (the set of all = data models YANG can express) to cover the generic data model of the = representation format. To be clear, the question I raised is about an encoding of YANG modeled = data. In particular the JSON encoding of the YANG empty leaf element. https://datatracker.ietf.org/doc/html/rfc7951#section-6.9 the justification for having the very odd encoding was that there was = some belief that some programming languages might have trouble with the = obvious JSON "null" encoding (which stands for "no value" in JSON -- = exactly what we want here). An old email gave a python example to try = and illustrate this, except the python example was an incorrect use of = python for this case (presence check) and not a problem with the natural = JSON encoding for no value items. In fact correctly written python code = has no problem at all with the more natural "null" encoding, and results = in the correct internal representation in python to boot. This isn't about the YANG specification in general, or making YANG = conform to any particular language. It's just about the a choice in the = specification for the encoding of YANG in a particular format (JSON). Thanks, Chris. >=20 > While RFC 8791 (and before it RFC 8040) extended YANG to be able to = describe data in flight, there is no intention that YANG can be used to = describe the entire expressibility of the representation format. We = have Relax-NG, CDDL, and a few other modeling approaches if we need = that. > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Sat Dec 18 06:13: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 34B2C3A0EB1 for ; Sat, 18 Dec 2021 06:13:54 -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, 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 K28y9_1esU0s for ; Sat, 18 Dec 2021 06:13:49 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41CE3A0EAF for ; Sat, 18 Dec 2021 06:13:48 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JGSWW5fbSzDCkt; Sat, 18 Dec 2021 15:13:43 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Sat, 18 Dec 2021 15:13:42 +0100 Cc: Eliot Lear , "netmod@ietf.org" , Ladislav Lhotka X-Mao-Original-Outgoing-Id: 661529622.651626-eb302c9a180cad698e3d8b25fbf3c7ef Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> To: Christian Hopps X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 18 Dec 2021 14:13:54 -0000 On 2021-12-18, at 14:35, Christian Hopps wrote: >=20 > This isn't about the YANG specification in general, or making YANG = conform to any particular language. It's just about the a choice in the = specification for the encoding of YANG in a particular format (JSON). I understand the objective to have a good representation for YANG data. For instance, in YANG-CBOR, a YANG empty is represented as a CBOR null = (0xf6, in case you need to visualize the bits); there is no expectation = that this will be difficult to handle by CBOR implementations. However, there is nothing wrong with representing empty with the array = =C2=BB[null]=C2=AB in YANG-JSON. It is just more complex, and = apparently unnecessarily so. Whether removing this complexity to save two characters is worth doing = an incompatible upgrade to the YANG-JSON representation format can be = debated. I=E2=80=99d say: emphatically no. The other motivation that came up in this thread is that it is natural = to have null as a value in JSON and YANG cannot describe such formats = via YANG-JSON. This was what I was reacting to, but, as you say, that = wasn=E2=80=99t your question. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Dec 18 08:34: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 A17D93A1032 for ; Sat, 18 Dec 2021 08:34:01 -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.20210112.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 1KE5q8AZpR8j for ; Sat, 18 Dec 2021 08:33:57 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 4D1133A0788 for ; Sat, 18 Dec 2021 08:33:57 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id k37so11441217lfv.3 for ; Sat, 18 Dec 2021 08:33:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e0L+Uf9MZQ6VbXEzBREL4rbqmlYPQ6jqVNfZsiSq2mk=; b=BCXbEhE7DZMfGTAYTllBm4Ggv57bwrAvuKdzQR2/Ns73+Z5QxrYtBUZKRPJdKgvTdb MoOofvl+02wZ4Nxsq1lLCM6NdrpQ2w1mkSzM7tm3MVRCZ+TLv+6SlJi2iYNKnIRJBPeN A+BeVHuYx0v61K9HBEeMfQKCONFkYJRlWCB2ez//CzhwjAIdWR4ID3vt6B6k3f0Vr6nU 1HxDumoq3bkPqBknhCSCamNGXU6e7WsleKS+F2Y+kfddnaopTG/QrChj4cqoaIpJFWHr PMsu6uM7KfZZpN+5ylxOjGTJao7tVpaNSlUmDoeCqyG03YPJFUreUxterDFuTBNdXWpT lNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e0L+Uf9MZQ6VbXEzBREL4rbqmlYPQ6jqVNfZsiSq2mk=; b=wV0fGbRLCswzCxYK9GWIQpRoeOycEUzy+Rs6Lx3P/qeB+QBMAAEO96YCTyLZbcgbk0 7G2feRjJMaFTGEr9wbldUz/GPcipepRZC5StNbjtkW2Y//W1Mfq5ifaTzA0+5rKlfI5z Z5TzNz5QRCDWhT+IB5Q4Lv7MLi/v/oD0ecdpxmkX6s6UO9r9VRigE9CDbvMzKtPVCgpP lCohOYYcuLUFp9woWWUYYfMgnyPgRdrswaY9EIvGcxhGyERpZ4+rDTS0XjSJp7BSMd4F SsVvP1Aw4FUR+lCKGlJKQ/bwjQSofB8kxxWg9zi0hOOCvhUSvT9HUSqi3vm3K4FIeHCO U/7g== X-Gm-Message-State: AOAM533sVAG45y2F1vPbwoQYYkf0vQJnt2s9F0Fhf3plZKVsj8S2ara7 zQvGxQDWHX2wKnHKDc34uW+Ytoii9A7iDssjDdItYDw8+2s= X-Google-Smtp-Source: ABdhPJxI9mL4IUV0cjKfoBR9WruiXF3F8qERy42vD+seJ8BostdZ9jHcYtZXWSErO+c0J2OvvUF5VWM2pRjcl+rxfME= X-Received: by 2002:ac2:5507:: with SMTP id j7mr7625096lfk.635.1639845234909; Sat, 18 Dec 2021 08:33:54 -0800 (PST) MIME-Version: 1.0 References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> In-Reply-To: From: Andy Bierman Date: Sat, 18 Dec 2021 08:33:43 -0800 Message-ID: To: Carsten Bormann Cc: Christian Hopps , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b6b7d205d36e383e" Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 18 Dec 2021 16:34:02 -0000 --000000000000b6b7d205d36e383e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 18, 2021 at 6:14 AM Carsten Bormann wrote: > On 2021-12-18, at 14:35, Christian Hopps wrote: > > > > This isn't about the YANG specification in general, or making YANG > conform to any particular language. It's just about the a choice in the > specification for the encoding of YANG in a particular format (JSON). > > I understand the objective to have a good representation for YANG data. > > For instance, in YANG-CBOR, a YANG empty is represented as a CBOR null > (0xf6, in case you need to visualize the bits); there is no expectation > that this will be difficult to handle by CBOR implementations. > > However, there is nothing wrong with representing empty with the array > =C2=BB[null]=C2=AB in YANG-JSON. It is just more complex, and apparently > unnecessarily so. > Whether removing this complexity to save two characters is worth doing an > incompatible upgrade to the YANG-JSON representation format can be debate= d. > I=E2=80=99d say: emphatically no. > > Thank you for caring about backward compatibility and stability. The other motivation that came up in this thread is that it is natural to > have null as a value in JSON and YANG cannot describe such formats via > YANG-JSON. This was what I was reacting to, but, as you say, that wasn= =E2=80=99t > your question. > > Gr=C3=BC=C3=9Fe, Carsten > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000b6b7d205d36e383e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 18, 2021 at 6:14 AM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
On 2021-12-18, a= t 14:35, Christian Hopps <chopps@chopps.org> wrote:
>
> This isn't about the YANG specification in general, or making YANG= conform to any particular language. It's just about the a choice in th= e specification for the encoding of YANG in a particular format (JSON).

I understand the objective to have a good representation for YANG data.

For instance, in YANG-CBOR, a YANG empty is represented as a CBOR null (0xf= 6, in case you need to visualize the bits); there is no expectation that th= is will be difficult to handle by CBOR implementations.

However, there is nothing wrong with representing empty with the array =C2= =BB[null]=C2=AB in YANG-JSON.=C2=A0 It is just more complex, and apparently= unnecessarily so.
Whether removing this complexity to save two characters is worth doing an i= ncompatible upgrade to the YANG-JSON representation format can be debated.<= br> I=E2=80=99d say: emphatically no.


Thank you for caring about backward co= mpatibility and stability.

The other motivation that came up in this thread is that it is natural to h= ave null as a value in JSON and YANG cannot describe such formats via YANG-= JSON.=C2=A0 This was what I was reacting to, but, as you say, that wasn=E2= =80=99t your question.

Gr=C3=BC=C3=9Fe, Carsten


Andy
=C2=A0
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000b6b7d205d36e383e-- From nobody Sat Dec 18 10:04: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 39D343A1086 for ; Sat, 18 Dec 2021 10:04:54 -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, 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 HzSIAAD7hkTS for ; Sat, 18 Dec 2021 10:04:49 -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 7E7CD3A1084 for ; Sat, 18 Dec 2021 10:04:48 -0800 (PST) Received: from localhost (unknown [IPv6:2a01:5e0:29:ffff::82e]) by mail.nic.cz (Postfix) with ESMTPSA id 8945A1409FE; Sat, 18 Dec 2021 19:04:45 +0100 (CET) From: Ladislav Lhotka To: Christian Hopps , Carsten Bormann Cc: Christian Hopps , Eliot Lear , "netmod@ietf.org" In-Reply-To: References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> Mail-Followup-To: Christian Hopps , Carsten Bormann , Christian Hopps , Eliot Lear , "netmod@ietf.org" Date: Sat, 18 Dec 2021 19:04:45 +0100 Message-ID: <875yrlhjr6.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.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 18 Dec 2021 18:04:54 -0000 Christian Hopps writes: >> On Dec 18, 2021, at 7:59 AM, Carsten Bormann wrote: >>=20 >> On 2021-12-18, at 09:20, Eliot Lear wrote: >>>=20 >>> Still it seems like the right thing to do, in order to fall into line w= ith the target language spec. >>=20 >> But that=E2=80=99s not what YANG was designed for. >> YANG is a data modeling language, which incidentally has a couple of rep= resentation formats (YANG-XML, YANG-JSON, YANG-CBOR). >> There is no intention for the YANG generic data model (the set of all da= ta models YANG can express) to cover the generic data model of the represen= tation format. > > To be clear, the question I raised is about an encoding of YANG modeled d= ata. In particular the JSON encoding of the YANG empty leaf element. > > https://datatracker.ietf.org/doc/html/rfc7951#section-6.9 > > the justification for having the very odd encoding was that there was som= e belief that some programming languages might have trouble with the obviou= s JSON "null" encoding (which stands for "no value" in JSON -- exactly what= we want here). An old email gave a python example to try and illustrate th= is, except the python example was an incorrect use of python for this case = (presence check) and not a problem with the natural JSON encoding for no va= lue items. In fact correctly written python code has no problem at all with= the more natural "null" encoding, and results in the correct internal repr= esentation in python to boot. > > This isn't about the YANG specification in general, or making YANG > conform to any particular language. It's just about the a choice in > the specification for the encoding of YANG in a particular format > (JSON). The original proposal (even before my individual draft appeared in the NETM= OD WG) was actually just "null". We'd been discussing it back in March 2012= in a smaller group (Andy, J=C3=BCrgen, Martin, Phil Shafer and myself), an= d Phil objected to this encoding of empty values. His arguments were, for e= xample: 'foo: null'? Doesn't that make testing for empty values a major pain? 'if (foo)' would not work. JSON evolved from Javascript, so it must keep the javascript meanings for these keywords. It is indeed true that tests in JavaScript cannot really distinguish betwee= n a non-existent member and member with the value of 'null'. I remember I w= asn't happy about this change but I thought it wasn't a big deal. Lada > > Thanks, > Chris. > > > >>=20 >> While RFC 8791 (and before it RFC 8040) extended YANG to be able to desc= ribe data in flight, there is no intention that YANG can be used to describ= e the entire expressibility of the representation format. We have Relax-NG= , CDDL, and a few other modeling approaches if we need that. > >> Gr=C3=BC=C3=9Fe, Carsten >>=20 > --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Sat Dec 18 11:02: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 DD8A83A10AB for ; Sat, 18 Dec 2021 11:02:48 -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 iJTjN1Lwg36o for ; Sat, 18 Dec 2021 11:02:44 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4333A3A00F7 for ; Sat, 18 Dec 2021 11:02:43 -0800 (PST) Received: from smtpclient.apple (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JGZww5QQNzDCgg; Sat, 18 Dec 2021 20:02:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <875yrlhjr6.fsf@nic.cz> Date: Sat, 18 Dec 2021 20:02:40 +0100 Cc: Christian Hopps , Eliot Lear , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <80C39075-B512-4771-BD06-077423A361EC@tzi.org> References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> <875yrlhjr6.fsf@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 18 Dec 2021 19:02:49 -0000 On 18. Dec 2021, at 19:04, Ladislav Lhotka = wrote: >=20 > 'foo: null'? Doesn't that make testing for empty values a major > pain? 'if (foo)' would not work. Same with =C2=BBfalse=C2=AB, which 7951 is not escaping into an array. This argument simply doesn=E2=80=99t hold water. As was mentioned, you would check =C2=BB=E2=80=9Dfoo=E2=80=9D in o=C2=AB, = which works for null, false, and all other values that may happen to be = falsy(*) in the platform. > JSON evolved from Javascript, so it must keep the javascript > meanings for these keywords. That is a common misconception that must be stamped out, but we have = json@ietf.org for that discussion. > It is indeed true that tests in JavaScript cannot really distinguish = between a non-existent member and member with the value of 'null'. I = remember I wasn't happy about this change but I thought it wasn't a big = deal. As mentioned, they can. And, yes, this little unnecessary complexity is not a big deal even if = it is based on mistaken beliefs; every non-trivial protocol has some = unburied zombies in the basement. Gr=C3=BC=C3=9Fe, Carsten (*) falsy: converted to false when implicitly coerced to a Boolean = (Ant.: truthy) From nobody Sun Dec 19 00:25:28 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 5EF843A0AEF for ; Sun, 19 Dec 2021 00:25:26 -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, 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 fM-7CrzVSBip for ; Sun, 19 Dec 2021 00:25:21 -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 958813A0AEB for ; Sun, 19 Dec 2021 00:25:20 -0800 (PST) Received: from localhost (unknown [IPv6:2a01:5e0:29:ffff::82e]) by mail.nic.cz (Postfix) with ESMTPSA id 2FEE8140A24; Sun, 19 Dec 2021 09:25:14 +0100 (CET) From: Ladislav Lhotka To: Carsten Bormann Cc: Christian Hopps , Eliot Lear , "netmod@ietf.org" In-Reply-To: <80C39075-B512-4771-BD06-077423A361EC@tzi.org> References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> <875yrlhjr6.fsf@nic.cz> <80C39075-B512-4771-BD06-077423A361EC@tzi.org> Mail-Followup-To: Carsten Bormann , Christian Hopps , Eliot Lear , "netmod@ietf.org" Date: Sun, 19 Dec 2021 09:25:13 +0100 Message-ID: <8735mpgfx2.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.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 19 Dec 2021 08:25:27 -0000 Carsten Bormann writes: > On 18. Dec 2021, at 19:04, Ladislav Lhotka wrote: >>=20 >> 'foo: null'? Doesn't that make testing for empty values a major >> pain? 'if (foo)' would not work. > > Same with =C2=BBfalse=C2=AB, which 7951 is not escaping into an array. T= his > argument simply doesn=E2=80=99t hold water. As was mentioned, you would > check =C2=BB=E2=80=9Dfoo=E2=80=9D in o=C2=AB, which works for null, false= , and all other > values that may happen to be falsy(*) in the platform. The whole story is that Phil wanted to have both empty and boolean values a= s JSON strings. The result was a compromise, and I thought that [null] was = a much better choice because, unlike "null" string, it cannot otherwise app= ear as a valid value of a YANG leaf. > >> JSON evolved from Javascript, so it must keep the javascript >> meanings for these keywords. > > That is a common misconception that must be stamped out, but we have > json@ietf.org for that discussion. It's not that I am defending these views. I did argue with RFC 4627, but no= t too hard, as this seemed like a marginal issue at that time - much more f= undamental objections against the JSON representation were raised back then. > >> It is indeed true that tests in JavaScript cannot really distinguish bet= ween a non-existent member and member with the value of 'null'. I remember = I wasn't happy about this change but I thought it wasn't a big deal. > > As mentioned, they can. > And, yes, this little unnecessary complexity is not a big deal even if it= is based on mistaken beliefs; every non-trivial protocol has some unburied= zombies in the basement. Right, in hindsight it was a mistake. It is also worth noting that [null] i= s only an on-the-wire value, so e.g. None can be used internally in Python.= I have written a lot of related running code and don't find it a serious p= roblem.=20=20 Lada > > Gr=C3=BC=C3=9Fe, Carsten > > (*) falsy: converted to false when implicitly coerced to a Boolean (Ant.:= truthy) > --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Dec 20 13:53: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 993F13A09DB for ; Mon, 20 Dec 2021 13:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rxDNvUyd_zGU for ; Mon, 20 Dec 2021 13:53:16 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 53A013A09DD for ; Mon, 20 Dec 2021 13:53:16 -0800 (PST) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 5008B7D00D; Mon, 20 Dec 2021 21:53:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Christian Hopps In-Reply-To: Date: Mon, 20 Dec 2021 16:53:14 -0500 Cc: Christian Hopps , Carsten Bormann , Ladislav Lhotka , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> To: Andy Bierman X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 20 Dec 2021 21:53:21 -0000 > On Dec 18, 2021, at 11:33 AM, Andy Bierman wrote: >=20 > Thank you for caring about backward compatibility and stability. >=20 I guess I left as implicit in my question of whether we could do = something to fix it, that that "could" implied a fix wouldn't break = things. I certainly care about stability and backward compatibility. Thanks, Chris.= From nobody Mon Dec 20 14:23: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 8044C3A0B2F for ; Mon, 20 Dec 2021 14:23:17 -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.20210112.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 vWKjAAvqbpmh for ; Mon, 20 Dec 2021 14:23:13 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 D25583A0B1F for ; Mon, 20 Dec 2021 14:23:12 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id e5so22911614wrc.5 for ; Mon, 20 Dec 2021 14:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=llm+9GjhXPGGinm08NPrKluurCK1rsvDIqvSNZ/q5cI=; b=5PP5Ne7bkEKSsusiiMlrwXGsvg6b5PmkF2dvfC0ToLyOeXS11hrZc0mo59KUDhYsEz J1MIxJY55lrwYRkayNEfnTgBqgWg5UFFlscjEMbOdb/IW2Orh+K7z5oIwIbpUH2WItUk p0Gjyc7FXfC8NwaPEpUYJhCklCXUol8qKY614h0gDAKlLhrp9taZBeQ4XjP/Qs29+FcN lFMEnRY/PgLl89gpSHSgK+xUDc3pny05Pux8xRH9IEWsb1gtS8EAp8wm+Hx8wAAJGve3 OsM1YTr7m8zM63G+9nJdXmq9/7hOZCtri4D5omjHYCiJ6wUMrpIt5Vw8hEigNNIIFy4X umuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=llm+9GjhXPGGinm08NPrKluurCK1rsvDIqvSNZ/q5cI=; b=ODnoelB+IHe+akbVfsbpA3qwodYaNGfmMlC7k2RipFRgQQ6WWTGKLbb7s5gNuDDrXp u/LHw3l59DxG6EAVia0Tb7jjLcMdoIha5R9rinO6ZYoV7DygLql/RuK5zTjh81ytKR/4 y3JIpGUKOJcFqI8HTCmnmqFqqtYGyh85OZU+z4vNzAw6pL29UFaIMgB/2sUHv06+Yt13 Qcl6tjaxOAiv2UXdoPIrKyfTHf08GqtC+GBMucICfszkmq1QekZgA9VgTYKqx0DWUUqH 4CHGYYpujfYQRorqO/oM4qvSFWt4WRLix3z4a+4qtMYXq646uHVO9HZSq8YzRCc8gssh 2g3g== X-Gm-Message-State: AOAM530v6yIoWZeGGgK31VWQ5syYcNm6/6n3Ii1ODAgv/IT3giAcszZJ 2ZztNLePj4q6O5B+GoQ6jh4NhPTpLS+dG7G3d5ofOg== X-Google-Smtp-Source: ABdhPJzN/SR4sleUrhTnPatWjMeouqIQFfXCdu6g3TQ6kMNQHux3LeQ8fOwPUzVWvZcCMrnEApZJZrRFw77MKH07ODY= X-Received: by 2002:a05:6000:156c:: with SMTP id 12mr175052wrz.104.1640038989353; Mon, 20 Dec 2021 14:23:09 -0800 (PST) MIME-Version: 1.0 References: <20150624145325.GB38016@elstar.local> <1640D503-A676-4BC5-82E6-E08ED04F7106@chopps.org> <4d8189be-aeea-9ed9-b43f-80580acd2b9a@lear.ch> <1FE71A45-2B1A-4B46-96FF-A1D781F4C47D@tzi.org> In-Reply-To: From: Andy Bierman Date: Mon, 20 Dec 2021 14:22:58 -0800 Message-ID: To: Christian Hopps Cc: Carsten Bormann , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000060e7d805d39b5591" Archived-At: Subject: Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)] 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, 20 Dec 2021 22:23:18 -0000 --00000000000060e7d805d39b5591 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 20, 2021 at 1:53 PM Christian Hopps wrote: > > > > On Dec 18, 2021, at 11:33 AM, Andy Bierman wrote: > > > > Thank you for caring about backward compatibility and stability. > > > > I guess I left as implicit in my question of whether we could do something > to fix it, that that "could" implied a fix wouldn't break things. I > certainly care about stability and backward compatibility. > > good point. Sometimes we forget that changing the RFCs is the easy part. People that don't even know this mailing list exists have to learn and implement the changes. Then the operator community has to deal with tool incompatibilities for years to come. The "industry" expects stability from YANG at this point. They are focused on implementing and deploying YANG models. The foundation is good enough. Not perfect. Nobody is expecting that. Thanks, > Chris. Andy --00000000000060e7d805d39b5591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 20, 2021 at 1:53 PM Chris= tian Hopps <chopps@chopps.org&g= t; wrote:


> On Dec 18, 2021, at 11:33 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
> Thank you for caring about backward compatibility and stability.
>

I guess I left as implicit in my question of whether we could do something = to fix it, that that "could" implied a fix wouldn't break thi= ngs. I certainly care about stability and backward compatibility.



good point.
<= br>
Sometimes we forget that changing the RFCs is the easy part.<= /div>
People that don't even know this mailing list exists have to = learn and implement the changes.
Then the operator community has = to deal with tool incompatibilities for years to come.

=
The "industry" expects stability from YANG at this point.
They are focused on implementing and deploying YANG models.
The foundation is good enough. Not perfect. Nobody is expecting that.

Thanks,
Chris.


Andy
=C2=A0=
--00000000000060e7d805d39b5591-- From nobody Tue Dec 21 05:09: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 6E52A3A0F4A for ; Tue, 21 Dec 2021 05:09:06 -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 0tjNVVkW6d3V for ; Tue, 21 Dec 2021 05:09:02 -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 B7C943A0F39 for ; Tue, 21 Dec 2021 05:09:01 -0800 (PST) Received: from fraeml706-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JJGrB1mmZz67Ncp for ; Tue, 21 Dec 2021 21:04:26 +0800 (CST) Received: from kwepemm000019.china.huawei.com (7.193.23.135) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Tue, 21 Dec 2021 14:08:57 +0100 Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm000019.china.huawei.com (7.193.23.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Tue, 21 Dec 2021 21:08:56 +0800 Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2308.020; Tue, 21 Dec 2021 21:08:56 +0800 From: "maqiufang (A)" To: Andy Bierman , Kent Watsen CC: "netmod@ietf.org" Thread-Topic: [netmod] Must offline-validation of alone be valid? Thread-Index: AdffkR5mw0pyFtGVS9uFCu3u8tPNZAAfJr4AAAKFEoAADiYHAAE2j/QAAK+uFwAAAPEZAAABOHuAAhGTXIAAAiv2AAAEfVSAAADNCoAAr8WigAAGG0gAAM5lDjA= Date: Tue, 21 Dec 2021 13:08:56 +0000 Message-ID: <5e9fbee4923a4d79b0bebbc2a1553f23@huawei.com> References: <0df9454875b54804b42ec2f5cc6b151f@huawei.com> <7511E143-A08F-4089-89CB-17F74C2E9CCE@tail-f.com> <0100017d6dbe6f00-1f424f2e-1faa-433b-bd36-a2b299a3764d-000000@email.amazonses.com> <20211203102610.6zntrwbemnyxxjnr@anna> <0100017db62efa5c-afe9bd3b-6ad6-41ad-89b8-d42cb0c4a9db-000000@email.amazonses.com> <0100017db6dd98ed-fc26f840-5965-41e1-a224-3a1e107cd910-000000@email.amazonses.com> <0100017dc8f257bb-06dfa1ba-4c38-4db6-92eb-ce299024e9e2-000000@email.amazonses.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.87] Content-Type: multipart/alternative; boundary="_000_5e9fbee4923a4d79b0bebbc2a1553f23huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Must offline-validation of alone be valid? 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, 21 Dec 2021 13:09:07 -0000 --_000_5e9fbee4923a4d79b0bebbc2a1553f23huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFuZHksIGFsbA0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jr cy5jb21dDQpTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMTgsIDIwMjEgMjowNiBBTQ0KVG86IEtl bnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4NCkNjOiBtYXFpdWZhbmcgKEEpIDxtYXFp dWZhbmcxQGh1YXdlaS5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9k XSBNdXN0IG9mZmxpbmUtdmFsaWRhdGlvbiBvZiA8cnVubmluZz4gYWxvbmUgYmUgdmFsaWQ/DQoN Cg0KDQpPbiBGcmksIERlYyAxNywgMjAyMSBhdCA3OjExIEFNIEtlbnQgV2F0c2VuIDxrZW50K2ll dGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCUyQmlldGZAd2F0c2VuLm5ldD4+IHdyb3RlOg0KQW5k eSwgZXQuIGFsLiwNCg0KDQpJIGNhbm5vdCBmaW5kIGFueSBSRkMgdGV4dCB0aGF0IHNheXMgPHJ1 bm5pbmc+IGhhcyBvbmx5IG5vZGVzIGNyZWF0ZWQgYnkgYSBjbGllbnQuDQoNClJlYWxseT8gIElu dGVyZXN0aW5nLiAgIFN0aWxsLCBJIGtub3cgaXTigJlzIGEgbWFudHJhIHdl4oCZdmUgaGVsZCBj bG9zZWx5IGZvciBtYW55IHllYXIsIHJpZ2h0Pw0KDQpOby4gUXVpdGUgdGhlIG9wcG9zaXRlLiAg PHNuaXA+DQpbUWl1ZmFuZyBNYV0gS2VudCBhbmQgSmFzb24gc2FpZCB0aGF0IHRoZSDigJxzaGFy ZWQgb2JqZWN0c+KAnSBpcyB0aGUgcHJpbWFyeSA8c3lzdGVtPiBjb25maWd1cmF0aW9uIHVzZSBj YXNlcy4gSSBkbyBhZ3JlZS4gSW4gSHVhd2Vp4oCZcyBpbXBsZW1lbnRhdGlvbiwgVGhlIHNlcnZl ciBhbHNvIGdlbmVyYXRlcyBodW5kcmVkcyBvZiBzeXN0ZW0gZGF0YSBvYmplY3RzKHNlcnZpY2Ug dGVtcGxhdGVzLCBwcmVkZWZpbmVkIHBvbGljaWVzLCBldGMpLiBQaHlzaWNhbCByZXNvdXJjZSBy ZWxhdGVkIGNvbmZpZ3VyYXRpb24gaXMgcmVhbGx5IG9ubHkgYSBzbWFsbCBwYXJ0IG9mIHRoYXQu DQpBbmQgYXMgeW91IG1lbnRpb25lZCwgdGhlcmUgaXMgbm8gUkZDIHRleHQgc2F5cyA8cnVubmlu Zz4gaGF2ZSBvbmx5IG5vZGVzIGNyZWF0ZWQgYnkgYSBjbGllbnQuIEFjdHVhbGx5LCBpbiBvdXIg aW1wbGVtZW50YXRpb24sIHdlIGRvIGFsbG93IHN5c3RlbSBjb25maWd1cmF0aW9uIHRvIGJlIHBv cHVsYXRlZCBpbnRvIDxydW5uaW5nPiBhdXRvbWF0aWNhbGx5IHdoZW4gaXQgaXMgZ2VuZXJhdGVk LCBiZWNhdXNlIGNvcHkvcGFzdGUgZm9yIHJlZmVyZW5jZSBpcyBwYWluZnVsLiBUaGF0IGlzLCBh bGwgdGhlIHN5c3RlbSBjb25maWd1cmF0aW9uIGlzIHJlYWxseSBhIHBhcnQgb2YgPHJ1bm5pbmc+ LiBCdXQgb3VyIGN1c3RvbWVycyBkbyBjb21wbGFpbiB0aGF0IHdoZW4gcmV0cmlldmluZyA8cnVu bmluZz4gdGhleSB1c3VhbGx5IGZpbmQgYSBsYXJnZSBudW1iZXIgb2YgY29uZmlndXJhdGlvbiBk YXRhIG9iamVjdHMgbm90IGRlZmluZWQgYnkgdGhlbXNlbHZlcywgbW9zdCBvZiB3aGljaCBhcmUg aXJyZWxldmFudCB0byB0aGVpciBvd24gY29uZmlndXJhdGlvbnMgYW5kIHRoZXkgaGF2ZSBubyBp ZGVhIHdoZXJlIHRoZXkgYXJlIGNvbWUgZnJvbS4NCkkgYWxzbyB0cmllZCB0byBicmluZyB0aGlz IGlkZWEgdG8gdGhlIElFVEYoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1tYS1uZXRjb25mLXdpdGgtc3lzdGVtLTAyI3NlY3Rpb24tMy4xKSBhbmQgd291bGQgbGlr ZSB0byBjb2xsZWN0IHNvbWUgbW9yZSBmZWVkYmFjaywgaXQgc2VlbXMgdGhhdCB0aGUgV0cgdGhp bmtzIHdlIHdhbnQgdGhlIGNsaWVudCB0byBmdWxseSBvd24gdGhlIHJ1bm5pbmcgZGF0YXN0b3Jl LCB0aGUgc2VydmVyIHNob3VsZCBuZXZlciBhdXRvLXBvcHVsYXRlcyA8cnVubmluZz4gdW5sZXNz IGFza2VkIGJ5IHRoZSBjbGllbnRzLg0KDQpCZXN0IFJlZ2FyZHMsDQpRaXVmYW5nIE1hDQoNClRo ZXJlIHdhcyBhIGJyb3VoYWhhIGJhY2sgd2hlbiBJIHByb3Bvc2VkIHRoZSAia2V5c3RvcmXigJ0g ZHJhZnQgaGF2ZSBhbiDigJxhY3Rpb27igJ0gY2FsbGVkIOKAnGdlbmVyYXRlLXByaXZhdGUta2V5 4oCdIHRoYXQgd291bGQgaW5zZXJ0IHRoZSBnZW5lcmF0ZWQga2V5IGludG8gPHJ1bm5pbmc+LiAg Q2xhaW1zIHdlcmUgbWFkZSBieSBwcm9taW5lbnQgbWVtYmVycyBvZiB0aGlzIGxpc3QgdGhhdCBp dOKAmXMgYmFkIGZvcm0gZm9yIGFueXRoaW5nIGJ1dCBhIGNsaWVudCB0byBlZGl0IDxydW5uaW5n Pi4NCg0KQXMgYSByZXN1bHQsIGV4dGVuc2l2ZSBlZmZvcnQgd2FzIHNwZW50IGRlZmluaW5nIGEg bWVjaGFuaXNtIGVuYWJsaW5nIHRoZSBnZW5lcmF0ZWQga2V5IHRvIGJlIHJldHVybmVkIGluIHRo ZSBSUEMtcmVwbHkgaW4gYW4gZW5jcnlwdGVkIGZvcm0gKHN1Y2ggdGhhdCBvbmx5IHRoZSBzZXJ2 ZXIgdGhhdCBnZW5lcmF0ZWQgdGhlIGtleSBjb3VsZCBkZWNyeXB0IGl0KSwgYWxsIHNvIHRoZSBj bGllbnQgY291bGQgaW1tZWRpYXRlbHkgcmV0dXJuIGl0IHRvIHRoZSBzZXJ2ZXIgdmlhIGEgY29u ZmlnIHB1c2ggaW4gb3JkZXIgdG8gcHJlc2VydmUgdGhlIHNhbmN0aXR5IG9mIGNsaWVudCByZWFk LWJhY2tzLg0KDQpJZiBjdXJyZW50IGNsYWltcyB3ZXJlIHRydWUgdGhlbiwgd2h5IGRpZG7igJl0 IHNvbWVvbmUganVzdCBzYXkgaXTigJlzIG9rYXkgc2luY2UgdGhlIHNlcnZlciBpcyBhY3Rpbmcg bGlrZSBhIGNsaWVudCB1bmRlciB0aGUgaG9vZD8NCg0KTWF5YmUgbm90IGEgbG90IG9mIG5vbi1z ZWN1cml0eSBwZW9wbGUgd2VyZSBmb2xsb3dpbmcgdGhlIHRocmVhZC4NCklNTyBhIGJldHRlciBk ZXNpZ24gd291bGQgaGF2ZSBiZWVuIHRvIGludHJvZHVjZSBhICJzZWN1cmUtTlYtc3RvcmFnZSIg Y29uY2VwdC4NClRoZSBrZXlzIGFyZSBuZXZlciBleHBvc2VkLiBPbmx5IGxhYmVscyBhcmUgZXhw b3NlZCBhbmQgdGhlIGNsaWVudCBjYW4gc3RvcmUgYSByZWZlcmVuY2UgdG8gdGhlIGtleSBpbiA8 cnVubmluZz4uDQpNYXliZSBKdWVyZ2VuIHByb3Bvc2VkIHRoaXMgaWRlYS4NCg0KWUFORy1iYXNl ZCBtYW5hZ2VtZW50IGFzc3VtZXMgdGhhdCB0aGUgY29uY2VwdHVhbCBBUEkgZm9yIGEgWUFORyBk ZXZpY2UNCmNhbiBiZSBkZXNjcmliZWQgYnkgYWxsIHRoZSBbbW9kdWxlLCByZXZpc2lvbiwgZmVh dHVyZXMsIGRldmlhdGlvbnNdIHR1cGxlcyAoWUFORyBsaWJyYXJ5KS4NClRoZXJlIHdhcyBhbiBv cmlnaW5hbCBhc3N1bXB0aW9uIHRoYXQgPHJ1bm5pbmc+IGNvdWxkIGNvbnRhaW4gYWxsIHRoZSBp bmZvcm1hdGlvbiB0bw0KZGVzY3JpYmUgdGhpcyAicmVhbCBBUEkiLg0KDQpUaGUgb3JpZ2luYWwg ZGVzaWduIHdhcyB0b28gc2ltcGxpc3RpYyBzbyBOTURBIGludHJvZHVjZWQgPGludGVuZGVkPiBh bmQgPG9wZXJhdGlvbmFsPiBkYXRhc3RvcmVzLg0KTm93IDxydW5uaW5nPiBubyBsb25nZXIgcmVw cmVzZW50cyB0aGUgInJlYWwgQVBJIi4gSXQgbm93IGNvbnRhaW5zIHNvbWUgb3IgYWxsIG9mIHRo ZSBpbmZvcm1hdGlvbiByZXF1aXJlZA0KdG8gcHJvZHVjZSB0aGUgcmVhbCBBUEksIHdoaWNoIGlz IG5vdyBkZWVtZWQgdG8gYmUgPGludGVuZGVkPi4NCg0KTm90IG9uZSBvZiB0aGUgbWVjaGFuaXNt cyB0byB0cmFuc2Zvcm0gPHJ1bm5pbmc+IGludG8gPGludGVuZGVkPiBpcyBzdGFuZGFyZGl6ZWQu DQpOb3cgPHJ1bm5pbmc+ICsgPz8/IGlzIGEgY29tYmluYXRpb24gb2YgdGhlIHJlYWwgQVBJIGFu ZCB0aGUgInByb3ByaWV0YXJ5IHNldHVwIEFQSSIuDQoNCkl0IGhhcyBuZXZlciBiZWVuIHRydWUg dGhhdCA8cnVubmluZz4gaXMgYWx3YXlzIHZhbGlkLiBJbiBoaW5kc2lnaHQsIHRoYXQgTVVTVCBp cyByZWFsbHkgYSBTSE9VTEQsIHBvc3QtTk1EQS4NCkluYWN0aXZlIG5vZGVzIGNhbm5vdCBiZSBj b3VudGVkIGFnYWluc3QgY29uc3RyYWludHMgKGUuZy4gbXVzdCwgbWluL21heC1lbGVtZW50cywg dW5pcXVlKS4NCkNvbnN0cmFpbnRzIG9uIGNvbmZpZyB0ZW1wbGF0ZXMgZG8gbm90IGFkZHJlc3Mg dGhlIG5lZWRlZCBjb25zdHJhaW50cyBvbiB0aGUgZXhwYW5kZWQgZGF0YS4NCg0KSU1PIGl0IGlz IHRvbyBsYXRlICJmaXgiIDxydW5uaW5nPiBieSBwbGFjaW5nIGFueSByZXN0cmljdGlvbnMgb24g dGhlIGNvbnRlbnRzIG9yIHdobyBjYW4gZWRpdCBpdC4NCk5NREEgKHdpc2VseSkgZGlkIG5vdCBk byBpdC4gIEEgInN5c3RlbSBlZGl0IiBpcyBkaWZmaWN1bHQgdG8gZGVzY3JpYmUsDQplc3BlY2lh bGx5IGluIGEgY29udHJvbGxlci1kcml2ZW4gYm9vdHN0cmFwIGZyYW1ld29yay4gIFRoZSBpbW11 YWJsZSBpc3N1ZQ0KaXMganVzdCBoaWRkZW4gYWNjZXNzIGNvbnRyb2wsIHNvIHRhZyBkYXRhIG5v ZGVzIHdpdGggbmV3IG1ldGFkYXRhIHRvIGV4cG9zZSB0aGF0Lg0KDQoNCg0KSy4NCg0KDQpBbmR5 DQoNCg== --_000_5e9fbee4923a4d79b0bebbc2a1553f23huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkhpLCBBbmR5LCBhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g QW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFNhdHVyZGF5LCBEZWNlbWJlciAxOCwgMjAyMSAyOjA2IEFNPGJyPg0KPGI+VG86PC9iPiBL ZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gbWFxaXVmYW5nIChBKSAmbHQ7bWFxaXVmYW5nMUBodWF3ZWkuY29tJmd0OzsgbmV0bW9kQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBNdXN0IG9mZmxpbmUtdmFs aWRhdGlvbiBvZiAmbHQ7cnVubmluZyZndDsgYWxvbmUgYmUgdmFsaWQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gRnJpLCBEZWMgMTcsIDIwMjEgYXQgNzoxMSBBTSBLZW50 IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQiPmtlbnQm IzQzO2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPkFuZHksIGV0LiBhbC4sJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5JIGNhbm5vdCBmaW5kIGFueSBSRkMgdGV4dCB0aGF0IHNheXMgJmx0O3J1 bm5pbmcmZ3Q7IGhhcyBvbmx5IG5vZGVzIGNyZWF0ZWQgYnkgYSBjbGllbnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPlJlYWxseT8mbmJzcDsgSW50ZXJlc3RpbmcuICZuYnNwOyBT dGlsbCwgSSBrbm93IGl04oCZcyBhIG1hbnRyYSB3ZeKAmXZlIGhlbGQgY2xvc2VseSBmb3IgbWFu eSB5ZWFyLCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Tm8uIFF1aXRl IHRoZSBvcHBvc2l0ZS4gJm5ic3A7Jmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjcyLjBwdCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVmYW5nIE1hXSBLZW50IGFuZCBKYXNvbiBzYWlkIHRoYXQg dGhlIOKAnHNoYXJlZCBvYmplY3Rz4oCdIGlzIHRoZSBwcmltYXJ5ICZsdDtzeXN0ZW0mZ3Q7IGNv bmZpZ3VyYXRpb24gdXNlIGNhc2VzLiBJIGRvIGFncmVlLiBJbiBIdWF3ZWnigJlzDQogaW1wbGVt ZW50YXRpb24sIFRoZSBzZXJ2ZXIgYWxzbyBnZW5lcmF0ZXMgaHVuZHJlZHMgb2Ygc3lzdGVtIGRh dGEgb2JqZWN0cyhzZXJ2aWNlIHRlbXBsYXRlcywgcHJlZGVmaW5lZCBwb2xpY2llcywgZXRjKS4g UGh5c2ljYWwgcmVzb3VyY2UgcmVsYXRlZCBjb25maWd1cmF0aW9uIGlzIHJlYWxseSBvbmx5IGEg c21hbGwgcGFydCBvZiB0aGF0Lg0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6NzIuMHB0Ij48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QW5kIGFzIHlvdSBtZW50aW9uZWQsIHRoZXJlIGlzIG5vIFJGQyB0 ZXh0IHNheXMgJmx0O3J1bm5pbmcmZ3Q7IGhhdmUgb25seSBub2RlcyBjcmVhdGVkIGJ5IGEgY2xp ZW50LiBBY3R1YWxseSwgaW4gb3VyIGltcGxlbWVudGF0aW9uLA0KIHdlIGRvIGFsbG93IHN5c3Rl bSBjb25maWd1cmF0aW9uIHRvIGJlIHBvcHVsYXRlZCBpbnRvICZsdDtydW5uaW5nJmd0OyBhdXRv bWF0aWNhbGx5IHdoZW4gaXQgaXMgZ2VuZXJhdGVkLCBiZWNhdXNlIGNvcHkvcGFzdGUgZm9yIHJl ZmVyZW5jZSBpcyBwYWluZnVsLiBUaGF0IGlzLCBhbGwgdGhlIHN5c3RlbSBjb25maWd1cmF0aW9u IGlzIHJlYWxseSBhIHBhcnQgb2YgJmx0O3J1bm5pbmcmZ3Q7LiBCdXQgb3VyIGN1c3RvbWVycyBk byBjb21wbGFpbiB0aGF0IHdoZW4gcmV0cmlldmluZw0KICZsdDtydW5uaW5nJmd0OyB0aGV5IHVz dWFsbHkgZmluZCBhIGxhcmdlIG51bWJlciBvZiBjb25maWd1cmF0aW9uIGRhdGEgb2JqZWN0cyBu b3QgZGVmaW5lZCBieSB0aGVtc2VsdmVzLCBtb3N0IG9mIHdoaWNoIGFyZSBpcnJlbGV2YW50IHRv IHRoZWlyIG93biBjb25maWd1cmF0aW9ucyBhbmQgdGhleSBoYXZlIG5vIGlkZWEgd2hlcmUgdGhl eSBhcmUgY29tZSBmcm9tLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjcyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkkgYWxzbyB0cmllZCB0byBicmluZyB0aGlzIGlkZWEgdG8gdGhlIElFVEYo PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tYS1u ZXRjb25mLXdpdGgtc3lzdGVtLTAyI3NlY3Rpb24tMy4xIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LW1hLW5ldGNvbmYtd2l0aC1zeXN0ZW0tMDIjc2VjdGlvbi0z LjE8L2E+KQ0KIGFuZCB3b3VsZCBsaWtlIHRvIGNvbGxlY3Qgc29tZSBtb3JlIGZlZWRiYWNrLCBp dCBzZWVtcyB0aGF0IHRoZSBXRyB0aGlua3Mgd2Ugd2FudCB0aGUgY2xpZW50IHRvIGZ1bGx5IG93 biB0aGUgcnVubmluZyBkYXRhc3RvcmUsIHRoZSBzZXJ2ZXIgc2hvdWxkIG5ldmVyIGF1dG8tcG9w dWxhdGVzICZsdDtydW5uaW5nJmd0OyB1bmxlc3MgYXNrZWQgYnkgdGhlIGNsaWVudHMuPG86cD48 L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t cmlnaHQ6NzIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tcmlnaHQ6NzIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCBS ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLXJpZ2h0OjcyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlFpdWZhbmcgTWE8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5UaGVyZSB3YXMgYSBicm91aGFoYSBiYWNrIHdoZW4gSSBwcm9wb3NlZCB0aGUgJnF1b3Q7a2V5 c3RvcmXigJ0gZHJhZnQgaGF2ZSBhbiDigJxhY3Rpb27igJ0gY2FsbGVkIOKAnGdlbmVyYXRlLXBy aXZhdGUta2V54oCdIHRoYXQgd291bGQgaW5zZXJ0IHRoZSBnZW5lcmF0ZWQga2V5IGludG8gJmx0 O3J1bm5pbmcmZ3Q7LiZuYnNwOyBDbGFpbXMgd2VyZSBtYWRlIGJ5IHByb21pbmVudCBtZW1iZXJz IG9mIHRoaXMNCiBsaXN0IHRoYXQgaXTigJlzIGJhZCBmb3JtIGZvciBhbnl0aGluZyBidXQgYSBj bGllbnQgdG8gZWRpdCAmbHQ7cnVubmluZyZndDsuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BcyBhIHJlc3VsdCwgZXh0ZW5zaXZlIGVm Zm9ydCB3YXMgc3BlbnQgZGVmaW5pbmcgYSBtZWNoYW5pc20gZW5hYmxpbmcgdGhlIGdlbmVyYXRl ZCBrZXkgdG8gYmUgcmV0dXJuZWQgaW4gdGhlIFJQQy1yZXBseSBpbiBhbiBlbmNyeXB0ZWQgZm9y bSAoc3VjaCB0aGF0IG9ubHkgdGhlIHNlcnZlciB0aGF0IGdlbmVyYXRlZCB0aGUga2V5IGNvdWxk IGRlY3J5cHQgaXQpLA0KIGFsbCBzbyB0aGUgY2xpZW50IGNvdWxkIGltbWVkaWF0ZWx5IHJldHVy biBpdCB0byB0aGUgc2VydmVyIHZpYSBhIGNvbmZpZyBwdXNoIGluIG9yZGVyIHRvIHByZXNlcnZl IHRoZSBzYW5jdGl0eSBvZiBjbGllbnQgcmVhZC1iYWNrcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SWYgY3VycmVudCBjbGFpbXMgd2VyZSB0cnVl IHRoZW4sIHdoeSBkaWRu4oCZdCBzb21lb25lIGp1c3Qgc2F5IGl04oCZcyBva2F5IHNpbmNlIHRo ZSBzZXJ2ZXIgaXMgYWN0aW5nIGxpa2UgYSBjbGllbnQgdW5kZXIgdGhlIGhvb2Q/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk1heWJlIG5vdCBhIGxvdCBvZiBub24tc2VjdXJpdHkg cGVvcGxlIHdlcmUgZm9sbG93aW5nIHRoZSB0aHJlYWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5J TU8gYSBiZXR0ZXIgZGVzaWduIHdvdWxkIGhhdmUgYmVlbiB0byBpbnRyb2R1Y2UgYSAmcXVvdDtz ZWN1cmUtTlYtc3RvcmFnZSZxdW90OyBjb25jZXB0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhl IGtleXMgYXJlIG5ldmVyIGV4cG9zZWQuIE9ubHkgbGFiZWxzIGFyZSBleHBvc2VkIGFuZCB0aGUg Y2xpZW50IGNhbiBzdG9yZSBhIHJlZmVyZW5jZSB0byB0aGUga2V5IGluICZsdDtydW5uaW5nJmd0 Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk1heWJlIEp1ZXJnZW4gcHJvcG9zZWQgdGhpcyBpZGVh LiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5ZQU5HLWJhc2VkIG1hbmFnZW1lbnQgYXNzdW1lcyB0aGF0IHRoZSBjb25jZXB0dWFs IEFQSSBmb3IgYSBZQU5HIGRldmljZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Y2FuIGJlIGRlc2Ny aWJlZCBieSBhbGwgdGhlIFttb2R1bGUsIHJldmlzaW9uLCBmZWF0dXJlcywgZGV2aWF0aW9uc10g dHVwbGVzIChZQU5HIGxpYnJhcnkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlcmUgd2FzIGFu IG9yaWdpbmFsIGFzc3VtcHRpb24gdGhhdCAmbHQ7cnVubmluZyZndDsgY291bGQgY29udGFpbiBh bGwgdGhlIGluZm9ybWF0aW9uIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5kZXNjcmliZSB0aGlz ICZxdW90O3JlYWwgQVBJJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5UaGUgb3JpZ2luYWwgZGVzaWduIHdhcyB0b28gc2ltcGxpc3RpYyBz byBOTURBIGludHJvZHVjZWQgJmx0O2ludGVuZGVkJmd0OyBhbmQgJmx0O29wZXJhdGlvbmFsJmd0 OyBkYXRhc3RvcmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Tm93ICZsdDtydW5uaW5nJmd0OyBu byBsb25nZXImbmJzcDtyZXByZXNlbnRzIHRoZSAmcXVvdDtyZWFsIEFQSSZxdW90Oy4gSXQgbm93 IGNvbnRhaW5zIHNvbWUgb3IgYWxsIG9mIHRoZSBpbmZvcm1hdGlvbiByZXF1aXJlZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+dG8gcHJvZHVjZSB0aGUgcmVhbCBBUEksIHdoaWNoIGlzIG5vdyBkZWVt ZWQgdG8gYmUgJmx0O2ludGVuZGVkJmd0Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Tm90IG9uZSBvZiB0aGUgbWVjaGFuaXNtcyB0byB0cmFuc2Zv cm0gJmx0O3J1bm5pbmcmZ3Q7IGludG8gJmx0O2ludGVuZGVkJmd0OyBpcyBzdGFuZGFyZGl6ZWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Ob3cgJmx0O3J1bm5pbmcmZ3Q7Jm5ic3A7JiM0MzsgPz8/ IGlzIGEgY29tYmluYXRpb24gb2YgdGhlIHJlYWwgQVBJIGFuZCB0aGUgJnF1b3Q7cHJvcHJpZXRh cnkgc2V0dXAgQVBJJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5JdCBoYXMgbmV2ZXIgYmVlbiB0cnVlIHRoYXQgJmx0O3J1bm5pbmcmZ3Q7 IGlzIGFsd2F5cyB2YWxpZC4gSW4gaGluZHNpZ2h0LCB0aGF0IE1VU1QgaXMgcmVhbGx5IGEgU0hP VUxELCBwb3N0LU5NREEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JbmFjdGl2ZSBub2RlcyBjYW5u b3QgYmUgY291bnRlZCBhZ2FpbnN0IGNvbnN0cmFpbnRzJm5ic3A7KGUuZy4gbXVzdCwgbWluL21h eC1lbGVtZW50cywgdW5pcXVlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkNvbnN0cmFpbnRzIG9u IGNvbmZpZyB0ZW1wbGF0ZXMgZG8gbm90IGFkZHJlc3MgdGhlIG5lZWRlZCBjb25zdHJhaW50cyBv biB0aGUgZXhwYW5kZWQgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPklNTyBpdCBpcyB0b28gbGF0ZSAmcXVvdDtmaXgmcXVvdDsg Jmx0O3J1bm5pbmcmZ3Q7IGJ5IHBsYWNpbmcgYW55IHJlc3RyaWN0aW9ucyBvbiB0aGUgY29udGVu dHMgb3Igd2hvIGNhbiBlZGl0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Tk1EQSAod2lzZWx5 KSBkaWQgbm90IGRvIGl0LiZuYnNwOyBBICZxdW90O3N5c3RlbSBlZGl0JnF1b3Q7IGlzIGRpZmZp Y3VsdCB0byBkZXNjcmliZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmVzcGVjaWFsbHkgaW4gYSBj b250cm9sbGVyLWRyaXZlbiBib290c3RyYXAgZnJhbWV3b3JrLiZuYnNwOyBUaGUgaW1tdWFibGUg aXNzdWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmlzIGp1c3QgaGlkZGVuIGFjY2VzcyBjb250cm9s LCBzbyB0YWcgZGF0YSBub2RlcyB3aXRoIG5ldyBtZXRhZGF0YSB0byBleHBvc2UgdGhhdC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5LLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QW5keTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5e9fbee4923a4d79b0bebbc2a1553f23huaweicom_-- From nobody Thu Dec 23 00:41: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 EB40A3A145F for ; Thu, 23 Dec 2021 00:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 zKIM3vEa8eKg for ; Thu, 23 Dec 2021 00:40:56 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::71a]) (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 ECE473A145D for ; Thu, 23 Dec 2021 00:40:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZaPVQsCkVj6qFAysBZ5U+n/wTXY63pMov6ZrzTRjCG7BwwizLSIWewZjwcjgYWyARfASw3Rab7y20sAluGklO7wi6N4SYV+5m0OU32Cavmg/jhJY4lEkfLVd2fYZrn90Uo5mTnkhPWgjA/Utx8JgMOO8PwmPeABkHG0X05ppY4VFpiing4jaiPaOOVMvocJzEijnAsyb4EF82bFu3NqWPSHhsMKkhcuP4QpJlmTCYaIc4cv3ysXLJA5sTF3KKC/iSmVjQVwo/6HI1lrjoQBL+kCHxd4keN/wrgMdv3pfMLlHrRbPg1UZk8zxHPkeunqe0M2rEI6kXMJyT+E4xZlbmg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=g5uEJyrbXo9j1Bb4kFk699H93+zbLW67Fgv9Z282Njw=; b=mCBRMZ7yRz4BDvaM2dHyWeQ90Q6b4JeMET9Ilvq+AevSO6L/2NkZ0CTFkN1OZ4X1yHgXvy5/jSGQWTnCur6PAbzY+Bz6kUhkw4nC1xYJdF82VQZQMzWzX8oYCYHSeQD3mkF+eOWu2iZGukxT46Luazcw7kRHUIIHGP9rdAkKr9OgqXfdIbA61WcSDdpGa6RRtFgUGEuEYgbcjYU1lJQ381/wsavLopdIhkAPeFmTMC8bZGxHNu4QGDrSn3ja3iAfDFgpT+3QvWbI4CAT0Yn30M8mkV/hF141UKGpw/MRIu3KNv42bt7U/K/kYmPQ7ClLQEIPihs1cAqu/gmDf/mB1A== 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=g5uEJyrbXo9j1Bb4kFk699H93+zbLW67Fgv9Z282Njw=; b=G/fQ5kJTPL74KOhVmdnJ7ru/ECNEIkNr/FBKr4VKlsLDntqIu6BDB63scFZ9XZXzgXO59aKxKwryKGCWzTWNn0CV4qpRu4PUdAFhlPLhtvuz1B85V+h09u1hW2SKj0knZjspKEaQ87tM+YKpsx67PkA7XT+egYCXnEf405s7XkA= Received: from PA4PR07MB7165.eurprd07.prod.outlook.com (2603:10a6:102:fd::12) by VI1PR0702MB3792.eurprd07.prod.outlook.com (2603:10a6:803:6::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.10; Thu, 23 Dec 2021 08:40:41 +0000 Received: from PA4PR07MB7165.eurprd07.prod.outlook.com ([fe80::2955:ca22:d988:efee]) by PA4PR07MB7165.eurprd07.prod.outlook.com ([fe80::2955:ca22:d988:efee%4]) with mapi id 15.20.4823.014; Thu, 23 Dec 2021 08:40:41 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netmod@ietf.org" Thread-Topic: Question on the path element of the NACM YANG model Thread-Index: Adf31fJlrgw308vJT0Gl7HM4fkECJQ== Date: Thu, 23 Dec 2021 08:40:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 440b2da5-4de4-47a8-85ab-08d9c5efe705 x-ms-traffictypediagnostic: VI1PR0702MB3792:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vqUY95OXUzjso3c2EgvSg7qx1XIS+BruWGZBOpj4CAFOsLfXFlXmbkvkfJsyHanu6xKkqnBsbTEVmbbtKbI2J6j4MKa9PZVrTrrFCNv+a8WokToir5lSuSgszL0fuznch5JAYixA252beD0OR4aXbdGlUXPlred42Eg39LpF8MwwmEw8BCUdVcC44XrRseIEm+zcZaZS5X0QqLMhAmnpOC45rvAKLiKsGyIgDSRFcvilQsMczVYI3ch/uzwlI2ZN04x9vfxrsH/+TWmx69eLkRZncpDfSBWaYQ06KELg70H+5HdeFvTKJ6t9t47oS4PMSDRjehEiqMYfKXF1Kp0s/KjaCZ3FYW+3NgEXkJxEhi+AiH/aIY27L1iEuRYd4GbCptSJ/QKaFqqrMBrOhrem3gtWFpsur+bkNYitwOSXuOTXBVNN8OxTzNNciCOCPHAOaZ9d0fV0djLVK/3JOS+1XCLimThorQ5VGfrmyzs6f/4CsGAek9g/ff14MYy9NpnpdqE1fjrvOBbWcCWysaBXI6QwIXhqmZPPReY3RJtWb5EdYHI25ToL8iW9wMoOWbeZ8xzKyuFIqTNssasdzFqWh8Cr8fmEOZZiWMs6lNSyFz8Nnc46z56INfVdwgxT6fOWCN/8svXTts78lpnhAHQK1/esSSyWOmZooGgbXfcL/IOosQnTV4YHqTpYicTNjDxH1f0hwJ+3QTzOy43EG4p40Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR07MB7165.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(26005)(186003)(508600001)(82960400001)(55016003)(38100700002)(83380400001)(5660300002)(52536014)(122000001)(2906002)(38070700005)(6506007)(86362001)(66946007)(8936002)(66446008)(64756008)(66556008)(66476007)(9686003)(8676002)(6916009)(7696005)(71200400001)(76116006)(316002)(33656002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Y1ymYOPFeYe8fwxbR7lc7oKBbcs8+vENnKf1h2u5MUHel0rRsxHkjRIVktdC?= =?us-ascii?Q?ElwyZEoEh9Hqyks6OltUfSACXaCSRnW1k45HmGMI+j4IwtBf9q8SD8JCkPnK?= =?us-ascii?Q?I4MZ9tdTk3YMNNRcYfX8pFFJyEPHSnahkKkDSb3+MTO1g8RCKS53iwGSUUkU?= =?us-ascii?Q?ip6pgjIPHPbcSiour/4Lcqg9Z8q6Rvj6j6gSKtRY3aosrpJIS9s6sP0TJhhX?= =?us-ascii?Q?2FlrJt9rAwTXnJoTHvg+k3ldPy7aGTj3cwnKgVmWy4je65TnO+ec+4E2Trrf?= =?us-ascii?Q?aqOVmUMe3OhkuH3kMS3jkzAd0omFaxhS9FJhjyxKXdLYQAyP9DsD1uqnSoOl?= =?us-ascii?Q?NWH39iX+DrKiyhFb0EcDO+Qpcs/xPcBpF4IQUyO6j0vZTbjzuka+3vdN0vPn?= =?us-ascii?Q?WSna44+GzGTead8ZFbSqEc+mI/7MW3/mIF936esHyrN4RL0rX9rithD8d1ZT?= =?us-ascii?Q?ev7lyCbG4la5X+IoKYiH2lPmps4JALtPFOaZp0r6rARb+ALZSDuo9H9AeUTw?= =?us-ascii?Q?Vd+6cfXHkOw6QUYO6n1ajKk3V3gz/VEF6MjKrAci0EGRODJoPzKYcaJev5r/?= =?us-ascii?Q?9ZEeV8ndzUjmnuFONuPfdZn6A1JWK/6uUrN+d/Ia4EncvFBOzP9baBlaDj3M?= =?us-ascii?Q?w1ZgKDfKVfp+BK4GGmIJ+5BAOuQWEAVlqGhzbeF2ttGQ3rk4qozXW5YMyhZ/?= =?us-ascii?Q?qHrYbtu8MRfxpKS6Iq36OYEkb3+IUJpfChqBbIut9JlLZr+7q5BCbW6oyChn?= =?us-ascii?Q?AXoFD2Y7ta8jxJJE7hcb+oaC1yj2Nt2Of1Uh8gKpFphxUQK2Ujdk+3rHAEuT?= =?us-ascii?Q?5n1d9LbTXMVwJ2q66sRiQbVOh9MgT9u+hIgvk+9yeQ8SUURp2XFdvoHyfZGp?= =?us-ascii?Q?eJq12oDmqC+pZ1HMBpcyjMudy1GqVGd5ucJWieZDwlooYnGeyJuKXbb/pWqr?= =?us-ascii?Q?ij190llx91vsXU7qPpNvPa78im5OpsIxogkZyR25VgCQHqf09YCxqxu/AK1N?= =?us-ascii?Q?EYvH+LQna6PFqLSjF3uTq7VgIUcbI8LgcBDIN2/+QTTtinp+0Ij3qJ5176EI?= =?us-ascii?Q?kNJ14APW9mO0LQI7aiNx5rBYeYgtjaroNvN/g1iSvoRmNNtz04tPFtnnPWDu?= =?us-ascii?Q?UGV1rUuzz2jSP2/rNXV36fSD+AuD+/ggGv0Vs/l8J2rveWwCBiCgD2Qmsoq5?= =?us-ascii?Q?JPEGcfskru7J0v7JnKUK3Nxb0aVD/ukJIrWw4KIkPqpoJOiQjQ0iHf1XpZ09?= =?us-ascii?Q?B9zq4MaSKaBLQPEKkPX09kaJ8EJMObSR3KuHZZjuJNtHerSepVsyFwJdEh54?= =?us-ascii?Q?coeRAuHesGfuaVsvNeMgdDReFE0NvckaqygqoUZ95+mVn/gmgvLWoizMMEQ9?= =?us-ascii?Q?5malaZi9+g+ONVlHsaSwrUwP2sUNKP5A+OO1Hi3tK1F0lqskq0r8LV7YXWwr?= =?us-ascii?Q?eatJUdA1r/Mt6Atyj0aJxfA5ivfARcvncQ5DBHtu41bongv6egr83zxe0EVz?= =?us-ascii?Q?n57dswEKZiew/oFV3ugf3zj4aFeBHakzbyD5mP48wq/YeYRQAGA9rzQPxkzE?= =?us-ascii?Q?ChlxCgQew8DKloPbV5M43cRw/+c1GH1ibD+flTj3Qa9W2LPmwxtn+C7cRVCZ?= =?us-ascii?Q?Vml5O6mSfDdFYjrxBDEhci0=3D?= Content-Type: multipart/alternative; boundary="_000_PA4PR07MB7165C37220965A94669194B7947E9PA4PR07MB7165eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PA4PR07MB7165.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 440b2da5-4de4-47a8-85ab-08d9c5efe705 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2021 08:40:41.2016 (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: nuT7aGMmQixz/vupYQZPRkvSF/km/T1fFAbotq3IKmMuhURQe+A0O45kBuTNR+X+scpmWinky/juhAMG3b1aAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0702MB3792 Archived-At: Subject: [netmod] Question on the path element of the NACM YANG 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: Thu, 23 Dec 2021 08:41:00 -0000 --_000_PA4PR07MB7165C37220965A94669194B7947E9PA4PR07MB7165eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We are having some debate about the contents of the path element of an NACM= rule when combined with the module-name element. Assume the following rul= e: nome-of-rule some-module /node-a/node-b/node-c read permit When reading the RFC txt, the way I understand this rule is that only /node= -a/node-b/node-c as defined in module 'some-module' will match (so the path= 'adopts' the namespace of module 'some-module'. As such it is not necessa= ry the prefix the path. When having a rule like this: some-other-rule /node-a/node-b/node-c read permit There may be more 'matches' depending on whether there would be more than 1= module defining a path as in the above example (I leave in the middle whet= her this is good modelling or not but it is for the sake of the context of = the question). The RFC text is not specific on whether prefixes are mandatory in the path = content but this is how I understand the text: * If a module-name is part of the rule, the path is within the context = of the module and 'adopts' the namespace of that module * If the module-name is not part of the rule, the complete data store a= pplies and then it depends on whether prefixes have been used in the path c= ontents (or not). * The module-name is not inside the rule-type choice, so the presence o= f module-name in the rule has meaning and brings context to the rule. Is that a correct understanding? Is there a section in the RFC that explic= itly describes what can be expected as behavior when implemented in a serve= r? Best regards, Bart --_000_PA4PR07MB7165C37220965A94669194B7947E9PA4PR07MB7165eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We are having some debate about= the contents of the path element of an NACM rule when combined with the mo= dule-name element.  Assume the following rule:

 

          =   <rule>

          =       <name>nome-of-rule</name>

          =       <module-name>some-module</module-na= me>

          =       <path>/node-a/node-b/node-c</path&g= t;

          =       <access-operations>read</access-ope= rations>

          =       <action>permit</action>

          =   </rule>

 

When reading the RFC txt, the w= ay I understand this rule is that only /node-a/node-b/node-c as defined in = module ‘some-module’ will match (so the path ‘adopts̵= 7; the namespace of module ‘some-module’.  As such it is n= ot necessary the prefix the path.

 

When having a rule like this:

 

          =   <rule>

          =       <name>some-other-rule</name>

          =       <path>/node-a/node-b/node-c </path&= gt;

          =       <access-operations>read</access-ope= rations>

          =       <action>permit</action>

          =   </rule>

 

There may be more ‘matche= s’ depending on whether there would be more than 1 module defining a = path as in the above example (I leave in the middle whether this is good mo= delling or not but it is for the sake of the context of the question).

 

The RFC text is not specific on= whether prefixes are mandatory in the path content but this is how I under= stand the text:

  • If a module-name is part of the rule, the path i= s within the context of the module and ‘adopts’ the namespace o= f that module
  • If the modul= e-name is not part of the rule, the complete data store applies and then it= depends on whether prefixes have been used in the path contents (or not).<= o:p>
  • The module-name is not ins= ide the rule-type choice, so the presence of module-name in the rule has me= aning and brings context to the rule.

 

Is that a correct understanding= ?  Is there a section in the RFC that explicitly describes what can be= expected as behavior when implemented in a server?

 

Best regards,=

Bart

--_000_PA4PR07MB7165C37220965A94669194B7947E9PA4PR07MB7165eurp_-- From nobody Thu Dec 23 02:37: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 595C93A02C1 for ; Thu, 23 Dec 2021 02:37:06 -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=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 JmWhclYdZ45U for ; Thu, 23 Dec 2021 02:37:00 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40041.outbound.protection.outlook.com [40.107.4.41]) (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 BFE303A02BB for ; Thu, 23 Dec 2021 02:36:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PbCsQkOA0vFbsz8J9t46oHUa8x/4BDo2ljGzFsWTsRxWsqt07lPPEWKkrHml9yEIj7goLRiFn6iFaq43W32mZdXhO4Ki5u6lopms16JLiz1J1Ry8F9fp1VpaFFUVnx0OpX+OQZAG0Bd1sdUfblKFqbmMTh+t059x/PXwwgmcBrVbCecvwnYPu2FX5oHmN79/sFgBvoUtnzDSrOuFvmcVHL+q0eaF5sh9e4GpmLux7NpwAvyQPYJRAEuertTROLy+VxteT2HTtBhyKG7VzHRphMM5Kbr78cRHxb0JY+KKA4JLFQ3pq/d2jLrhhcbF0Qzu5fjvjJIGPIiLTJuvW9z8tQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nEjzbw8W1FX6Sf0ncNf5wovTxwjfHRF9rrza2xf+RXs=; b=YImGXkFw2WGqte7zfa/JAx+RLWPEjHXujR3yIBwpDftDLGoAzpIGhiqVpAVWsW7JVt2Zr7+N/ODzkQtiL7d3dYTVEyfITXB82G0fDZskrNV8+/q20xchfMAW6GAWVXg3iYZooCnK2la8JOUYAUjBYE0oasABQqgcKzY9ugZ8spuhC5kB0cRSarU/bZ6yXxYTq1+zl4xaJNHtT0u50+NgeanutxRcx1avgKlO4C0g9VOO5tz/+aCXsG8Sl8faVIN/LIXx2ecLESu5n53nhoBFYAdbv6ifWv9+sehdyR+KFUlp6RGS1RjfC7lHT8lOI+jJKVWnzFSyVsndGsOWBsRAQA== 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=nEjzbw8W1FX6Sf0ncNf5wovTxwjfHRF9rrza2xf+RXs=; b=N8kGwomD1hvhIOqSFOlEXXzKFvSnCqNj5tmsHBXfppOEm7lMPe2qnrOwKrF8YRQXRatDAuO5GK2wsm8b8beSfLDztYAp3iMaJe04IA7OnyUCSZHq/qJM4afAzhKeg2rWlc/YYd0UxuWSa3ViNj3Cvdenm3NZ/taX2EJ7BSOQIac= Authentication-Results: dkim=none (message not signed) header.d=none;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.4823.19; Thu, 23 Dec 2021 10:36:56 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::f12d:e975:556d:30f8%3]) with mapi id 15.20.4823.019; Thu, 23 Dec 2021 10:36:56 +0000 Date: Thu, 23 Dec 2021 11:36:55 +0100 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: "Bogaert, Bart (Nokia - BE/Antwerp)" Cc: "netmod@ietf.org" Message-ID: <20211223103655.ab3ubzdantsurswr@anna> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AM8P251CA0013.EURP251.PROD.OUTLOOK.COM (2603:10a6:20b:21b::18) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 47ebbba9-36e7-4f1d-b6cd-08d9c600248b X-MS-TrafficTypeDiagnostic: AM9P190MB1044:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UxeikAlT8BxRuaUOFP7bAXyreLjpNlqYQ5Evu1DgyLjDoWOyk51xZwPGCUMQhIBzCucTgC2/UV0qgE98QHqDGjNAFrfj58usGvYZ3HP8ZfST7X06xNh7nEvWWVt0IwYR8Ebc3kDxT6R+BUal3gJbS7/Y92GYdjscfqFxLPGlnASWD4u0lR2619Zc9g2tO7Bs9UG2bz2O917B3kA9Tc/9d6JM39RYH3VejLE6Jme+BdLyHwaKIX7c3uH3/slWCG6nuHJwRzeCMj+VNzapOpIuCqBdxKIxGm8RNClZStPsz3GxhlOOnrskpqTBM3RLFWIgZS8LjdDe4ZjYtrSuP2CRsAp8bZHmq4prj/2CEVko2hqu1Cce+jMZ8UktXs431TFENEQVVZw1ltKqD4r55gHdN0H0NZwKV0Tt1Ktk8w4fuHhFJw9rg6b+R7Ya5dkPQPTk3hKdRRSg8gBeG7pWV8VFRQwtDvuPkaQshEs5GmV7awxa7RkozAG/w/oIrDwJVaxnkoPBAEEWDvfeoIPyLAW1RYOQOgRmjO3vl6vWe/kpJXkD5ud7lsQTxXHzuwV5idpTSXCYYv4jWHi1hh9CobKrS29HWjyLaVSKe/D4MpX53D0bEazLDu+6AiMbUGL5jlxOjqsPZMKr4BXQ0tyiIfCabWiuNC1wBRdqUdxJZ11oqcnUFkyPBVOuzwoOdcCqFB6H22IyPLeuPCVKEBmKm8zLeCDHWcz2ZIUe0QjRKYVlW1g4mzFnK8uL9g6Jc/ZFFY3TJdSCoF3DUEVUhQcYAsDVRgfiIyr6WOY5a77z7pQz1rg= 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:(7916004)(366004)(40140700001)(316002)(186003)(38100700002)(786003)(85202003)(296002)(38350700002)(508600001)(1076003)(2906002)(5660300002)(6506007)(4326008)(66946007)(86362001)(6486002)(9686003)(85182001)(52116002)(66556008)(66476007)(8936002)(3450700001)(6916009)(33716001)(8676002)(6512007)(26005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UDB1cVQvUEdaQ3JmZTVGcXJ1c0RaSC9ya0c5Tzk0cDhYSmJXYVo3dEgwTE1Z?= =?utf-8?B?SWFVQVd2U0x5QWVxdEhIejJKaC9vZkQrY0c3MVBNRVVNd1oxbUdFR0c2emd2?= =?utf-8?B?QWRsU1Nzc0RWUDFoYTY1Wm5EaHBmdEtmZk03V3pYUTRhcDlpRm1BeUs5aDhC?= =?utf-8?B?MlpwS25nbE1HSHlMUlg2cHRiOVpnd2FLY3JyMUdTMkxvSE5XeEFVQ21Yc3Zy?= =?utf-8?B?b2ZKWTc5UkZJRW5wZitGUmcxejBlLzBwMi9lZmVLRFBJV1IybHJLUi83UTFN?= =?utf-8?B?M1o5czkxOGlVamZob0NpUXA1NlRpa0VTbGc3Uk9Sc3UxeHNhQWFyOWt2RGJU?= =?utf-8?B?VHRDSjZidHBjdUNDVUNBajludys4bzgzRUlWZW9VSWJDU2lDVG1iU3EyNlZH?= =?utf-8?B?S3RvWk9yNER6TlJnc2xFQ2pubWN4QjNvUDRMZTVqV1dwS2o3UlBjdzladHZV?= =?utf-8?B?bmNtMnNiMkJ0WmJIRDNYU3RESHltbDFTTmo4VnJPZmkvUEZtd1R5YU9sWkg2?= =?utf-8?B?c0ZQSnBSREJFQkRhVWszZVFjM0JqRktqd1lPYk1zcnBHV2NUbnloa2NyeS9Q?= =?utf-8?B?cWlkckllczl1SFV2OWVpZ1VXejVkbStqeVBJZVMzaE8waStMOEVGL3RNcDMr?= =?utf-8?B?M0JjY2tBSWN0ZnVqaStFQWxuM1Y0c29zN1UrVVlEMmFaMklwd3RGNDNWZmF2?= =?utf-8?B?TWRxb3l1Q29GVFlyTEdha3JmZlRuYS8wYld1VnpXVUVhbTVDelYzNnhSYWQ4?= =?utf-8?B?NmJLZzdoUmt6cGFFVVJGR2NsTmlmekZaTnFEV2JuZDZrZTg4b0pBOXk4bTBW?= =?utf-8?B?Mjc1WVEzTnA5QVVQaFhXNTk2Y1pTUVo1dXhSSEZldHBzUnQzWEFiSzB1WWZw?= =?utf-8?B?MEdpWlpwNUxyZ1BqOFM1Q011dXdaSGpmb0RvWmc5R1dnSDQreW5WcEdKYWN5?= =?utf-8?B?cXVYaFM2UjNHZFZkMldGeTZxWm5GekpHVGlTY2R2VFRUcTZKQ05EWkdNdisv?= =?utf-8?B?cENSTTFVelM1UmxDVXRmN3hYYm5vMi9MVllHM0dBUlNUTDRRaW9haUZZUTVP?= =?utf-8?B?TE1qU0ZpVjh0NDB5QmdVWDRuNjJOb3hPYW1WaUNqTXdKNmw5dkF1S2FDUW9w?= =?utf-8?B?RVpNRTdVWGZLSXM1ZnFCejdTQTNONVowZndmakVsK3lLb2FINGo4MWp6VU9p?= =?utf-8?B?VDBGZEphVUt5dWJBbkJ6b0pXSnhMdnVwV0VIdlNQRHdibzNZczRaOGJGMEt3?= =?utf-8?B?d1g5QjRITjd1MnoranoybGhrTGxsek1RbEVWRUZRaXUrZGpJb2Z2T0FhUGx6?= =?utf-8?B?UkZjTTIraFlYNFVyazV3dVNsRmJvS3ZKUHhxTU93U1hVRk1jMjZ1amZmNDVa?= =?utf-8?B?bU5wMXdJTmRpOVZPT0p6OGcyVm8rNzQvTWtCdGZEa28yKy83YXNUTm5wMS9Z?= =?utf-8?B?VVhPZzdPd2VycjBLTXRKV1lNcEpxSDNwQVpPMmlnWno0RWxjSThlV0p5Y0Uz?= =?utf-8?B?d2NSS29FcnV3TzdlalVTOGM4Q2ZCbWQ5d1VSK2c0a2d6WDVDRXNzNHFLY2hl?= =?utf-8?B?a2NVWUY0clFzRHUyM3pRUHJGMTc5dVplNEEvSlVXR3JyRjc4SzBBSEV0NXlv?= =?utf-8?B?M2xmVHcxM3ltQjZDUGJIRlQ5OWZBQmtId04zYkx1NWYwdnFNTElDcXlTVFRP?= =?utf-8?B?bVBUdldocU1nK2pEaGVvc2c2amZqdXlJQmJqQUJhVzExTS9PNDN0RlhtVlBr?= =?utf-8?B?ZXdsK2I4ZnREUDFBdERiaW80Z2wwZ3JvaW5Gc1UyeStmT0dJeE1VZGhKVHpt?= =?utf-8?B?ZW9YV1ZUN1BUTm9qVkgxWDFoQ2FqZ2RGT21ZdlhJTGl6V0ZTM21LckgvTGlB?= =?utf-8?B?NkozZDd1MzdQanZ6dTdqQ1IyR3BzWDhyS0FnMW55emRPQ25YayszakxWeWhL?= =?utf-8?B?WXh0S3psR2JtSGpYV3hjK0F5c2R4dHM4WE0xK2Z1ZWU1a2pobFdpZjUzdDJK?= =?utf-8?B?U3daQXplRDgzdFdLbk56a0dOVzhITGt5bDEwUlhkYVhEeVhES3RPb080b1NE?= =?utf-8?B?bGNBQUZvaElHK0NseWgwTXI1RWY4N0xXWHZDek9Ea0dnOXZ6Qy9oSTRsZGFL?= =?utf-8?B?a2JGR1dlNm9GM0VwZjZocVJxbUZLa1dhZ1F5UUNIRTFPVE5xTEowYnR0eW1H?= =?utf-8?B?Mi9GZDd4QnFYVzVxUERLTnJhYVEzUldqL2V5MGFkL2hPeFEya1NaNkg2M0ZT?= =?utf-8?B?OEt5VmNuYjBDa0xFVGdXMVZadER3PT0=?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 47ebbba9-36e7-4f1d-b6cd-08d9c600248b X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2021 10:36:56.7571 (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: U8f5mk2T5yn5X6QR6aV/vGioPsiJiZeSLJEJjQ7PsKkpyQ0jzw709BbiWuukrZ/14t68ApiMePsXwGjO93Vd/x3gBDO7XT2Obf25YcTT1pE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1044 Archived-At: Subject: Re: [netmod] Question on the path element of the NACM YANG 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: Thu, 23 Dec 2021 10:37:07 -0000 On Thu, Dec 23, 2021 at 08:40:41AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > > The RFC text is not specific on whether prefixes are mandatory in the path content but this is how I understand the text: > > * If a module-name is part of the rule, the path is within the context of the module and 'adopts' the namespace of that module > * If the module-name is not part of the rule, the complete data store applies and then it depends on whether prefixes have been used in the path contents (or not). > * The module-name is not inside the rule-type choice, so the presence of module-name in the rule has meaning and brings context to the rule. > I have not implemented this so I am not sure either but I would assume that the 'data-node' value (of type 'node-instance-identifier') resolves into a set of nodes, regardless of the existence or value of the 'module-name' sibling. If a 'module-name' is set, then this set is further restricted to the set of nodes defined in that module. Note that in my interpretation, instance identifiers with components in multiple modules, e.g., "/a:level0/b:level1/c:level3", will match as long as the prefix 'c' of the node 'level3' is bound to 'c-module' and 'module-name' is 'c-module'. In other words, I would not assume that setting 'module-name' to 'c-module' implies that all nodes in the instance identifier have to belong to 'c-module'. /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 Thu Dec 23 03:57: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 D9BB83A1590 for ; Thu, 23 Dec 2021 03:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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 dzNl8W2gL2i4 for ; Thu, 23 Dec 2021 03:57:08 -0800 (PST) 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 CB5EA3A1591 for ; Thu, 23 Dec 2021 03:57:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TgHt5VR7VUDNT+Qf3lPWoAu1fFJ0cWKXML3xu3NZvtwpVvt8OZrsoFZG8RMnEHhNw5ifK1qkzZJyFPBr6I6XQrWBpaR69JY3vJQs188wWhd3X1NeGrUPEO4jkmJCxZNJZ9k7VmjrnUR2MbPJM7Bd56e13sPw9UCgWMWvchZatqXpdNWWd3t0tuuJpwuDgCJOJ57ZUO/zMP/62UsnLD0dTm10N1CYJXANN0KQ24exVhwwdRIFTlKGGaHr7m1qbvVeZ3ZXwDlJEbqW8ydLywmecfeUw/T6gMyTufpu43L2qQHZa8ZkqcSKEAnxYc80xKM3FL1Ld1jL37cg4ekueOWHxg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Zb1vKuRNsGMKLXsrC/ZJAKrjqZsZfj2wajwam2Eb+5s=; b=l4PgmMedaNTpHqthqgTu0oKPG1grmkqj3zWEe8nUdQbdAPJizf1R6KQjsOgLqbqZgF1LiGnwnpJ3eaFOtnc+UZOglYjp2sPBGDalYcv0I/zcC6qni9x562e9g3EvbPbXIUtDU533UIRy2Pz9FDRNlITWpvzbSnkmlzztMF0CB+z8Vb3qaJ6+BUxVSJnSDfNLWPx81S3Hcwo+iPItL3QL8b1gkVhUYiSyhe8aEjjD4ywvQ69KF3GkCrH8Cej3JK5AMVaT0bpNVYgWj9Hjx+E849xCvtFLFWDG/TbaYk1LX8mcVmqojYjNloIXzcWYlhJ9g8C3ZoIGdcrp6uDLWfNnfw== 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=Zb1vKuRNsGMKLXsrC/ZJAKrjqZsZfj2wajwam2Eb+5s=; b=xtVLfeZN/Ijr2aVFF2Y6GJgF7FJo6+9Jvrc2QvJnlGB6zTh8fB8Ulf008WaxGJyULs/YwyC6u6NKjbEIz0nqUVG9npW4t82c7k8oQfUq4DoO8VNd9VPeH3T1F3m7hHpHva0NkgqOy+CQxf7raxO/6X7fpVdjrk2DeJ+fWmsX5MU= Received: from PA4PR07MB7165.eurprd07.prod.outlook.com (2603:10a6:102:fd::12) by AM5PR0701MB2723.eurprd07.prod.outlook.com (2603:10a6:203:73::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.18; Thu, 23 Dec 2021 11:57:02 +0000 Received: from PA4PR07MB7165.eurprd07.prod.outlook.com ([fe80::2955:ca22:d988:efee]) by PA4PR07MB7165.eurprd07.prod.outlook.com ([fe80::2955:ca22:d988:efee%4]) with mapi id 15.20.4823.014; Thu, 23 Dec 2021 11:57:02 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] Question on the path element of the NACM YANG model Thread-Index: Adf31fJlrgw308vJT0Gl7HM4fkECJQAEw7KAAAKcJ5A= Date: Thu, 23 Dec 2021 11:57:02 +0000 Message-ID: References: <20211223103655.ab3ubzdantsurswr@anna> In-Reply-To: <20211223103655.ab3ubzdantsurswr@anna> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 592e3736-8fe0-40c9-9f4a-08d9c60b5537 x-ms-traffictypediagnostic: AM5PR0701MB2723:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BG2cvSKbDrAT6vee6cnjFIUoZnePXe6Or6HuTaau/hmvCE73pK/71CgT44uAPQZyHdDwfJkIPsoq+1KXBTQfoBZWwlKkRnAvRG0RqN8wNVkRuIbbOEJUGfhx5A1wIW5L67T2tDrLxwwb2sSDFmdvCD6e5ZcKt4aH1KlFIWbsz/0TV3MVRbt8vFuRdaWLGfk5YDfXnFf7EU6ZMscYGa0GuUIsqwa3jawsnIK0c+SIlyAB0xdWaz8toF5M3+dYoGc6wUfSGz9MnJngs5hpUA8IAlorNpt85iN/LqRGLxhpI5eIbgWA/t8F8ePrjhqe+rp3hotSiUUqCHOKgs3IB7t8/gjXkD+DFq9rVjbHybTYm5D2/pXGwQia5640S973moaUQsw6fhkAas/qsBEks0f+MZtym/usNIeN9pxlEI9yCK9cpUqomUeoTDGXcKlB+vpVsPPoAM2b7Ra50bWBBt4B6r8iEKntVrWloNjvOtRaQDSAt2E3FapCybtyzUCOMnU3HoaDxzw837JJkz4RI4K5BzxNIDezyaPtbkREAW/g4vbigEmDmBmii4hz2oFE1Dkq/yPvkwgRePcwQ2Z8ORbdzgSbriKVV60+J1dhjcEhYzgvbaI/LdhCBBC4huXihOb1unS8oWS6z9k0oO16bAqkLgwkUszjNpYZ5rDRvzUGaCFygHGoI6SHp4M+XbiWiFuUlpvN/sIeFu4su6uPPJd7JSsL/ftjMbJ4J729qgrNfGLWIl7yFbAIVdgb2Z5crjHaaTjbwijJalBa4rL4sGnVmomTyYHLq3Nhk94fICCj6cQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR07MB7165.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(2906002)(86362001)(7696005)(26005)(9686003)(53546011)(8676002)(6506007)(66946007)(66476007)(316002)(52536014)(40140700001)(64756008)(33656002)(71200400001)(8936002)(508600001)(66446008)(6916009)(66556008)(76116006)(55016003)(4326008)(38100700002)(122000001)(38070700005)(186003)(82960400001)(83380400001)(66574015)(5660300002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SG1PNHptbkpyblA5M1JPS1ZEeHJwYk83bEtQSGFpM3hQRWtYdXhHdUI1cUwy?= =?utf-8?B?cGFBVmczZWRudlZpNFBEYWtja2xtTzF4SEF4SEE1OFNQbG9Na0wvbXFCSi9p?= =?utf-8?B?b2NMd1NaaTM5WnpIUHVGMlN6UWU4MWFJdHpadTd3a2pHRWc2ZHNTUDNmTmti?= =?utf-8?B?Z3hRYmlWSy9MQUZWanE5eTlzQUFoYUlHVm8vZmw1LytyTFc0L3MwUGw3bHVi?= =?utf-8?B?Y050ZlZWTDYwd3lOQjhEaHVXY3JyaFMzOWp4V3RJTXkrWkxtQ04wellSYnNy?= =?utf-8?B?YXVCMkw3alJXV0lIbkJ6a1hJczliaEQrR0xxR0JCOFNzQVRDa0VQS2g4NXJP?= =?utf-8?B?d2cvcWZWODJJd016bkZKVGZ6cCtrSnNUdGg5YUN2eHJkTDJVUERmRkdTb0Fx?= =?utf-8?B?N2VIN2IyWnhzQ3pvT3NqSDQyQS9nR1dTanJwbGJvN0RhZVNBazh2WUVLbzZz?= =?utf-8?B?QUtBSG9PRFQxRWFMV3VIOTRCMXNVU2hCQlA0V3I2ODlkY3EzRFJUM0FNSTFk?= =?utf-8?B?Y1lyRFJDZnY4aDNtVVRBN245Mkc4azdiRHBadGcwZ0RZb2kzM3FQTTlFL3dL?= =?utf-8?B?U1RpNHhwTmo4eG1HYm1rTCtEbG5WaWpDQnFnazNHeGF0R3hDaWpGNVNFaDF3?= =?utf-8?B?QjNxd2x6Q0lObGVnd09JcnBzM2UxU0pvSE00bWVXcVdOK1pKU2dFakFscTl2?= =?utf-8?B?eUtzMG9sYk5UYTZQdmVVSC82bU51VWd0M1BtMEozS3lnZ0MxK2NGQTlRZEV1?= =?utf-8?B?NWgvZGc0aXRZWDhPVkJyS3RrMmhxMmxUZXBzb0lNZFk5czRpTjFsSDZhV3hQ?= =?utf-8?B?eUlobUk4dWd3dmtKL2svN0QremlqdXNOSzEwcXNRS0N2cXRKRGNHeWJwQjlE?= =?utf-8?B?ZFd1N0djR0NiQ2QxWmxEV3hKbGlObDJoQTdzSmw5aUtUamgxTEtuZUZuTndO?= =?utf-8?B?WTFRT3RNVS9jL3kxcnB6NFJjZVQzUy9sWnpROFJ0UUUzQ0t5NnA1WklMcVdu?= =?utf-8?B?RGpTNEs2RzNHazgwVW5FbXVMaHZFS0MyVkc0NVMwZXl0aHlxNmM1TkxBdHpI?= =?utf-8?B?SWN4OXI3RSs2bXdiQ1ZPeEFIYVpsc2JvZk5TTjR3Ui8vTEYxMWc3M0g3SWZY?= =?utf-8?B?K1d5WkZRd1F3K2NseHR4TzhiczM5OGxOTFVSM1MwYnoyQlJpWk1Mdkh3Ty9u?= =?utf-8?B?ckxPWk9QRUd0QzBmY2FLdmNSOFR3cVRscDFwc0YvdVRkeTM5MmJiOGlaZDNK?= =?utf-8?B?SW1HUFBuSitRRGcvZi9jMkJ3OFAxUkdxV2xYejdJbGpHRzYzc3pReXRjZk1T?= =?utf-8?B?K1lMUFdaWDNvRzFVelE2M1dTK014RGhaQ2Flalh2QzRaVytDK1pKUEprZDhL?= =?utf-8?B?WjRpRUZpS1FHMmxFQTZlTmhkMVF3VEJJSkNNVGFGdERnNFB6RDMvcElNNlhH?= =?utf-8?B?cVFOUWNLVHhXS2VWWDJFZWVsV2U4VmhtYlJVcVNXMGFNOHIvYlNjUExUOCth?= =?utf-8?B?SHJxeUtqWkZFT1BSd3VZcFFVczRTdUJRTnBaeTNmL3ROOEJiVk4zTHcwODlh?= =?utf-8?B?NnZWYkRSUURNaHJKU0I4UUNGZ3NMeDBRSzk2VGFuM2QwVnNTWVNjdm51cTRk?= =?utf-8?B?QUExNUdzaDViRkpTc0dPS055MU5yc1NmdzY1MXpnTDhYclAwVEl5eFRXS3Ny?= =?utf-8?B?RGlRM2s3a3dGZmh5STlhaDgwVTJpamlkL1JRMTVHN0hLUm96QWpkWVNuVTNO?= =?utf-8?B?dVVGamRUZWFmOU5KRGVJeXRMMDVKL0Q4Nk5ackVrNWhIeUFtVTdPTHZabkNV?= =?utf-8?B?d3ZCekFsMWV6d3hVNTZhTWlLb2l3VXZXNkVDNS9SNmJncGpwZ2piSk1TS0ZX?= =?utf-8?B?ZkZZVTd5ckNDT0Z4cDN3SjIxZXJ6SXduckk4Rkd5dEpwWVl3ZXNqeS9sck03?= =?utf-8?B?WDdwT2Q3cmxlL3Q0d1NsTTgxaUFuYVIzQi9SU2h5Tml0WFZXbm9sQ0gxSEFY?= =?utf-8?B?Nk1qaXVyVXNRS01VbnU2SzJsMktwYXFobERpS0F1aEFueHBmaFA5aEZsODBF?= =?utf-8?B?Y204RmRBTUZFcTZrTi84TDJoY0FRL3d4VlRGeE5JcTlYb3VvWFVidmZwQUht?= =?utf-8?B?clVZZzBJSmhVSnNNZFdSWTFmL1FJcTRGcE45a296UWlqNytzK0FUcGVNNDQ3?= =?utf-8?Q?PMgmbuE9eUD3wdFx3xHeoYw=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PA4PR07MB7165.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 592e3736-8fe0-40c9-9f4a-08d9c60b5537 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2021 11:57:02.5149 (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: RTMFP2cGsgOxWRzXcdPwm2w75FYhlECE73YP/TuUyx69AdJyaeUlYj7dR/2h4Mz1Dj5H3IgOoPgS8A7omJ4pig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2723 Archived-At: Subject: Re: [netmod] Question on the path element of the NACM YANG 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: Thu, 23 Dec 2021 11:57:13 -0000 SGkgSnVlcmdlbiwNCg0KVGhhbmtzIGZvciB5b3VyIGludGVycHJldGF0aW9uLg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKw7xyZ2VuIFNjaMO2bnfDpGxkZXIgPGouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gDQo+IFNlbnQ6IFRodXJzZGF5LCBEZWNl bWJlciAyMywgMjAyMSAxMTozNyBBTQ0KPiBUbzogQm9nYWVydCwgQmFydCAoTm9raWEgLSBCRS9B bnR3ZXJwKSA8YmFydC5ib2dhZXJ0QG5va2lhLmNvbT4NCj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gUXVlc3Rpb24gb24gdGhlIHBhdGggZWxlbWVudCBvZiB0 aGUgTkFDTSBZQU5HIG1vZGVsDQo+DQo+IE9uIFRodSwgRGVjIDIzLCAyMDIxIGF0IDA4OjQwOjQx QU0gKzAwMDAsIEJvZ2FlcnQsIEJhcnQgKE5va2lhIC0gQkUvQW50d2VycCkgd3JvdGU6DQo+ID4g DQo+ID4gVGhlIFJGQyB0ZXh0IGlzIG5vdCBzcGVjaWZpYyBvbiB3aGV0aGVyIHByZWZpeGVzIGFy ZSBtYW5kYXRvcnkgaW4gdGhlIHBhdGggY29udGVudCBidXQgdGhpcyBpcyBob3cgSSB1bmRlcnN0 YW5kIHRoZSB0ZXh0Og0KPiA+IA0KPiA+ICAgKiAgIElmIGEgbW9kdWxlLW5hbWUgaXMgcGFydCBv ZiB0aGUgcnVsZSwgdGhlIHBhdGggaXMgd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBtb2R1bGUg YW5kICdhZG9wdHMnIHRoZSBuYW1lc3BhY2Ugb2YgdGhhdCBtb2R1bGUNCj4gPiAgICogICBJZiB0 aGUgbW9kdWxlLW5hbWUgaXMgbm90IHBhcnQgb2YgdGhlIHJ1bGUsIHRoZSBjb21wbGV0ZSBkYXRh IHN0b3JlIGFwcGxpZXMgYW5kIHRoZW4gaXQgZGVwZW5kcyBvbiB3aGV0aGVyIHByZWZpeGVzIGhh dmUgYmVlbiB1c2VkIGluIHRoZSBwYXRoIGNvbnRlbnRzIChvciBub3QpLg0KPiA+ICAgKiAgIFRo ZSBtb2R1bGUtbmFtZSBpcyBub3QgaW5zaWRlIHRoZSBydWxlLXR5cGUgY2hvaWNlLCBzbyB0aGUg cHJlc2VuY2Ugb2YgbW9kdWxlLW5hbWUgaW4gdGhlIHJ1bGUgaGFzIG1lYW5pbmcgYW5kIGJyaW5n cyBjb250ZXh0IHRvIHRoZSBydWxlLg0KPiA+DQo+DQo+IEkgaGF2ZSBub3QgaW1wbGVtZW50ZWQg dGhpcyBzbyBJIGFtIG5vdCBzdXJlIGVpdGhlciBidXQgSSB3b3VsZCBhc3N1bWUgdGhhdCB0aGUg J2RhdGEtbm9kZScgdmFsdWUgKG9mIHR5cGUgJ25vZGUtaW5zdGFuY2UtaWRlbnRpZmllcicpIHJl c29sdmVzIGludG8gYSBzZXQgb2Ygbm9kZXMsIHJlZ2FyZGxlc3Mgb2YgdGhlIGV4aXN0ZW5jZSBv ciB2YWx1ZSBvZiB0aGUgJ21vZHVsZS1uYW1lJw0KID4gc2libGluZy4gSWYgYSAnbW9kdWxlLW5h bWUnIGlzIHNldCwgdGhlbiB0aGlzIHNldCBpcyBmdXJ0aGVyIHJlc3RyaWN0ZWQgdG8gdGhlIHNl dCBvZiBub2RlcyBkZWZpbmVkIGluIHRoYXQgbW9kdWxlLg0KPg0KPiAgTm90ZSB0aGF0IGluIG15 IGludGVycHJldGF0aW9uLCBpbnN0YW5jZSBpZGVudGlmaWVycyB3aXRoIGNvbXBvbmVudHMgaW4g bXVsdGlwbGUgbW9kdWxlcywgZS5nLiwgIi9hOmxldmVsMC9iOmxldmVsMS9jOmxldmVsMyIsIHdp bGwgbWF0Y2ggYXMgbG9uZyBhcyB0aGUgcHJlZml4ICdjJyBvZiB0aGUgbm9kZSAnbGV2ZWwzJyBp cyBib3VuZCB0byAnYy1tb2R1bGUnDQo+IGFuZCAnbW9kdWxlLW5hbWUnIGlzICdjLW1vZHVsZScu IEluIG90aGVyIHdvcmRzLCBJIHdvdWxkIG5vdCBhc3N1bWUgdGhhdCBzZXR0aW5nICdtb2R1bGUt bmFtZScgdG8gJ2MtbW9kdWxlJyBpbXBsaWVzIHRoYXQgYWxsIG5vZGVzIGluIHRoZSBpbnN0YW5j ZSBpZGVudGlmaWVyIGhhdmUgdG8gYmVsb25nIHRvICdjLW1vZHVsZScuDQoNCkkgYWxzbyBkaWQg bm90IG1ha2UgdGhhdCBhc3N1bXB0aW9uIGJ1dCBJJ20gbm90IHN1cmUgLSB3aGVuIHNwZWNpZnlp bmcgYSBtb2R1bGUtbmFtZSBJbiB0aGUgcnVsZSAtIHRvIHJlZmVyIHRvIG90aGVyIG5vZGVzIGhh dmluZyBub3RoaW5nIHRvIGRvIHdpdGggdGhhdCBtb2R1bGUuICBNYXliZSB0aGVyZSBpcyBhIHVz ZSBjYXNlLCBob3dldmVyIG5vdCBzdXJlIHdoaWNoIG9uZSAoSSB3b3VsZCBvbWl0IHRoZSBtb2R1 bGUtbmFtZSBpbiBzdWNoIGNhc2VzKS4gIA0KVG8gbWUgaXQgYWxzbyBkb2VzIG5vdCBzZWVtIHRv IGJlIG1hbmRhdG9yeSB0byBwcmVmaXggdGhlIG5vZGVzIChzbyBiaW5kaW5nIGl0IHRvIGEgbmFt ZXNwYWNlKS4gIElmIGl0IGlzIHByZWZpeGVkLCB0aGVuIHRoZSBtYXRjaCB3aWxsIGJlIHJlc3Ry aWN0ZWQgdG8gdGhhdCBuYW1lc3BhY2Ugb25seSwgaW4gY2FzZSB0aGVyZSBpcyBubyBwcmVmaXgg eW91IG1heSBnZXQgbXVsdGlwbGUgbWF0Y2hlZCBmcm9tIGRpZmZlcmVudCBuYW1lc3BhY2VzIChp ZiB0aGVyZSBoYXBwZW5zIHRvIGJlIGFuIG92ZXJsYXBwaW5nIHhwYXRoLiANCg0KQmVzdCByZWdh cmRzLA0KQmFydA0KPiAvanMNCj4NCj4gLS0gDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAg ICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiArNDkgNDIxIDIw MCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4g RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZl cnNpdHkuZGUvPg0K From nobody Thu Dec 23 05:29: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 516413A0934 for ; Thu, 23 Dec 2021 05:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 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, NICE_REPLY_A=-1.852, 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=mg-soft.si 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 RyLRfuVnMcbY for ; Thu, 23 Dec 2021 05:28:58 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id CF7A23A09C1 for ; Thu, 23 Dec 2021 05:28:56 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 8CC5CC3DC57C; Thu, 23 Dec 2021 14:28:54 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 galileo.mg-soft.si 8CC5CC3DC57C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1640266134; bh=/rOOCq1w+ZK9KPvYFGbPsuswElUzNk+XJ746MzEQ6ws=; h=Date:Subject:To:References:From:In-Reply-To:From; b=FjvFNSxN1M/oyGDVyB0NFXwYnn6YDL60FqPueB/+etDfQBo4YtBQtBKWwFw6pGgdH yvWNXRRotjiEDjjo/JV7Hu2gtbzZpt8xktYxL4lvjeI8xu+humX4iJtRS9qk0oYcpP o3mUfptq0oWfzXukaLkbPRjr861VX+iHG6GAepaT5En57I0hdMQobtyeGe8mJ0S/mS OXLtq2sZ93RExdLjO60pb9NPmHC11uDMJSrDkdr4nSYp04kfWbBMT3EVHqJjiSRXRX OaRzhXUW3cEaTyTwogM3Z8Lfg7T1Qml/FiYCANInMpRcorapngCdrn3X/E7J5B7bE0 5zItCkKueb5nQ== Content-Type: multipart/alternative; boundary="------------kWVY0WZvaBPzaIR8LDo76xsE" Message-ID: <02a4aa5b-e817-c19b-bdd1-b5985a0d8091@mg-soft.si> Date: Thu, 23 Dec 2021 14:28:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: From: Jernej Tuljak In-Reply-To: Archived-At: Subject: Re: [netmod] Question on the path element of the NACM YANG 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: Thu, 23 Dec 2021 13:29:03 -0000 This is a multi-part message in MIME format. --------------kWVY0WZvaBPzaIR8LDo76xsE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 23/12/2021 09:40, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > > Hi, > > We are having some debate about the contents of the path element of an > NACM rule when combined with the module-name element.  Assume the > following rule: > >             > > nome-of-rule > > some-module > > /node-a/node-b/node-c > > read > > permit > >             > > When reading the RFC txt, the way I understand this rule is that only > /node-a/node-b/node-c as defined in module ‘some-module’ will match > (so the path ‘adopts’ the namespace of module ‘some-module’.  As such > it is not necessary the prefix the path. > > When having a rule like this: > >             > > some-other-rule > > /node-a/node-b/node-c > > read > > permit > >             > > There may be more ‘matches’ depending on whether there would be more > than 1 module defining a path as in the above example (I leave in the > middle whether this is good modelling or not but it is for the sake of > the context of the question). > > The RFC text is not specific on whether prefixes are mandatory in the > path content but this is how I understand the text: > > * If a module-name is part of the rule, the path is within the > context of the module and ‘adopts’ the namespace of that module > * If the module-name is not part of the rule, the complete data > store applies and then it depends on whether prefixes have been > used in the path contents (or not). > * The module-name is not inside the rule-type choice, so the > presence of module-name in the rule has meaning and brings context > to the rule. > > Is that a correct understanding?  Is there a section in the RFC that > explicitly describes what can be expected as behavior when implemented > in a server? > If this is for RFC8341, from the "description" of node-instance-identifier "typedef", which "leaf" path is a type of:           A node-instance-identifier value is an           unrestricted YANG instance-identifier expression.           All the same rules as an instance-identifier apply,           except that predicates for keys are optional. And YANG instance-identifier lexical representation rules say this:    An instance-identifier value is lexically represented as a string.    All node names in an instance-identifier value MUST be qualified with    explicit namespace prefixes, and these prefixes MUST be declared in    the XML namespace scope in the instance-identifier's XML element. Jernej > Best regards, > > Bart > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------kWVY0WZvaBPzaIR8LDo76xsE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 23/12/2021 09:40, Bogaert, Bart (Nokia - BE/Antwerp) wrote:

Hi,

 

We are having some debate about the contents of the path element of an NACM rule when combined with the module-name element.  Assume the following rule:

 

            <rule>

                <name>nome-of-rule</name>

                <module-name>some-module</module-name>

                <path>/node-a/node-b/node-c</path>

                <access-operations>read</access-operations>

                <action>permit</action>

            </rule>

 

When reading the RFC txt, the way I understand this rule is that only /node-a/node-b/node-c as defined in module ‘some-module’ will match (so the path ‘adopts’ the namespace of module ‘some-module’.  As such it is not necessary the prefix the path.

 

When having a rule like this:

 

            <rule>

                <name>some-other-rule</name>

                <path>/node-a/node-b/node-c </path>

                <access-operations>read</access-operations>

                <action>permit</action>

            </rule>

 

There may be more ‘matches’ depending on whether there would be more than 1 module defining a path as in the above example (I leave in the middle whether this is good modelling or not but it is for the sake of the context of the question).

 

The RFC text is not specific on whether prefixes are mandatory in the path content but this is how I understand the text:

  • If a module-name is part of the rule, the path is within the context of the module and ‘adopts’ the namespace of that module
  • If the module-name is not part of the rule, the complete data store applies and then it depends on whether prefixes have been used in the path contents (or not).
  • The module-name is not inside the rule-type choice, so the presence of module-name in the rule has meaning and brings context to the rule.

 

Is that a correct understanding?  Is there a section in the RFC that explicitly describes what can be expected as behavior when implemented in a server?


If this is for RFC8341, from the "description" of node-instance-identifier "typedef", which "leaf" path is a type of:

          A node-instance-identifier value is an
          unrestricted YANG instance-identifier expression.
          All the same rules as an instance-identifier apply,
          except that predicates for keys are optional.

And YANG instance-identifier lexical representation rules say this:

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes, and these prefixes MUST be declared in
   the XML namespace scope in the instance-identifier's XML element.

Jernej

 

Best regards,

Bart


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

--------------kWVY0WZvaBPzaIR8LDo76xsE-- From nobody Thu Dec 30 04:29: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 203073A1318 for ; Thu, 30 Dec 2021 04:29:47 -0800 (PST) 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, 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=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 hG3YdyDg_PVK for ; Thu, 30 Dec 2021 04:29:42 -0800 (PST) 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 3A8933A1320 for ; Thu, 30 Dec 2021 04:29:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nARwT8P6ZEssDfSG1i3mIk/fADwtk4Zid3oAcnEgkszdKrVCx6w6A8Ls+3nhtU7lDt8P+ytFHa3l+YSF7AA25VwVLndE/Bzg8q14dnzzNTurZcgb0a4UgH5Q9uqX0E5y1QDT4//De7CWh1BiR40Znm1Pndms7Z+MsSrTfFujqB5cXfQCnRKlcJO+pznBAAnkJ8/+fFKz7AGiuX44Ic0/8A3mwQyiV97o/TA/SG4zeMyorJxdJg2IG6wV+RAgOnM+SmIlIBZUhJonlrfw1WEeXa8OxHQiOhraCQ4wi/0nFqI2YtJuyMdCFBZyCDc1zC0CPTpj64RtA37A+wEt/cH2TQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Vfwwi7ExcXTJt/hyYlVFOB9/l93k2a/JB9NZk9Zl9rI=; b=jy8sqMyKYA2Xg9n54p+AsZzZMmgzxdqf4In0Zxg2VU69aw4TWAm0zMBeCsjaJROU49tZzWHOMVvERHiri+Gvm/LUSyGrvzqQOga8obcoYS0B7r5QrcyqqBKF7MDlDo8F2ypd1As1BPG28VMTiCGY9i4gGuFPbrnq47q6ugJjFbXy8ucZ2byAW5CnuVosDEWtjA13O5P0EK9jsDdJF7YQmXGxXM5a72X+iletpkblfhb2d+VQpbZZT/tc0NS57DY4ClyYRtwuJAY27awv260MRzLDBlBH7GT3zFDPteN0TFGaXrbCuVgb9CQkGWb2qya/KWZZ51xxvTfk4dWgU/ewSw== 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=Vfwwi7ExcXTJt/hyYlVFOB9/l93k2a/JB9NZk9Zl9rI=; b=X4bBMv5MdUAgoDI7/Vgn6UAFzPGrr0C8+g76pYCPukmxehBuZ4EODeAvq5HykzobmZDiF8F4iAVXFhF5Y+iVaprAv1S8UZXTFETkphYFED5AvH2x57nM1UXYnGuZqzzyxxMPltd+p5LbYTMQHayuGsBEbzNidRApLuPd9v2JOsw= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by VI1PR07MB5773.eurprd07.prod.outlook.com (2603:10a6:803:ce::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.14; Thu, 30 Dec 2021 12:29:38 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::719a:2b70:b9fd:d912]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::719a:2b70:b9fd:d912%6]) with mapi id 15.20.4844.014; Thu, 30 Dec 2021 12:29:38 +0000 From: tom petch To: "netmod@ietf.org" Thread-Topic: YANG 'when' with absolute path Thread-Index: AQHX/XaoYX/gsG8fJkOvON2F5wSGIg== Date: Thu, 30 Dec 2021 12:29:38 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: e40f5288-4725-c52f-5fef-ee4d8165c2b4 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d227cc54-0f8e-47e7-d30d-08d9cb900bc6 x-ms-traffictypediagnostic: VI1PR07MB5773:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qjFyq/GuckFru3SAzVr7H/QPKuHfGTkSPgDPIFdwaYtjh51VCir856SjwaDAVY7gRBRBkKr3zPfJve4Emu/DoA4GSifh7mLf/CTB8ffSu3eYbkOar5tR8tViH+ySdP4YvUy/Oe2rTi4pLbSkfsnojGK0nk+Ua41r5saFs79FVvO+0D7hUp+xdLfcGItJYr3QnbKAucCAkUpvF5/bSmoXh1BRyaBbtwTmwCkX1ZnT/gK4Behy3aev6mS+lRaLjYq1cWQ5ZjqYJbhJ1hkGCKiMhUwOz56LjuYROk4AOGzcu3+6HTsN71O4wkvsuCToXehRyj7DIRpeS2sOAcs66vWj89DxGcbopV1BHZfCrx+uDyjBEs2xiiQIrbOmsiDhjbT6E4DaJlrZC5l+RkmYOaAcgfKLobvhWtRpkurxBX79rOhmlz8+74cyC9rSi/9mVvjKeknmt2ePUDStayuHXrmMNugVF6Bg+WSI8a/vabDqcqdz6D1hcjRfveXc7DsjgfkfEG3Np92Mz7BR8vEbwIeptQr+l1YCsqPFmnC+TkDoyZc3Cuws4+NKKuRgARcbFQoJatSMBfToXyNi3XG2KK4XM4fuCVS6tq2iYWagQwNkDOvA1x3wYlhR8xXS9axKtchlPzmR48s9vyx8rfkrl8GIc03RamlrlRQsf3F7uQ0onXeeyBI/FYmUWSGNkwKPS9bxrVFg5wqG0eDladjrVxHIKQ== 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:(13230001)(4636009)(366004)(55016003)(66446008)(66476007)(64756008)(76116006)(316002)(66556008)(33656002)(7696005)(52536014)(508600001)(38070700005)(86362001)(71200400001)(6916009)(6506007)(122000001)(38100700002)(2906002)(66946007)(5660300002)(186003)(8676002)(8936002)(26005)(9686003)(82960400001)(91956017)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?HHkIa09/qiep3+CtDAKxHIjlgtzNJinepFt6mMjXeuW4S9Mt5/f6ezOW5d?= =?iso-8859-1?Q?TVR22yDOWZE39/s+A2pksWhImtyloyYN+nHOnBvDrOz1CaYMyXoWcduW8R?= =?iso-8859-1?Q?ToEHYoPRY3rp7Z1MTKzjWcDXvgW7UKjX2HbL3ADabWOlN1OMoHz98Weie0?= =?iso-8859-1?Q?JwOU88H0Quk7OgqyskT3b9MNbVnkQi7SbJ42o6rz4jKzq/4XYJKeLp1gUY?= =?iso-8859-1?Q?8WS4zW5b6+IF7rSGTZja9RZbbF3NwbBMAy/Gn1dxC5qD2FNaQT7f5M+9Qm?= =?iso-8859-1?Q?C5+vWee6EFLE3C4SUJ0TApN4NPWhrXL7Gs9et6LZCMzAOr750YCCk41kla?= =?iso-8859-1?Q?O+Lkfd8IHhuF10eAitlMtu7Ev0jDjjNq86I2UFPvdlfNOHvHXW/JJqNqCz?= =?iso-8859-1?Q?O3CMncJCHie6TTa0iC+MrverSao71DnYicyDP81/pw59xew7fVDhtiyu5a?= =?iso-8859-1?Q?1qAFH5TH9xQkFiDWlLwwYarn8heAZOLDlgNpnhvH70H3BWuQij06IQw0d5?= =?iso-8859-1?Q?jb1RLkV8kidgw7lavzwj2lpW5e2jVV+1anIxKnYKftrolwo5RHYkxItnyp?= =?iso-8859-1?Q?8w5dFrDcyBF3a50hNQYfGYxpmj4jfbic43Kl2SeqvlhNSgIHww4CtDx2bV?= =?iso-8859-1?Q?HfUUVnzjkLLIdYeyfFehBG5RWqyirdkB7A32bSl+EzemP5cAkTMFx2wNtV?= =?iso-8859-1?Q?rRhQqajD+NxNqo2ugy8YGR9rKryX7lRF9FLk6SUkcZqjagHm5/J2/yYV/B?= =?iso-8859-1?Q?bNWsm+qUP50OKK/QAjJTN7csjv+vgeqQ1uOdu6JkBgYcAbamDxdS9dquS9?= =?iso-8859-1?Q?HU/MfWgMsRFYnm0ejxZ/CDMEiUjtayAQuHznXF+WpySZ45QgJm8c38Pilw?= =?iso-8859-1?Q?Hb9nrOEnnJeMHnO9LddIbVJw6mwQLiRiWrl+AkXTJOBGkrZjssPT9JxF0o?= =?iso-8859-1?Q?MhxrdG0UPw71iXJnOnW3N969SaBo7EQuQjFOVYozLTdXMMpJrlBqUO7yAp?= =?iso-8859-1?Q?GcMJifnfo6blBV0okg7rOzJqqXDk80pcrSDCx/syOSTscDjeeSzd6hDai9?= =?iso-8859-1?Q?SP88RLPmcaVNtMA4EaaGZjWyf5FJXHNbWLOG6OmJM+SM2e4DUgazLFcLpH?= =?iso-8859-1?Q?9hVz04hqR9fa710hPMCA3wF9Gm4rP2v0/xGnFDq71JgGyrbXSlKnUhtkmm?= =?iso-8859-1?Q?Oqri6xc/cSQKSzyBIQLcr5lq/euaKxxV7oM/A+nJfYJaFBeFZZo7+4iUEf?= =?iso-8859-1?Q?SfI0qlAjIVvx39Zxkw/zmxtldjkeO/t0U1Agd49d+NT32Jv809aySwl4yN?= =?iso-8859-1?Q?PchYgd9KNRl10uy3JTIlemkXi4scl5MBcMfziXorpgYZXhRsTAlg3S4/Hv?= =?iso-8859-1?Q?AM1uLnkVjgSWSvKEfbFuA5GllcYLaWz9z5YVhR6ALhVCHP//jahsCwOORG?= =?iso-8859-1?Q?nKLGCcBWr72Hlgz2735IkvkJSf+p9iG2HdIv4PRTUBGuUNXy8TGfyfd96C?= =?iso-8859-1?Q?doVQs89dOQbp7REbSm8wS3HImdeqMuthcXQH3QtE2NUwg+Np4xoFAOYOYf?= =?iso-8859-1?Q?mGuopypvLSO4tkLh/i86GIFJ4QMXMr6VLJFUKbpNvSn0m2MY6ymJxYfz8K?= =?iso-8859-1?Q?AphwwC4YssVm/tLglKWkGqAuL8y7D1E7CZthCb5wSNMUn6IW8bhTw+CQ?= =?iso-8859-1?Q?=3D=3D?= 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: d227cc54-0f8e-47e7-d30d-08d9cb900bc6 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2021 12:29:38.2163 (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: kAcAJM1QLm6E4WOvC/bs5xQietB14RCpk3djUq90pN5YGdVudIR+BO7i30iw36GIjBDaBNYEoxwPoKRXrT3g2A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5773 Archived-At: Subject: [netmod] YANG 'when' with absolute path 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, 30 Dec 2021 12:29:47 -0000 Any one of many, many YANG modules from such as TEAS and CCAMP have dozens = and dozens of augment, some more than a 100, almost all controlled by 'when= '. The 'when' are almost all performing the same test for a presence conta= iner for the network type but because the tree is ten deep and the augments= take place at different levels and the 'when' use the relative form of the= Xpath statement, then the 'when' take many different forms and it is not o= bvious that they are correct.=0A= =0A= Is there a drawback to using the absolute form of the Xpath statement which= would then always be the same?=0A= =0A= Thus=0A= A YANG Data Model for Flexi-Grid Optical Networks=0A= draft-ietf-ccamp-flexigrid-yang-11=0A= has=0A= =0A= when "../../../../../../nw:network-types/tet:te-topology/"=0A= + "flexgt:flexi-grid-topology" {=0A= when "../../../../../nw:network-types/tet:te-topology/"=0A= + "flexgt:flexi-grid-topology" {=0A= when "../../../../nw:network-types/tet:te-topology/"=0A= + "flexgt:flexi-grid-topology" {=0A= =0A= which could be =0A= when "/nw:networks/nw:network/nw:network-types"=0A= + "/tet:te-topology/flexgt:flexi-grid-topology" {=0A= =0A= if I understand aright.=0A= =0A= Tom Petch= From nobody Thu Dec 30 05:36:59 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 84DEC3A157A for ; Thu, 30 Dec 2021 05:36:57 -0800 (PST) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=4668.se header.b=Qk/KNsKn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lNGnbxEq 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 w_s140UpTidi for ; Thu, 30 Dec 2021 05:36:52 -0800 (PST) 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 4126D3A1577 for ; Thu, 30 Dec 2021 05:36:50 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0E9915C0172; Thu, 30 Dec 2021 08:36:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 30 Dec 2021 08:36:48 -0500 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=fm3; bh= OFHggs0OGaAehwI/z2KRXDvpJv2XcC9UIrYgGDk6kXc=; b=Qk/KNsKnOmnusDvg vwL6FHdul2lUewhaO/gEx/MSg7buo/y3xMPhikAj38keQcIN/dxsuPi99T98wb0W Z+xeH9iBAWJcRTXFsebjBtQsn6AtRItit/myE//8bC5dGuPOa+SYC/eA0FiNC7BT /gzGH42DG10nuac3KPvWjxvWMROwkQou9LDE9rFGNcbLCCKL8ZPM74VqCMNuFzJI UcVx0MI7qx43G2EGIBCAPwCVS7SfkzJPNMykFmu96yn+m4u3Q4WIBAeaqKVGHXm8 iW0QB8RqGGdbTC9NVNu8AJFyzDtYVIuqS5IAOS/ZhTXAaYQX84huaHb/xxwXG/2F eipiWw== 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=fm1; bh=OFHggs0OGaAehwI/z2KRXDvpJv2XcC9UIrYgGDk6k Xc=; b=lNGnbxEqMpALHIltafuGxIMthoMNDRlgwiCdS5N8cFgGTR9XNarUYJRSR F73a2XuPX/7iiXPOjBt9rdAkr6y37l5f11rsMsc7VX3YHWcG/wUFU5R7ADHrBfdP 0JeURJKO0u60LZyAHlD0BEs1g3KK1frYXijYsywT7dJTHqeolMVEXYmFzoMz/jQG bwUD3KjyvKwipzoD/8wc99s9zCVk6ojDo1wHE+7zerQ6mIPlh+PtPFTHP/C+Vas3 f+KTu9BLCdcIiKHKxiHwdr9mDNh4+5w2N8Mx1QRMKnhFCqNheV2mf6a9aSDUZYaE LZ2WyQSM7wvzpMmoQqR5y6KryRLsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvfedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepjeetgedvueelfeduudeule egfefgveevgfevueejhefhleeghfelieehfeffhfeknecuffhomhgrihhnpehivghtfhdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 30 Dec 2021 08:36:46 -0500 (EST) Date: Thu, 30 Dec 2021 14:24:25 +0100 (CET) Message-Id: <20211230.142425.716682265318196429.id@4668.se> To: ietfc@btconnect.com Cc: 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=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] YANG 'when' with absolute path 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, 30 Dec 2021 13:36:58 -0000 Hi, tom petch wrote: > Any one of many, many YANG modules from such as TEAS and CCAMP have dozens and dozens of augment, some more than a 100, almost all controlled by 'when'. The 'when' are almost all performing the same test for a presence container for the network type but because the tree is ten deep and the augments take place at different levels and the 'when' use the relative form of the Xpath statement, then the 'when' take many different forms and it is not obvious that they are correct. > > Is there a drawback to using the absolute form of the Xpath statement which would then always be the same? > > Thus > A YANG Data Model for Flexi-Grid Optical Networks > draft-ietf-ccamp-flexigrid-yang-11 > has > > when "../../../../../../nw:network-types/tet:te-topology/" > + "flexgt:flexi-grid-topology" { > when "../../../../../nw:network-types/tet:te-topology/" > + "flexgt:flexi-grid-topology" { > when "../../../../nw:network-types/tet:te-topology/" > + "flexgt:flexi-grid-topology" { > > which could be > when "/nw:networks/nw:network/nw:network-types" > + "/tet:te-topology/flexgt:flexi-grid-topology" { This is not the same as the relative paths, since "nw:network" is a list. If there is one network with nw:network-types/tet:te-topology/flexgt:flexi-grid-topology set, then this expression always returns true! /martin > > if I understand aright. > > Tom Petch > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Dec 30 08:19:09 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 552CD3A12C9 for ; Thu, 30 Dec 2021 08:19:07 -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 FQtyUqP2jN-f for ; Thu, 30 Dec 2021 08:19:02 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60091.outbound.protection.outlook.com [40.107.6.91]) (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 4F37A3A12C4 for ; Thu, 30 Dec 2021 08:19:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NHm80IO7cRV2XsMWCBDLvKhBkuOO5qIJJPfavPrvhf300XGDLlc/+FzZgX0W/II99qBzO+TRftrw5C1E+APCEGv+qznn4e6r1ETH7JQSqsYZrafOSVEMmZ6JWaDyLMIfM9kcpLVjDKk/OO7+yOovP8EuTQrfN8LsNeR5Aow1DMCgkgkfDir+pvZkwQhmUvlJ9Qgm4VNIsks4Gfebk7ix1WrPTJVLtmftYsri2gDWOM9nweSoULRsyfDVSTAhXSGhxLTjaYfhxSyDdLV7qNGwrnmUBMzTt4c28o9EGQJiLalJqE4a1NBWtF+aa8NU2AC9GyKb3BuriBVGU4mQcFA8qQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hhknqj5zjOO2cm1IURYi7Cq17w0+XJEhaSafOZaJ+Vs=; b=c30On57Qk+zWRk1QzVvdU2wLNHpZLp94eElwgEJpxVg6bRvRO/PTMJupJKoRqm8xZjgP4Ai+OLp6o9q2HVH5ZQb1SSoa5U6/qX4UV/macJ0iX3efV4pKKIJ8JxkDF+eICfmXg0dDze28zSzg7RB/7RAuz09d2u1uqre2mMUN99DnWy4wMcO9/TnRMh1UGaZaqcuroVLcu7DFofJQWZq8PbwxJ5ufMYHm9MwGNUyTvn90snbmBh9zv/g+U/2Wc86M6tqY1oCfjNcxIZWZN1qS77e7sEMCD/Nu+gIdDFR8a9yzUGt1notP077HH6F+u8ptxYrRw++PxNVL7UXf35Rn/Q== 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=hhknqj5zjOO2cm1IURYi7Cq17w0+XJEhaSafOZaJ+Vs=; b=ORHW0WNS18sHLVJTUWMJcY54dX2in007m9djf5TfJWqIG3BfJ7YZ8VjWxsO4BiQvNSZwUmwo/dvw/klXw75viCnS3a/0M8vfyVJNQpm4rgsMpXrSQ73ygCDoDa0jYNrCX+ZeJUatV9WJfJ6zDP502ux9rL9Tq/qK5IpCm+zA9d4= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM7PR07MB6804.eurprd07.prod.outlook.com (2603:10a6:20b:1b4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.4; Thu, 30 Dec 2021 16:19:00 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::719a:2b70:b9fd:d912]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::719a:2b70:b9fd:d912%6]) with mapi id 15.20.4844.014; Thu, 30 Dec 2021 16:19:00 +0000 From: tom petch To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= CC: "netmod@ietf.org" Thread-Topic: [netmod] YANG 'when' with absolute path Thread-Index: AQHX/XaoYX/gsG8fJkOvON2F5wSGIqxLBjOAgAAwPgE= Date: Thu, 30 Dec 2021 16:18:59 +0000 Message-ID: References: <20211230.142425.716682265318196429.id@4668.se> In-Reply-To: <20211230.142425.716682265318196429.id@4668.se> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: e9f45acf-ed9c-f5e1-6ee6-1b8f7e1027f2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bd5f52fa-e0b2-409b-4763-08d9cbb01673 x-ms-traffictypediagnostic: AM7PR07MB6804:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QtjcXqTZYvKgh6y1RrffCR6tzrl6qdTh05o46ZyJjJpzCb/FRvS29sjFapLM4kvAo7Ttztf/H77d8BfHCTu2+Hfe23fwZYDDP4IVJfvX6sSLZETyTQw2cmC5q2dbWyKdeoB9ohRsekF8jWwaVVpMPjjaOYQ448RJnHxDt4oCXYVQxxw5dV1B4+7wkUzkfbJ40R8w78KKyZx9s8u444+ARYGfz1wIeKXoUoUFB461InofmhTaMUuPU9Cl8Ot+QCRjJMN8SK+EJfO1gV/0EQPNHtD7cEwWKsAB1tIH8fllkoEqG1HHIzLaIImlGDSaXes0Rp4sHspPTCMpLcOru/UTykhyVVkjW5yQh/AFRJeyaO4jR9GkISJFEVdiMvJUV8kalKjpN6lKnqvWLT0RE7mDQO36OkH1hcjoQ4LnnlMWo7F6vv0QQ8mqOUUPlIQgD6gGZbIkCsynsHhL3ThVCaZOMcKp/qWGPMbR3cJ7w4BhTRIdbqfaVmHJOjgsSjyo/f41qXYWZ9PHdEEs+BBhXKeBpF7eo/VoBAOFGq/xAD31fb+KYB5tKEAcu+Ko1n8FwaiprYjZZ+p44YmcqoVT6miYeHOOGE0kus3Y7/CFZHtdma5pSgHBZsMTsGuPGFjcYxpc/lnTrzt2P1BWRNRZ7jBPMRW3eog6HU5Lzbt7719bAk+wwhZagV349r8euQzNKMzVgOBYMblwMMqp7NAZeru8onFlOZ9psXJU64miiUd/kEkOx+BwXNXdE49eU3vV8uSdEJmQQq1eQMRMHRSyvtDqrvdCXYTnPD8eTLUssd3MrTeJ6rTZ6n+JyK3AK0DP6oXG5chvObw12GRLT6hsUdPqRw== 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:(13230001)(4636009)(366004)(966005)(7696005)(26005)(6506007)(38070700005)(186003)(66574015)(71200400001)(2906002)(4326008)(91956017)(76116006)(33656002)(316002)(9686003)(508600001)(52536014)(55016003)(82960400001)(86362001)(5660300002)(8676002)(8936002)(66476007)(66556008)(66946007)(64756008)(66446008)(122000001)(38100700002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?fjX7jQpsnhU861VEAmTfY3TX4hasEHaM3zZzZwbVmlxh1EE7AVDej9+pre?= =?iso-8859-1?Q?QxmeFVc4PuDBcHJWolLJPKHLebpBrQDxdnfK3YaMWyJ/JcZrpeJGjYTbVc?= =?iso-8859-1?Q?wZor+BnfJ729aZKmMx6u5qj8da/DtyTuVSkWdeuu7qXlalgSSEZwasKNys?= =?iso-8859-1?Q?AiIW/g7KWvbIv4iZN6jkw9eT+U1n+CMnuNGoA4jqVCGw1sH/MJIgSH9Sx+?= =?iso-8859-1?Q?9Ffx7sicfjeOoBjk2uwWwzsXGHLfV0fyH/tfDkZuaCevkRM+QX4zgxNrn5?= =?iso-8859-1?Q?PhbHlzgT56poGI83HsYt/YrSxT21cr80y32uAxulaSqN1eS2A8OfD0+3OO?= =?iso-8859-1?Q?/Sa1pbAwakf1vt1qsmXwrBmRF8YVthXe6+bpWzaqnL9QPDPuiEWatw9bs6?= =?iso-8859-1?Q?U1b8bsoYe4qdVEgZ44y7hlxYuYJmmI3IUz5trswl6k0W11xgHy08mdgOFi?= =?iso-8859-1?Q?S31QTofaYYcZuVZEwwG53RkmAbO0s08pwBB3hqT5xX5D+fpPgbnnA4FdcN?= =?iso-8859-1?Q?2QQbGjjH2atbdiMTeO5wN8z8wPQVnQvYW3ZiizMlA7406TU6At442JprXy?= =?iso-8859-1?Q?tQtbvAxjjkSskkpK8SJYrPzZieUn+KK8W9sbpnZ/Q5IJIzJHgPNQNn+H5h?= =?iso-8859-1?Q?CAs+4+gnVC1mPQocIiMlzeXgMC37kVlLS7j/F+SoJlxdxn+qunVg5PVlc7?= =?iso-8859-1?Q?Yr8WldLD+YosS0NXfDfB/7KUqLyxSPegPny/NY8EL+T7cvt09onpZqxIGj?= =?iso-8859-1?Q?1WawdFu5Mu910d0zZpfZBSnSWaUBiLmMBZGqgymoiWltPT2yj5q9S3tg8x?= =?iso-8859-1?Q?uBgdEq03qShZWK8zsK0SDfh5ytvXzbk6ZUtKg37LCoZ/JvXBKSnVGxETgL?= =?iso-8859-1?Q?W2PORtFj30Zi4oy+kmCuUZGBEbSLJpDO+ODsoNuB4CQYVSqiFvGhc4yPhD?= =?iso-8859-1?Q?DZX7X4eS8BRNZsvHC3b/xjo3W2m9y5cI7bAFJ9aXhIaa6C6uL635FdoQHZ?= =?iso-8859-1?Q?SGtTJmc/pH5lW2MudVgnEcjZo/+63Z1elKjDqvcTo67M/xHse7e+oVyx1p?= =?iso-8859-1?Q?AmsmWeM1nWqmaAdnZfPka89m0RarckzZoYj0+FajkCYnqJm+O1nMitYiO5?= =?iso-8859-1?Q?lKtKbd+mTHJHCMiq84hlTq3kk8fsM3gIfKX2IzHKVhaA1aIc6Yi42cZlk7?= =?iso-8859-1?Q?CPbXi4YConBiuP1u6H9bqve6QwbN5skmLKVdfHYyZbm5x2s2O0LBrY0o/g?= =?iso-8859-1?Q?LE4XtTJClWbQWXVlL9FRb+M0chTPCekug91qLGBKhc69dPMcfRq7ocmOYD?= =?iso-8859-1?Q?yBxXqrekR4LN5WLwRlrV+ZXe7GJHbSyoRPIWPYmHQVbdeEY3cDCqGMNFkg?= =?iso-8859-1?Q?scCFF359LSrHjC9hLHeylXv9r28ZXv+1vk0MMDpZy7HX6oerSoTXC/tYhx?= =?iso-8859-1?Q?HxAq5kQV4Wk39gvPXHJVQjZ5rfBmLsID5oKLtO4b+GKVWVR8x1lPqbKARL?= =?iso-8859-1?Q?a/CaGKXbfT9gVwZx/9qOu9a1Z1MIwfR7VwHvIwezouG3RLyDe5NQTA3vN0?= =?iso-8859-1?Q?GVr8Hywf1sqqEWUvd0hBfdFzKDwqXoibXhTrzNKpBwZeQhuWT3SKcqqZUP?= =?iso-8859-1?Q?BR2pwYl2C1yp1tHH7S2FeRKn7nqaNdAnI0QKVqBCCrVJgsJkhGrwIlog?= =?iso-8859-1?Q?=3D=3D?= 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: bd5f52fa-e0b2-409b-4763-08d9cbb01673 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2021 16:18:59.9722 (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: SZ1ZYVw8xMEoxs9BC0fKlIdd2kdeoy/4HfT7NXF0crxl/iKVVIwIga4gvCTcPP9kxYr+wDOt4mQWPfLweTlmeg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6804 Archived-At: Subject: Re: [netmod] YANG 'when' with absolute path 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, 30 Dec 2021 16:19:07 -0000 From: Martin Bj=F6rklund =0A= Sent: 30 December 2021 13:24=0A= =0A= Hi,=0A= =0A= tom petch wrote:=0A= > Any one of many, many YANG modules from such as TEAS and CCAMP have dozen= s and dozens of augment, some more than a 100, almost all controlled by 'wh= en'. The 'when' are almost all performing the same test for a presence con= tainer for the network type but because the tree is ten deep and the augmen= ts take place at different levels and the 'when' use the relative form of t= he Xpath statement, then the 'when' take many different forms and it is not= obvious that they are correct.=0A= >=0A= > Is there a drawback to using the absolute form of the Xpath statement whi= ch would then always be the same?=0A= >=0A= > Thus=0A= > A YANG Data Model for Flexi-Grid Optical Networks=0A= > draft-ietf-ccamp-flexigrid-yang-11=0A= > has=0A= >=0A= > when "../../../../../../nw:network-types/tet:te-topology/"=0A= > + "flexgt:flexi-grid-topology" {=0A= > when "../../../../../nw:network-types/tet:te-topology/"=0A= > + "flexgt:flexi-grid-topology" {=0A= > when "../../../../nw:network-types/tet:te-topology/"=0A= > + "flexgt:flexi-grid-topology" {=0A= >=0A= > which could be=0A= > when "/nw:networks/nw:network/nw:network-types"=0A= > + "/tet:te-topology/flexgt:flexi-grid-topology" {=0A= =0A= This is not the same as the relative paths, since "nw:network" is a=0A= list. If there is one network with=0A= nw:network-types/tet:te-topology/flexgt:flexi-grid-topology set, then=0A= this expression always returns true!=0A= =0A= =0A= Martin=0A= =0A= Aah shucks; thank you for putting me right. I thought it was too obvious n= ot to have been raised by a YANG Doctor previously:-(=0A= =0A= =0A= /martin=0A= =0A= =0A= =0A= =0A= >=0A= > if I understand aright.=0A= >=0A= > Tom Petch=0A= > _______________________________________________=0A= > netmod mailing list=0A= > netmod@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Thu Dec 30 08:49: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 9FC343A134E for ; Thu, 30 Dec 2021 08:49:19 -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 wxCLPo20EF08 for ; Thu, 30 Dec 2021 08:49:15 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357163A134D for ; Thu, 30 Dec 2021 08:49:13 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JPvPL7359zDCcX; Thu, 30 Dec 2021 17:49:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Thu, 30 Dec 2021 17:49:10 +0100 X-Mao-Original-Outgoing-Id: 662575750.4439369-413dbd1e7216e2eabe08a93bb1b44408 Content-Transfer-Encoding: quoted-printable Message-Id: <2F6E4A1B-618E-4CAA-AFAE-9C41609B1B7A@tzi.org> References: To: "netmod@ietf.org" X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] YANG 'when' with absolute path 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, 30 Dec 2021 16:49:20 -0000 On 2021-12-30, at 13:29, tom petch wrote: >=20 > when "../../../../../../nw:network-types/tet:te-topology/=E2=80=9C= I=E2=80=99m probably showing my ignorance about YANG again, but what is = the reason this is not phrased as when "./ancestor::nw:network-types/tet:te-topology/=E2=80=9C ? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 31 02:01: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 E80683A128D for ; Fri, 31 Dec 2021 02:01:29 -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, 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 CGfHMTX3LUBV for ; Fri, 31 Dec 2021 02:01:24 -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 B0D683A0D61 for ; Fri, 31 Dec 2021 02:01:23 -0800 (PST) Received: from localhost (unknown [IPv6:2a01:5e0:29:ffff::82e]) by mail.nic.cz (Postfix) with ESMTPSA id 17263146C91; Fri, 31 Dec 2021 11:01:16 +0100 (CET) From: Ladislav Lhotka To: Carsten Bormann , "netmod@ietf.org" In-Reply-To: <2F6E4A1B-618E-4CAA-AFAE-9C41609B1B7A@tzi.org> References: <2F6E4A1B-618E-4CAA-AFAE-9C41609B1B7A@tzi.org> Mail-Followup-To: Carsten Bormann , "netmod@ietf.org" Date: Fri, 31 Dec 2021 11:01:15 +0100 Message-ID: <87sfu9w0t0.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.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] YANG 'when' with absolute path 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, 31 Dec 2021 10:01:30 -0000 Carsten Bormann writes: > On 2021-12-30, at 13:29, tom petch wrote: >>=20 >> when "../../../../../../nw:network-types/tet:te-topology/=E2=80=9C > > I=E2=80=99m probably showing my ignorance about YANG again, but what is t= he reason this is not phrased as > > when "./ancestor::nw:network-types/tet:te-topology/=E2=80=9C Yes, this would work, with a minor correction: when "./ancestor::node()/nw:network-types/tet:te-topology" because 'nw:network-types' isn't an ancestor of the context node. Also, the= initial './' isn't actually needed, hence when "ancestor::node()/nw:network-types/tet:te-topology" Lada > > ? > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > 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 Fri Dec 31 04:42:59 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 0A3F13A143E for ; Fri, 31 Dec 2021 04:42:58 -0800 (PST) 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, 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=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 Tzef9NaU--IP for ; Fri, 31 Dec 2021 04:42:52 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80122.outbound.protection.outlook.com [40.107.8.122]) (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 A9B483A143D for ; Fri, 31 Dec 2021 04:42:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eDgUyiSDbZEBv7NYsws3DdEwU8JeArmHbirFpFQmzJ02MzyySMkXTw/bLrO4Rhf8tAbxApXTxol0WFqilQ8tPMR4O3A3QE3S2X4X1YYhH1n9QnCYOz1DOQnLwxr+8SYJDqX5s7uZc1zXu0KhAWP1S+2IDwvUiFfSbhw+9IeGe4r/H5OlcXW9hmyx2jmefygakHWGMNod2qOPhzUYSrajAqypNocKu8pdXdyX4o8krqs0LCIydXKTB2ddu345g2Zi4OXpVZv228Z+xhqWTl5W3sAHW0jgiW0FnJpe68qReMNNUBjmzpZk/8pVHm8EqqarR+kqJO6SQflJUQAKVd1AFQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Kz4xPnsR1zJImMaceuKyD94nz3uPOiBzlRiZRSPwvpk=; b=WKuSC+fj4LnhRGrFeFEsXrMtTFmk/DfnkbkNkkMxJsBs4kkPMs7igkkS3ZHw+sXwRMYzDjLOAwa4RKSQ5HFK5LbrKYB531r93jBvjiVQozhW5D64fwsxU9ZMlJEupLD69sLaFG9YHav2wDw7F5+0NDBqr3yqCLKqhcPeMg/cCb0d/xLXHyRJOfs2KIwUV69NnzZCVrnxDdtJtBebx/MJ6QDWtWooHSaSZT69cW2+0YFSqzMUg5B7h1f23EeM0m0RrDPlOETFkb7yYZhzG0Ik2RkYPFi0EVm7i2BNRoe2L/YqKyL6MnxzNsU3TxylNZ1/DmUMr4E4mSYihMQRDuV16A== 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=Kz4xPnsR1zJImMaceuKyD94nz3uPOiBzlRiZRSPwvpk=; b=tjkUQTE7Jhrt2cQnMhCq/X0imSfI+obex/nyoH0VzGdHywvOX3krnDwiT1tRUWTqSi39BEUAYVl7B67uSt8RWXN84Z54U5fiGqVHVrlA2jiFm7XGVkG2pxfcvrgxdiMSDQFJJw9V0naUJ2wFbkJrcjwjNOrZWnRo2X+ptU++XoE= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by VI1PR07MB6336.eurprd07.prod.outlook.com (2603:10a6:800:139::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.10; Fri, 31 Dec 2021 12:42:47 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::719a:2b70:b9fd:d912]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::719a:2b70:b9fd:d912%6]) with mapi id 15.20.4844.014; Fri, 31 Dec 2021 12:42:47 +0000 From: tom petch To: "netmod@ietf.org" Thread-Topic: Camel Case versus hyphenation Thread-Index: AQHX/kLKdmSNaEBzmU2yHd1TXzusRA== Date: Fri, 31 Dec 2021 12:42:46 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 76439cab-84a4-2ef3-9691-4111299a5d38 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b2c67b12-1a6b-455c-b7fe-08d9cc5b0c52 x-ms-traffictypediagnostic: VI1PR07MB6336:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n4kxkbeEjQDVG86TTqmT/qoFsnAynQV9w5oeL9xpD/cud0+fWaNRH9VSTHC2cztnEx9radrtKRlOHfgRuMWo/34veJPqRCWJhkp7yPDB/fPtIeWAP4R6xI0Phk5/pUKlRtW5t0hnqpTFLxHVPROdEJ2URhBpu1TqwCOeWnNA2mlHFZOBnsYB1IMSXaxiS804pegAAdiq+DQ6t3nG2Ybr1VVqHhGAAOxtNVBJWdQXdcWt5GKxJKprNyiPKPjeG4W94sTi7OUrmwHn3yZRz3yLvbC9f5cOlTQoQEjcVhayJ6jvY6yNZtk8AOkG51t091ZQ/KIlHj0tFhJB/GMQGeq9ho2gplkS6eHt2neChjjxsx6N3pUgehGVXEnCgKDDB2hfim1z/WgpBR2OpJsa+Szwto6NEwsFKZ9uCTOHuUX4ctHCtt0Wms9320OX57zs2geJs6JVCQLSm4zZi3SHQg3QXEv7IxDFK44MlVHxL7292tzRz0Ukgv+6Wm2pf/PXs91fh6HGHllSuJoYENisXaYoDOgzfeG7aiys1lQeQh4nQ1MAtV+o0middxN3IafIJ/iGqtsousglOKFEjhidKbiGAFFFbBYXI2G3n94tHO+dj+W/E6505qu+4MPC+Mm0ZUfmthnLx3wqtu91Fe6Piy/B6oghfVuWtHtrLadsXgNK267IVXc0+jbBDLQFV1dKYhOvUwoR9pcPjsR9v8riWYyuWLgDYMaYIA7JNVu/FymIvRZW0LMi3e6skuP7ugIQdvKS 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:(13230001)(4636009)(366004)(26005)(186003)(9686003)(86362001)(316002)(2906002)(33656002)(122000001)(64756008)(66556008)(38070700005)(76116006)(66946007)(4744005)(66446008)(8676002)(6916009)(66476007)(38100700002)(52536014)(3480700007)(7696005)(8936002)(508600001)(55016003)(5660300002)(71200400001)(6506007)(82960400001)(91956017)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?+cBvyAOsbrHgmax6lmO76SSKkZO1a/GCYBp8xPw459quU3KxRtM1pxYASh?= =?iso-8859-1?Q?eLMOctPfytLKITQK4xp09LEMjK2/PLjwWVP+pKseV98iRJFDsz218l32kT?= =?iso-8859-1?Q?6uPT9OOaN5kO3t+yPuk0gxAF33gS0AEcrw492thnFXQrr2YBZkVlYX8yjl?= =?iso-8859-1?Q?TA9o3QhzPbi1jUXeQQ2A0/X6TFTnOKmEu4OGu4rPWWGfvqutg1ta3ODtUO?= =?iso-8859-1?Q?FUS8B9BOwU/IN0DcnBUvPkkR9+dDXDvsfXsG2Eq017wNCWWBCEQ83vrfMi?= =?iso-8859-1?Q?MPP/0hItjcPFZLdpqrg2SlOzsMV0PVayNQUnWrw5NksFZYjmoAOcoO/h37?= =?iso-8859-1?Q?3S/fv9WPprxsGtJMKHX2jGwg8t7bZZGaJTQ7JQK2zyrv0r+sacOdbguRKL?= =?iso-8859-1?Q?keJc7hqcu90NZcR2yKeBCrxUYJYqNSI4LO+l39/utw95/Pfisb31TN4nm3?= =?iso-8859-1?Q?vFTBjE5i2ZHNNpkaOxfG02CWrRezidig4z65qR1fqfG4cibZDuPP3UUr87?= =?iso-8859-1?Q?RW6WRWI6cNz8Ubg5EiYkc5Pf42hXG6vhweKO6SEMsjkoHtz42GNPZTZJdv?= =?iso-8859-1?Q?+DfVAqzYjQv3AZGoi6UeAq/XCJ2+vr9jMhOa2kqskkxz3n9GoV8AQpRqKp?= =?iso-8859-1?Q?O9eNYKPCya+q6RH/fkKydlw9jXKz5V722BfDK2UV3xgA+lyzABzpxCgomR?= =?iso-8859-1?Q?MinHX0TjpReqOk2HNZ0JEnA8/9YHLQj+x4RaT9U/Ryjpz1Lbmr8LDAukqD?= =?iso-8859-1?Q?IYQkSEz8LZW8aMMSMZqLL8uHDcb8Wcq7EMcIM5nG5NCFX61Rn1DrZqOCNH?= =?iso-8859-1?Q?s2pz6f+8JE+LNs8jviP6Lvv4VX2JFziOuumzZy1aF05AfOSZAr2RKmwixI?= =?iso-8859-1?Q?0j+bEdHgXWvwwPAWPn68UenpyoOhH3PJgjk+IuMCn5TZobgk1Wf6ooHaK6?= =?iso-8859-1?Q?FrlVyhMsYkL9hNyQ+3e1ev8lZ81n7mfEoEby8PUIFRguE7AxgNqE3P7H0d?= =?iso-8859-1?Q?5Uay2SaU8mIYuec+nF8Z+W2QXjNDMueesey9RU0tOBiJ93TcwHU4rhX9xB?= =?iso-8859-1?Q?QHqJZCwylf7YNEaix9OBVQ1+HiqYOIRoMn1z7gMQAEYGC1c+65G1CQ4kdQ?= =?iso-8859-1?Q?QTUQ7GY6o3optzD1YsCWYjvQMyyIa6SWVq7bZs8OR0JujKxapTCCO5+s1f?= =?iso-8859-1?Q?wantCciZJoQB7vRrmSpoP+L6LJhDr9AtDgFLCy3J1iBI09NlXpQMd1wg+q?= =?iso-8859-1?Q?YbaXHv8KCPEwqA2S013qR9EA9Xf13fIN0AlO/ZyrkfEJYhYaJs04hlZE9Q?= =?iso-8859-1?Q?xNlRUjm/JqeFZLMAC0Fns2tRvxM2J1sQChbP9/RnOe8kzMBJAXf2CwQFz8?= =?iso-8859-1?Q?T+YrrsJwN6v8LYOvDsh9yTf1SktQgImnJdSBhJMprmvkpFt24KYfrsXgRg?= =?iso-8859-1?Q?W7N1ZznIyzIWbCsU3OPp5L1OEbp7wwiZzJ2p1hZRDycAd51Bn5t36JFoMi?= =?iso-8859-1?Q?huVvm8pcmDKUQAHCDd9WwtsSgre8kY3RSgJXes1wi3cFfolDRSE7RGGGTT?= =?iso-8859-1?Q?BMpCKO4WHlOUtVVkEHfbJ5nNHiam9yNruVe4Ugns82T5ivLUtrqkgGgPQN?= =?iso-8859-1?Q?Akak04BZt6rlXN1p4iAZfSoGndYSs/9FE1r5tPni08b8J00RX86uo+cA?= =?iso-8859-1?Q?=3D=3D?= 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: b2c67b12-1a6b-455c-b7fe-08d9cc5b0c52 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2021 12:42:46.7818 (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: dSwWCNfP8P2Rjd3T6DR8ShebRL6Alr4ut3kCB3L34T7yzMpns3zrxC8VC1T7xZ332LTEnNdHmxiR5KaPUgaRpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6336 Archived-At: Subject: [netmod] Camel Case versus hyphenation 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, 31 Dec 2021 12:42:59 -0000 A number of protocols name protocol values using camel case, protocols such= as TCP, BGP and PCEP (RFC5440). YANG does not like camel case and so some= YANG module authors put hyphens in instead, so that OpenWait and KeepWait = become open-wait and keep-wait. (draft-ietf-pce-pcep-yang) =0A= =0A= I strongly believe that the YANG identifiers should follow the protocol ide= ntifiers but can see that the absence of camel case can make them harder to= read, to follow, perhaps when part of a compound identifier such as peer-k= eepalive-timer.=0A= =0A= Which is then better, openwait or open-wait? Is there some factor that mak= es one preferable.=0A= =0A= Tom Petch= From nobody Fri Dec 31 07:38: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 35DBA3A079B for ; Fri, 31 Dec 2021 07:38:51 -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.20210112.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 8xlnIE7Bc2MB for ; Fri, 31 Dec 2021 07:38:46 -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 85E5C3A079A for ; Fri, 31 Dec 2021 07:38:45 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id r4so17646575lfe.7 for ; Fri, 31 Dec 2021 07:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZWO3TVVH4xlZbRR/CNUUDCQycqkmckb6yV1WjbX6Tx0=; b=Ly4qMXQEBvViDCpeYwySeWn7cUWrcM3LBGyu03Nq4zo8R9RELDf+j7k8MVT4dPcJdD sm0RwXSr0cy9FWebbNsLRyc/NP2sVH+spEFjZDMRsPAbtKAyodjH4V8d8yzEZpezJNkz UwBWksQ9kgxfr/Day5U5gYVK04gDFzBeEyxFE/GvtD4+awBrqHxKSckeSaFWvStuAZ77 ABkt46tPR+FyZ9vbzYWdXkCML2Oq825K/LsbrK6NfOfIuAxr8CferQp3lh9cWl0RTPu+ bsxMhz8DZ4v1K1u8KwmhZOCgk1wI6i9cW2aqGGJSsATmx7i0rQOcrmWEOtrYc2knJbde OD5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZWO3TVVH4xlZbRR/CNUUDCQycqkmckb6yV1WjbX6Tx0=; b=HEfVk6NhqddsXL7FiUPHlGMmN94DrZ1BOCqNwyOWTL5Z3vERdijg5FbR3azgBdYRcG 1DeG3zfAe9EnqNzK7dz+F7BWzeA6PY8yb0VuIXdy3VaFCOaX/19Dbx9VXxuJtn5tYdGn 4Ii7KBzwZKfjM5LUT5MaGPVRqndfRU5f8O2rDkp80ZIWxqwyh4xV0UUPWnNJcD/Kv3lU chdS3uG5RP4UCYYqomxLlSim8FCBpgQ2XN3kxKwGXPKwv46stT7ZLVTZgih2dOkw0S0i MW9zFE/FMdIeLcEHlMm0sz7amkCbivHJdv6z8oHPVWqb+TbHXpsoXz7Adrwr06HrmOZ7 mjAQ== X-Gm-Message-State: AOAM5314lgdzYiFArCwRQUeSdTAp2Gwm1dBScxw8esE5pb9SUr1lE7L4 f7MNbqrBVsBuITflM29P+d9sVwxMKtFzC6WMyhoaVg== X-Google-Smtp-Source: ABdhPJz1moea7eiYMS6OO2W53EAyyHCD5wZ9IboK330RK09h61iT/nlm2NHyJ2bX37wn/9VTvuGjUvLi9LdpZx6lBDM= X-Received: by 2002:a05:6512:453:: with SMTP id y19mr32244881lfk.10.1640965122463; Fri, 31 Dec 2021 07:38:42 -0800 (PST) MIME-Version: 1.0 References: <2F6E4A1B-618E-4CAA-AFAE-9C41609B1B7A@tzi.org> <87sfu9w0t0.fsf@nic.cz> In-Reply-To: <87sfu9w0t0.fsf@nic.cz> From: Andy Bierman Date: Fri, 31 Dec 2021 07:38:31 -0800 Message-ID: To: Carsten Bormann , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000036ad6d05d472f7e1" Archived-At: Subject: Re: [netmod] YANG 'when' with absolute path 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, 31 Dec 2021 15:38:52 -0000 --00000000000036ad6d05d472f7e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2021 at 2:01 AM Ladislav Lhotka wrote: > Carsten Bormann writes: > > > On 2021-12-30, at 13:29, tom petch wrote: > >> > >> when "../../../../../../nw:network-types/tet:te-topology/=E2=80= =9C > > > > I=E2=80=99m probably showing my ignorance about YANG again, but what is= the > reason this is not phrased as > > > > when "./ancestor::nw:network-types/tet:te-topology/=E2=80=9C > > Yes, this would work, with a minor correction: > > when "./ancestor::node()/nw:network-types/tet:te-topology" > > This is not equivalent to the original expression. The ".." location step stands for parent::node(). The node match has to occur at a specific ancestor level. But "ancestor::node()" will match any ancestor node. Andy > because 'nw:network-types' isn't an ancestor of the context node. Also, > the initial './' isn't actually needed, hence > > when "ancestor::node()/nw:network-types/tet:te-topology" > > Lada > > > > > ? > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > 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 > --00000000000036ad6d05d472f7e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 31, 2021 at 2:01 AM Ladis= lav Lhotka <ladislav.lhotka@ni= c.cz> wrote:
Carsten Bormann <c= abo@tzi.org> writes:

> On 2021-12-30, at 13:29, tom petch <ietfc@btconnect.com> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0when "../../../../../../nw:network-= types/tet:te-topology/=E2=80=9C
>
> I=E2=80=99m probably showing my ignorance about YANG again, but what i= s the reason this is not phrased as
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when "./ancestor::nw:network-types/tet:= te-topology/=E2=80=9C

Yes, this would work, with a minor correction:

=C2=A0 =C2=A0 when "./ancestor::node()/nw:network-types/tet:te-topolog= y"



This is not equivalent = to the original expression.

The ".."=C2= =A0 location step stands for parent::node().
The node match has t= o occur at a specific ancestor level.

But "an= cestor::node()" will match any ancestor node.



Andy


=C2=A0
because 'nw:network-types' isn't an ancestor of the context nod= e. Also, the initial './' isn't actually needed, hence

=C2=A0 =C2=A0 when "ancestor::node()/nw:network-types/tet:te-topology&= quot;

Lada

>
> ?
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> 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
--00000000000036ad6d05d472f7e1-- From nobody Fri Dec 31 08:32: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 03C213A08D9 for ; Fri, 31 Dec 2021 08:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, 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 rrEBVyZ9QwJJ for ; Fri, 31 Dec 2021 08:32:41 -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 8591D3A08D7 for ; Fri, 31 Dec 2021 08:32:40 -0800 (PST) Received: from [IPV6:2a01:5e0:29:ffff::82e] (unknown [IPv6:2a01:5e0:29:ffff::82e]) by mail.nic.cz (Postfix) with ESMTPSA id 5AF781409F2; Fri, 31 Dec 2021 17:32:33 +0100 (CET) Message-ID: <4ac64047-3acf-1cba-914c-c6cd21267b47@nic.cz> Date: Fri, 31 Dec 2021 17:32:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Andy Bierman , Carsten Bormann , "netmod@ietf.org" References: <2F6E4A1B-618E-4CAA-AFAE-9C41609B1B7A@tzi.org> <87sfu9w0t0.fsf@nic.cz> From: Ladislav Lhotka Organization: CZ.NIC In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] YANG 'when' with absolute path 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, 31 Dec 2021 16:32:46 -0000 On 31. 12. 21 16:38, Andy Bierman wrote: > > > On Fri, Dec 31, 2021 at 2:01 AM Ladislav Lhotka > wrote: > > Carsten Bormann > writes: > > > On 2021-12-30, at 13:29, tom petch > wrote: > >> > >>       when "../../../../../../nw:network-types/tet:te-topology/“ > > > > I’m probably showing my ignorance about YANG again, but what is > the reason this is not phrased as > > > >       when "./ancestor::nw:network-types/tet:te-topology/“ > > Yes, this would work, with a minor correction: > >     when "./ancestor::node()/nw:network-types/tet:te-topology" > > > > This is not equivalent to the original expression. It is not equivalent but will work fine in this case because there is only one ancestor having a 'nw:network-types' child. Unlike the absolute path, one is confined to the same 'nw:network' entry here. It means slightly more work for an XPath processor but is IMO considerably more readable and less error-prone. Lada > > The ".."  location step stands for parent::node(). > The node match has to occur at a specific ancestor level. > > But "ancestor::node()" will match any ancestor node. > > > > Andy > > > because 'nw:network-types' isn't an ancestor of the context node. > Also, the initial './' isn't actually needed, hence > >     when "ancestor::node()/nw:network-types/tet:te-topology" > > Lada > > > > > ? > > > > Grüße, Carsten > > > > _______________________________________________ > > 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 Fri Dec 31 10:18: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 8F19C3A0B64 for ; Fri, 31 Dec 2021 10:18:21 -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, 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 mBdTy5L9F5NN for ; Fri, 31 Dec 2021 10:18:17 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C416D3A0B59 for ; Fri, 31 Dec 2021 10:18:15 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JQYKY1srSzDCcB; Fri, 31 Dec 2021 19:18:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <4ac64047-3acf-1cba-914c-c6cd21267b47@nic.cz> Date: Fri, 31 Dec 2021 19:18:08 +0100 Cc: Andy Bierman , "netmod@ietf.org" X-Mao-Original-Outgoing-Id: 662667488.7471319-020e72c46c320b23fd6471df4169ab5a Content-Transfer-Encoding: quoted-printable Message-Id: References: <2F6E4A1B-618E-4CAA-AFAE-9C41609B1B7A@tzi.org> <87sfu9w0t0.fsf@nic.cz> <4ac64047-3acf-1cba-914c-c6cd21267b47@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] YANG 'when' with absolute path 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, 31 Dec 2021 18:18:22 -0000 On 2021-12-31, at 17:32, Ladislav Lhotka wrote: >=20 > It means slightly more work for an XPath processor but is IMO = considerably more readable and less error-prone. The original phrasing with ../../../../../ etc. is in conflict with the = powerful maxim =E2=80=9Clet the computer do the counting=E2=80=9D = (remember 12HHello World in FORTRAN?). We had the same =E2=80=9Crelative-path=E2=80=9D disease with the = original use of (non-standard) relative JSON pointers in SDF. Going to = (the standard) absolute ones helped a lot, but actually finding the = right node would be even better =E2=80=94 can=E2=80=99t be done in RFC = 6901 JSON Pointers though. So my brain was just activated to this anti-pattern, and since XPath is = infinitely more powerful than JSON Pointer, I just wanted to know how to = avoid it. Thank you! Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 31 12:28: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 839CB3A0D97 for ; Fri, 31 Dec 2021 12:28:33 -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.20210112.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 zKVvrTs8LQQd for ; Fri, 31 Dec 2021 12:28:28 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4F0813A0D96 for ; Fri, 31 Dec 2021 12:28:28 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id g26so61874048lfv.11 for ; Fri, 31 Dec 2021 12:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i8W/8MmzDLYxjRS1y39wLipFp3VtrUfJZQPViLCrYvM=; b=p5CU/U3RWpMMYztx22/bCN3wd26Q9gjxSSmUB1Q01Xm9L0nv6/2GWhZAA+y52s9YR0 v5aCP1T9Rup9IdZjuWLay1Zx2GV9I7GUSbxAHk3gx3eglfRCHnDBsRnZQj5S3jnCKxZJ rbfcVCNih/AeCw5cDukxBHK+FK6pc0hk3b9lf27rdciLKrbKXDoHt9+u66gYMPnJkf36 QTtlsYhqlZif0iBmJjV6c4NPsXpWiTf+L9irerXifGsljknorH/RD5Z+RZPVUEE++yWq g6d2x1yeAVxXY6t4YXddVw3oIngjAOE1+J3CZeMt8updoF7tmwR/Ky8/BRwV+2uqAhzy aWKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i8W/8MmzDLYxjRS1y39wLipFp3VtrUfJZQPViLCrYvM=; b=qjPZxEXEt2v6IqVsCp+E/75vNNiE4is/enQz8nS2QyZfqlDrmy52RqLkwMxIYFsGI7 zoTryeMOejcW04NtEQEiswkGsWFp+saOWBzxjNkrFEojK1txx4OIKmxuL/yxnYy7+so2 Z0iUuAdVZo2lx6+PHUniz87tbX+bLFtQ6YVaS6tgKTY9wfDQNnncNDZGXg32XW+tHxJT K5rf13ezHfC+JR3mM6IOiBGnBafs7IXfDxJ+dur83vOaGK/Vj7y+WHrCmVWzxM11eW6R J2iDwOtLaGlC4Ny4ZFhH0uwbi/XwxS83vM13uE7y+4OXVu5b4IFMt77LdVBdzdIC7oBf tqtQ== X-Gm-Message-State: AOAM531pidwKWScb4SwL2E7/Kga6/eOaxYAryEFeWppf2diMdvLlTiCD UKDXdZWb9yhUXypn1DCxJaawKuAhA/5TvLr37l/z+A== X-Google-Smtp-Source: ABdhPJy31B9jd8x2+ODKURr+v0l0PlcYw7J+gKW1hml1ie40RZUxxljTRMuAI4PltZIlrtGiu/zvHSdpg4EfRLBQuWE= X-Received: by 2002:a05:6512:3502:: with SMTP id h2mr31870226lfs.551.1640982504298; Fri, 31 Dec 2021 12:28:24 -0800 (PST) MIME-Version: 1.0 References: <2F6E4A1B-618E-4CAA-AFAE-9C41609B1B7A@tzi.org> <87sfu9w0t0.fsf@nic.cz> <4ac64047-3acf-1cba-914c-c6cd21267b47@nic.cz> In-Reply-To: From: Andy Bierman Date: Fri, 31 Dec 2021 12:28:13 -0800 Message-ID: To: Carsten Bormann Cc: Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000406b1b05d47703aa" Archived-At: Subject: Re: [netmod] YANG 'when' with absolute path 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, 31 Dec 2021 20:28:34 -0000 --000000000000406b1b05d47703aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2021 at 10:18 AM Carsten Bormann wrote: > On 2021-12-31, at 17:32, Ladislav Lhotka wrote: > > > > It means slightly more work for an XPath processor but is IMO > considerably more readable and less error-prone. > > The original phrasing with ../../../../../ etc. is in conflict with the > powerful maxim =E2=80=9Clet the computer do the counting=E2=80=9D (rememb= er 12HHello World > in FORTRAN?). > > We had the same =E2=80=9Crelative-path=E2=80=9D disease with the original= use of > (non-standard) relative JSON pointers in SDF. Going to (the standard) > absolute ones helped a lot, but actually finding the right node would be > even better =E2=80=94 can=E2=80=99t be done in RFC 6901 JSON Pointers tho= ugh. > > So my brain was just activated to this anti-pattern, and since XPath is > infinitely more powerful than JSON Pointer, I just wanted to know how to > avoid it. Thank you! > > IMO it is not safe to assume that the correct node will be selected using the "ancestor" axis. However the use of relative paths within groupings is probably worse. Perhaps "Relocatable Groupings" is a feature already on the yang-next wishlist? Implicit node-set conversions and other XPath corner-cases can be less safe than relative-expr and equality-expr expressions that compare a value to a node-set. XPath is quite happy to accept an expression and do the totally wrong thing. (It's called robustness :-) As Martin pointed out, relative paths are usually required for testing a constraint within one list entry. > Gr=C3=BC=C3=9Fe, Carsten > Andy --000000000000406b1b05d47703aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 31, 2021 at 10:18 AM Cars= ten Bormann <cabo@tzi.org> wrote:=
On 2021-12-31, = at 17:32, Ladislav Lhotka <ladislav.lhotka@nic.cz> wrote:
>
> It means slightly more work for an XPath processor but is IMO consider= ably more readable and less error-prone.

The original phrasing with ../../../../../ etc. is in conflict with the pow= erful maxim =E2=80=9Clet the computer do the counting=E2=80=9D (remember 12= HHello World in FORTRAN?).

We had the same =E2=80=9Crelative-path=E2=80=9D disease with the original u= se of (non-standard) relative JSON pointers in SDF.=C2=A0 Going to (the sta= ndard) absolute ones helped a lot, but actually finding the right node woul= d be even better =E2=80=94 can=E2=80=99t be done in RFC 6901 JSON Pointers = though.

So my brain was just activated to this anti-pattern, and since XPath is inf= initely more powerful than JSON Pointer, I just wanted to know how to avoid= it.=C2=A0 Thank you!



IMO it is not safe to a= ssume that the correct node will be selected
using the "ance= stor" axis.

However the use of relative paths= within groupings is probably worse.

Perhaps "= ;Relocatable Groupings" is a feature already on the yang-next wishlist= ?

Implicit node-set conversions and other XPath co= rner-cases can be less safe
than relative-expr and equality-expr = expressions that compare a value
to a node-set.

=C2=A0XPath is quite happy to accept an expression and do the total= ly wrong thing.
(It's called robustness :-)

As Martin pointed out, relative paths are usually required for
testing a constraint=C2=A0within one list entry.

=
=C2=A0
Gr=C3=BC=C3=9Fe, Carsten


Andy
=C2=A0
--000000000000406b1b05d47703aa--