From nobody Tue Jun 1 06:36: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 90EC93A1858 for ; Tue, 1 Jun 2021 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 qf0Vu0jEl619 for ; Tue, 1 Jun 2021 06:36:13 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2095.outbound.protection.outlook.com [40.107.92.95]) (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 067743A184A for ; Tue, 1 Jun 2021 06:36:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vm//SAiTUAWZtqKNeoeZJRFuMhijp7tm/onHtQIxgsRFgSQG5yXtu9TZwH+OR66sJOnCemKEWJioxy1cCsLlAVVVc3u7xkf8u5b7tO1VeMS9Vu6bsJuR5Az8ofa1YUGXMB1q+nZLKnZ44WpyW1RLdlSQxg4XPXk09E/uE0uoccPkQJMZW9WChJW4VplPkld1MvLPvxUTBhon8wzHoiL9pTgpYumjzf+luslMWjzHG3fSNqItqe8An2PN4R//nFWGqBoxnNBVz8VDOWop+HkdzKJUFpr/hSQiWn1VvyYDcv1ZdIC82RDocJr8vxu3UjIXkp7EdogVfd70+NghLH2EMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6VE0NngTSaSliacOtY/2Ym7j1yXL7kpbAiRIGQzu5h4=; b=TARdc0AUKDZ8TG5lw81hx0BxiopMYBFIviYZ54EhFtfpNR6VMrC4UbYlDCRCFvN0RGxS7ZH3fe1mxqrxJTKkfVdSInm7WGZ2nTuRj/Ybjhp1TsN7HNcFY3hsEf67xBW7iyzFtiS6In/sS7V6n66M5i8n07kl/mi4KKa0oJwmiarQH+IoMIKua8oQmzU1ik9y/dkV0r/JzrUQuWIAAVcDWGLTzrW7Kgpcv/3KGapuRfvO4gmRr8z30Rw6MxXZKgF3A8yQ2j1WUagUF8frb51SP9R2kFI/AVneCnNNKzkGq2FBilnEIBwGPvUtmOHczbTLnMlq9cxAo/Ei7t8oTGAyvA== 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=6VE0NngTSaSliacOtY/2Ym7j1yXL7kpbAiRIGQzu5h4=; b=jrPmL0a8LIfL2TH39k8wMRaeWqqSJQoYYuI0HxmmgdzxH/I8JaWwIuHNFrAQNmdXl5Cz9S+EIjhhWQlqVmWSK8nTsdWkRdoyDZ2I26oNoF0w5mVmhT9AUITlERIviMop9Jx18e/1eP3GuI7aBf/+bySN33ihRJi0zcmBds2CfQM= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5706.namprd08.prod.outlook.com (2603:10b6:5:155::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20; Tue, 1 Jun 2021 13:36:10 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4173.030; Tue, 1 Jun 2021 13:36:10 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG revision dates unique in module ? Thread-Index: AddW6bSJ5kIwcurNTT+o7cnFFV/8kQ== Date: Tue, 1 Jun 2021 13:36:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 494cc6b0-cd9a-4a3a-8295-08d92502377d x-ms-traffictypediagnostic: DM6PR08MB5706: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: miGUpeNCHMSODXUWxN0+P1go+FrD9f0ygZsEQWbou9VpDHIXxwr822ZnkAJdGLwTXY9ZVSxN7HF3C0VuEl67kXa10WLKySnRXwe8VzTwMqx/80wXqfCLXnzmszugZSeOtGQN4YLfi6qPxzy5f+RYPTy55i57GDh16LT16PaFn7w8/Ey1CKspjAXsj3Was5dOZgGFxtb2rLQMLjWK+znaRIvmBTkkDgDzEzUejYN39xWHVdPHBtA2vyao/hQYubIri9AOkHFNbuRbykxbW+r8tv++0M44Pkh2cFmZR13c+G8owv6qG11ZOPN4seGSAoAooxy9yyQvVxLEVvOBFgBK28DzB4i/igUqI8bccDcORt8mZnwYhNyrCz3HoF8LWNDLbMNY37UVs0gJeNcT0U+IA0PqEdprqUd4dbl+TvAzY+eVCz6p55iv8lsQVfmpTnO0s41pcUxXE9R+fRsGVRfWjg/bzu+kfQ8JSmyAEFjjN6+CvUP/4OTpbAne/sJmr5Cah/iz2ImvnyWVqsIZEqb/Yksaqj1sRKWSP4EQHIHgmLZzQz2ZGVIRSGHuHAl/Ei9JthX0yNGglgi3R9nWKkRpJ/pS6sX4Zogala2xo8RZurvQwyLH/BeSVUZyjmaimiEuNsjN4DdQ6PaEXy3n0TctzaNTuR/RSO8Sqz/4hdtaYlfyRYvB1SDC+O19ymTVKKafc2hX/gcRHjp5WotiBpncFDvbM4Sd1URl0TZhtnO6nxs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(9686003)(6506007)(2906002)(7696005)(33656002)(478600001)(8936002)(38100700002)(316002)(26005)(86362001)(5660300002)(6916009)(8676002)(186003)(76116006)(122000001)(66476007)(52536014)(64756008)(66446008)(83380400001)(55016002)(66556008)(166002)(66946007)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?mxI7A025UDJ+cdI8fp2c8FKKGSlLHFUObkILfMXvSkE45sTMfBUI64c1H5hC?= =?us-ascii?Q?/E+QH+LDE2G+/4JjlZs+4i7vt8Vc3fbkqZ0wmhltf0fF0fr8zbbGImlWLn5q?= =?us-ascii?Q?m0K92Fu5wXeu1LBbJJ/0spiGxE+mOXebGHLkOgWKfvFLHgfs8adXzhTXCju5?= =?us-ascii?Q?x6hhi8nL3j6yCSQLQGP/IE8lpMy3z9brO9VsrYjL/yLR/oTx1XRahbNnmAd9?= =?us-ascii?Q?85OzL/LjJNhjdQMzyzhkstZ79RJWmpvGzwmW9Q5LDMEe3qMTtlUXH+iHxnzV?= =?us-ascii?Q?CHWgC36wOS4JDV8Sk9DpIPD+JIqMwqHqxioGCbfeCSI7KqQMoJfBWS44ikFp?= =?us-ascii?Q?JT0tTul+Hap5AGgoZPxkYA0bvEgCERWzzoGO3GXkuDLw58c6/GUZ3NkfH3BB?= =?us-ascii?Q?om4EcApk6WN8NnjDLK1brrWG2KlPmA2GAaeBEg4ZZBT0PYkTqFcsVurkJD48?= =?us-ascii?Q?M6sTBY7ybpZt5AksmKWaF+U4k/qlz8sbQal5q2fecxXVpycqqVTZ6DSlZVUI?= =?us-ascii?Q?NJFv1ZQork76Ii+lvIkaLS38eNrswcfd/lapgPiHUtvalcy51qelXgPB9xx+?= =?us-ascii?Q?Ru6c8+hGOHjNtUK1b8EBPLnhVY0rVByNAyjMw3n3t/jCPl5DMjOiyvrciWfh?= =?us-ascii?Q?EPwKD1y0AVD8GRl5kYfdotYS4pGysAjiTviP0DXJzixLi/vG6D5XFSKlYfkf?= =?us-ascii?Q?UsR0K4To913U3LpCO/IHoz16YzHMjYkufPQ/sltwQzGrAXBRGKyEGXM8ybgr?= =?us-ascii?Q?szXv4rSO1+LEaz8HrroRjjj3tHnOIEitpp0PWV/P9msJL8ACul6dhEALTLX6?= =?us-ascii?Q?TbQTkbMnc7ktT1CiDLJ5vjzjXTsPPGsLgbVeHmCUpWkgnuccZnFMD4QWShE0?= =?us-ascii?Q?P3DD4ncZN4BAyb49CbEpkRxPqlUVkM4PRRftiAmWFyeF0wNXDi66Ie4lN0RF?= =?us-ascii?Q?GdkUQ6cadENJtv74uQLPSJso2A8EF+M2wFCTkeP5pjJivzRLlX061C2iRs7b?= =?us-ascii?Q?uVJN4vkJFqgGDQNWZpb1UHqKcL20QBQ/gcYbqvKJSCIznsi3yVAPIbl0uvjW?= =?us-ascii?Q?KlJZEgPjGMvZYNhziu5BHAOJtRCvEGLDt1emymeR4hwGajev6GRU4e3SWeZe?= =?us-ascii?Q?QNvi0y+kXw63B2k9UOew4eY/KNWsnsf/qTuYZ9GQM4/XYEaDyYZtzGkb+UAv?= =?us-ascii?Q?g7dZDYI8VWOoRz3vB8E59JR4EyWAd1I/bT8+YQLkoBlQ9WUPs3sIDt4dXHaw?= =?us-ascii?Q?dxEh/KVk5lGNrTmSzs3ZUwIWG+XhXS48frRUhinCmAeigWE+8q3sU/4V7SP4?= =?us-ascii?Q?Sd3EkPi2eGMCAYHFYMvr5eyU?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084CAC59121591A4ACC7B029B3E9DM6PR08MB5084namp_" 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: 494cc6b0-cd9a-4a3a-8295-08d92502377d X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2021 13:36:09.9820 (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: ciXheDKft3LdP51umIGicg7V+pi5CTZWeAj7cCedFbs3aUO7M+esivkC/RYVhIRg2ui0G/9WBB4DM0rgBamXSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5706 Archived-At: Subject: [netmod] YANG revision dates unique in module ? 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, 01 Jun 2021 13:36:19 -0000 --_000_DM6PR08MB5084CAC59121591A4ACC7B029B3E9DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In our YANG versioning work we are proposing that a revision-label is uniqu= e and the revision history of a module must not contain the same revision-l= abel twice. We're debating whether we should state the same rule for revision *date* as= well. RFC7950 doesn't seem to explicitly say that revision date must not be dupli= cated in the revision history. This issue came up recently in an OpenConfig discussion here: Updates to OpenConfig types modules. * openconfig/public@f20ed84 (github.co= m) Was it the intention of RFC7950 that a revision history should never have t= he same revision date twice ? I think it is somewhat inferred from various drafts that describe how a mod= ule name + revision date uniquely identifies a module revision. But it does= n't seem to be explicitly stated in RFC7950. If we disallow duplicate revision dates, that makes the module-name+date tu= ple unique, but it does mean that authors can't produce 2 versions of a mod= ule in the same day. In theory we *could* do something like this: - require unique revision-labels - allow duplicate revision dates But in that case, only the module-name+revision-label can be the unique ide= ntifier for a revision. Jason --_000_DM6PR08MB5084CAC59121591A4ACC7B029B3E9DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

In our YANG versioning work we = are proposing that a revision-label is unique and the revision history of a= module must not contain the same revision-label twice.

 

We're debating whether we shoul= d state the same rule for revision *date* as well.=

 

RFC7950 doesn't seem to explici= tly say that revision date must not be duplicated in the revision history.<= o:p>

 

This issue came up recently in = an OpenConfig discussion here:

Updates= to OpenConfig types modules. · openconfig/public@f20ed84 (github.co= m)

 

Was it the intention of RFC7950= that a revision history should never have the same revision date twice ?

 

I think it is somewhat inferred= from various drafts that describe how a module name + revision date unique= ly identifies a module revision. But it doesn't seem to be explicitly state= d in RFC7950.

 

If we disallow duplicate revisi= on dates, that makes the module-name+date tuple unique, but it does mean th= at authors can't produce 2 versions of a module in the same day. In theory = we *could* do something like this:

- require unique revision-label= s

- allow duplicate revision date= s

 

But in that case, only the modu= le-name+revision-label can be the unique identifier for a revision.

 

Jason

 

--_000_DM6PR08MB5084CAC59121591A4ACC7B029B3E9DM6PR08MB5084namp_-- From nobody Tue Jun 1 06:44: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 66F943A1895 for ; Tue, 1 Jun 2021 06:44:31 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Z3jzozqdqb-9 for ; Tue, 1 Jun 2021 06:44:26 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2041.outbound.protection.outlook.com [40.107.21.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 A5CBC3A1894 for ; Tue, 1 Jun 2021 06:44:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oaD9tvgf2VWPYteTWZsmSECAUYb9rwkklr0bvpwncaAwFq0Tkyi1ffHug7qhts7cHutMVFdEGy0+3cMCFS4BowyYelqhVHGGIxQmbKJgXvo4VAXKMNjKmobgNpEUoE2KgajDh6qa9VBzHCON/iTmggEHC8dZ7zJketvV9L2uE6fHFh7CJEN9uBPITfRfQ/HdJsV+YylReE8HHsc9bT3nuOxo2Gl7Wa5q49DRktK4UBpyevfk21yEv8Eb3hIm4MjzEN0TWGOq9qZBiO1E8PV3pTrM3eutU9ine4WPzzzryg5CCslaj3fqVDXo8EtKQXhNuxhrTcSPmcp52RIyLsb4uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SdXdEviMXFpIQ59ezTpOcBG0/XnxeZVUqFPQMgTXjTg=; b=ROcWa2U4q+p7wLDJFw5B7+0N2GgbFlSItx53Uq2Fvh8vHiykBSCfgaGQWhLv6UyqKdPKxxC9Yu3K9piaoJk6OR/ojk4lzf2YOY0Rg7EUWZdvxGWeQXE8NNKMQBuwuTRMCilWP1zgOfJmmJebKRefHdwRUwYIU2J06jRrUtV1MDfvuKRzsi1ZMfrH1bDVWkMeH4k9tQpCTytgeIBo6ppsL12Wy5/PxpBYwHy4xqR6wpLE/2EhXgETvZ1mpzH6OX9MkGwwCtvCg84mAzV7s8jybouMPLX4xVYHn/SKdE8YrQP2j6WbikH/vYyE5V11MR2xdSnz0GpdpS49girROBwENQ== 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=SdXdEviMXFpIQ59ezTpOcBG0/XnxeZVUqFPQMgTXjTg=; b=aKs4z8JUSWY3/EcmOiz0r6Mb+w20G7nNgGOZq7ngj0jqLquetb5fCWEG03iOPIrurw+IarVD5UwkpmNtROhtUz+A3vJmPK/E//Ph2mocRSYVf21RN+8Z6N8Ft5YesiNctUwO/Z0kCNVf5TLU4niRHyEhos0FpiVI3sbdaUn1lKc= Authentication-Results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:65::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.22; Tue, 1 Jun 2021 13:44:23 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4173.030; Tue, 1 Jun 2021 13:44:23 +0000 Date: Tue, 1 Jun 2021 15:44:22 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "netmod@ietf.org" Message-ID: <20210601134422.cmftmzgqhk4p3k2l@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR0P264CA0272.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1::20) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR0P264CA0272.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20 via Frontend Transport; Tue, 1 Jun 2021 13:44:23 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b3a3369c-2371-45b8-360c-08d925035d90 X-MS-TrafficTypeDiagnostic: AM4P190MB0004: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: GfQwEsrCtA2cdPM5CU9R5/hMscyTui0bYaJK7SmQg+mBQIf9q1dukTxT+X6NwhCoYwcBTbDiyPvl7meWBXE1Gm4kwujfKFXsCUM4s4Jku4TOmeBaYrk/k+Dcrt/X0RdX6GEXnz/nu+RnUGAKA991d3ODJg0rRLAs4M/1ZSO1Is8kwXAK77G7GQCpw0L/sEzUKEzvI0CWAU2qhc3MiT1ltsW0v+RDOGiB+n3Jbq6fObXqXuclpG0J/G6Na0oYq1TzfwUWC2fOwBrk8dD20bbXc+cWegohZ5qh9oa8adKOzbIYaZxTDud33bvLfJBlwaqI9/IRnbtvsurkXGYSDjM0qFWvHvN0XvEO4jTZ+7VI8g/6PdthVlEc3KpvNusfAuXOtN44dBe5v5afuTRBw0O8i/BemHNLYzUdpN8H72yG5xtknLh9DAjEHQNM/QIrPTiiQagesNJ19Wo2lwatQRntpF4vvA11S6aMRWe4NUYWGOOUY89iiRUaWTh/It9+6WAnqEREbu/kVKjueHrjnjS7pRVE2g2U+Hyac5+E3pWQC87M+iMtru4bgnyeNrZzebu1U+rLgaxwVH06RGYMhKDAHCZdA/hSk3pD8Su01AG9XFptf1rNP83955MBEQNtWiHFQIlNbnwbNkZYTqHp/tlu6zWKragHWFRFJRAhLrntAIBG2N3VE3cEZyDzTR/ZEHcIZ3Gd/TYfTAvXNysEst48suuu5DzrgsCNx+dX2nq8om57ElrD3KXT2Q5VRHIvI69Xa7e1kq4PwAKOBNu4l39AiwTiqDN3grCxAwKoWo44CYlhiQNchtjPpX7ySjHJ3lbc X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(3450700001)(26005)(8676002)(8936002)(83380400001)(498600001)(186003)(38100700002)(4326008)(86362001)(1076003)(6496006)(956004)(52116002)(6916009)(16526019)(2906002)(66556008)(6486002)(66476007)(966005)(66946007)(296002)(38350700002)(5660300002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?WFW8DESjaXNRsbVPD9I1NrZGDZRRxRudi0ySa4jgvE5k3GfUKHpvwFz84xYt?= =?us-ascii?Q?UvPJOcoQYF+Ti9LoOO/RiKzAiRAXJ69PzvPaJ1EVyXKne7tw5XbR1q7It1Cq?= =?us-ascii?Q?DpaSMeo+CqDQ8d1K3phL2DQCNe6WrV/LbmjMqmnHI2GWA6xeHDEVOecHz0Gg?= =?us-ascii?Q?OtfA4GI3F59WSsb8R5XP1qNt9TO7IhsSRypcOY+lcXNJFEwghyPqr0VXOaJG?= =?us-ascii?Q?QFr4zKdN4ROBq8dG89/2ugN8iIU5lmtoCKdOw5/QbCOUHFpx+1v25SW3nSIl?= =?us-ascii?Q?8Xo+Q49xk0IWi30DMaSpvkIcv6abkOkkO44h+2dv34bZy/aB9acbsu7sptS8?= =?us-ascii?Q?XdTUhDdAMVkdKcT27zhQIpG4KrChFLatGwePd/NMV22lWwnsnqyM9T3QunRd?= =?us-ascii?Q?8pFYNmzWCr//LGsgpvGl8xwgC0H4qEQHr4Iug9Nbm9oc6VJOTWmpTev/vDXQ?= =?us-ascii?Q?KTXkN81GsOl835Iht/jadLg1uWtt+NPAeWCTshPN2Frg9N4pbfztnYuYLcRx?= =?us-ascii?Q?sBv34LY9oYfGUYBgpQ6+n0HW64rby3LE1ex/xyjxvlkp/w6t7P3YO0vp5qRS?= =?us-ascii?Q?9xmmbkQZ6kV8DecT0jOc8l+BG8ChPyD9gnuDUWmiGaBpm4ycpaT+XhAe00zz?= =?us-ascii?Q?cTLDbCkDn0YGC7/Aj9nFwVODAeaKhHW4ZXz9/8dkaOoe+zm+ExEEofr/m8E3?= =?us-ascii?Q?Z1PvL1MGkdO6qaCCPil9U7DTwFu3InZgIgjA3rajsbuCXl6WgA0Jc4FXwDiQ?= =?us-ascii?Q?RfvOL8Si0vlOoFc82h3NeNtUBHcX6VKOd7FU0XhHQb6XYmUVkYkyHoUsQm6S?= =?us-ascii?Q?53E/z00OGHaEGesFjpl2hpDf0KLmmO3aCfPE5j+eiHxjTmodE711VOQSeSGZ?= =?us-ascii?Q?E+ULkHDFjljNhYqEW3qrOCh1V5FuMtoXiDEaHdLeHZc9H6Gj6WHd0j3LKn/A?= =?us-ascii?Q?o8UIUqPVJkWrxjTP2tLFEBdEWlj8WQd3aFv9O9FZyAdw8+AeXyEYNSyk6Ekm?= =?us-ascii?Q?RV5hyHMstObeoP1UwiaNOu480KX1AgZz4xTm/Xz+ndw06JKXVdDWSiZRahxB?= =?us-ascii?Q?t/sX3zQMT1l+EZo3xcF2yDDTkpyniBaB+1ryR+ID5qrqps1wcW0wDQj+qThO?= =?us-ascii?Q?lbidmJSsIHiRLnwflfBIdhA+0pzrJcjxPAjkr5z9V2zT0YP7smlpVWPI+fNG?= =?us-ascii?Q?h06G+Ebwdgn5LHACa3QeKv8HmJBAlgD4TcQHGKuNS9ZA9XnBsWYolnWM08dT?= =?us-ascii?Q?0737Pm2A+nbUBvzbWH6wzUhepaCaBc5kVMZ6HDF9ouEwd5ZzH9XP2Own0a/c?= =?us-ascii?Q?pOLKsgJTf0KPYUW9a2jJro1i?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: b3a3369c-2371-45b8-360c-08d925035d90 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2021 13:44:23.5851 (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: xRoVjyK+OUh0egUPU9Mkn4klIuvGIV22qqJG3aQsnS5r6vaIwCIhfF41tQhD3VATdMWc7A63XUklimjGpfpIIsDKdcHy+axefXoniQUbHz0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0004 Archived-At: Subject: Re: [netmod] YANG revision dates unique in module ? 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, 01 Jun 2021 13:44:31 -0000 The assumption back then was indeed that an organization would not _publish_ two revisions on the same date. Note the choice of the verb 'publish', which is not to be confused with edits made during development, at least back then we made this distinction between module development and module publication. /js On Tue, Jun 01, 2021 at 01:36:09PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > In our YANG versioning work we are proposing that a revision-label is unique and the revision history of a module must not contain the same revision-label twice. > > We're debating whether we should state the same rule for revision *date* as well. > > RFC7950 doesn't seem to explicitly say that revision date must not be duplicated in the revision history. > > This issue came up recently in an OpenConfig discussion here: > Updates to OpenConfig types modules. * openconfig/public@f20ed84 (github.com) > > Was it the intention of RFC7950 that a revision history should never have the same revision date twice ? > > I think it is somewhat inferred from various drafts that describe how a module name + revision date uniquely identifies a module revision. But it doesn't seem to be explicitly stated in RFC7950. > > If we disallow duplicate revision dates, that makes the module-name+date tuple unique, but it does mean that authors can't produce 2 versions of a module in the same day. In theory we *could* do something like this: > - require unique revision-labels > - allow duplicate revision dates > > But in that case, only the module-name+revision-label can be the unique identifier for a revision. > > Jason > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 1 07:20: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 647893A19B9 for ; Tue, 1 Jun 2021 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8DX4Ww82kdZ for ; Tue, 1 Jun 2021 07:20:44 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2108.outbound.protection.outlook.com [40.107.237.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47D23A19B6 for ; Tue, 1 Jun 2021 07:20:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TixWr9nsw1h7JKhpRw/iD4ZJxzoMcGVfrhGTcuHQ1gPONnyS+ePohACV0p/VpfQpIK2bgMQphbViBuQPQcuOygXmGFX3kD2ArOethhmUeNbGJzo3OZ1veYX17IYkHk/DJxt6LO4cXJHrHUdiJQbPqBkEDJfU0JC1PPk57Slp4I3f4xVZejJJj+Gd1fqnIWBD4ymBFB519Tlr8rzT0i/lVCiFy3Yhf/SNruNIwzNwmfO0gSnGwa4S5cvszYs2MoNjocO//WIsFxAlTOQFyNwDcWmp4X1nBe7WV+IYds3X1VVQoxOfi6S5Q2VN5IwvWACXzBGpM7A6gKs217ik5WwioQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gxcQuVOebNNNRYxgAGDxOi8y68yB8Ryv9xW7oBBTyQ8=; b=Y+IGrkzGYdYDg8S4KBvWPbAI6Prlg/bt+QRwmHcQPf6NF2gYCqYmHDqBH+OCheXkldGUK0rP3xmeWR2tqg5647C0i++PiwvVBvSRqnzZA2rosfeWAEHTECjnbJf33gas0U4sMFoOnwC5AoL0yQcLI9leqniX4Z2jS3Gae9BwK5s2hDVPdmzqJ2+1PVW7NNOkWZ+57TAnFA5ya5WdX/Gxfs7HNULXQH40wAnnt6e1vlxDG4uZTa5pLtEioFuRJ9gwnuOir1Qcu5iyBdAGdiUL5L6K7lkOgC/hp7GUT2S7A7VLpmZK1tLwtU9HNrII3TbteltGZoSP/MPvxPHoE8AUqA== 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=gxcQuVOebNNNRYxgAGDxOi8y68yB8Ryv9xW7oBBTyQ8=; b=J5j3VG+iZs46l1g2ScpkewRRi+EGJbYsn5vDyZwpMxTgavmND71ljetXLPPNBOp8rAjQKeq91q4GRIFrrbJIiRQzzA4l2FDSGaRhIvUc0gxktXUghVGS34oS9POISjr6rwT+wS0TxD54UA4fu54HE1TtLXSdj0UF/T5t8tz5AAk= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6313.namprd08.prod.outlook.com (2603:10b6:5:1ea::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.21; Tue, 1 Jun 2021 14:20:41 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4173.030; Tue, 1 Jun 2021 14:20:41 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-06-01 Thread-Index: AddW8STyPfig1S0sRLq9gIn+IjVqnQ== Date: Tue, 1 Jun 2021 14:20:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b52b7d4-4a96-480a-caed-08d925086f88 x-ms-traffictypediagnostic: DM6PR08MB6313: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c7MxlhO6YVDluzrlGpVkj1gKc5DD5ZvcIZaCNWj2od0no25V+TbccJrsfdhU60g6qJujZ83FSnHtK0zJFkIo3u4aN9Uf1D0g2foRxMIozoJMljUJREttHWh5cH0MfJOHYJjlYl7oCCNlAziqBXGp8TPRo2SsXBJdb+h6V3odp//2rEdqlFZjelJLukHLUZO/B63tSk6gtqPBr3UvhI2rVnr/6+z7rsF5CZQb1LcX5Vo7oALCVgIXdhsUwoU03/vX4apSUQX5/G1vTfpLy7znbK/qmuGySYRPKabPphxkPIqyha4xHnP7yXjULBIxk0KdydNEORAStSKInLbQi30DMjJ5HCsRP2Y0kubwPvZHVywaTVu0vA8zS9hQb6LIj9H25u2lxdjhbWQ5fg92WKSRBHnbqe8Othld4oqfQxfvlkR5jNr8NFwHm2BSTuamID37HC30ISF7xrxNzm2Td8TPWaicJBS7ixySVUGXWmWkTog5psGdo84lqxkAk58ooBt9FBtI11RIdibjzs6QHFjc+OJVarTMLzE9wPWuf6vSNWcnFN6gTKYQH1Np4Da80uhQlMWMJTfIszztSDyzdpE4KV2higdr2njZvL3KHCX6x5mfJQpOOZpIL3wvKt2qFgHmLlL+D2jQV/qqvZZDl7do2QRnGNpGvMRftuZJ2xgoop6Oo+zh49ED5hsJ2YTQZehY4m3dgaX101knltUFAtqzFaRkAz80712MpHgWzuMPV3g9Po0pt1XXn3sZ9C3a/sj7 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(366004)(39860400002)(396003)(52536014)(83380400001)(86362001)(26005)(64756008)(8676002)(71200400001)(6506007)(16799955002)(478600001)(2906002)(55016002)(186003)(38100700002)(8936002)(6916009)(966005)(7696005)(66476007)(316002)(5660300002)(9686003)(66946007)(66446008)(76116006)(66556008)(33656002)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?mWKQt52aw2OmPTtYZmJv044ByvH/HmKsgNbbZuX7y1OMnic8DlELqZNqW1gH?= =?us-ascii?Q?7YrrmBwawRMfUAEEEPz/LVYBXbR1xDvy+n1lw7/h0Dc03xqXETWpwMvEodBx?= =?us-ascii?Q?jskw0fs1M7f0wNik0nBaY6RLaHC4T8H1Wb/QFL/zaZ6xwEK/Gq/28W31JOy2?= =?us-ascii?Q?h7XI2Y9Df6OEmIQ35HhhvcYZsP6vynjvsRJPAeEVuRG9Sk6lN128bAmZmrs/?= =?us-ascii?Q?UXEQUzFZOurBvLpOQasSfktz8phyrj0wBHOEyi4Jru+PPGt8xa4A6XeBR1aO?= =?us-ascii?Q?9mnNoXaL5F+sUBpjKaLrBuAfaG6qPDjirBoFEr5M77ScB723jWZZEJXiefkV?= =?us-ascii?Q?DvhO5Tk68Sibhxen+LBkYUXP7lfXIHTrWvgUO1KJwlSQlEbZb654N0Mt0W1o?= =?us-ascii?Q?d+IHtllCRR35xfOpUz9kcufB+lWo70nHpCLODscPhZxXjyVKWBP8pd8foTAY?= =?us-ascii?Q?eO1qVRBwzKKAHGi+9rqQkO37Qp3ms21UcZ2hwSwOLabTtBXDT9XeGik1TnQM?= =?us-ascii?Q?uRXrO9gSwgzVTuZUw332gWIY7dIRvl5X9JCmvH8zXNVkPCfnWoOCPT9RFYF/?= =?us-ascii?Q?iHMvNs2Qb9TxOHUo4k0ifQI2xo6HwOkqUXdzdIajYq7A7+wxFVIRBMkMWKpf?= =?us-ascii?Q?VBcxb/UxZBrZ5ODtDoeFb9InMzs1X3L8ny0cNKNq9LmtrRWIjdV260FoVGbm?= =?us-ascii?Q?ihLQ2IjJZGRfIWw8MYDOl9EYO+RsSEeUKPCVlwbVsuMPWw1D5F9R1NLUBduA?= =?us-ascii?Q?ovICOoKe1KN0bKB3P5XOEenbjmnpLJbC9UJ//VuMvpva0H1VXakvHkD1ZGpe?= =?us-ascii?Q?fW59YrgN+hjIRJ4pTzW8q3liKIVe2Hru+qzKVN3dYthaWqMtJMgVxZkn+BAo?= =?us-ascii?Q?5lWwWMMSZrcCF0Fp5mM/Xs78xQwGsRtweAdaAV+Z1CxUBfsnKoXLSs4jz+HQ?= =?us-ascii?Q?+YFuxrHiCDAvkiSc+Vz5+Yxw76Drg/209j+QWJMt7ZR4ovYttjKlqCG9Pv8q?= =?us-ascii?Q?eUkacepd/2s5onr/fF5QKBYhl5fAKAZcGgTMf/CI5rI/Gtr0Z/2/nBJ/aVg9?= =?us-ascii?Q?rqBGVVTNg3XHpt+SlbvM1mm2UK2Tq4veWWbqFYF8wa2AH/HFW49VkqbNq4/k?= =?us-ascii?Q?7L0yfTPeK4KxGrTVgSduMmHMiG4A4gRJiVsKC4raRz3ag7zBHRNn3Fd12tNK?= =?us-ascii?Q?eajOkUI8Vp6U32aNvXm6IKY42itGiljw+AnJXOoU/aUgCKiLqq5stAl3UvdW?= =?us-ascii?Q?VJKvztPxmgQmGXPcg+o0voL063l6gUjOMTAfn/iQHyJjnfltlEOb+Zvtx6Aj?= =?us-ascii?Q?RFpeKOskKd3fEQFN5f6wPoG9?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB50840E16F504D22E75A9D31D9B3E9DM6PR08MB5084namp_" 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: 2b52b7d4-4a96-480a-caed-08d925086f88 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2021 14:20:40.9588 (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: 9F1OktSJo4Uk0qav60yfpbGbYtJRZqpB3IWqnqqbMQPCj6SrOT8jXL6FFBMwrAMNQfVKXD8c2TTHfm4RNbT6Hg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6313 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-01 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, 01 Jun 2021 14:20:48 -0000 --_000_DM6PR08MB50840E16F504D22E75A9D31D9B3E9DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-06-01 - YANG versioning - extensions - Reshad: integrate the text from the email thread from May 18 - Jason: create a separate issue for submodule vs module (Jan: what does= 7950 do ?) - ISSUE 83 - Jason: summarize the final changes - All: Need to review the draft (after Reshad's final updates) top to botto= m before LC ready - duplicate revisions - no revision label twice in the history - Jason: ask WG mailing list if revision date can appear tw= ice in a module history Next meeting: 1) identify any last missing updates or issues from Module Versioning 2) move onto YANG Semver draft: - start with reviewing feedback from IETF110 (https://datatracker.ietf.= org/meeting/110/materials/slides-110-netmod-yang-semver-00) - then go over GitHub open issues ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB50840E16F504D22E75A9D31D9B3E9DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-06-01

 

- YANG versioning - extensions

   - Reshad: integrate the text from the e= mail thread from May 18

   - Jason: create a separate issue for su= bmodule vs module (Jan: what does 7950 do ?)

  

- ISSUE 83

    - Jason: summarize the final chan= ges

        &nbs= p;      

- All: Need to review the draft (after Reshad's fina= l updates) top to bottom before LC ready

 

- duplicate revisions

     - no revision label twice i= n the history

        &nbs= p;       - Jason: ask WG mailing list if revi= sion date can appear twice in a module history

 

Next meeting:

1) identify any last missing updates or issues from = Module Versioning

2) move onto YANG Semver draft: 

    - start with reviewing feedb= ack from IETF110 (https://datatracker.ietf.org/meeting/110/materials/slides= -110-netmod-yang-semver-00)

    - then go over GitHub open issues=

 

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

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

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

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

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

Tap to join from a mobile device (attendees only)

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

--_000_DM6PR08MB50840E16F504D22E75A9D31D9B3E9DM6PR08MB5084namp_-- From nobody Tue Jun 1 07: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 73F553A1AA4 for ; Tue, 1 Jun 2021 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTOy2AmEbD-f for ; Tue, 1 Jun 2021 07:42:24 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9211B3A1A83 for ; Tue, 1 Jun 2021 07:42:24 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id 131so19597983ljj.3 for ; Tue, 01 Jun 2021 07:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tPLYuS6sL2NC19AWZSkc/PJ5LZyK3eoj06iGAePF1mQ=; b=i1WdPCkcJI4bWT+nrvJ8BSQ2kHMYAfzdsQRQ3466POkNe8HpoTzIevLx/nbPkI7fYn NYpUUpWk3SyQoFRihbSbfSn1nuzAZedxAlhIXzdNEd6UpE2Ur8J09R26ckBOdSb75Leq A4LMCEWoVdcXU4n40T75ypG7xOEjbq8hSD7K/PesEOSW6q7gFjwl/0IWJrrevYHSdl72 utGP5EgzAA5KCRSohBRvXaUpP5go/Bt3PoDLQCWRx6eBvlYa6k6lBgocEVQ6g3yRILIl TxFfwytLkn5SE5UTYM8KOQw9Utn2WaQl5XA4i75wRBID4QhT6pYaGYQjA+sMPJZb9O+r UV6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tPLYuS6sL2NC19AWZSkc/PJ5LZyK3eoj06iGAePF1mQ=; b=sCRxRWO6snT7WLZG7tryYzEdT3veERGOcshc52LldvU+1KeSc5fCg5uZNwLe8rV4TM 7v0zQwq/N79w7O+W52aI421EaKXBeFxRafvJ5iuoKwQpXXUO4gV00Cd4BunePrEtaNIy sZer6opsg0yDKoxkhBkRHg898iP3v/HjgB8Lb1/j7wB/Q+3K+jEDFuP5xSLGHXPe98k0 7HYkS42oNL3Ie9fX6L6Sv5DWxnBl9jHRStMFKF35vJ80aRCYykh3U1KcZXyDTkIj5Z78 ZNidh4SPy9imz5t3Do+FaMANSnWVW95gpdswaK2IS0wqZ6AZ8UxbZIiT07NWfpaqso5N +rLA== X-Gm-Message-State: AOAM530DaGAS+ismnFDo6kzhziGutkqLIL/4ox0tj09mu7zTWha/qNVy J1qmKI4sKmEGR5ATN9SWu7Ww4BBV5R/lj1IlUYSbniFLDZ6DaA== X-Google-Smtp-Source: ABdhPJw8ndqCoY88oIZ53ZP5WKEQv/WzzPyaTYdfoUHXttMvjqynILqg7Fqcn6GMZN+0HZOjM4i1Z7b4Os9b7ZX2Djg= X-Received: by 2002:a2e:7e06:: with SMTP id z6mr21132977ljc.55.1622558537375; Tue, 01 Jun 2021 07:42:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Tue, 1 Jun 2021 07:42:06 -0700 Message-ID: To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003f73b505c3b5591c" Archived-At: Subject: Re: [netmod] YANG revision dates unique in module ? 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, 01 Jun 2021 14:42:37 -0000 --0000000000003f73b505c3b5591c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 1, 2021 at 6:36 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.sterne@nokia.com> wrote: > Hi all, > > > > In our YANG versioning work we are proposing that a revision-label is > unique and the revision history of a module must not contain the same > revision-label twice. > > > > We're debating whether we should state the same rule for revision **date*= * > as well. > > > > RFC7950 doesn't seem to explicitly say that revision date must not be > duplicated in the revision history. > > > > This issue came up recently in an OpenConfig discussion here: > > Updates to OpenConfig types modules. =C2=B7 openconfig/public@f20ed84 > (github.com) > > > > > Was it the intention of RFC7950 that a revision history should never have > the same revision date twice ? > It seems that way. How would the duplicates be distinguished within a server? The server cannot advertise "foo@datestring" twice. Import-by-revision cannot identify the 2 revisions with the same date. Andy > > I think it is somewhat inferred from various drafts that describe how a > module name + revision date uniquely identifies a module revision. But it > doesn't seem to be explicitly stated in RFC7950. > > > > If we disallow duplicate revision dates, that makes the module-name+date > tuple unique, but it does mean that authors can't produce 2 versions of a > module in the same day. In theory we **could** do something like this: > > - require unique revision-labels > > - allow duplicate revision dates > > > > But in that case, only the module-name+revision-label can be the unique > identifier for a revision. > > > > Jason > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000003f73b505c3b5591c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 1, 2021 at 6:36 AM Sterne= , Jason (Nokia - CA/Ottawa) <j= ason.sterne@nokia.com> wrote:

Hi all,

=C2=A0

In our YANG versioning work we = are proposing that a revision-label is unique and the revision history of a= module must not contain the same revision-label twice.

=C2=A0

We're debating whether we s= hould state the same rule for revision *date* as well.=

=C2=A0

RFC7950 doesn't seem to exp= licitly say that revision date must not be duplicated in the revision histo= ry.

=C2=A0

This issue came up recently in = an OpenConfig discussion here:

Updates to OpenConfig types modules. =C2=B7 openconfig/public@f= 20ed84 (github.com)

=C2=A0

Was it the intention of RFC7950= that a revision history should never have the same revision date twice ?


It seems that way.
How would the duplicates be distinguished within a server?
The server cannot advertise "foo@datestring" twice.
I= mport-by-revision cannot identify the 2 revisions with the same date.
=


Andy

=C2=A0

I think it is somewhat inferred= from various drafts that describe how a module name + revision date unique= ly identifies a module revision. But it doesn't seem to be explicitly s= tated in RFC7950.

=C2=A0

If we disallow duplicate revisi= on dates, that makes the module-name+date tuple unique, but it does mean th= at authors can't produce 2 versions of a module in the same day. In the= ory we *could* do something like this:

- require unique revision-label= s

- allow duplicate revision date= s

=C2=A0

But in that case, only the modu= le-name+revision-label can be the unique identifier for a revision.<= u>

=C2=A0

Jason

=C2=A0

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--0000000000003f73b505c3b5591c-- From nobody Tue Jun 1 12:31: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 70E633A2495 for ; Tue, 1 Jun 2021 12:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-6WNX31luH9 for ; Tue, 1 Jun 2021 12:31:17 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F953A2499 for ; Tue, 1 Jun 2021 12:31:17 -0700 (PDT) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Fvhth19DZz6P40h; Wed, 2 Jun 2021 03:24:44 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) 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.2176.2; Tue, 1 Jun 2021 21:31:13 +0200 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2176.012; Tue, 1 Jun 2021 21:31:13 +0200 From: Italo Busi To: 'Andy Bierman' , "Sterne, Jason (Nokia - CA/Ottawa)" CC: "netmod@ietf.org" Thread-Topic: [netmod] YANG revision dates unique in module ? Thread-Index: AQHXVxhsezsIj7lHy0yd2lBkuPNQYar/h3vg Date: Tue, 1 Jun 2021 19:31:13 +0000 Message-ID: <614a0780b8ca4030a3d6b02897977c38@huawei.com> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.88.123] Content-Type: multipart/alternative; boundary="_000_614a0780b8ca4030a3d6b02897977c38huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] YANG revision dates unique in module ? 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, 01 Jun 2021 19:31:23 -0000 --_000_614a0780b8ca4030a3d6b02897977c38huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWNhbGwgSSByYWlzZWQgYSBzaW1pbGFyIHF1ZXN0aW9uIGluIG9uZSBvZiB0aGUgcHJldmlv dXMgbWVldGluZ3MgKGluIHRoZSBjb250ZXh0IG9mIHRoZSBZQU5HIGZpbGUgbmFtaW5nKSBhbmQg dGhlIGFuc3dlciBJIGhhdmUgZ290IGlzIHRoYXQgdGhlIHJldmlzaW9uLWRhdGUgaXMgc3RpbGwg cmVxdWlyZWQgdG8gYmUgdW5pcXVlIGZvciBhIGdpdmVuIFlBTkcgbW9kdWxlDQoNCklNSE8sIHRo aXMgcmVxdWlyZW1lbnQgd2FzIHZlcnkgcmVhc29uYWJsZSBmb3IgYSBsaW5lYXIgbW9kdWxlIGRl dmVsb3BtZW50IChhcyBwZXIgY3VycmVudCBSRkM3OTUwKSBidXQgaXQgd291bGQgaW1wb3NlIGFu IHVubmVjZXNzYXJ5IGFuZCBlcnJvci1wcm9uZSBwcm9jZXNzIGZvciBwYXJhbGxlbCBtb2RlbCBk ZXZlbG9wbWVudCB3aGljaCBpcyBlbmFibGVkIGJ5IHRoZSB1c2Ugb2YgcmV2aXNpb24gbGFiZWxz DQoNCkZvciBleGFtcGxlLCBsZXTigJlzIGNvbnNpZGVyIGEgY2FzZSB3aGVyZSwgYWZ0ZXIgcmVs ZWFzZXMgMS4wLjAsIDEuMS4wIGFuZCAxLjIuMCBoYXZlIGJlZW4gcHVibGlzaGVkLCBhIGJ1ZyBp cyBkaXNjb3ZlcmVkIGZyb20gUjEuMC4wICBhbmQgdGhlcmVmb3JlIHRocmVlIGJ1Zy1maXhpbmcg cmVsZWFzZXMgKDEuMC4xLCAxLjEuMSBhbmQgMS4yLjEpIG5lZWRzIHRvIGJlIHB1Ymxpc2hlZCAg 4oCcYWxtb3N04oCdIGF0IHRoZSBzYW1lIHRpbWUgd2l0aCB0aGUgc2FtZSBidWcgZml4DQoNClRo ZSByZXF1aXJlbWVudCBmb3IgdW5pcXVlIHJldmlzaW9uLWRhdGUgbWFrZXMgdGhpcyBpbXBvc3Np YmxlIGFuZCB0aGUgZGV2ZWxvcGVyIG5lZWRzIHRvIHB1Ymxpc2ggdGhlc2UgdGhyZWUgcmVsZWFz ZWQgaW4gdGhyZWUgZGlmZmVyZW50IGRheXMNCg0KSU1ITywgbW9zdCBvZiB0aGUgcGVvcGxlIHdp bGwgbm90IGZvbGxvdyB0aGlzIHJ1bGUgYW5kIHB1Ymxpc2ggdGhlc2UgdGhyZWUgcmVsZWFzZXMg 4oCcYWxtb3N04oCdIGF0IHRoZSBzYW1lIHRpbWUNCg0KVGhlIHJldmlzaW9uLWRhdGUgdW5pcXVl bmVzcyByZXF1aXJlbWVudCBjYW4gYmUgcmVsYXhlZCBpZiBhIG1vZHVsZSByZXZpc2lvbiBpcyBh bm5vdW5jZWQgYXMgImZvbyNyZXZpc2lvbi1sYWJlbCIgaW5zdGVhZCBvZiBhcyAiZm9vQGRhdGVz dHJpbmciDQoNCkl0YWxvDQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdv cmtzLmNvbV0NClNlbnQ6IG1hcnRlZMOsIDEgZ2l1Z25vIDIwMjEgMTY6NDINClRvOiBTdGVybmUs IEphc29uIChOb2tpYSAtIENBL090dGF3YSkgPGphc29uLnN0ZXJuZUBub2tpYS5jb20+DQpDYzog bmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFORyByZXZpc2lvbiBkYXRl cyB1bmlxdWUgaW4gbW9kdWxlID8NCg0KDQoNCk9uIFR1ZSwgSnVuIDEsIDIwMjEgYXQgNjozNiBB TSBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkgPGphc29uLnN0ZXJuZUBub2tpYS5j b208bWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0KSW4g b3VyIFlBTkcgdmVyc2lvbmluZyB3b3JrIHdlIGFyZSBwcm9wb3NpbmcgdGhhdCBhIHJldmlzaW9u LWxhYmVsIGlzIHVuaXF1ZSBhbmQgdGhlIHJldmlzaW9uIGhpc3Rvcnkgb2YgYSBtb2R1bGUgbXVz dCBub3QgY29udGFpbiB0aGUgc2FtZSByZXZpc2lvbi1sYWJlbCB0d2ljZS4NCg0KV2UncmUgZGVi YXRpbmcgd2hldGhlciB3ZSBzaG91bGQgc3RhdGUgdGhlIHNhbWUgcnVsZSBmb3IgcmV2aXNpb24g KmRhdGUqIGFzIHdlbGwuDQoNClJGQzc5NTAgZG9lc24ndCBzZWVtIHRvIGV4cGxpY2l0bHkgc2F5 IHRoYXQgcmV2aXNpb24gZGF0ZSBtdXN0IG5vdCBiZSBkdXBsaWNhdGVkIGluIHRoZSByZXZpc2lv biBoaXN0b3J5Lg0KDQpUaGlzIGlzc3VlIGNhbWUgdXAgcmVjZW50bHkgaW4gYW4gT3BlbkNvbmZp ZyBkaXNjdXNzaW9uIGhlcmU6DQpVcGRhdGVzIHRvIE9wZW5Db25maWcgdHlwZXMgbW9kdWxlcy4g wrcgb3BlbmNvbmZpZy9wdWJsaWNAZjIwZWQ4NCAoZ2l0aHViLmNvbSk8aHR0cHM6Ly9naXRodWIu Y29tL29wZW5jb25maWcvcHVibGljL2NvbW1pdC9mMjBlZDg0MTFhNmZjMWY1NWM5ZGViZWQ1NWM4 NTJlYTRmZmVmNWJiI2NvbW1pdGNvbW1lbnQtNTEwNzY0NzA+DQoNCldhcyBpdCB0aGUgaW50ZW50 aW9uIG9mIFJGQzc5NTAgdGhhdCBhIHJldmlzaW9uIGhpc3Rvcnkgc2hvdWxkIG5ldmVyIGhhdmUg dGhlIHNhbWUgcmV2aXNpb24gZGF0ZSB0d2ljZSA/DQoNCkl0IHNlZW1zIHRoYXQgd2F5Lg0KSG93 IHdvdWxkIHRoZSBkdXBsaWNhdGVzIGJlIGRpc3Rpbmd1aXNoZWQgd2l0aGluIGEgc2VydmVyPw0K VGhlIHNlcnZlciBjYW5ub3QgYWR2ZXJ0aXNlICJmb29AZGF0ZXN0cmluZyIgdHdpY2UuDQpJbXBv cnQtYnktcmV2aXNpb24gY2Fubm90IGlkZW50aWZ5IHRoZSAyIHJldmlzaW9ucyB3aXRoIHRoZSBz YW1lIGRhdGUuDQoNCg0KQW5keQ0KDQoNCkkgdGhpbmsgaXQgaXMgc29tZXdoYXQgaW5mZXJyZWQg ZnJvbSB2YXJpb3VzIGRyYWZ0cyB0aGF0IGRlc2NyaWJlIGhvdyBhIG1vZHVsZSBuYW1lICsgcmV2 aXNpb24gZGF0ZSB1bmlxdWVseSBpZGVudGlmaWVzIGEgbW9kdWxlIHJldmlzaW9uLiBCdXQgaXQg ZG9lc24ndCBzZWVtIHRvIGJlIGV4cGxpY2l0bHkgc3RhdGVkIGluIFJGQzc5NTAuDQoNCklmIHdl IGRpc2FsbG93IGR1cGxpY2F0ZSByZXZpc2lvbiBkYXRlcywgdGhhdCBtYWtlcyB0aGUgbW9kdWxl LW5hbWUrZGF0ZSB0dXBsZSB1bmlxdWUsIGJ1dCBpdCBkb2VzIG1lYW4gdGhhdCBhdXRob3JzIGNh bid0IHByb2R1Y2UgMiB2ZXJzaW9ucyBvZiBhIG1vZHVsZSBpbiB0aGUgc2FtZSBkYXkuIEluIHRo ZW9yeSB3ZSAqY291bGQqIGRvIHNvbWV0aGluZyBsaWtlIHRoaXM6DQotIHJlcXVpcmUgdW5pcXVl IHJldmlzaW9uLWxhYmVscw0KLSBhbGxvdyBkdXBsaWNhdGUgcmV2aXNpb24gZGF0ZXMNCg0KQnV0 IGluIHRoYXQgY2FzZSwgb25seSB0aGUgbW9kdWxlLW5hbWUrcmV2aXNpb24tbGFiZWwgY2FuIGJl IHRoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgYSByZXZpc2lvbi4NCg0KSmFzb24NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5n IGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== --_000_614a0780b8ca4030a3d6b02897977c38huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkkgcmVjYWxsIEkgcmFpc2VkIGEgc2ltaWxhciBxdWVzdGlvbiBpbiBvbmUgb2YgdGhl IHByZXZpb3VzIG1lZXRpbmdzIChpbiB0aGUgY29udGV4dCBvZiB0aGUgWUFORyBmaWxlIG5hbWlu ZykgYW5kIHRoZSBhbnN3ZXIgSSBoYXZlIGdvdCBpcyB0aGF0IHRoZSByZXZpc2lvbi1kYXRlDQog aXMgc3RpbGwgcmVxdWlyZWQgdG8gYmUgdW5pcXVlIGZvciBhIGdpdmVuIFlBTkcgbW9kdWxlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JTUhPLCB0aGlzIHJlcXVp cmVtZW50IHdhcyB2ZXJ5IHJlYXNvbmFibGUgZm9yIGEgbGluZWFyIG1vZHVsZSBkZXZlbG9wbWVu dCAoYXMgcGVyIGN1cnJlbnQgUkZDNzk1MCkgYnV0IGl0IHdvdWxkIGltcG9zZSBhbiB1bm5lY2Vz c2FyeSBhbmQgZXJyb3ItcHJvbmUgcHJvY2Vzcw0KIGZvciBwYXJhbGxlbCBtb2RlbCBkZXZlbG9w bWVudCB3aGljaCBpcyBlbmFibGVkIGJ5IHRoZSB1c2Ugb2YgcmV2aXNpb24gbGFiZWxzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Gb3IgZXhhbXBsZSwgbGV04oCZ cyBjb25zaWRlciBhIGNhc2Ugd2hlcmUsIGFmdGVyIHJlbGVhc2VzIDEuMC4wLCAxLjEuMCBhbmQg MS4yLjAgaGF2ZSBiZWVuIHB1Ymxpc2hlZCwgYSBidWcgaXMgZGlzY292ZXJlZCBmcm9tIFIxLjAu MCAmbmJzcDthbmQgdGhlcmVmb3JlIHRocmVlIGJ1Zy1maXhpbmcNCiByZWxlYXNlcyAoMS4wLjEs IDEuMS4xIGFuZCAxLjIuMSkgbmVlZHMgdG8gYmUgcHVibGlzaGVkJm5ic3A7IOKAnGFsbW9zdOKA nSBhdCB0aGUgc2FtZSB0aW1lIHdpdGggdGhlIHNhbWUgYnVnIGZpeDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHJlcXVpcmVtZW50IGZvciB1bmlxdWUgcmV2 aXNpb24tZGF0ZSBtYWtlcyB0aGlzIGltcG9zc2libGUgYW5kIHRoZSBkZXZlbG9wZXIgbmVlZHMg dG8gcHVibGlzaCB0aGVzZSB0aHJlZSByZWxlYXNlZCBpbiB0aHJlZSBkaWZmZXJlbnQgZGF5czxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SU1ITywgbW9zdCBvZiB0 aGUgcGVvcGxlIHdpbGwgbm90IGZvbGxvdyB0aGlzIHJ1bGUgYW5kIHB1Ymxpc2ggdGhlc2UgdGhy ZWUgcmVsZWFzZXMg4oCcYWxtb3N04oCdIGF0IHRoZSBzYW1lIHRpbWU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSByZXZpc2lvbi1kYXRlIHVuaXF1ZW5lc3Mg cmVxdWlyZW1lbnQgY2FuIGJlIHJlbGF4ZWQgaWYgYSBtb2R1bGUgcmV2aXNpb24gaXMgYW5ub3Vu Y2VkIGFzICZxdW90O2ZvbyNyZXZpc2lvbi1sYWJlbCZxdW90OyBpbnN0ZWFkIG9mIGFzICZxdW90 O2Zvb0BkYXRlc3RyaW5nJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JdGFsbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFu ZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBtYXJ0ZWTDrCAxIGdpdWdubyAyMDIxIDE2OjQyPGJyPg0KPGI+VG86PC9iPiBTdGVybmUsIEph c29uIChOb2tpYSAtIENBL090dGF3YSkgJmx0O2phc29uLnN0ZXJuZUBub2tpYS5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtu ZXRtb2RdIFlBTkcgcmV2aXNpb24gZGF0ZXMgdW5pcXVlIGluIG1vZHVsZSA/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVu IDEsIDIwMjEgYXQgNjozNiBBTSBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkgJmx0 OzxhIGhyZWY9Im1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tIj5qYXNvbi5zdGVybmVAbm9r aWEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkluIG91ciBZQU5HIHZlcnNpb25pbmcgd29yayB3ZSBhcmUgcHJvcG9zaW5n IHRoYXQgYSByZXZpc2lvbi1sYWJlbCBpcyB1bmlxdWUgYW5kIHRoZSByZXZpc2lvbiBoaXN0b3J5 IG9mIGEgbW9kdWxlIG11c3Qgbm90IGNvbnRhaW4gdGhlIHNhbWUgcmV2aXNpb24tbGFiZWwgdHdp Y2UuPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UncmUgZGViYXRpbmcgd2hldGhlciB3ZSBzaG91 bGQgc3RhdGUgdGhlIHNhbWUgcnVsZSBmb3IgcmV2aXNpb24gKjxiPmRhdGUqPC9iPiBhcyB3ZWxs LjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJGQzc5NTAgZG9lc24ndCBzZWVtIHRvIGV4cGxpY2l0 bHkgc2F5IHRoYXQgcmV2aXNpb24gZGF0ZSBtdXN0IG5vdCBiZSBkdXBsaWNhdGVkIGluIHRoZSBy ZXZpc2lvbiBoaXN0b3J5LjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgaXNzdWUgY2FtZSB1 cCByZWNlbnRseSBpbiBhbiBPcGVuQ29uZmlnIGRpc2N1c3Npb24gaGVyZTo8c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1DQSI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL29wZW5jb25maWcvcHVi bGljL2NvbW1pdC9mMjBlZDg0MTFhNmZjMWY1NWM5ZGViZWQ1NWM4NTJlYTRmZmVmNWJiI2NvbW1p dGNvbW1lbnQtNTEwNzY0NzAiIHRhcmdldD0iX2JsYW5rIj5VcGRhdGVzIHRvIE9wZW5Db25maWcg dHlwZXMNCiBtb2R1bGVzLiDCtyBvcGVuY29uZmlnL3B1YmxpY0BmMjBlZDg0IChnaXRodWIuY29t KTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPldhcyBpdCB0aGUgaW50ZW50aW9uIG9mIFJGQzc5NTAgdGhhdCBhIHJldmlzaW9u IGhpc3Rvcnkgc2hvdWxkIG5ldmVyIGhhdmUgdGhlIHNhbWUgcmV2aXNpb24gZGF0ZSB0d2ljZSA/ PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyB0 aGF0IHdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhvdyB3b3VsZCB0aGUgZHVwbGljYXRlcyBiZSBkaXN0aW5ndWlzaGVkIHdpdGhpbiBhIHNl cnZlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBzZXJ2ZXIgY2Fubm90IGFkdmVydGlzZSAmcXVvdDtmb29AZGF0ZXN0cmluZyZxdW90OyB0 d2ljZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkltcG9ydC1ieS1yZXZpc2lvbiBjYW5ub3QgaWRlbnRpZnkgdGhlIDIgcmV2aXNpb25zIHdpdGgg dGhlIHNhbWUgZGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRo aW5rIGl0IGlzIHNvbWV3aGF0IGluZmVycmVkIGZyb20gdmFyaW91cyBkcmFmdHMgdGhhdCBkZXNj cmliZSBob3cgYSBtb2R1bGUgbmFtZSAmIzQzOyByZXZpc2lvbiBkYXRlIHVuaXF1ZWx5IGlkZW50 aWZpZXMgYSBtb2R1bGUgcmV2aXNpb24uIEJ1dCBpdCBkb2Vzbid0IHNlZW0gdG8gYmUgZXhwbGlj aXRseSBzdGF0ZWQNCiBpbiBSRkM3OTUwLjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNB Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdlIGRp c2FsbG93IGR1cGxpY2F0ZSByZXZpc2lvbiBkYXRlcywgdGhhdCBtYWtlcyB0aGUgbW9kdWxlLW5h bWUmIzQzO2RhdGUgdHVwbGUgdW5pcXVlLCBidXQgaXQgZG9lcyBtZWFuIHRoYXQgYXV0aG9ycyBj YW4ndCBwcm9kdWNlIDIgdmVyc2lvbnMgb2YgYSBtb2R1bGUgaW4gdGhlIHNhbWUgZGF5LiBJbiB0 aGVvcnkNCiB3ZSAqPGI+Y291bGQ8L2I+KiBkbyBzb21ldGhpbmcgbGlrZSB0aGlzOjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pi0gcmVxdWlyZSB1bmlxdWUgcmV2aXNpb24tbGFiZWxzPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBhbGxvdyBkdXBsaWNh dGUgcmV2aXNpb24gZGF0ZXM8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CdXQgaW4gdGhhdCBjYXNl LCBvbmx5IHRoZSBtb2R1bGUtbmFtZSYjNDM7cmV2aXNpb24tbGFiZWwgY2FuIGJlIHRoZSB1bmlx dWUgaWRlbnRpZmllciBmb3IgYSByZXZpc2lvbi48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5KYXNv bjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1v ZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_614a0780b8ca4030a3d6b02897977c38huaweicom_-- From nobody Tue Jun 1 12:51:29 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45C23A2524 for ; Tue, 1 Jun 2021 12:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t71ST0hSYzBu for ; Tue, 1 Jun 2021 12:51:22 -0700 (PDT) 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 A7B863A2525 for ; Tue, 1 Jun 2021 12:51:21 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id x38so23636716lfa.10 for ; Tue, 01 Jun 2021 12:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=alLOhl38nmIBnV0eP/XKKackKXJfrWj1Jf5zSZN1fVc=; b=CYWbVhVlt1fa7Amc/z7IkkkuMWL8zv/ZyMUTnsEr366PkAMxDHBbsqAZkYm031EO/9 b2f75d+yFphoHXaJwN4PQT9IbX+NbANZbvm/eoKWtgZBK/pJrP8VRciNWAEkgiIQrKML 41bhiYvTOhNWk/2ExBwAMsrUO4BCxNMNQ2zvUvcOLaZchTpSG2ZFbNgAG8F2B7yoM6+h j33V2ZTZ3tHyLN9L2huYLd3mrKbGUD2nWU5Xpc/QDdaaSyqZsQxgSz59ffmNkNUKsp9u BPRpr0+aZgAWYM1VN/fsMMdH1p1Wfpi4HQXVhlM+FhZYgEwrEc/CwqDnj7wV9hod3PM0 lLAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=alLOhl38nmIBnV0eP/XKKackKXJfrWj1Jf5zSZN1fVc=; b=CB4VSC36WpijUA6kt4xLcDLEsibG2qux6tB/BO7ESiM5TItrTPlsBcuyXvtHK6h2SX gDRpp8rpaVi2W0OcTJPIwgffWVE+dNTtOarKmodlz3fK3X+kcprGLZc4nqEzf7s1kYHu cMJQJpqKV9kvNzl53Vmw75v0/9db+ZEzzkRESeOSB8Iqxyw7z++Gqhz+ISHRHum/Y83u kocy0qTKbXhiYbvCJ2AI2uZM0EWOwKqPgAJ0b6jdmC4bkvdVxu158AfTKRhD1WelLe45 vHdZ0wsgflIOYskb1BM+8frzNrZXyrqGn44c2jdbJ12+fqWo/qnwYW3u42V5ff+sSWL3 uOUQ== X-Gm-Message-State: AOAM531ldGhYLFiIB58Hhh3voHilBTsNWYsZaiRWaFQhpNPHKQU9krgz ur2oNJibGbHYBNC96oFRxdB6ADtVFJeSjYPuIRZpnQ== X-Google-Smtp-Source: ABdhPJwfyiK3Gf+vbGxRf3YAfPRnTsV29r2pabxNUlR9ttfMl41c3hAy9w+PHICmP3UiB9DJsL1S7TIGKRYBRhAkNgk= X-Received: by 2002:ac2:548d:: with SMTP id t13mr6208046lfk.568.1622577077815; Tue, 01 Jun 2021 12:51:17 -0700 (PDT) MIME-Version: 1.0 References: <614a0780b8ca4030a3d6b02897977c38@huawei.com> In-Reply-To: <614a0780b8ca4030a3d6b02897977c38@huawei.com> From: Andy Bierman Date: Tue, 1 Jun 2021 12:51:06 -0700 Message-ID: To: Italo Busi Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000058307e05c3b9aaf4" Archived-At: Subject: Re: [netmod] YANG revision dates unique in module ? 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, 01 Jun 2021 19:51:27 -0000 --00000000000058307e05c3b9aaf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 1, 2021 at 12:31 PM Italo Busi wrote: > I recall I raised a similar question in one of the previous meetings (in > the context of the YANG file naming) and the answer I have got is that th= e > revision-date is still required to be unique for a given YANG module > > > > IMHO, this requirement was very reasonable for a linear module developmen= t > (as per current RFC7950) but it would impose an unnecessary and error-pro= ne > process for parallel model development which is enabled by the use of > revision labels > > > > For example, let=E2=80=99s consider a case where, after releases 1.0.0, 1= .1.0 and > 1.2.0 have been published, a bug is discovered from R1.0.0 and therefore > three bug-fixing releases (1.0.1, 1.1.1 and 1.2.1) needs to be published > =E2=80=9Calmost=E2=80=9D at the same time with the same bug fix > > > > The requirement for unique revision-date makes this impossible and the > developer needs to publish these three released in three different days > > > > IMHO, most of the people will not follow this rule and publish these thre= e > releases =E2=80=9Calmost=E2=80=9D at the same time > > > > The revision-date uniqueness requirement can be relaxed if a module > revision is announced as "foo#revision-label" instead of as "foo@datestri= ng > " > I will never be convinced that it is a feature for every platform to have a different copy of all the YANG modules, with the same names and revision dates. This strategy is not helpful to client developers because they cannot easily reuse code across server platforms. I agree that a revision-label helps in the case where "foo@datestring" is only unique within a certain proprietary context (like per-platform variants). I do not agree it was the intent in RFC 7950 to support such a requirement. Andy > > > Italo > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* marted=C3=AC 1 giugno 2021 16:42 > *To:* Sterne, Jason (Nokia - CA/Ottawa) > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] YANG revision dates unique in module ? > > > > > > > > On Tue, Jun 1, 2021 at 6:36 AM Sterne, Jason (Nokia - CA/Ottawa) < > jason.sterne@nokia.com> wrote: > > Hi all, > > > > In our YANG versioning work we are proposing that a revision-label is > unique and the revision history of a module must not contain the same > revision-label twice. > > > > We're debating whether we should state the same rule for revision **date*= * > as well. > > > > RFC7950 doesn't seem to explicitly say that revision date must not be > duplicated in the revision history. > > > > This issue came up recently in an OpenConfig discussion here: > > Updates to OpenConfig types modules. =C2=B7 openconfig/public@f20ed84 > (github.com) > > > > > Was it the intention of RFC7950 that a revision history should never have > the same revision date twice ? > > > > It seems that way. > > How would the duplicates be distinguished within a server? > > The server cannot advertise "foo@datestring" twice. > > Import-by-revision cannot identify the 2 revisions with the same date. > > > > > > Andy > > > > > > I think it is somewhat inferred from various drafts that describe how a > module name + revision date uniquely identifies a module revision. But it > doesn't seem to be explicitly stated in RFC7950. > > > > If we disallow duplicate revision dates, that makes the module-name+date > tuple unique, but it does mean that authors can't produce 2 versions of a > module in the same day. In theory we **could** do something like this: > > - require unique revision-labels > > - allow duplicate revision dates > > > > But in that case, only the module-name+revision-label can be the unique > identifier for a revision. > > > > Jason > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --00000000000058307e05c3b9aaf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 1, 2021 at 12:31 PM Italo= Busi <Italo.Busi@huawei.com> wrote:

I recall I raised a similar question in one = of the previous meetings (in the context of the YANG file naming) and the a= nswer I have got is that the revision-date is still required to be unique for a given YANG module

=C2=A0

IMHO, this requirement was very reasonable f= or a linear module development (as per current RFC7950) but it would impose= an unnecessary and error-prone process for parallel model development which is enabled by the use of revision lab= els

=C2=A0

For example, let=E2=80=99s consider a case w= here, after releases 1.0.0, 1.1.0 and 1.2.0 have been published, a bug is d= iscovered from R1.0.0 =C2=A0and therefore three bug-fixing releases (1.0.1, 1.1.1 and 1.2.1) needs to be published=C2=A0 =E2=80=9Calm= ost=E2=80=9D at the same time with the same bug fix

=C2=A0

The requirement for unique revision-date mak= es this impossible and the developer needs to publish these three released = in three different days

=C2=A0

IMHO, most of the people will not follow thi= s rule and publish these three releases =E2=80=9Calmost=E2=80=9D at the sam= e time

=C2=A0

The revision-date uniqueness requirement can= be relaxed if a module revision is announced as "foo#revision-label&q= uot; instead of as "foo@datestring"


I will never be convinced that it is a feature fo= r every platform to have a different copy
of all the YANG modules= , with the same names and revision dates.=C2=A0 This strategy is
= not helpful to client developers because they cannot easily reuse code acro= ss server platforms.

I agree that a revision-label= helps in the case where "foo@datestring" is only unique
within a certain proprietary context (like per-platform variants).
<= div>


=C2=A0

Italo

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

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: marted=C3=AC 1 giugno 2021 16:42
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
Cc: netmod@ietf= .org
Subject: Re: [netmod] YANG revision dates unique in module ?<= u>

=C2=A0

=C2=A0

=C2=A0

On Tue, Jun 1, 2021 at 6:36 AM Sterne, Jason (Nokia = - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Hi all,

=C2=A0

In our YANG versioning work we are proposing that a = revision-label is unique and the revision history of a module must not cont= ain the same revision-label twice.

=C2=A0

We're debating whether we should state the same = rule for revision *date* as well.=

=C2=A0

RFC7950 doesn't seem to explicitly say that revi= sion date must not be duplicated in the revision history.

=C2=A0

This issue came up recently in an OpenConfig discuss= ion here:

Updates to OpenConfig types modules. =C2=B7 openconfig/public@f20ed84 (github.com)

=C2=A0

Was it the intention of RFC7950 that a revision hist= ory should never have the same revision date twice ?

=C2=A0

It seems that way.

How would the duplicates be distinguished within a s= erver?

The server cannot advertise "foo@datestring&quo= t; twice.

Import-by-revision cannot identify the 2 revisions w= ith the same date.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

I think it is somewhat inferred from various drafts = that describe how a module name + revision date uniquely identifies a modul= e revision. But it doesn't seem to be explicitly stated in RFC7950.

=C2=A0

If we disallow duplicate revision dates, that makes = the module-name+date tuple unique, but it does mean that authors can't = produce 2 versions of a module in the same day. In theory we *could* do something like this:

- require unique revision-labels

- allow duplicate revision dates

=C2=A0

But in that case, only the module-name+revision-labe= l can be the unique identifier for a revision.<= u>

=C2=A0

Jason

=C2=A0

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

--00000000000058307e05c3b9aaf4-- From nobody Fri Jun 4 04:44: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 C54A73A0D86; Fri, 4 Jun 2021 04:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 GrxlSffokRgw; Fri, 4 Jun 2021 04:44:03 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.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 E6CD23A0D77; Fri, 4 Jun 2021 04:44:02 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FxLWg4lz7z2xFs; Fri, 4 Jun 2021 13:43:59 +0200 (CEST) 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: Fri, 4 Jun 2021 13:43:59 +0200 Cc: Eliot Lear , "opsawg@ietf.org" , netmod WG X-Mao-Original-Outgoing-Id: 644499839.165211-44dbcbc0d3571aa9fd2330979721860d Content-Transfer-Encoding: quoted-printable Message-Id: <70188F34-2E70-49A8-B324-5FBF34705293@tzi.org> References: <340b29f4-e867-6a5d-b45c-8c8b9e45eb47@lear.ch> To: ljeanc@gmail.com X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] [OPSAWG] please see draft-lear-opsawg-ol on licensing 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, 04 Jun 2021 11:44:06 -0000 On 2021-06-04, at 13:21, L Jean Camp wrote: >=20 > Given the explicit inclusion of licensing in the data structures of = SBoM I think that SHOULD would be too strong in the case that MUD is = extended to SBoMs. Both SPDX and CyCloneDX are integrating licensing in = a more nuanced and consistent manner.=20 The current discussion is about the license under which a MUD file is = offered, not about the licenses governing the components of an SBOM. > SHOULD would create a conflict with the extension unless there is an = alternative in the SBoM extension data. Unless you envision an SBOM for the SBOM, I think we are clear. (But we sure can try to be consistent with license description schemes = employed by SBOMs. Please tell us more about those.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 7 13:45: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 172CB3A0C49; Fri, 4 Jun 2021 04:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht-7PYhbS7vv; Fri, 4 Jun 2021 04:22:01 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 C764D3A0C44; Fri, 4 Jun 2021 04:22:00 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id v22so9435014oic.2; Fri, 04 Jun 2021 04:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=qAcg5INhp5yZsepeMxdSbo9hmNBjFOeS+mhgfvrrE4A=; b=c10+y7vrQODHsjnETQuNeW2ekFfdEZKbBQ6IH1IspgfoDQzxmiriypcYvAPmmIxx+c wOYUoiS7NM30MVMAbPMJQP2OV9mzrOeU9qxPcp13A1Mz+OKm/Q+3Ava/q3T8t4GhD6qX 9T91HHn2m6zRfV9odorAAzBsk++I7SwSm/LkGbkmhofQP61bq2icpARO2JE4NYypN19P MKZYfZt8SD9sltHjk5FZzQ0qdFUWTzuhHUMnGuf05uCnPqKCOL5/ekb2dqxuweXwTJsc Hnn3EyqOuFws/pGy92/weEMhZlrDtZzeFobb61WYeobMpW62vuUnPHh3SPxYFbJN5HwN sbZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=qAcg5INhp5yZsepeMxdSbo9hmNBjFOeS+mhgfvrrE4A=; b=bCNtiOPXvId2RBzm5WQUdzLm7AyfYw7aSGa5Nf8zn+BexzePLyeDxKtOXfLAytzvsA V8H4FC8J7jjuYA95wFpRwuj7AYjK2UgtaHPwWXR7Vg2ulg6X17TTKtDdEwEhi4UTOgqU y3HDfHJBCTSyaHzqcWah71D95hsay3Uutki+/3duODdEdTWG2gWkuRMEsbdgsW+7XxAi gQlJFWSRhRGKM3wincd0uEV8nv66V5a3CKKrdlBUKpyln9StU58W4IXIcj1KZHkvYgCs KlWQwgNnW7NSC6jjyGPBfOfryBj88RdVRAxzBoi5Hzcq/20L2NIvRHXAZKXDceh6qqAU 2tLw== X-Gm-Message-State: AOAM530mvbKXU8tNWe1+hsdDwgSmrZcnUBDMs7eMlOLEZ16dAYpGLO1l 18qfisyeoRlwaml/rnBc5g4rd4lv8i2i4OpzcTRwCK/3Gpw= X-Google-Smtp-Source: ABdhPJxoxBiCpo3+IiBFJYCqWVFxMoN1D9RPPekP+RnojSopyoAmrMbyIe/eqXjkFT7O9FCdCJLiyl3TEPWTupKYWjs= X-Received: by 2002:aca:4cc3:: with SMTP id z186mr2643380oia.73.1622805719636; Fri, 04 Jun 2021 04:21:59 -0700 (PDT) MIME-Version: 1.0 References: <340b29f4-e867-6a5d-b45c-8c8b9e45eb47@lear.ch> In-Reply-To: <340b29f4-e867-6a5d-b45c-8c8b9e45eb47@lear.ch> Reply-To: ljeanc@gmail.com From: L Jean Camp Date: Fri, 4 Jun 2021 07:21:24 -0400 Message-ID: To: Eliot Lear Cc: "opsawg@ietf.org" , netmod WG Content-Type: multipart/alternative; boundary="000000000000755de205c3eee67b" Archived-At: X-Mailman-Approved-At: Mon, 07 Jun 2021 13:45:39 -0700 Subject: Re: [netmod] [OPSAWG] please see draft-lear-opsawg-ol on licensing 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, 04 Jun 2021 11:22:06 -0000 --000000000000755de205c3eee67b Content-Type: text/plain; charset="UTF-8" Given the explicit inclusion of licensing in the data structures of SBoM I think that SHOULD would be too strong in the case that MUD is extended to SBoMs. Both SPDX and CyCloneDX are integrating licensing in a more nuanced and consistent manner. SHOULD would create a conflict with the extension unless there is an alternative in the SBoM extension data. On Thu, May 27, 2021 at 6:04 AM Eliot Lear wrote: > [CC netmod] > > Hi everyone, > > Based on Carsten's concerns about licensing of MUD files we wrote a very > short extension to RFC 8520 to allow statements to be added. I note it > misses an Updates: header, but we should probably add that so people > know they SHOULD use this extension. > > The extension is written as a grouping that is then 'used' to augment a > 'mud' container. The intent here is that if you find the need to use > the extension for other purposes, you can. I wonder if some yang > doctors would like to take a look. We'd like to move on this one quickly. > > Eliot > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --000000000000755de205c3eee67b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given the explicit inclusion of licensing in the data stru= ctures of SBoM I think that SHOULD would be too strong in the case that MUD= is extended to SBoMs. Both SPDX and CyCloneDX are integrating licensing in= a more nuanced and consistent manner.=C2=A0

SHOULD woul= d create=C2=A0 a conflict with the extension unless there is an alternative= in the SBoM extension data.


On Thu, May 27, 2021 at 6:= 04 AM Eliot Lear <lear@lear.ch> w= rote:
[CC netmod= ]

Hi everyone,

Based on Carsten's concerns about licensing of MUD files we wrote a ver= y
short extension to RFC 8520 to allow statements to be added.=C2=A0 I note i= t
misses an Updates: header, but we should probably add that so people
know they SHOULD use this extension.

The extension is written as a grouping that is then 'used' to augme= nt a
'mud' container.=C2=A0 The intent here is that if you find the need= to use
the extension for other purposes, you can.=C2=A0 I wonder if some yang
doctors would like to take a look. We'd like to move on this one quickl= y.

Eliot


_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
--000000000000755de205c3eee67b-- From nobody Mon Jun 7 13:45: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 F23A93A1101; Fri, 4 Jun 2021 06:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfxq1UiYmmA8; Fri, 4 Jun 2021 06:41:29 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 47D8D3A10FE; Fri, 4 Jun 2021 06:41:29 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id c13so4227515oib.13; Fri, 04 Jun 2021 06:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=Wg5ihB0fellbq3IT5xnQJ8UEmFJzn8Y5lmD/V7C/fkg=; b=GC/rCNT4et1dfnITb8vZS0RGU+V235Oc4jtDXGvfR4PTw08BYxqogNl9r21BYd921l 1C7VP7m5fM+3Yvb8igjVADK7VBAy81+dVoc5m4GeRnPahPUMTJ9jFYNT2KbjaUuEr36I etXbp7cKGTzG/LRL5RSXwqSFQJkNNpDdUzN4OeiUN4It6BP+jCHOicab9mYm4VQbozyZ zNbTOBeHAavgMARI+2y+xDxf5NV6/c2/ld+zn3Ry25McLPowPNlwMOlwF0JASZE0PrTp Bw5fSqWQCV3KAul1aBzG2TiSv0ZW7d95tfN+fPfPCCGaCmoIlLSLZtCgoT7gt39wrW/E OW8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=Wg5ihB0fellbq3IT5xnQJ8UEmFJzn8Y5lmD/V7C/fkg=; b=JMin+wt4koow8VPB65RdTmC04LyFzn1qVLmQ7hbopIFZR17Q89fcIbMl2skRY9CaXi p3X+ZGIyGVkGpWrit4JtO/DZIvObEt48BqW0nK6K2w0rhbYAM6m/0XsHMD8BrrwPL9UN eQSk1mgvkQC9VR3LEq1OJPj5fnctJfB4rLjaWkCbk+wRbLdVRlX637NCaBz6AE87IT98 jfAVb6Q4Py0KtNzSCVFC7roYnfyP90r2RtHf5RuPz7lzSDlLgBZO0TXE6C1NzimiU8x/ Wvuyam3fiAhunJpu13txQ9ZN34wmfJHp0g+PXSALLmsrIYDyL9zIh+xqpqPvn6WhuZPA 1oTQ== X-Gm-Message-State: AOAM533shOkh3MZ0MhJhKGckGvd80uew2xeWsDaRKp0i08aU7nCj1UWq IWuPDbIrDYjxBg8Npc7vLLAKpVtQV598FRXnOPF/t2DkHYUTrA== X-Google-Smtp-Source: ABdhPJwnLTBW+2+1vYRQD3mgumc71+W8QITxC6DMtCzfSMEOYxmD2T5vDb10B8KE5ZWEsumW1gplftxJhhZXVOelkHc= X-Received: by 2002:a05:6808:1308:: with SMTP id y8mr3097265oiv.45.1622814087574; Fri, 04 Jun 2021 06:41:27 -0700 (PDT) MIME-Version: 1.0 References: <340b29f4-e867-6a5d-b45c-8c8b9e45eb47@lear.ch> <70188F34-2E70-49A8-B324-5FBF34705293@tzi.org> In-Reply-To: <70188F34-2E70-49A8-B324-5FBF34705293@tzi.org> Reply-To: ljeanc@gmail.com From: L Jean Camp Date: Fri, 4 Jun 2021 09:40:52 -0400 Message-ID: To: Carsten Bormann Cc: Eliot Lear , "opsawg@ietf.org" , netmod WG Content-Type: multipart/alternative; boundary="00000000000039faf905c3f0d9ad" Archived-At: X-Mailman-Approved-At: Mon, 07 Jun 2021 13:45:39 -0700 Subject: Re: [netmod] [OPSAWG] please see draft-lear-opsawg-ol on licensing 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, 04 Jun 2021 13:41:34 -0000 --00000000000039faf905c3f0d9ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If MUD is only used to obtain the SBoM then there is already a license of the MUD-File (and a place to seek updates) in that case because the MUD-File that is obtained is itself a bom. So including licensing information about the MUD-File is a structure that will require repeating information that is already embedded in the file itself, and thus increase the chance of conflict. The component licensing in the (why are there 2? I do not know) data structures are just YANG specifications to enable consistent XML or JSON descriptions of licensing requirements, enabling a list to point to licensing of the SBoM itself as well as any level of specific per-component or sub-component licenses. On Fri, Jun 4, 2021 at 7:44 AM Carsten Bormann wrote: > On 2021-06-04, at 13:21, L Jean Camp wrote: > > > > Given the explicit inclusion of licensing in the data structures of SBo= M > I think that SHOULD would be too strong in the case that MUD is extended = to > SBoMs. Both SPDX and CyCloneDX are integrating licensing in a more nuance= d > and consistent manner. > > The current discussion is about the license under which a MUD file is > offered, not about the licenses governing the components of an SBOM. > > > SHOULD would create a conflict with the extension unless there is an > alternative in the SBoM extension data. > > Unless you envision an SBOM for the SBOM, I think we are clear. > > (But we sure can try to be consistent with license description schemes > employed by SBOMs. Please tell us more about those.) > > Gr=C3=BC=C3=9Fe, Carsten > > > --00000000000039faf905c3f0d9ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If MUD is only used to obtain the SBoM= then=20 there is already a license of the MUD-File (and a place to seek updates) in= that case because the MUD-File that is obtained is itself a bom.=C2=A0 So = including licensing information about the MUD-File is a structure that will= require repeating information that is already embedded in the file itself,= and thus increase the chance of conflict.=C2=A0

<= div>The component licensing in the=C2=A0(why are there 2? I do not know) da= ta structures are just YANG specifications to enable consistent XML or JSON= descriptions of licensing requirements, enabling a list to=C2=A0 point to = licensing of the SBoM itself as well as any level of specific per-component= or sub-component licenses.=C2=A0


=
= On Fri, Jun 4, 2021 at 7:44 AM Carsten Bormann <cabo@tzi.org> wrote:
On 2021-06-04, at 13:21, L Jean Camp <ljeanc@gmail.com> wrote:
>
> Given the explicit inclusion of licensing in the data structures of SB= oM I think that SHOULD would be too strong in the case that MUD is extended= to SBoMs. Both SPDX and CyCloneDX are integrating licensing in a more nuan= ced and consistent manner.

The current discussion is about the license under which a MUD file is offer= ed, not about the licenses governing the components of an SBOM.

> SHOULD would create=C2=A0 a conflict with the extension unless there i= s an alternative in the SBoM extension data.

Unless you envision an SBOM for the SBOM, I think we are clear.

(But we sure can try to be consistent with license description schemes empl= oyed by SBOMs.=C2=A0 Please tell us more about those.)

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


--00000000000039faf905c3f0d9ad-- From nobody Mon Jun 7 13:45: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 569D43A198D; Fri, 4 Jun 2021 10:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y7Kd7gHwTrZ; Fri, 4 Jun 2021 10:09:28 -0700 (PDT) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 B4EDC3A198A; Fri, 4 Jun 2021 10:09:28 -0700 (PDT) Received: by mail-oo1-xc33.google.com with SMTP id x22-20020a4a62160000b0290245cf6b7feeso2387040ooc.13; Fri, 04 Jun 2021 10:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=3zPpcTnCAQIl1Lp6HwUIl+7uBZZclmZ1iwtneAYWaHs=; b=TJMcTczjdkVzSiiXbVPpmDZjcCdZ1vZZGDrjDT1hw7OGEsCJkSzii99kECR/eua4MB 6bnTRFkecG0gqNHPRowPOWOHApPnlc2wXE7ABJfM4LhXJE7er57zZDZzI+TBoB/QkpPe wx5NNQ0Ec75Lsl5FNPI5lQ3X4pqRhn0Oqi0OYAdfU3H8iTPgWBXnSQqIQdosXGAIqT27 uZAmLF0kt/sMhW+e1n4cLZcg757luGJK/DXCg6ISydMCjWFojaPF0FN6GiLL0RUIXqhM VZpE0yqNRptfe2+mjIsf/+n/Gk7/vU9/RbRu4EFNXRphhz9kpSSFffu9Bzk22I6kdzPZ XHKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=3zPpcTnCAQIl1Lp6HwUIl+7uBZZclmZ1iwtneAYWaHs=; b=FRW3TqpOEqQ6MCVfHf0MCRese5W2HgmB6VObQv76xpKel6dQbYqW72yrQvi7lM7tQB 8TxhekngLc5mUdiPbldAyddwd6zw8kbziHb8jtwr2IhdEJpzfryWie83j0ibCSokgNkK nQU6kHNLY8Q5DgG9Dy++yzccT8TeAgYYninvzrLbGYlep5QNeVgBVynArjM/4tJ80VRz 8OBN28guyKCEZ88M2P5WakiQc3AY/giVft6C9tBMDNiYIBxid/IfbY324o2mT9mm0how r6VkxNzYmhfl8d/80kiTfYdwtIWqYcS1VNTa04onBp7wYlcv7l2X5FYWiBSFIRdJX3ly ku/Q== X-Gm-Message-State: AOAM531mravs2AqvAWsJYIC7kQPXkSJ0HqjY0vRwAc5XwWfUNDcIBGXV 4ro17pxBdj7WMJ2kB5fJ/xyPeAj7TLB0TEucyGg= X-Google-Smtp-Source: ABdhPJzmilcVrsf/fZxnE//Cou2Ekbpt2AazHXAKnDjPKPge/ldtdpLwwZp/pECIkpJ3gHmAHxDSCglPpVmO2xx9smU= X-Received: by 2002:a05:6820:54e:: with SMTP id n14mr4340645ooj.49.1622826567411; Fri, 04 Jun 2021 10:09:27 -0700 (PDT) MIME-Version: 1.0 References: <340b29f4-e867-6a5d-b45c-8c8b9e45eb47@lear.ch> <70188F34-2E70-49A8-B324-5FBF34705293@tzi.org> In-Reply-To: <70188F34-2E70-49A8-B324-5FBF34705293@tzi.org> Reply-To: ljeanc@gmail.com From: L Jean Camp Date: Fri, 4 Jun 2021 13:08:52 -0400 Message-ID: To: Carsten Bormann Cc: Eliot Lear , "opsawg@ietf.org" , netmod WG Content-Type: multipart/alternative; boundary="000000000000152c7805c3f3c12c" Archived-At: X-Mailman-Approved-At: Mon, 07 Jun 2021 13:45:39 -0700 Subject: Re: [netmod] [OPSAWG] please see draft-lear-opsawg-ol on licensing 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, 04 Jun 2021 17:09:35 -0000 --000000000000152c7805c3f3c12c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pardon the formatting, my responses are now in-line. On Fri, Jun 4, 2021 at 7:44 AM Carsten Bormann wrote: > On 2021-06-04, at 13:21, L Jean Camp wrote: > > > > Given the explicit inclusion of licensing in the data structures of SBo= M > I think that SHOULD would be too strong in the case that MUD is extended = to > SBoMs. Both SPDX and CyCloneDX are integrating licensing in a more nuance= d > and consistent manner. > > The current discussion is about the license under which a MUD file is > offered, not about the licenses governing the components of an SBOM. > This interaction between these two standards is a human factors disaster waiting to happen. There is a good case to be made that SBoM in the EO to be the driver for MUD adoption. > > > SHOULD would create a conflict with the extension unless there is an > alternative in the SBoM extension data. > > Unless you envision an SBOM for the SBOM, I think we are clear. > And it would not be an SBOM for the SBOM because the SBOM license is already in the data standard. > > (But we sure can try to be consistent with license description schemes > employed by SBOMs. Please tell us more about those.) > The only example currently implemented is the medical example. I expect the requirements on these to be defined by a FDA statement. Again, otherwise, there will be a license for the SBoM, the components, the sub-components, etc that are expected to be standard software licenses. Except special cases, of which the most developed SBoM pilot is one of these, and the regulatory constraints I expect for be forthcoming. I think Kevin is focusing on those fairly intensely right now. > Gr=C3=BC=C3=9Fe, Carsten > > > --000000000000152c7805c3f3c12c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Pardon the formatting, my responses are n= ow in-line.


On Fri, Jun 4, 2021 at 7:44 AM Carsten Bormann &l= t;cabo@tzi.org> wrote:
On 2021-06-04, at 13:21, L Je= an Camp <ljeanc@gm= ail.com> wrote:
>
> Given the explicit inclusion of licensing in the data structures of SB= oM I think that SHOULD would be too strong in the case that MUD is extended= to SBoMs. Both SPDX and CyCloneDX are integrating licensing in a more nuan= ced and consistent manner.

The current discussion is about the license under which a MUD file is offer= ed, not about the licenses governing the components of an SBOM.

This interaction between these two standards is a human= factors disaster waiting to happen.

There is a good case to be made that SBoM in= the EO to be the driver for MUD adoption.=C2=A0

<= div>=C2=A0

> SHOULD would create=C2=A0 a conflict with the extension unless there i= s an alternative in the SBoM extension data.

Unless you envision an SBOM for the SBOM, I think we are clear.
=C2=A0
=C2=A0And it would not be an SBOM for the SBOM b= ecause the SBOM license is already in the data standard.=C2=A0 =C2=A0
=C2=A0

(But we sure can try to be consistent with license description schemes empl= oyed by SBOMs.=C2=A0 Please tell us more about those.)

The only example currently implemented is the medical examp= le.=C2=A0 I expect the requirements on these to be defined by a FDA stateme= nt. Again, otherwise, there will be a license for the SBoM, the components,= the sub-components, etc that are expected to be standard software licenses= .

Except special cases, of which the most develope= d SBoM pilot is one of these, and the regulatory constraints I expect for b= e forthcoming.=C2=A0 I think Kevin is focusing on those fairly intensely ri= ght now.=C2=A0


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


--000000000000152c7805c3f3c12c-- From nobody Tue Jun 8 10:39: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 36AC93A37D7 for ; Tue, 8 Jun 2021 10:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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 17qiZyNiVVS4 for ; Tue, 8 Jun 2021 10:39:29 -0700 (PDT) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2119.outbound.protection.outlook.com [40.107.212.119]) (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 BB8363A37D5 for ; Tue, 8 Jun 2021 10:39:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nWB0aQLgdYS9Grqd1xs4lzONiOmSuccC3xZOl6ap8Ee/wRma7lNrBkdENiTPukZ/3aapUT/iRFrIb2dNrwR0zxvHKkJ4UmShNynlHbgDN5CauiEhWjVdLpyYnqGsOtlBnx630JfQCpcWu/7qXKJQL564Jk25B/Hr2DeQ8y2jjO5u8ih3wuYEzCqcZbL7+90ZWZqbQXGo77SCqIjsZ95w4if8Q/DWwbBdFQiIiMjC+Tuw9o5nJtJ38uAK25KgQwzr71+q/IwKhf2OcFQwpSLglI88adyuguO0z09Sgdrh622ESwpjxUq2rmoJ9EVZHKQQHTJcLNiETHL4EfdJDXL87w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i1q7BOynZXTmNO1szFxkNTmX+9kdcgt1XFepE5EOYIM=; b=h75fBv9o50s/IS1tLN5Wu8kSvF0Y9FeXUT1UMv5aVfibmcSJSiIWIC3oPW8fX+FWLO3fHGjvKleqIy8wNB5PA/+svB7DaYcAV6na/e5T7pzCJzzt1dbvdxXknoSYyp/N3DWKnNGPEneo1bcuhtqCIfoo1sVG+41dRIwtEvoiJq6SCwOSvVYenDb4fyg9ltlN97C5wrGzUh64I0RJmi1mQK8jMVv+u4O7qizc8+g+1HNLl0o69qroX4VILbxEKBuvFa5nQXTvbNWlWpXP4yeB9+Szb8cBj4nuOwbPSAm8Dc9aH6g15IaSkcQ6wuhADs+tBwVEdGa7f15OVA4a0Gfhww== 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=i1q7BOynZXTmNO1szFxkNTmX+9kdcgt1XFepE5EOYIM=; b=KnlBZyoQI+qIJRnQmtVjQJ/KYPsmyLnS0t8yG2eRFh8qI96Pt7gOyNnNwKKRHPqaKSRgQDzSWK5GcpJpVLic7bdQMlNp9pH2l261788D1Hc9ktSsGRfvKZj1CWksjAfr0zS7XhleasM+yse7pMNOZrgAxVEcbtHSdK9j5XuBRVM= 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.4195.23; Tue, 8 Jun 2021 17:39:25 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4195.030; Tue, 8 Jun 2021 17:39:25 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-06-08 Thread-Index: AddcjRHyR82Br9bERdeXBXT0W+r1ig== Date: Tue, 8 Jun 2021 17:39:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2607:f2c0:e4ae:97:51a6:4312:1068:42f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e6497577-141a-4b96-bb8c-08d92aa45c05 x-ms-traffictypediagnostic: DM6PR08MB6315: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ElnIyfNwrAnWNNBo7lm+uWxsqJdnMIHbImhD4HTeJkYVfbNh6TJm7vzk3u/caFUnQGsOeSHXee9vedwe9OuzOoTV8DF7yEBZsnlGfjHs9lBn6GMmF0tTW0Ao3eW2X3X64byyYqkQ7rTF+spf8xmoF2clbGO0Ppx2HDFdzBw9Zn1TAPZepYAj4ZaQKG5VY3zTKrhGWXPcPLB2NY6QAtkKnTvl41SU6drO4TBoTaOFNmurw0Cao6cscAqP48adCyplnkNofPO2BsFMOaVLeNS2hAIhKoCaFoxj/TRBnxd0YWmFZ3dtAM1QrBwn7LQslrNDi9CptofCEj8WZuefzjVyfpM1Xc5T1lM6iD5VB6hiuBKoLqRK3OmGVEJA7osBQd9UctFlQ1FdUrSeY6wXfOSZI1vdm99YNnhyMdZSryfS3ZgUGDdAHjs5/HlmmpmCoWeCV+dZJbKpCUXy2xhz21wsJiX5qLKN8Ruz7tqt+0urnXnJxqxKUssbHscuMErdt5xr4w80xzRVCigbLroMDaNy7jDKPu0/fihxg3I+tAesMH9olGvGD173S5C+IafUkLjsRgOHY9LhsYSKT71b/ujs9YwFQNMcaEGjSWyh1Go1VyJBdJp6ilUshyyb0KinrRe8WmeD5Hp6dOrXLeg7HOGRkeAObJYBVsbYUrozJS/HkM5uP+XVxT6aeX3SFpRrr9tDu8ug0utGo2LGxOzjYdAWei9RBY9Omiru2mOldOnLfBk= 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)(396003)(39860400002)(376002)(346002)(136003)(8936002)(9686003)(16799955002)(52536014)(8676002)(66946007)(66476007)(33656002)(5660300002)(6506007)(86362001)(2906002)(83380400001)(55016002)(6916009)(38100700002)(122000001)(966005)(66446008)(7696005)(64756008)(316002)(76116006)(478600001)(186003)(71200400001)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?S+yhjzh3EgyxHopQP2jnJFSWsaKRErVGVrxdpQYNTbd6PL1D+kS3Q+ApL5bR?= =?us-ascii?Q?w1ZrLjw+vnXsHfYFj3MjCpvxzLFuc66p+ha4sK7CwWsMjPv0rTX29ZiF2OEb?= =?us-ascii?Q?thBYsGlxUJpYQS6DTyTSxe269IG9OD5PP68oRsm2eUmwM3yhbN44BwtNDrZr?= =?us-ascii?Q?5+Roy2Q9q7KjM64TmCRAjKD39XPFOmgWnHfG9RmY4mHajKHQ5jW7lIC/eQEj?= =?us-ascii?Q?ZNLz1hqs+FKhz81WWDIkyuXU6FEfcFKqFgKyzkn9tc9mSYA9pJ0hZd7KDnLT?= =?us-ascii?Q?c8zkfk2VlHZRNvUfJA/eu9Mh+IJw3YeAHAMXm0KCPLvZztUpA5xjrKu3rffM?= =?us-ascii?Q?4agMEHOewvb/H8iwEOjK6IlLYFe4D4/JZ8H99nQGLpfOGctcChfpgpsdNbdV?= =?us-ascii?Q?tr9EZ4SBe1gdmh5inqnGL9rhlZiaSc9muG1pFzFri1yRg5MjZR6ByLkyVrhF?= =?us-ascii?Q?xhHPF+gLA/OytXQ9VJTeoHehE0Zz6rihj609BTy/1UGJXysD6EVQizf0AFuL?= =?us-ascii?Q?a760aO3T7+ysd1yfaeXcFwHe182aihhrtu4OvFQI7WtjbxGXh9nCkZqJ6biM?= =?us-ascii?Q?Lr+oPvi7YArQ8mg5752OjhPCOIi4fy502Ti6L5z0WZOiD5N8jNmFKiE5KiRN?= =?us-ascii?Q?h7q5TaqLNRaQTR2FabLUFFf/RdDrlHgiBF4rZigc+NQMI0bEF5YE6CsiAq1X?= =?us-ascii?Q?Fz7O5CuZZFhcK8s84W7Gow156fb8luiW8oj0n6EE6+FWDlSSEk6IMOVJG3Zb?= =?us-ascii?Q?QJ4VOTcWYGMWv7diZGeeE2DSNI5BPaI+O0qLimvOAFFeDfwjYjmWSWYfGmjH?= =?us-ascii?Q?yygIYEnaV7TMBL/ZIO77ImxgwnF3TwJakhRFp57iYMZM1PRD4Tlm+ruXoi1y?= =?us-ascii?Q?7M4urqvQPLDsme1AnfiPyGlE2AQf5OhNKOmM0cR2RM0bOMSHC2bLSvopVkeP?= =?us-ascii?Q?MSMtokBcTnxkjBkxwlMxKE1PgGjwfxoql1pz1R4ZKNu8SEIgpa1Uw50d5mMq?= =?us-ascii?Q?CAzAvPlyI065LQBwQpfsBpsv11d6tKVtKo8ioPeccxUIyEWmExxBOvkz3sEN?= =?us-ascii?Q?MLeZE61O9p0edaGmzQke8Yy8xhrFVjPIqpR8tri8K2u2C1Ed/+mFJF1JxaJP?= =?us-ascii?Q?iwS7T1GPtx+8a8nKezOGe6ghQm9diTlUIQFcBqej1vPw9kLTZvqkjh1Ieyyf?= =?us-ascii?Q?vweAdA+F/9cHSX3pvliPONOO9ouQw2diwdO7DPX9vRZMyc0KjLGqtL2ICPGF?= =?us-ascii?Q?XtPOa409du4TzdgnhLQJPmlFEtSqGa5OQsT/AWjaFNOesg3RYsD4S7Fon0QA?= =?us-ascii?Q?z3nq2Nx4xy2xxRKnq38srhmILDPWuSqVD0KEuTjakLvMIqjEGSyj0oTqQc29?= =?us-ascii?Q?5pIC9lxFb/oXWrTDD4MyiA2jrxz6?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084E7DB644D2BFAA34A84359B379DM6PR08MB5084namp_" 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: e6497577-141a-4b96-bb8c-08d92aa45c05 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2021 17:39:25.4549 (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: utRbk2k+uy+earn6s6DO7WtE7sq3gJd61GHIrZef6wes3JImGb34Iv2izl3U7biDocXNLNOmaWBeMKupBDMNpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6315 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 08 Jun 2021 17:39:34 -0000 --_000_DM6PR08MB5084E7DB644D2BFAA34A84359B379DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-06-08 Submodule vs Module in module versioning draft: - avoid 'artifact', put "submodule or module" everywhere it is applicable - Reshad: add "or submodules" in most places. Non duplicate revision dates: - revision-label is just another label for that revision date - we won't say anything in our drafts about non-duplicate revision dates in= a revision history. This is something for YANG NEXT. YANG SemVer Draft - IETF 110 feedback Raise github issue in verdt *and* against pyang to flag when a module or su= bmodule is missing a revision label Raise github issue to review the IANA guidelines (in our 2 drafts) with IAN= A folks We discussed pre-release version precedence - can't assume precedence of pre-release versions - wipe out the pre-release revision history when publishing the final versi= on (SHOULD) ? or when publishing each pre-release version? Put this guidan= ce in Module Revision Handling (instead of Semver ?) - Joe to propose wording Rgds, Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB5084E7DB644D2BFAA34A84359B379DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-06-08

 

Submodule vs Module in module versioning draft:=

- avoid 'artifact', put "submodule or module&qu= ot; everywhere it is applicable

- Reshad: add "or submodules" in most plac= es.

 

Non duplicate revision dates:

- revision-label is just another label for that revi= sion date

- we won't say anything in our drafts about non-dupl= icate revision dates in a revision history. This is something for YANG NEXT= .

 

YANG SemVer Draft - IETF 110 feedback

 

Raise github issue in verdt *and* against pyang to f= lag when a module or submodule is missing a revision label

 

Raise github issue to review the IANA guidelines (in= our 2 drafts) with IANA folks

 

We discussed pre-release version precedence

- can't assume precedence of pre-release versions

- wipe out the pre-release revision history when pub= lishing the final version (SHOULD) ?  or when publishing each pre-rele= ase version? Put this guidance in Module Revision Handling (instead of Semv= er ?)

- Joe to propose wording

 

Rgds,

Jason

 

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

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

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

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

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

Tap to join from a mobile device (attendees only)

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

--_000_DM6PR08MB5084E7DB644D2BFAA34A84359B379DM6PR08MB5084namp_-- From nobody Tue Jun 8 10:49: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 68BA63A3827 for ; Tue, 8 Jun 2021 10:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1-r0aIW0NOJ for ; Tue, 8 Jun 2021 10:49:15 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 2DE183A3826 for ; Tue, 8 Jun 2021 10:49:15 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id u18so7966325lju.12 for ; Tue, 08 Jun 2021 10:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R4oaAEOQLe2kpqi1i5APfMVDd8FG8f7mAoy0srIjTRs=; b=0vIIQCFhmNL4p8fBYgtgCbjCkSX5KgAJY3d4ZOKO6ButwEp6mkSE05f6W22yrvMYkd wI1vofqxMpS85RbNbzHDMg86ZzH9BsPh3WYIPOVP8VS6585j4DCfJxq2FugnLj7ddef3 sjTh8H+8A11tviecBNdhEEGPO46Zdxm0tGqWYUvHAYioKgFNKx7CuWF1zV7TEmGrNj8S d19/SmVM6aoBCiwEehubeba6TEZQIlEhKEeoA4XzC8xcVGTm913G4dZjY3aBQR2VyICB 5keUY86/cIz4iXU+LlkwDEkvB+LMdpjG6XrMZaSOwgGuCZg7ydvsIj/AtqZyukWfbgBM Duog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R4oaAEOQLe2kpqi1i5APfMVDd8FG8f7mAoy0srIjTRs=; b=qJRQZYgWv+DLJdDJGa1Nf+2L72Te5+60ffENm42qf05zFuDCvf22J77NyxbUs58Gop em+MRiV+kTGIuNN2N3KEViahu4YgecgtNEh2LrKHsNvNkzUntgshAKggDd+apwnsLN3K G4ZvZHIwR1H6DmbPASzTorjljvR8xy0jXjvPPeWqlRUl2ebkO4l3xhxfZu4p80gJwF+C uQ0y6f5sVA5HftZZ5fi/X/IgsADG/S37hG1qTGKW2IsRzTnqxxNMYUGf2xTxJoix8D1K jpevDo5CIEgtTI7TV5LRpM9BJNjV0b8f3CZpQ2kRugRXig05a6K7oBNfuo7Ruul6cmxq EWMA== X-Gm-Message-State: AOAM532WdOzLhDn821MFMl4Ab5Hkk0ryzmRa1Kp3hBH9NkNMnQR2JUcj 8dR/LNmk+/WWJnWh5Nn1X5q7PDzlUsIe3HbCQalp6nBTD4xGmA== X-Google-Smtp-Source: ABdhPJy1GAPqV6K5nXk3zRlSK6OXOAv1zJpE6Wal9DKL6vCP2FCunv7Wg9qy8J/Qn07/QXId2JsQvKzg3pH6EK5/nnM= X-Received: by 2002:a05:651c:178b:: with SMTP id bn11mr19342511ljb.43.1623174547885; Tue, 08 Jun 2021 10:49:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Tue, 8 Jun 2021 10:48:54 -0700 Message-ID: To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000055f1ab05c444c62d" Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 08 Jun 2021 17:49:22 -0000 --00000000000055f1ab05c444c62d Content-Type: text/plain; charset="UTF-8" On Tue, Jun 8, 2021 at 10:39 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.sterne@nokia.com> wrote: > YANG Versioning Weekly Call Minutes - 2021-06-08 > > > > Submodule vs Module in module versioning draft: > > - avoid 'artifact', put "submodule or module" everywhere it is applicable > > - Reshad: add "or submodules" in most places. > > > > Non duplicate revision dates: > > - revision-label is just another label for that revision date > > - we won't say anything in our drafts about non-duplicate revision dates > in a revision history. This is something for YANG NEXT. > > > Can you find any text in RFC 7950 that says that a module with a specific name and revision date can refer to multiple YANG modules? It seems like the opposite is true -- that if the name and revision date are the same then they refer to the same specific module. Andy YANG SemVer Draft - IETF 110 feedback > > > > Raise github issue in verdt *and* against pyang to flag when a module or > submodule is missing a revision label > > > > Raise github issue to review the IANA guidelines (in our 2 drafts) with > IANA folks > > > > We discussed pre-release version precedence > > - can't assume precedence of pre-release versions > > - wipe out the pre-release revision history when publishing the final > version (SHOULD) ? or when publishing each pre-release version? Put this > guidance in Module Revision Handling (instead of Semver ?) > > - Joe to propose wording > > > > Rgds, > > Jason > > > > ---------------------------------------------- > > Weekly webex call details: > > Meeting number (access code): 171 069 0374 > > Meeting password: semver? > > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, > August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & > Canada) > > 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr > > https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293c70 > > Tap to join from a mobile device (attendees only) > > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000055f1ab05c444c62d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 8, 2021 at 10:39 AM Stern= e, Jason (Nokia - CA/Ottawa) <= jason.sterne@nokia.com> wrote:

YANG Versioning Weekly Call Minutes - 2021-06-08<= /u>

=C2=A0

Submodule vs Module in module versioning draft:

- avoid 'artifact', put "submodule or m= odule" everywhere it is applicable

- Reshad: add "or submodules" in most plac= es.

=C2=A0

Non duplicate revision dates:

- revision-label is just another label for that revi= sion date

- we won't say anything in our drafts about non-= duplicate revision dates in a revision history. This is something for YANG = NEXT.

=C2=A0


<= /div>

Can you find any text in RFC 7950 that says that a= module
with a specific name and revision date can refer to multi= ple YANG modules?
It seems like the opposite is true -- that if t= he name and revision date are the
same then they refer to the sam= e specific module.


Andy
<= br>

<= div lang=3D"EN-CA" style=3D"overflow-wrap: break-word;">

YANG SemVer Draft - IETF 110 feedback<= /p>

=C2=A0

Raise github issue in verdt *and* against pyang to f= lag when a module or submodule is missing a revision label

=C2=A0

Raise github issue to review the IANA guidelines (in= our 2 drafts) with IANA folks

=C2=A0

We discussed pre-release version precedence

- can't assume precedence of pre-release version= s

- wipe out the pre-release revision history when pub= lishing the final version (SHOULD) ?=C2=A0 or when publishing each pre-rele= ase version? Put this guidance in Module Revision Handling (instead of Semv= er ?)

- Joe to propose wording

=C2=A0

Rgds,

Jason

=C2=A0

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

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

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

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

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

Tap to join from a mobile device (attendees only)=

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

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000055f1ab05c444c62d-- From nobody Tue Jun 8 11:00:57 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 D65DF3A3873 for ; Tue, 8 Jun 2021 11:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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 RNbTc7H5kSaU for ; Tue, 8 Jun 2021 11:00:52 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2135.outbound.protection.outlook.com [40.107.223.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84FE3A387A for ; Tue, 8 Jun 2021 11:00:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BPwxICdb8d2x8fbdHqSEqgw2qCmk3xXsujuIZh+Ve7MaESyjQJuukClzVFa71Y78jMfOJyZcPKPZdtr4xUFsp45XWsC54Cw5T8iTJyEmNiAFVy8VCqtBa1ACILl93cZ+9da06TdbmJD3ObTnMya/zmo+QPHugGmDjlZWIWGO/re0b+7UC7iLCvdgBYW3cTALBg6nK7SUgzBKBMx1x/hQYy0DA6e6CFfzNfCj6MP9VMBOwnoGa9HmyIATtOvva8YQbAvt6fAb4DvOOs3ClE/A2XuktQhbC/4Cuh8+2xc15kir/9dKXL5R6+ckRE6g/LqfnnsBUon+VVho8hRHMNgb6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8NEcApw3O4mMTQsonJqOoE+ZLNLmOTrdyiOeydBPO7s=; b=XvZNVKQ8GudsM9dglOvgnRgQi8GkkK9Y1AYSdmr6r7ULVvCHebdUvLgYRa80KJf13eGjhC+J3kwFYcMLbc5u4DJ7l8lVYdlK05mkqfu1tZNoNhW/Og4EO/p8Xyz2fB7FUovLvrcaulCLxaBH5THWaQv+p8862w6Lhoe8qbewjyGzewW/kpS17d59VqjiQ3LA0U1aPSwSD5BOF0E5pY/RLhzxrOOBGXTid6Wss/SteJgv1UyuCNryhtKQNnOqvNU+6fJrXJsiZOmdA0CAnui4/sMGMrv2X5SYAtFyxnQtbmkE9PHEDSv2wn5EED2ZXVvFD8/n04VimyuKbTg8AcMKGA== 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=8NEcApw3O4mMTQsonJqOoE+ZLNLmOTrdyiOeydBPO7s=; b=KbfLVQ46y1pz0gFaD/SHIBr6O86YHwHBrkgk37vH+ydCiw9gtjW2v26Z4HEjQIO38fEbVaUQLeOSjnHSwPL2nbfC2ZofRAXSMRGyzuZr5hTCSVGKJDwJzJIovH6ozmMbZ8536+4R5D2C9zofpq8TaJdnvksFmo/nvU+1GMUTAEE= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB4907.namprd08.prod.outlook.com (2603:10b6:5:52::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.24; Tue, 8 Jun 2021 18:00:49 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4195.030; Tue, 8 Jun 2021 18:00:49 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 Thread-Index: AddcjRHyR82Br9bERdeXBXT0W+r1igAAXpcAAABV89A= Date: Tue, 8 Jun 2021 18:00: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: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2607:f2c0:e4ae:97:51a6:4312:1068:42f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3badc1f5-f142-4ba8-d1f8-08d92aa75946 x-ms-traffictypediagnostic: DM6PR08MB4907: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5AbuEWtyupljbzRBkL45a4BsDfPOPABVtAAa3lyGdy4c1l5eRYcyAD8Uta+4LDaSr0v1f2Tzj6Ql5+5+WrQpngYmPlCnCss3IkLc5goqHJyrbTzQDi+JUFsckLq3e1NQWfJ2LQ1+Ja5ONr0LIOyxrNaJ9h8WYE48fu97a0o3Q3faib+Vvvv/V+RybPY7m2fUWLoC0eLI/uwynKD2sN3manFjceGB5pMFD/iJJlTwS4f/xNAvivzTyR96bGJDNJ8pXun0Kw16Fokhpn3ycNAbL2FchvoEKo5qp6G2Jed6IF3oiK/PaJb8m4ZNFliH8OnHV3i4jw+1lg2Q/F5l7acLPGhgV4KTcJkH8CWK4zAqaU163FBty7g/oTWtQ8YBuuAn8ZzlVnZloMDlZH9xxMDOrQZlMgH71KDSPWCz0HYMuReONstPlaVwsX8n+x/k83TOVc+D4E69riLTG3RIobHEN9lYW4mfNL+R1bLPdsT7ZKqBDEi5DnoY/q3TqcbeHTwn5Bm4n1naKdMILjYkqK5+NjX6fi35lE6eCmYzCTdf1dqlyz5sVxoLvxW2ImadLWeF/mTSz/4v8VbWkCFFTVFDni/SWDRAKnKUxQeN7f0+FY7zYQADNP/I8FV77AkInVltKEHZwOIoSGOToir2lfYvrZtF+eSuHvuiNHb30ub5ETo+81HMywMEnZ4WF2XGd00F7zHU8F/1g7VXhtpK7gzc7THbiGFMsfUwt44zaVj3rvxsJ6JJqZlBq+DDmFK6O6GM 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)(396003)(346002)(136003)(376002)(39860400002)(9326002)(2906002)(478600001)(33656002)(6916009)(55016002)(8936002)(122000001)(52536014)(38100700002)(71200400001)(186003)(66476007)(8676002)(966005)(66556008)(64756008)(66446008)(53546011)(7696005)(9686003)(66946007)(86362001)(83380400001)(5660300002)(316002)(4326008)(6506007)(16799955002)(76116006)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NmliVGNlMEdScHh4cjlvbTd6SmpNay9jZEpObXR5ZThxeG1ZREQrYU1lNVQ1?= =?utf-8?B?Mi9aL21jNmFKSmxNa2hiOENHdnZISFF3d1pDR1BJNS9jZXVwYXFDVUoxcFpj?= =?utf-8?B?QmRHSVNLcUM0OG9SV2tOZEJiek5TRkhmTjJqL3NjZ3gxM2luMU9BM3F4SUJy?= =?utf-8?B?TlNyMUEwbFBjTTNHTkZOUVBzSEZOZFRQQnQvZXV0Rlp6a2pjdHB6MDYvK0xl?= =?utf-8?B?L01kaHpxS25YSDJKVDAvT1o3Rkd0R0dQa1RwSGdGUS9NbUl6Tm5JLzdNRnVG?= =?utf-8?B?V2NzUFRoaDlZVzJZY2tRMEZXeWlPbGdEOVRQS1g1a3RYTWNzUTdKNmVOTDZW?= =?utf-8?B?dFlUVld1bCtwaGhIb2p5S0hra2I1VTdCb05jb1laUDJDNlZjZy9PVEU0VTRX?= =?utf-8?B?c0VDVmFoa1NTc1N6WkwwSnhoTXFjWmY1T1F5MS81ditFWThqY2lSVkdpY3hF?= =?utf-8?B?MlBtenFUTW1zQjFLcGlBcDF6a3JHR1MycjUwOXd4NUFLbUJFYU5LWGU1Tnlv?= =?utf-8?B?NVhpZEZDZ1U5TW5UTjM1TUZyNFV0cExva2NVSTEwcWVPVEIrYnRsdjVwWDcz?= =?utf-8?B?TWxSKy9NcXFmKzlZaVgyME5kYWVMVUltNHJhZ0d4a0p1dWUzaWFQOE9kMEpp?= =?utf-8?B?QVNtekZUOVV0YmhkTGs5cGxiZlc0VmpiN2cxSnVCa0tWWXdvcjRjbVNKL2JF?= =?utf-8?B?U1E3c2swUjdidElLdi8xeU9SK2t1SktaaDJScEFOK051bjhuaHNWcTlPaXlW?= =?utf-8?B?YlB5LzJaRWFoZDNuRW9MR3dMZENjc1NCb3FTL1Z0d3EzUGRUNFJRR1NLeTRX?= =?utf-8?B?anc3U2Nla3YzckdKQ2h6YkxNSU1YYnMrc3orbVZxcFYwK3hwWDZhbUVyaXd1?= =?utf-8?B?RGdFSGozT2pGYTBaSi9nN2JjTFVGNzcwTGpKVXhmOHFDMDhjU0g2UUNSempy?= =?utf-8?B?TEtFcVdjY25xYlNJSlo0dmhQTFFWb0VLM1FlaEd0ODhDZmJIcGRqa3FnRUNT?= =?utf-8?B?U1RUUExtc014OXZMVmhDL3FCeGV0UnFoMUwvYjNOcURIZmJENCtPb3JRZVJQ?= =?utf-8?B?TE1QSE9qdmZNZjJGWVFOZitIL3JQcXE2RVZJK3VacWxiem9RcENQZW9IOVVX?= =?utf-8?B?OHlXT25QSjIzdVVYaXYyY2NwcTdmZlBySng1WFBCcCtzcnpLM29NUjdsUGRl?= =?utf-8?B?ZHNacndKSExBWG9KOFdJMVplZ0FiMjczeVVubXFKdjFYTVoycGFabHFDK040?= =?utf-8?B?dmdxZTNTU2d3MEZGK0ZDTGVoM0tHaWNIYjk3VXJpdnlSTk9OQTFMdS80dEhk?= =?utf-8?B?bU53SzZjd2p4cTFwTDdiSno3V3VnWXhGZlE1UjRQbE5XaVBQNHdIa1JRWHhR?= =?utf-8?B?MHI0cjhlQlljSE1VSzd1aG8xN0R6eHIwTUVZWmRuNHVxNGpxSlZRY0RCc2Va?= =?utf-8?B?WDdNSWdONWZ6RmNNOWV1ejE4aE1zUVMyM1VPNmtsbmFGSDdKbEtEZFNtR2dJ?= =?utf-8?B?NHRzRkJSclNid0pudHhaUmp5MU9DUkp1ZTA1d0pMd3BvRmxHajg0U0pXU05G?= =?utf-8?B?Z2tGMURPa2JBbHFWSVpCUTY3SGx1eS84VUZyaWViY01Gckc2QTlHR3lQTE9K?= =?utf-8?B?THYzUjgrczBWSmI0ckJtWW5iTm5xTTZBb3U5WE9EcmJGQTZkdDd4S3BLbmU4?= =?utf-8?B?clV1SlpDU0VsTzlHUFU3Z3h2MlhCR0xGZVVnZGpIZHJ4VFdta2JSSnUwSkc5?= =?utf-8?B?b0dpMHVOMnJCTUlmQ2ZEYVE4enB3SzFWUjlEd0I0bnpuVFY5b2FJSXRRRERW?= =?utf-8?B?NmNpcmVHdERiamVUOGpDWWsyZ2VQTW1UOHV0QVVYSEdtRUdIYmErTWU0K2xE?= =?utf-8?Q?rgqAEZWLv0IsT?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB50848C69B0319DA2E4C3FB079B379DM6PR08MB5084namp_" 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: 3badc1f5-f142-4ba8-d1f8-08d92aa75946 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2021 18:00:49.3265 (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: w2oZYQarZuvk5y7hXSO95oZF5sMivXBV4Vx6mm8f7pomoaK/abWbQHeGbidYBqkk4gS33O1yhMZWQdhII9Q07A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4907 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 08 Jun 2021 18:00:57 -0000 --_000_DM6PR08MB50848C69B0319DA2E4C3FB079B379DM6PR08MB5084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KTm90aGluZyBpbiBSRkM3OTUwIHNheXMgZHVwbGljYXRlcyBhcmUgYWxsb3dl ZC4gV2UgZG9uJ3QgcGxhbiB0byBjaGFuZ2UgdGhhdCAob3IgcGFydGljdWxhcmx5IHNheSBhbnl0 aGluZyBhYm91dCBpdCkgaW4gYW55IG9mIG91ciBZQU5HIHJldmlzaW9uIHdvcmsuDQoNCkJ1dCBt YXliZSBpbiBZQU5HIE5FWFQsICppZiogYSBTZW12ZXItbGlrZSByZXZpc2lvbiBsYWJlbCB3YXMg YWRvcHRlZCBhcyB0aGUgbWFpbiBpZGVudGlmaWVyIChhbmQgcmV2aXNpb24gZGF0ZSBqdXN0IGJl Y29tZXMgYSBub24ta2V5IGF0dHJpYnV0ZSksIGkuZS4geWFuZyBsaWJyYXJ5IHdhcyBjaGFuZ2Vk IHRvIHVzZSByZXZpc2lvbiBsYWJlbCBpbnN0ZWFkIG9mIHJldmlzaW9uIGRhdGUsIHRoZW4gdHdv IHZlcnNpb25zIGNvdWxkIGJlIGFsbG93ZWQgb24gdGhlIHNhbWUgZGF0ZS4gIEJ1dCB0aGF0J3Mg Zm9yIGEgWUFORyBORVhUIGRpc2N1c3Npb24uDQoNCkphc29uDQoNCkZyb206IEFuZHkgQmllcm1h biA8YW5keUB5dW1hd29ya3MuY29tPg0KU2VudDogVHVlc2RheSwgSnVuZSA4LCAyMDIxIDE6NDkg UE0NClRvOiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkgPGphc29uLnN0ZXJuZUBu b2tpYS5jb20+DQpDYzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFO RyBWZXJzaW9uaW5nIFdlZWtseSBDYWxsIE1pbnV0ZXMgLSAyMDIxLTA2LTA4DQoNCg0KDQpPbiBU dWUsIEp1biA4LCAyMDIxIGF0IDEwOjM5IEFNIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EvT3R0 YXdhKSA8amFzb24uc3Rlcm5lQG5va2lhLmNvbTxtYWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNv bT4+IHdyb3RlOg0KWUFORyBWZXJzaW9uaW5nIFdlZWtseSBDYWxsIE1pbnV0ZXMgLSAyMDIxLTA2 LTA4DQoNClN1Ym1vZHVsZSB2cyBNb2R1bGUgaW4gbW9kdWxlIHZlcnNpb25pbmcgZHJhZnQ6DQot IGF2b2lkICdhcnRpZmFjdCcsIHB1dCAic3VibW9kdWxlIG9yIG1vZHVsZSIgZXZlcnl3aGVyZSBp dCBpcyBhcHBsaWNhYmxlDQotIFJlc2hhZDogYWRkICJvciBzdWJtb2R1bGVzIiBpbiBtb3N0IHBs YWNlcy4NCg0KTm9uIGR1cGxpY2F0ZSByZXZpc2lvbiBkYXRlczoNCi0gcmV2aXNpb24tbGFiZWwg aXMganVzdCBhbm90aGVyIGxhYmVsIGZvciB0aGF0IHJldmlzaW9uIGRhdGUNCi0gd2Ugd29uJ3Qg c2F5IGFueXRoaW5nIGluIG91ciBkcmFmdHMgYWJvdXQgbm9uLWR1cGxpY2F0ZSByZXZpc2lvbiBk YXRlcyBpbiBhIHJldmlzaW9uIGhpc3RvcnkuIFRoaXMgaXMgc29tZXRoaW5nIGZvciBZQU5HIE5F WFQuDQoNCg0KDQpDYW4geW91IGZpbmQgYW55IHRleHQgaW4gUkZDIDc5NTAgdGhhdCBzYXlzIHRo YXQgYSBtb2R1bGUNCndpdGggYSBzcGVjaWZpYyBuYW1lIGFuZCByZXZpc2lvbiBkYXRlIGNhbiBy ZWZlciB0byBtdWx0aXBsZSBZQU5HIG1vZHVsZXM/DQpJdCBzZWVtcyBsaWtlIHRoZSBvcHBvc2l0 ZSBpcyB0cnVlIC0tIHRoYXQgaWYgdGhlIG5hbWUgYW5kIHJldmlzaW9uIGRhdGUgYXJlIHRoZQ0K c2FtZSB0aGVuIHRoZXkgcmVmZXIgdG8gdGhlIHNhbWUgc3BlY2lmaWMgbW9kdWxlLg0KDQoNCkFu ZHkNCg0KDQpZQU5HIFNlbVZlciBEcmFmdCAtIElFVEYgMTEwIGZlZWRiYWNrDQoNClJhaXNlIGdp dGh1YiBpc3N1ZSBpbiB2ZXJkdCAqYW5kKiBhZ2FpbnN0IHB5YW5nIHRvIGZsYWcgd2hlbiBhIG1v ZHVsZSBvciBzdWJtb2R1bGUgaXMgbWlzc2luZyBhIHJldmlzaW9uIGxhYmVsDQoNClJhaXNlIGdp dGh1YiBpc3N1ZSB0byByZXZpZXcgdGhlIElBTkEgZ3VpZGVsaW5lcyAoaW4gb3VyIDIgZHJhZnRz KSB3aXRoIElBTkEgZm9sa3MNCg0KV2UgZGlzY3Vzc2VkIHByZS1yZWxlYXNlIHZlcnNpb24gcHJl Y2VkZW5jZQ0KLSBjYW4ndCBhc3N1bWUgcHJlY2VkZW5jZSBvZiBwcmUtcmVsZWFzZSB2ZXJzaW9u cw0KLSB3aXBlIG91dCB0aGUgcHJlLXJlbGVhc2UgcmV2aXNpb24gaGlzdG9yeSB3aGVuIHB1Ymxp c2hpbmcgdGhlIGZpbmFsIHZlcnNpb24gKFNIT1VMRCkgPyAgb3Igd2hlbiBwdWJsaXNoaW5nIGVh Y2ggcHJlLXJlbGVhc2UgdmVyc2lvbj8gUHV0IHRoaXMgZ3VpZGFuY2UgaW4gTW9kdWxlIFJldmlz aW9uIEhhbmRsaW5nIChpbnN0ZWFkIG9mIFNlbXZlciA/KQ0KLSBKb2UgdG8gcHJvcG9zZSB3b3Jk aW5nDQoNClJnZHMsDQpKYXNvbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpXZWVrbHkgd2ViZXggY2FsbCBkZXRhaWxzOg0KTWVldGluZyBudW1iZXIg KGFjY2VzcyBjb2RlKTogMTcxIDA2OSAwMzc0DQpNZWV0aW5nIHBhc3N3b3JkOiBzZW12ZXI/DQpP Y2N1cnMgZXZlcnkgVHVlc2RheSBlZmZlY3RpdmUgVHVlc2RheSwgU2VwdGVtYmVyIDEsIDIwMjAg dW50aWwgVHVlc2RheSwgQXVndXN0IDI0LCAyMDIxIGZyb20gOTowMCBBTSB0byAxMDowMCBBTSwg KFVUQy0wNDowMCkgRWFzdGVybiBUaW1lIChVUyAmIENhbmFkYSkNCjk6MDAgYW0gIHwgIChVVEMt MDQ6MDApIEVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpICB8ICAxIGhyDQpodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYTc2MjdhMmFlN2I3NzA1MzdjZmY1ZjViODkyOTNj NzANClRhcCB0byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSkNCisx LTY1MC00NzktMzIwOCwsMTcxMDY5MDM3NCMjIENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFk YSkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRt b2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --_000_DM6PR08MB50848C69B0319DA2E4C3FB079B379DM6PR08MB5084namp_ 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 OnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Tm90aGluZyBp biBSRkM3OTUwIHNheXMgZHVwbGljYXRlcyBhcmUgYWxsb3dlZC4gV2UgZG9uJ3QgcGxhbiB0byBj aGFuZ2UgdGhhdCAob3IgcGFydGljdWxhcmx5IHNheSBhbnl0aGluZyBhYm91dCBpdCkgaW4gYW55 IG9mIG91ciBZQU5HIHJldmlzaW9uIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJ1dCBtYXliZSBpbiBZQU5HIE5FWFQs ICo8Yj5pZjwvYj4qIGEgU2VtdmVyLWxpa2UgcmV2aXNpb24gbGFiZWwgd2FzIGFkb3B0ZWQgYXMg dGhlIG1haW4gaWRlbnRpZmllciAoYW5kIHJldmlzaW9uIGRhdGUganVzdCBiZWNvbWVzIGEgbm9u LWtleSBhdHRyaWJ1dGUpLCBpLmUuIHlhbmcgbGlicmFyeSB3YXMgY2hhbmdlZCB0byB1c2UgcmV2 aXNpb24NCiBsYWJlbCBpbnN0ZWFkIG9mIHJldmlzaW9uIGRhdGUsIHRoZW4gdHdvIHZlcnNpb25z IGNvdWxkIGJlIGFsbG93ZWQgb24gdGhlIHNhbWUgZGF0ZS4mbmJzcDsgQnV0IHRoYXQncyBmb3Ig YSBZQU5HIE5FWFQgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SmFzb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ow0KPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEp1bmUgOCwgMjAyMSAxOjQ5IFBNPGJyPg0KPGI+VG86PC9iPiBTdGVy bmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkgJmx0O2phc29uLnN0ZXJuZUBub2tpYS5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtuZXRtb2RdIFlBTkcgVmVyc2lvbmluZyBXZWVrbHkgQ2FsbCBNaW51dGVzIC0gMjAyMS0w Ni0wODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEp1biA4LCAyMDIxIGF0IDEwOjM5IEFNIFN0ZXJuZSwgSmFzb24gKE5va2lh IC0gQ0EvT3R0YXdhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20i Pmphc29uLnN0ZXJuZUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Z QU5HIFZlcnNpb25pbmcgV2Vla2x5IENhbGwgTWludXRlcyAtIDIwMjEtMDYtMDg8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlN1Ym1vZHVsZSB2cyBNb2R1bGUgaW4gbW9kdWxlIHZlcnNpb25p bmcgZHJhZnQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gYXZvaWQg J2FydGlmYWN0JywgcHV0ICZxdW90O3N1Ym1vZHVsZSBvciBtb2R1bGUmcXVvdDsgZXZlcnl3aGVy ZSBpdCBpcyBhcHBsaWNhYmxlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pi0gUmVzaGFkOiBhZGQgJnF1b3Q7b3Igc3VibW9kdWxlcyZxdW90OyBpbiBtb3N0IHBsYWNlcy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vbiBkdXBsaWNhdGUgcmV2aXNpb24gZGF0ZXM6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gcmV2aXNpb24tbGFiZWwg aXMganVzdCBhbm90aGVyIGxhYmVsIGZvciB0aGF0IHJldmlzaW9uIGRhdGU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB3ZSB3b24ndCBzYXkgYW55dGhpbmcgaW4gb3Vy IGRyYWZ0cyBhYm91dCBub24tZHVwbGljYXRlIHJldmlzaW9uIGRhdGVzIGluIGEgcmV2aXNpb24g aGlzdG9yeS4gVGhpcyBpcyBzb21ldGhpbmcgZm9yIFlBTkcgTkVYVC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4g eW91IGZpbmQgYW55IHRleHQgaW4gUkZDIDc5NTAgdGhhdCBzYXlzIHRoYXQgYSBtb2R1bGU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpdGggYSBz cGVjaWZpYyBuYW1lIGFuZCByZXZpc2lvbiBkYXRlIGNhbiByZWZlciB0byBtdWx0aXBsZSBZQU5H IG1vZHVsZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JdCBzZWVtcyBsaWtlIHRoZSBvcHBvc2l0ZSBpcyB0cnVlIC0tIHRoYXQgaWYgdGhlIG5h bWUgYW5kIHJldmlzaW9uIGRhdGUgYXJlIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2FtZSB0aGVuIHRoZXkgcmVmZXIgdG8gdGhlIHNhbWUg c3BlY2lmaWMgbW9kdWxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WUFORyBTZW1WZXIgRHJh ZnQgLSBJRVRGIDExMCBmZWVkYmFjazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmFpc2Ug Z2l0aHViIGlzc3VlIGluIHZlcmR0ICphbmQqIGFnYWluc3QgcHlhbmcgdG8gZmxhZyB3aGVuIGEg bW9kdWxlIG9yIHN1Ym1vZHVsZSBpcyBtaXNzaW5nIGEgcmV2aXNpb24gbGFiZWw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlJhaXNlIGdpdGh1YiBpc3N1ZSB0byByZXZpZXcgdGhlIElBTkEg Z3VpZGVsaW5lcyAoaW4gb3VyIDIgZHJhZnRzKSB3aXRoIElBTkEgZm9sa3M8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPldlIGRpc2N1c3NlZCBwcmUtcmVsZWFzZSB2ZXJzaW9uIHByZWNlZGVu Y2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBjYW4ndCBhc3N1bWUg cHJlY2VkZW5jZSBvZiBwcmUtcmVsZWFzZSB2ZXJzaW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tIHdpcGUgb3V0IHRoZSBwcmUtcmVsZWFzZSByZXZpc2lvbiBoaXN0 b3J5IHdoZW4gcHVibGlzaGluZyB0aGUgZmluYWwgdmVyc2lvbiAoU0hPVUxEKSA/Jm5ic3A7IG9y IHdoZW4gcHVibGlzaGluZyBlYWNoIHByZS1yZWxlYXNlIHZlcnNpb24/IFB1dCB0aGlzIGd1aWRh bmNlIGluIE1vZHVsZSBSZXZpc2lvbiBIYW5kbGluZw0KIChpbnN0ZWFkIG9mIFNlbXZlciA/KTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIEpvZSB0byBwcm9wb3NlIHdv cmRpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJnZHMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkphc29uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlZWtseSB3ZWJleCBjYWxsIGRldGFpbHM6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1lZXRpbmcgbnVtYmVyIChhY2Nl c3MgY29kZSk6IDE3MSAwNjkgMDM3NA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk1lZXRpbmcgcGFzc3dvcmQ6IHNlbXZlcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T2NjdXJzIGV2ZXJ5IFR1ZXNkYXkgZWZmZWN0aXZlIFR1ZXNkYXksIFNl cHRlbWJlciAxLCAyMDIwIHVudGlsIFR1ZXNkYXksIEF1Z3VzdCAyNCwgMjAyMSBmcm9tIDk6MDAg QU0gdG8gMTA6MDAgQU0sIChVVEMtMDQ6MDApIEVhc3Rlcm4gVGltZSAoVVMgJmFtcDsgQ2FuYWRh KQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjk6MDAgYW0mbmJzcDsg fCZuYnNwOyAoVVRDLTA0OjAwKSBFYXN0ZXJuIFRpbWUgKFVTICZhbXA7IENhbmFkYSkmbmJzcDsg fCZuYnNwOyAxIGhyDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEg aHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWE3NjI3YTJhZTdi NzcwNTM3Y2ZmNWY1Yjg5MjkzYzcwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL2oucGhwP01USUQ9bWE3NjI3YTJhZTdiNzcwNTM3Y2ZmNWY1Yjg5MjkzYzcwPC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UYXAgdG8gam9pbiBmcm9t IGEgbW9iaWxlIGRldmljZSAoYXR0ZW5kZWVzIG9ubHkpPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPisxLTY1MC00NzktMzIwOCwsMTcxMDY5MDM3NCMjIENhbGwtaW4gdG9s bCBudW1iZXIgKFVTL0NhbmFkYSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0 bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR08MB50848C69B0319DA2E4C3FB079B379DM6PR08MB5084namp_-- From nobody Wed Jun 9 15:27: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 026FC3A28AD for ; Wed, 9 Jun 2021 15:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDVXsPtu0diX for ; Wed, 9 Jun 2021 15:27:23 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE723A28AB for ; Wed, 9 Jun 2021 15:27:23 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id r16so1873223ljk.9 for ; Wed, 09 Jun 2021 15:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p3Xf68THFcF+l9KtdcvghBKaWYtbZtjVAPFvrP7e4fw=; b=mkOYAEk6EfUuV+5W0TAxSAVxsRxwcrZMfZXur8Q/lkAY/L8qXLNi3K472cagzpwmBT 37mU4GUgarNfW9v7Nhz5/17E2Vt1uIegbBa+TV0cS1Xz+SzSCY5ZaMItpIczKlPLZf20 ipKOJTK/DBvbl6flbQTuEeCS1xXwl2TXKjueKJoBAihI2Yt7kcj5lwySx3CpeWPYjq/c 7plVPaegJlp6pcN+ZNPYoSGlHbWphJ5jVlzqXnQetwn4u/KvVtd68rFIiOswPI78nrNx R0dezsXjz4Umojgn9YqXkLZ1ey1w9XD3xtOXt/I6W/vBV2kKDc5LH91aDZ3IYLa6kGNw pJMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p3Xf68THFcF+l9KtdcvghBKaWYtbZtjVAPFvrP7e4fw=; b=EpGIW5Og6rpscxbmoOoX7D7Fi3qcyeUpyAFxaCmw06K2CrRH6nHtXzcRzNKEpuCAWJ eqqxEMOM1raGXE09kEvHv0OBqef8zUMhGcVBsUZXDefG5+liv6ErtlwIfg+et6i2aWJg wGDLQ38YB568JMJZjOuJZt4k2XIO/2JzlESwg9NQF3/JH5BWX8ca8BtQKUrOwxI7Z6DB FlB4tiBwGqXoWrNGxVku5rJUoGndgid4AW8rQo1hUjmewEuj/KX1U0TDeH51hNdXCzrU W07017byvEE2MtmsZS8rcGfsTjjNlH+48IPi5TcbACtQe/CIHqoeGyUecSNw/ecBbm+i eG2A== X-Gm-Message-State: AOAM531XaEnYEXPej/zST8wbAWmS6pNvEdsNU/cXengXAMkjWS263U1p uS4A7t9se/2iOpJfpuXLr47pJx6xTupLFoHfNkrWEA== X-Google-Smtp-Source: ABdhPJwmGwagR/p+r6tMh92kKs6p+fVYL9XiqOXxCeE7/7OpQ1QvzUxWnasbOTEPr7g7FaFBD0FEyaqBNfXabVFA8rw= X-Received: by 2002:a2e:8e28:: with SMTP id r8mr1479039ljk.325.1623277640468; Wed, 09 Jun 2021 15:27:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Wed, 9 Jun 2021 15:27:09 -0700 Message-ID: To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000021de8305c45cc739" Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 09 Jun 2021 22:27:29 -0000 --00000000000021de8305c45cc739 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 8, 2021 at 11:00 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.sterne@nokia.com> wrote: > Hi Andy, > > > > Nothing in RFC7950 says duplicates are allowed. We don't plan to change > that (or particularly say anything about it) in any of our YANG revision > work. > > > > But maybe in YANG NEXT, **if** a Semver-like revision label was adopted > as the main identifier (and revision date just becomes a non-key > attribute), i.e. yang library was changed to use revision label instead of > revision date, then two versions could be allowed on the same date. But > that's for a YANG NEXT discussion. > If we were having a YANG-Next discussion, I would certainly agree that YANG 2.0 should officially use module-name + revision-label and not use revision-date as a module identifier at all. Although non-intuitive, creating a new version of YANG is actually more backward-compatible than continually adding ad-hoc bits and pieces to YANG 1.1. A new language version allows NBC changes to be clearly identified, and lots of NBC changes (like revision-label) are needed to take YANG to the next level. Attempts to fix major problems indirectly (e.g. YANG extensions) will fail in the long run. Good thing we are not discussing YANG-next... > > Jason > Andy > > > *From:* Andy Bierman > *Sent:* Tuesday, June 8, 2021 1:49 PM > *To:* Sterne, Jason (Nokia - CA/Ottawa) > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 > > > > > > > > On Tue, Jun 8, 2021 at 10:39 AM Sterne, Jason (Nokia - CA/Ottawa) < > jason.sterne@nokia.com> wrote: > > YANG Versioning Weekly Call Minutes - 2021-06-08 > > > > Submodule vs Module in module versioning draft: > > - avoid 'artifact', put "submodule or module" everywhere it is applicable > > - Reshad: add "or submodules" in most places. > > > > Non duplicate revision dates: > > - revision-label is just another label for that revision date > > - we won't say anything in our drafts about non-duplicate revision dates > in a revision history. This is something for YANG NEXT. > > > > > > > > Can you find any text in RFC 7950 that says that a module > > with a specific name and revision date can refer to multiple YANG modules? > > It seems like the opposite is true -- that if the name and revision date > are the > > same then they refer to the same specific module. > > > > > > Andy > > > > > > YANG SemVer Draft - IETF 110 feedback > > > > Raise github issue in verdt *and* against pyang to flag when a module or > submodule is missing a revision label > > > > Raise github issue to review the IANA guidelines (in our 2 drafts) with > IANA folks > > > > We discussed pre-release version precedence > > - can't assume precedence of pre-release versions > > - wipe out the pre-release revision history when publishing the final > version (SHOULD) ? or when publishing each pre-release version? Put this > guidance in Module Revision Handling (instead of Semver ?) > > - Joe to propose wording > > > > Rgds, > > Jason > > > > ---------------------------------------------- > > Weekly webex call details: > > Meeting number (access code): 171 069 0374 > > Meeting password: semver? > > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, > August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & > Canada) > > 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr > > https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293c70 > > Tap to join from a mobile device (attendees only) > > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --00000000000021de8305c45cc739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 8, 2021 at 11:00 AM Stern= e, Jason (Nokia - CA/Ottawa) <= jason.sterne@nokia.com> wrote:

Hi Andy,

=C2=A0

Nothing in RFC7950 says duplicates are allowed= . We don't plan to change that (or particularly say anything about it) = in any of our YANG revision work.

=C2=A0

But maybe in YANG NEXT, *if* a Semver-l= ike revision label was adopted as the main identifier (and revision date ju= st becomes a non-key attribute), i.e. yang library was changed to use revis= ion label instead of revision date, then two versions could be allowed on the = same date.=C2=A0 But that's for a YANG NEXT discussion.



If we were having a = YANG-Next discussion, I would certainly agree that
YANG 2.0 shoul= d officially use module-name=C2=A0+ revision-label and not use
re= vision-date as a module identifier at all.

Althoug= h non-intuitive, creating a new version of YANG is actually more
= backward-compatible than continually adding ad-hoc bits and pieces to YANG = 1.1.
A new language version allows NBC changes to be clearly iden= tified,
and lots of NBC changes (like revision-label) are needed = to take YANG to the next level.
Attempts to fix major problems in= directly (e.g. YANG extensions) will fail in the long run.

Good thing we are not discussing YANG-next...

=

=C2=A0

Jason

=

Andy
=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: Tuesday, June 8, 2021 1:49 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
Cc: netmod@ietf= .org
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-= 08

=C2=A0

=C2=A0

=C2=A0

On Tue, Jun 8, 2021 at 10:39 AM Sterne, Jason (Nokia= - CA/Ottawa) <jason.sterne@nokia.com> wrote:

YANG Versioning Weekly Call Minutes - 2021-06-08<= /u>

=C2=A0

Submodule vs Module in module versioning draft:

- avoid 'artifact', put "submodule or m= odule" everywhere it is applicable

- Reshad: add "or submodules" in most plac= es.

=C2=A0

Non duplicate revision dates:

- revision-label is just another label for that revi= sion date

- we won't say anything in our drafts about non-= duplicate revision dates in a revision history. This is something for YANG = NEXT.

=C2=A0

=C2=A0

=C2=A0

Can you find any text in RFC 7950 that says that a m= odule

with a specific name and revision date can refer to = multiple YANG modules?

It seems like the opposite is true -- that if the na= me and revision date are the

same then they refer to the same specific module.=

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

YANG SemVer Draft - IETF 110 feedback<= /p>

=C2=A0

Raise github issue in verdt *and* against pyang to f= lag when a module or submodule is missing a revision label

=C2=A0

Raise github issue to review the IANA guidelines (in= our 2 drafts) with IANA folks

=C2=A0

We discussed pre-release version precedence

- can't assume precedence of pre-release version= s

- wipe out the pre-release revision history when pub= lishing the final version (SHOULD) ?=C2=A0 or when publishing each pre-rele= ase version? Put this guidance in Module Revision Handling (instead of Semver ?)

- Joe to propose wording

=C2=A0

Rgds,

Jason

=C2=A0

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

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

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

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

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

Tap to join from a mobile device (attendees only)=

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

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

--00000000000021de8305c45cc739-- From nobody Fri Jun 11 08:01:29 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0F83A0414; Fri, 11 Jun 2021 08:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqnyFpXt0X5U; Fri, 11 Jun 2021 08:01:22 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2077.outbound.protection.outlook.com [40.107.20.77]) (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 04A3F3A045B; Fri, 11 Jun 2021 08:01:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ahiRDDxu8HI5uLIne/7YE9l5h51BC2qfh+X7ItDZLSyZ3hCAN3JZOygUI+CB1zHCGAwJR3TBD3Ns9WsFkEP1lLphcBGsAHD2mRKcg2Q0Z9pbooovzV6mz1nY6RHX+TnsfQId5/+2titDqzkE+UJQTMsVnYPjqSqTfjQhIR4GidoZlvPzsRLx+1WCFOwm1drDzEzvBRsDEBKCB/PfArYoffWChBWVrmytmsDOJnCwsVXiuNMFBUKUhWn/V+jiS0YSLBD5ioYOAVcNss/Dl9935gJcXjsBxItOYam5d83zNaQj2hgC/eSEnT+Vkic9/mVpBh9TGwkjbRA8WbGl6MEKUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OsdTDAuDT/ia6to/NTLqXLZrxsY0rQ0nWDZB8eFgYlo=; b=DOQvNfC4fJPcktjF57hbm2tMMjHLFLfO8Bxr7BgMVBbi85TjVwrFu7Ya+UB0i/7rWY2c0AEgkY1X6VBAYDzSm6DXhqc3gHRGHYPdocq/rFRRgl2BUidaJmdeuh9/jZIUQD/4g5io16cb6fU4A0YyI8yMJAb8Z12HSE0aN4Hxs0XQ/cWrAtbA9TU/M4LV+5tREkg0KrwEMNfVr3ciqmWbIBnyZki/4TZMCkdHCfcJXQUmwCy0ipl1/eVv4xg9DflLlWeKyVzWBK6pHdFcCvH86ePWMIUNBmWvlW6E5UAfrE2s00Y1Iu2gMdgIf/EbwjZ6YROt1nRC5uvFk7UhSc9KVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OsdTDAuDT/ia6to/NTLqXLZrxsY0rQ0nWDZB8eFgYlo=; b=qllIu8eb14BwGCIfx582u8xkoM1jUzjWX92B7+r484AjXaGx576cAKGP1ALdJSYtDzvDG4RdNsfnFNQbF00kjtzdt6KVTNc2RjL6oMS8pzdg+ndYTaw2xjsIXucIuteWCDP3PD3G5mmVCIFSR8W6LDEJ/uRVP4FXvWUqb2op7d8= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2572.eurprd07.prod.outlook.com (2603:10a6:3:97::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.10; Fri, 11 Jun 2021 15:01:15 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6ce5:7088:a9a8:15d9]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6ce5:7088:a9a8:15d9%7]) with mapi id 15.20.4219.022; Fri, 11 Jun 2021 15:01:15 +0000 From: Francesca Palombini To: Christian Hopps CC: The IESG , "draft-ietf-netmod-geo-location@ietf.org" , "netmod-chairs@ietf.org" , "netmod@ietf.org" , "kent+ietf@watsen.net" Thread-Topic: Francesca Palombini's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) Thread-Index: AQHXTKicqz2cNR7DgUuMysdLRMkUxKr2WqsAgBjSyoA= Date: Fri, 11 Jun 2021 15:01:15 +0000 Message-ID: <0872384B-C41A-4F2F-8D5D-736C78265B89@ericsson.com> References: <162142641389.26028.16682502889430351090@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:1ba8:147a:eb00:c091:d1e1:ec17:aa92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1a6a5c7-e6fc-4c3e-8723-08d92ce9c2b3 x-ms-traffictypediagnostic: HE1PR0701MB2572: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /XCOtdLP82fuIZqF4sUfnBNPh+0TW00phFwPjxjOHTLFYIISE+1ueE8M6WMvazVYT2MkLzBKiyhVI1OG6fCCH74V585MmiIw7gINQERfA4HqdKbaenFwx6RDWuYPt8FKcK41ZjI8QUS1WPSvfy/N2ntECbfPy13CDmSx6A1WsCRbW2hUXkCipPN3sgP+D0HppCK7AmSCTHSMHPxVE+ebT9RY18b6zkkbzVTs8hdAwH070RW0rkWrAmfDq4Frme4/i2DVhlMSHe41FRD/ZH2RJGduXCWogkAJc3/Jkya4Rj25zFzF6+ArK07tdbx0zeOvULS2q+77E7iljp3FcTCskbjXGkJkARaxHxyYleVaT+NBDZERkZXY2PyNd1RvKt5um4G+lcsFONNi8DO29UHaJL4gqprpSI6CjgxxCFTS7AUoaLTuhez3gERCG18GrFQqLlr5dRlyOOob7B5/mqNPoz/HT2FeQHa7vPpxP6yhsvX/bS6KAZdevygzewADjnGQSHT+J7v+A2OCoMjOrJS4FxO9d99yAcK8xVb7a89GQBetHN1ou53mPfb0KWNvM1S/Ro3iotsJlkC5bMlpXspwOMibzxuy7100fmeZZXdPNnOayZro8BFVW1SoIGgpi2hhlupxLuAf8fM8mXz1pnhunEX8yRJQ73D4jVuxgI1OWqfTiAfG8W+VFBcumEFbXHUcj9+7AcO51osq6ieqHjpPLcHaljiq07wqXKUnHm7lMa/1x7o1gY6//bpHVs3npHhsOwg0AXr6OqROISj9Y9u0Hw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(6506007)(54906003)(64756008)(66476007)(76116006)(4326008)(33656002)(66446008)(36756003)(66556008)(186003)(86362001)(2616005)(44832011)(5660300002)(66946007)(71200400001)(6916009)(8936002)(316002)(478600001)(83380400001)(8676002)(6486002)(966005)(2906002)(6512007)(122000001)(38100700002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?M1JTMHpnYXJPVlQrSXVnVjhBdE9SbWp2U3BuaE8yRlpvL3ZFd3pLRFFxNlZu?= =?utf-8?B?Z29qRHJLcW54WEt1NlYxdzN6SWY3aXdMZXlWNDZpSktWRVRka2xYYjJGMTV6?= =?utf-8?B?bHVUV1JqZzRkb2RpenFuVVN6bGhsa3pGQ1E0WDl6WlVzTFQzeGVPWWY0b0xZ?= =?utf-8?B?Qm9nSUcxMUxHV1c0UjYyNGxNT2ZsL3pzeDNqd2pzOGc2dDhPdmNWUlNIcnVh?= =?utf-8?B?SitIR3A1eGlvSXYrZGp3Mm4zeGhQb0tnSjRpV2c2YXBxTG9CbnpzdlJrNUdV?= =?utf-8?B?RlQ0MytOeFpadFB6NXV4MnMzWXpYR2xVekttOWhpSmVqRnREcUhGblQxNEpO?= =?utf-8?B?b3B1eDFxeDNUR0NveGhrd3g1L2Z0VVJCUGFBOFVPcXljRzlqK29FcFd5L2Fz?= =?utf-8?B?Z0YyRFFSR3crMTNoM05TSGd2L25hQ1VVWVZ5djJrTlF3MUo3dlJrU2FHYTBS?= =?utf-8?B?S1ZPNEJsRGlHUlBnTEVFQXEzdzZFTzZMbXY1ZGlJdmxEd1BvdDBUd0NGZjJz?= =?utf-8?B?OGJhSUt2YnU4WGFaZ1J0b0RvVG5KZ29XUjlNelNpNDdaTkZrTVVOY0JYaXI4?= =?utf-8?B?NWwrcFEwRTJCbDFDWVJFcHMyQTRyWkp5Z0pJYU0yb29hdUpvVzYyUnFDcXZT?= =?utf-8?B?cW9VRzZRbzlNVDJWS1BOZE10L1dvMUhaa0YxbWw1NVRYMVdEMm1VSTNoaStx?= =?utf-8?B?cHBFMUdST1RKRjdWQnowcVJjSnJ1Mmk5Wk1NQ1JsZXd6bDFSOWsySlpEMUhV?= =?utf-8?B?VnhFVzFVQXFZNFlMK21EaGlPdnVGajFxMDZKM0ZJR3NqNWUzYzdmWHRUYmtT?= =?utf-8?B?ZU1FQTlkRHpVQzg2SENYcVZOSzF5eFpIVy9GWlk3cGtkeTRueVJqRlhwcWIr?= =?utf-8?B?cEtmSndYcEFqbFQ5dTJTSGJEazdCdktQeVZHbkljQXpadnhUZjh5SCs3T2VC?= =?utf-8?B?SEdTdmlzdHBZcFVCMmFWK3ptN2F5aVZNSkhCN25CMUF0eVJnWDIyOUtmT2Rw?= =?utf-8?B?UE4yaG9xcEk5Sm9XYTFvZXM5SUM3VHpHendhZzNSWnkzVjRrcm5PMDhFYlp3?= =?utf-8?B?ZG9aZFQ0Y0xZa1YxVWlDTzNUbmc1ZnU3b3hZZUNsV1hGVHBCNzQxczNJVGNF?= =?utf-8?B?L3VEVVVHV3dCOW96T1pISGtJRWcrWkdMOGxNUDFKYkdxNzV1ZTVFRmhqOEtP?= =?utf-8?B?THBpQTh5dU1kQ09oZ0dDeGlFTW5mQUNySW9VM2E0VjJZZEEvbUxlSmh3YWdR?= =?utf-8?B?ZUtLWmNCVUYwbURRVXpWdHdiSjRRanJLc0ZHU3dqdWh1K24rSm9Fc3duR1VP?= =?utf-8?B?eGlKeXJIbUhjL1ZJMHpySUtIdzFmditxNWpTQm1iSmx0eTVmZ2F1eldzVUxv?= =?utf-8?B?RzVIZmtRK2kzT0NRMHNyNVA3TWdPNlJiRExNUWxmSlljVDE3YjV0bGpJRW1P?= =?utf-8?B?T2djWmI0TmVVZzBXNTFzNzNjV2NLTkNvT3ZsVytZbjVlOXpQZ1B5akh1NUFt?= =?utf-8?B?Zkd4S3EySmNheTdpSVIwTUo2aFNDeDVPN2lMd0FHWmVkVWFiZzhjTkxuZ01X?= =?utf-8?B?cXV2REFRcXNDZHZPeWxOU0lndldlMDFKaUI4RjVEQ2Z5cWJua1NVQ1luNmJW?= =?utf-8?B?M3haWkF6NURLYXBYaXh1ck1USVJQTjdKaFkzSGtwT0pWU3VWMG5xVmpHZVhj?= =?utf-8?B?ZlZHUThLOFRlK0taR3U5cXY0aDd0VHVYMDJYTEJ4ZElqSFZMdHJYMEtWbW5V?= =?utf-8?B?LzBlNnozVFNraHlKVmN6YkdjWkM1UU5FNlZkZFJRZ0dwR3E3NVVHc08wenBr?= =?utf-8?B?YmppTVRJdzZoSno2OUNIbE5VWDJMS0xVLzJqaFRsaDkwWlFta0RQbWRKZDEr?= =?utf-8?B?L3htYzVrL0pwS0VGbXRKZCtaMkZhL3cyZVZETDMvYVFTdVE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7770E1AF11B6F8428C865D74F69954EA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1a6a5c7-e6fc-4c3e-8723-08d92ce9c2b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2021 15:01:15.3486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: imIyhIYWbGS5sZ42he+ExzG4n142XMVpMefp5w+SpLdTz5uLq7RetvL3nzbNM+Z7NQ1JBkcZad9bOGmue0vP/yE8hRYZL+CIYx/vapPdJjv3AYhMUAmKtF1lXkaQZfBH X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2572 Archived-At: Subject: Re: [netmod] Francesca Palombini's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) 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, 11 Jun 2021 15:01:28 -0000 SGkgQ2hyaXMsDQoNCklubGluZS4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCu+7v09uIDI3LzA1 LzIwMjEsIDAwOjA0LCAiQ2hyaXN0aWFuIEhvcHBzIiA8Y2hvcHBzQGNob3Bwcy5vcmc+IHdyb3Rl Og0KDQoNCiAgICBGcmFuY2VzY2EgUGFsb21iaW5pIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBp ZXRmLm9yZz4gd3JpdGVzOg0KDQogICAgPiBGcmFuY2VzY2EgUGFsb21iaW5pIGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgID4gZHJhZnQtaWV0Zi1uZXRt b2QtZ2VvLWxvY2F0aW9uLTA4OiBEaXNjdXNzDQogICAgPg0KDQogICAgPg0KICAgID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KICAgID4gRElTQ1VTUzoNCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+DQogICAg PiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIG9uIHRoaXMgZG9jdW1lbnQsIGFuZCB0aGFuayB5b3Ug dG8gdGhlIHNoZXBoZXJkIGZvciBhDQogICAgPiB2ZXJ5IHdlbGwtd3JpdHRlbiBzaGVwaGVyZCB3 cml0ZSB1cC4NCiAgICA+DQogICAgPiBJIGhhdmUgYSBjb3VwbGUgb2YgRElTQ1VTUyBwb2ludHMg cmVsYXRlZCB0byB0aGUgSUFOQSBzZWN0aW9uLCBhbmQgc29tZSBub24NCiAgICA+IGJsb2NraW5n IHF1ZXN0aW9uLg0KICAgID4NCiAgICA+IEZyYW5jZXNjYQ0KICAgID4NCiAgICA+IDEuIC0tLS0t DQogICAgPg0KICAgID4gICAgVGhlIGFsbG9jYXRpb24gcG9saWN5IGZvciB0aGlzIHJlZ2lzdHJ5 IGlzIEZpcnN0IENvbWUsIEZpcnN0IFNlcnZlZCwNCiAgICA+ICAgIFtSRkM4MTI2XSBhcyB0aGUg aW50ZW50IGlzIHNpbXBseSB0byBhdm9pZCBkdXBsaWNhdGUgdmFsdWVzLg0KICAgID4NCiAgICA+ IEZQOiBSRkMgODEyNiBzcGVjaWZpZXM6DQogICAgPg0KICAgID4gICAgV2hlbiBjcmVhdGluZyBh IG5ldyByZWdpc3RyeSB3aXRoIEZpcnN0IENvbWUgRmlyc3QgU2VydmVkIGFzIHRoZQ0KICAgID4g ICAgcmVnaXN0cmF0aW9uIHBvbGljeSwgaW4gYWRkaXRpb24gdG8gdGhlIGNvbnRhY3QgcGVyc29u IGZpZWxkIG9yDQogICAgPiAgICByZWZlcmVuY2UsIHRoZSByZWdpc3RyeSBzaG91bGQgY29udGFp biBhIGZpZWxkIGZvciBjaGFuZ2UgY29udHJvbGxlci4NCiAgICA+ICAgIEhhdmluZyBhIGNoYW5n ZSBjb250cm9sbGVyIGZvciBlYWNoIGVudHJ5IGZvciB0aGVzZSB0eXBlcyBvZg0KICAgID4gICAg cmVnaXN0cmF0aW9ucyBtYWtlcyBhdXRob3JpemF0aW9uIG9mIGZ1dHVyZSBtb2RpZmljYXRpb25z IG1vcmUgY2xlYXIuDQogICAgPiAgICBTZWUgU2VjdGlvbiAyLjMuDQogICAgPg0KICAgID4gVGhl IGN1cnJlbnQgcmVnaXN0cnkgZG9zIG5vdCBjb250YWluIGNvbnRhY3QgcGVyc29uLCBub3IgcmVm ZXJlbmNlLCBub3IgY2hhbmdlDQogICAgPiBjb250cm9sbGVyIGZpZWxkcy4NCg0KICAgIEkgaG9u ZXN0bHkgaGF2ZSBubyBpZGVhIHdoYXQgdG8gcHV0IGluIHRoYXQgZmllbGQgZm9yIHRoZSByZWZl cmVuY2VkIHN0YW5kYXJkcy4gQ2VydGFpbmx5IHdlIGNhbid0IGp1c3QgcG9pbnQgcGVvcGxlIGF0 IHRoZSBkZWZpbmluZyBzdGFuZGFyZHMgb3IgcGVvcGxlIHdobyB3cm90ZSB0aGVtIGFzIHRoZXkg aGF2ZSBubyByZWFzb24gdG8gcGF5IGF0dGVudGlvbiB0byBvdXIgWUFORyBncm91cGluZ3MgSUFO QSByZWdpc3RyeS4gU2hvdWxkIEkgcHV0IG15c2VsZiwgb3IgdGhlIE5FVE1PRCB3b3JraW5nIGdy b3VwIHBlcmhhcHM/DQoNCkZQOiBGb3IgdGhlIHZhbHVlIHlvdSByZWdpc3RlciBpbiB0aGlzIGRv Y3VtZW50LCBJIHRoaW5rIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gaGF2ZSB0aGUgcmVmZXJlbmNl IHRvIHRoaXMgZG9jdW1lbnQuIEZvciBjaGFuZ2UgY29udHJvbGxlciwgaXQgaXMgcXVpdGUgY29t bW9uIHRvIGhhdmUgSUVTRy4gVGhhdCB3b3VsZCBtZWFuIHR3byBjaGFuZ2VzOg0KLSBhZGQgMiBj b2x1bW5zOiAiUmVmZXJlbmNlIiBhbmQgIkNoYW5nZSBjb250cm9sIiB0byB0YWJsZSAzLCB3aGVy ZSBSZWZlcmVuY2UgaXMgW1RoaXMgZG9jdW1lbnRdIGFuZCBDaGFuZ2UgY29udHJvbCBpcyBJRVNH LCBmb3IgYWxsIHJvd3MuIChZb3UgZG9uJ3QgbmVlZCB0byBhZGQgb25lIGNvbHVtbiBmb3IgY29u dGFjdCBwZXJzb24sIEkgaGF2ZSBub3RpY2VkIGl0IGlzIHF1aXRlIGNvbW1vbiBmb3IgSUFOQSBy ZWdpc3RyeSB0byB1c2UgdGhhdCBzYW1lIFJlZmVyZW5jZSBjb2x1bW4gdG8gcG9pbnQgZWl0aGVy IHRvIGEgc3RhbmRhcmQgb3IgdG8gYSBjb250YWN0IHBlcnNvbikNCi0gYWRkIGEgc2VudGVuY2Ug c3RhdGluZyB0aGF0ICJSZWZlcmVuY2UiIGNhbiBwb2ludCB0byB0aGUgZG9jdW1lbnQgZG9pbmcg dGhlIHJlZ2lzdHJhdGlvbiBvciB0aGUgY29udGFjdCBwZXJzb24sIGFzIGRlZmluZWQgYnkgUkZD IDgxMjYuDQoNCiAgICA+IDIuIC0tLS0tDQogICAgPg0KICAgID4gICAgSXQgc2hvdWxkIGJlIG5v dGVkIHRoYXQgW1JGQzU4NzBdIGFsc28gY3JlYXRlcyBhIHJlZ2lzdHJ5IGZvcg0KICAgID4gICAg R2VvZGV0aWMgU3lzdGVtcyAoaXQgY2FsbHMgQ1JTKTsgaG93ZXZlciwgdGhpcyByZWdpc3RyeSBo YXMgYSB2ZXJ5DQogICAgPiAgICBzdHJpY3QgbW9kaWZpY2F0aW9uIHBvbGljeS4gIFRoZSBhdXRo b3JzIG9mIFtSRkM1ODcwXSBoYXZlIHRoZSBzdGF0ZWQNCiAgICA+ICAgIGdvYWwgb2YgbWFraW5n IENSUyByZWdpc3RyYXRpb24gaGFyZCB0byBhdm9pZCBwcm9saWZlcmF0aW9uIG9mIENSUw0KICAg ID4gICAgdmFsdWVzLiAgQXMgb3VyIG1vZHVsZSBkZWZpbmVzIGFsdGVybmF0ZSBzeXN0ZW1zIGFu ZCBoYXMgYSBicm9hZGVyDQogICAgPiAgICAoYmV5b25kIEVhcnRoKSBzY29wZSwgdGhlIHJlZ2lz dHJ5IGRlZmluZWQgYmVsb3cgaXMgbWVhbnQgdG8gYmUgbW9yZQ0KICAgID4gICAgZWFzaWx5IG1v ZGlmaWVkLg0KICAgID4NCiAgICA+IEZQOiBUaGFua3MgZm9yIGJyaW5naW5nIHRoaXMgdXAgLSBJ IHdhbnQgdG8gY29uZmlybSB0aGF0IHdlIG5lZWQgdGhpcyByZWdpc3RyeSwNCiAgICA+IGFuZCB0 aGF0IHdlIGFyZSBub3QgY3JlYXRpbmcgYSB3YXkgdG8gYnlwYXNzIHRoZSBDUlMgcmVnaXN0cmF0 aW9uIHBvbGljaWVzIGJ5DQogICAgPiBwcm92aWRpbmcgYSBkaWZmZXJlbnQgcmVnaXN0cnkgd2l0 aCBhIG1vcmUgbGVuaWVudCBwb2xpY3kuDQogICAgPg0KDQpGUDogVGhpcyB3YXMgZGlzY3Vzc2Vk IGR1cmluZyB0aGUgdGVsZWNoYXQgYW5kIGlzIHJlc29sdmVkLCBzbyBhcyBzb29uIGFzIHdlIGFn cmVlIG9uIHBvaW50IDEuIEkgd2lsbCByZW1vdmUgbXkgRElTQ1VTUy4NCg0KICAgID4NCiAgICA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiAgICA+IENPTU1FTlQ6DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg Pg0KICAgID4NCiAgICA+IDMuIC0tLS0tDQogICAgPg0KICAgID4gICAgW1dHUzg0XSAgICBOYXRp b25hbCBJbWFnZXJ5IGFuZCBNYXBwaW5nIEFnZW5jeS4sICJOYXRpb25hbCBJbWFnZXJ5DQogICAg PiAgICAgICAgICAgICAgIGFuZCBNYXBwaW5nIEFnZW5jeSBUZWNobmljYWwgUmVwb3J0IDgzNTAu MiwgVGhpcmQNCiAgICA+ICAgICAgICAgICAgICAgRWRpdGlvbi4iLCAzIEphbnVhcnkgMjAwMCwg PGh0dHA6Ly9lYXJ0aC0NCiAgICA+ICAgICAgICAgICAgICAgaW5mby5uZ2EubWlsL0dhbmRHL3B1 YmxpY2F0aW9ucy90cjgzNTAuMi93Z3M4NGZpbi5wZGY+Lg0KICAgID4NCiAgICA+IEZQOiBJIHN1 cHBvcnQgTGFycyBESVNDVVNTLCBhbmQgYWRkIHRoZSBmb2xsb3dpbmcgbm9ybWF0aXZlIHJlZmVy ZW5jZSB0byB0aGUNCiAgICA+IGxpc3QgLSBsaW5rIGlzIGJyb2tlbi4gQSBxdWljayBnb29nbGUg c2VhcmNoIGZvdW5kIHRoaXM6DQogICAgPiBodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3Yx L3VybD9rPThjNGRjOWI3LWQzZDZmMDlhLThjNGQ4OTJjLTg2OTJkYzgyODRjYi1jMGRmMTliNjI5 NTUzZDllJnE9MSZlPTdlNDRjOTE2LWZmNDctNGRhZS1iMTkzLWE4OTI4M2M0OTQ3MiZ1PWh0dHBz JTNBJTJGJTJGZ2lzLWxhYi5pbmZvJTJGZG9jcyUyRm5pbWEtdHI4MzUwLjItd2dzODRmaW4ucGRm ICwgd2hpY2ggSSBhc3N1bWUgaXMgdGhlDQogICAgPiB3YW50ZWQgcmVmZXJlbmNlLi4uIGJ1dCBJ IGRvbid0IHRoaW5rIHRoYXQgd2Ugc2hvdWxkIGJlIHJlbHlpbmcgb24gaW5mb3JtYWwNCiAgICA+ IGNvbW11bml0aWVzIHRvIG1haW50YWluIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIG91ciBkb2N1 bWVudHMsIGNhbiB3ZSBkbyBiZXR0ZXI/DQoNCiAgICBJIHJlbW92ZWQgdGhlIFVSTHMgLS0gb2J2 aW91c2x5IHRoZXkgYXJlIG5vdCBzdGFibGUuIFNvIHdlIGNhbiBwcm9jZWVkIHdpdGggdGhlIG5v cm1hbCBkb2N1bWVudCB0aXRsZSwgYXV0aG9yLCBhbmQgcHVibGljYXRpb24gZGF0ZS4NCg0KRlA6 IEkgc2VlIHRoYXQgdGhlcmUgd2FzIGRpc2N1c3Npb24gd2l0aCBMYXJzIGFib3V0IGl0LCBzbyBJ IHdpbGwgbGVhdmUgaXQgdXAgdG8geW91IGFuZCBSb2IgdG8gZGVjaWRlIHRoZSBiZXN0IHdheSBm b3J3YXJkLiBIb3dldmVyIEkgZG8gYWdyZWUgd2l0aCBMYXJzIChhbmQgcXVvdGluZyBoaW0pIHRo YXQ6DQoiLi4gc2luY2UgeW91J2Qgd2FudCB0aG9zZSByZWZlcmVuY2VzIHRvIGJlIGVhc2lseSBh bmQgdW5hbWJpZ3VvdXNseSBmaW5kYWJsZSBieSByZWFkZXJzL2ltcGxlbWVudGVycywgaW5jbHVk aW5nIHRoZW0gaXMgdXN1YWxseSB2ZXJ5IGhlbHBmdWwsIGVzcGVjaWFsbHkgZm9yIG5vcm1hdGl2 ZSByZWZlcmVuY2VzLCB3aGljaCBhcmUgYmFzaWNhbGx5IHJlcXVpcmVkIHJlYWRpbmcuIiBTbyBt eSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGtlZXAgdGhlIFVSSSB0byB0aGUgbW9zdCBzdGFibGUg cG9zc2libGUgbGluay4NCg0KICAgID4gNC4gLS0tLS0NCiAgICA+DQogICAgPiAgICBjaG9pY2Ug ImxhdGl0dWRlIiBhbmQgImxvbmdpdHVkZSIgYXJlIHNwZWNpZmllZCBhcyBmcmFjdGlvbnMgb2YN CiAgICA+ICAgIGRlY2ltYWwgZGVncmVlcywgYW5kIHRoZSAiaGVpZ2h0IiB2YWx1ZSBpcyBpbiBm cmFjdGlvbnMgb2YgbWV0ZXJzLg0KICAgID4gICAgRm9yIHRoZSBDYXJ0ZXNpYW4gY2hvaWNlICJ4 IiwgInkiIGFuZCAieiIgYXJlIGluIGZyYWN0aW9ucyBvZiBtZXRlcnMuDQogICAgPg0KICAgID4g RlA6IEkgaGF2ZSB0aGUgZmVlbGluZyB0aGF0IHRoZSBkb2N1bWVudCBpcyBzcGVjaWZ5aW5nIGJv dGggbnVtZXJpYyBkYXRhDQogICAgPiBleHBlY3RlZCBhbmQgdW5pdCBhdCB0aGUgc2FtZSB0aW1l ICJmcmFjdGlvbiBvZiBfaW5zZXJ0IHVuaXRfIi4gRm9yIHRoZSBzYWtlIG9mDQogICAgPiBjbGFy aXR5LCBJIHRoaW5rIGl0IHdvdWxkIGJlIGJlc3QgdG8gc3BsaXQgdGhpcyB1cCwgc28gY2hhbmdl IHRoZSAiZnJhY3Rpb24gb2YNCiAgICA+IG1ldGVycyIgdG8gIm1ldGVycywgZXhwcmVzc2VkIGlu IGZsb2F0aW5nIHBvaW50Ii4gVE9ETzogY2hlY2sgdGhhdCBmb3JtYXQgaXMNCiAgICA+IGRlZmlu ZWQuDQoNCiAgICBJdCBpcyBzcGVjaWZ5aW5nIHVuaXRzIGFuZCB0aGVpciBmb3JtYXQsIEkgZmVs dCB0aGlzIHdhcyBzaW1wbHkgY29uY2lzZSwgYnV0IG5vdCBjb25mdXNpbmcuIERvIHlvdSBmZWVs IHN0cm9uZ2x5IGFib3V0IHRoaXM/IEZXSVcgd2UgdXNlIFlBTkcgZGVjaW1hbDY0IG5vdCBmbG9h dGluZyBwb2ludCBpbiB0aGUgWUFORyBncm91cGluZy4NCg0KRlA6IE5vIEkgZG9uJ3QgZmVlbCBz dHJvbmdseSBhYm91dCB0aGlzLCBhbmQgYXMgeW91IHNheSB0aGF0IGlzIGRlZmluZWQgaW4gdGhl IFlBTkcgZ3JvdXBpbmcuIEl0J3MgZmluZSBrZWVwaW5nIGl0IHRoaXMgd2F5LCB0aGFua3MgZm9y IHRoZSBhbnN3ZXIuDQoNCiAgICA+IDUuIC0tLS0tDQogICAgPg0KICAgID4gRlA6IEFmdGVyIGxv b2tpbmcgZm9yIGEgd2hpbGU6IGRvZXMgYSBzdGFibGUgcmVmZXJlbmNlIGV4aXN0IGZvciB0aGUg bGlzdCBvZg0KICAgID4gYXN0cm9ub21pY2FsIGJvZGllcyBhbmQgdGhlaXIgbmFtZSAocmF0aGVy IHRoYW4ganVzdCBzYXlpbmcgaXQgaXMgbWFpbnRhaW5lZCBieQ0KICAgID4gSUFVKT8gSSBvbmx5 IGZvdW5kIHRoZSBmb2xsb3dpbmcgZm9yIHN0YXJzOg0KICAgID4gaHR0cHM6Ly9wcm90ZWN0Mi5m aXJlZXllLmNvbS92MS91cmw/az04MTVhNTkyMy1kZWMxNjAwZS04MTVhMTliOC04NjkyZGM4Mjg0 Y2ItMzdiYzBmMTg1MDhiYjIyZSZxPTEmZT03ZTQ0YzkxNi1mZjQ3LTRkYWUtYjE5My1hODkyODNj NDk0NzImdT1odHRwcyUzQSUyRiUyRnd3dy5pYXUub3JnJTJGcHVibGljJTJGdGhlbWVzJTJGbmFt aW5nX3N0YXJzJTJGIC4gSSBhbHNvIGZvdW5kIHRoZSBwYWdlIGZvciB0aGUNCiAgICA+IGNvcnJl c3BvbmRpbmcgV0csIHdoaWNoIGRlZmluZWQgdGhlIGd1aWRlbGluZXMgZm9yIG5hbWluZyBzdGFy cy4gSSB3YXMNCiAgICA+IHdvbmRlcmluZyBpZiB0aGVyZSBpcyBhIHJlZmVyZW5jZSB0byB0aGVz ZSBndWlkZWxpbmVzIGZvciBhbGwgYXN0cm9ub21pY2FsDQogICAgPiBib2RpZXMuIFdoYXQgSSBh bSBlc3BlY2lhbGx5IGNvbmNlcm5lZCBhYm91dCBpcyB0aGF0IEkgd2FzIG5vdCBhYmxlIHRvIHZl cmlmeQ0KICAgID4gdGhhdCB3ZSB3aWxsIG5vdCBpbmN1ciBvbiBlbmNvZGluZyBwcm9ibGVtcywg aWYgSUFVIGNoYW5nZXMgdGhlaXIgbmFtaW5nDQogICAgPiBjb252ZW50aW9ucywgZ2l2ZW4gdGhl IGZvbGxvd2luZyB0ZXh0IGluIHRoZSBkb2N1bWVudDoNCiAgICA+DQogICAgPiAgICAgICAgICAg ICAgICAgJzY3cC9jaHVyeXVtb3YtZ2VyYXNpbWVua28gKGEgY29tZXQpLiBUaGUgdmFsdWUgc2hv dWxkDQogICAgPiAgICAgICAgICAgICAgICAgYmUgY29tcHJpc2VkIG9mIGFsbCBsb3dlciBjYXNl IEFTQ0lJIGNoYXJhY3RlcnMgbm90DQogICAgPiAgICAgICAgICAgICAgICAgaW5jbHVkaW5nIGNv bnRyb2wgY2hhcmFjdGVycyAoaS5lLiwgdmFsdWVzIDMyLi42NCwgYW5kDQogICAgPiAgICAgICAg ICAgICAgICAgOTEuLjEyNikuIEFueSBwcmVjZWRpbmcgJ3RoZScgaW4gdGhlIG5hbWUgc2hvdWxk IG5vdCBiZQ0KDQogICAgTm8gSSBkb24ndCBoYXZlIGEgc3RhYmxlIHJlZmVyZW5jZS4gSXQgd2Fz IHZlcnkgaGFyZCB0byB0cmFjayBhbGwgb2Ygd2hhdCBJIGhhdmUsIGRvd24uIFRoZSBiZXN0IEkg Y291bGQgZG8gd2FzIGp1c3QgcG9pbnQgYXQgdGhlIElBVS4NCg0KRlA6IEkgc2VlIHRoYXQgUm9t YW4gaGFzIHRoZSBzYW1lIGNvbW1lbnQgYXMgbWUgaW4gaGlzIERJU0NVU1MsIEknbGwgbGV0IHlv dSBhbmQgUm9iIHNvbHZlIHdpdGggaGltLiBUaGUgcG9pbnQgaXMgdGhhdCB3aXRob3V0IGEgY2xl YXIgcmVmZXJlbmNlLCB0aGUgZGVzY3JpcHRpb24gb2YgICJBbiBhc3Ryb25vbWljYWwgYm9keSBh cyBuYW1lZCBieSB0aGUgSW50ZXJuYXRpb25hbCBBc3Ryb25vbWljYWwgVW5pb24gKElBVSkgIiBi ZWNvbWVzIGhhcmQgdG8gZW5mb3JjZS4NCg0KICAgIFRoYW5rcywNCiAgICBDaHJpcy4NCg0K From nobody Fri Jun 11 13:12: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 9CBE53A140A for ; Fri, 11 Jun 2021 13:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pf4osN_xtNwg for ; Fri, 11 Jun 2021 13:12:09 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2132.outbound.protection.outlook.com [40.107.223.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253533A1409 for ; Fri, 11 Jun 2021 13:12:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FF8xLKkHmiuYEG2oql0BAcR7N1YBUhX26TdHbiRC3+g78mSBEba0QxDGQK4cL/Qk4crPOs0+4v2FWaU3iUQJZ4chqVV/vzsSw9QJKWVFZGZs5jvK2T/hbzBWwNypwlFaURDsYWbh9QryzNZO5+6tmGts9Hbccsb6ulCDIIQzdtVB++4Y4svIvn4mFH1Ui677a7mYzBvwQuSnAFD1jV789P0RTz/wOfATJKAwltE15HYV4J4u0WABeVnT2qBVXzSMEQisg/kOLeqNB4ArTfffYAD9ww7Id8Z5ThApELmGVa9JbNOoaZXXvA9hL6ud/7RjMCJgt6TNmSUx+1+QA26hVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aDD15hgqqYAVh+Sr1FpuRT5zWfp/slht15xncfLftLQ=; b=KUTS3j3GpcxbeJp/IF6AbiKylB/D2wH8PaisHmdqkeDRP1K/UYisIsivucXdZ2fMD13/0OAt6kheGJ0+C/li3gel79o3FyFv96/OY6C2WeMmmrJmB4iVRVhnM6Q0ba/vWEDDzeiKQwtuYLSfczspga9WY+M8x0SZHkU+w6gLGiiF6ULrAfSszB0vQ5eEHMG17Y+rmtTT5goYq/mYXDB1MR5FCcWauv+BMAzyHEkU8myMqxN988K1utYmAUNa8QU++cNtjlkYBGuiMaIytNY9hCJhKSLPWSOzurFaMGxHmAzudcqq+stOmH+/vjliCM1Zk+7OgT0FCmdbSvDXSqZy0Q== 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=aDD15hgqqYAVh+Sr1FpuRT5zWfp/slht15xncfLftLQ=; b=niXH2vThn3wHsF1JL62fP+Kra1M9Q0WSLmagOyNR1A6niqdwlw2V5WVmmbYhloibeuZ2bpt1A0WYeATVbzFgaBtj6utsidN/lS3Mh5U8ZnGrhp+OkOIsaGHQEsd2WDgTqoUuTABMHBTplT25LRISYYwgf7OmyQznTFfm+dpW94g= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB2939.namprd08.prod.outlook.com (2603:10b6:3:150::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.23; Fri, 11 Jun 2021 20:12:05 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4195.030; Fri, 11 Jun 2021 20:12:05 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-06-08 Thread-Index: AddcjRHyR82Br9bERdeXBXT0W+r1igCcNUWg Date: Fri, 11 Jun 2021 20:12:05 +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: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2607:f2c0:e4ae:97:6cd0:182b:8e85:6c8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19fb2451-aef8-4cf8-22da-08d92d152ed6 x-ms-traffictypediagnostic: DM5PR08MB2939: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pQjxTL/VjSxT6davPHlw2iECUgM1XoaT4epudaVSXxVlM/0mdgQlRrt7JkWlZzMaCKrqfA9MUuukdVFqqWml4DcjhZqHTVvTN30KBI8CaT1yt+3UE4Epa+9yhlKXdj0siXcY6IuEcmebG8eLEc8EE+fFPTxOMAV02lLluJvPBoeiN/lyvNa4d5hwh9X2vFCczdpB1fMpaIvoSsGg9lNnRtDYgkdsuqFCE7DPs5xhVEbu5nTbyMy9fDhZV0SRotv8UfkSXBfYR/pb1mcH8EO8xLKptz9HvS23Jk0tHkUL2azv20ggb1Cvnd5/JjTg1jlhV9Qx3N0JsPoMuitCftvEfLuIlocyCXDJ8E1ag53/hK2r7XE72LeB1GRjsonWJpmXWf58t58ZQbaggi5uZCEgroczEjWpnrwGrCWUQb0ZO3KTCxZ3hwgtbtnJzZi7umhoHYpynf9XKOiZrVlvP2qy5FOiZXMM3orozwia42WEGw2BlBeg7ruaDW1fQauPnbRbEHildPFs39qBSomX0mkKn+PYRyQHYbzr3qga0vUjpfoHeTRCRGNkCZa03hxB1jkrQ7mqmgKLhz3Z5KHmprIzJWiw1WKgoUEPwnyZD+yvKA4ysJUhtcHzuw5sSnWlJzkomJVM3uiWY6dHqmnxmkqNixFyIVLXA3yurCxg4VGn0VOkxrlKwL86pNbCp9jzSArSBasGUU/+LgxN/Y7fDPorE7/wELM9HdD7E984XKxvPQeBeNNXPD6B1aUlxGcrzuo1MTlrXcfkuBHAkfo1Ng5dKg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39860400002)(136003)(366004)(376002)(55016002)(9686003)(71200400001)(8936002)(110136005)(38100700002)(8676002)(186003)(316002)(122000001)(7696005)(478600001)(86362001)(6506007)(66556008)(16799955002)(53546011)(5660300002)(66476007)(166002)(2906002)(66946007)(33656002)(76116006)(83380400001)(64756008)(52536014)(66446008)(966005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?z/GCeb1a74V+5Pe5mfW9YOEAAdnFwcJeohjLSc3e8+/+CxTuIaqE0cT64EVe?= =?us-ascii?Q?3zKqstoxGItWyknuU5KIztsB3qniWqjsb4gXl2ep3YTGKhfmXxkAUI8B5CBp?= =?us-ascii?Q?KnSTxTGpj0vRHtp7wFqt2fWVyCwZ+EH4rDgDCHZO6YnQcmeMGopUFNocQlWh?= =?us-ascii?Q?BWzxUQWqfK6/mqPGn7crKJVRZlzuiy04+jSgGnQz/GPTStDs9iYsCndYnZBC?= =?us-ascii?Q?Ue0kc+T7oXzX21wwhDYNCo1bsJFrs1V4hwKergsSjMrF+UTKg39rQjxTpi7D?= =?us-ascii?Q?4T2rbSC47eSLBXNwPJgR++USAJx0XGwqlddac7RxWo0RxaFhpGBAzt9172Pb?= =?us-ascii?Q?2NYj/nd0qHzzoicuFopCYfRGHpy/Nn6PxzTJuLwJagFBksfKfCiU/Xzjabzd?= =?us-ascii?Q?SFudheOGWEvfB8pFL2D1JUEJ8G9wFFwPs9hWbFIPr/1cMPMWLxUTttWwoGyr?= =?us-ascii?Q?olmnow9W2Iy7BqNZ9zMGYXsWfS/5S5V+lLzUD8MWf4nP1IiBbdAeRorXipMZ?= =?us-ascii?Q?EXjr+vPBOxbukUqlx4h4qt4nTupu9I42MwXXfzrSKLNBZeEXS8TFPRBDENPf?= =?us-ascii?Q?oQ+iBuswxSSf5sYmTlLZYnM+uL6XDwmfVODlffELAElpyE24cpwJ5gnO98VU?= =?us-ascii?Q?oxL+OAHkXAiLvkuTtWLrnLMZPCO0880lmzD95Ue583etok7o4XYEcBlqa+FT?= =?us-ascii?Q?zkajNtJgVagoxPoX6MfILHJvF7eT96ASLZ1lcYqW6bbMjHQ2e9JK6/3cMBF+?= =?us-ascii?Q?M2oKSrpTlpsCXSKupNyzbIw/xZIZK7K8oit2E2elvOZ57afPNobOjwSQzOF1?= =?us-ascii?Q?LQF9JV6GvFOPdOSZloeOrFGlc/BCInlGKvwrxMmz25bahQw4tvwQz76wmclQ?= =?us-ascii?Q?8YHdhziEQa1VspGfBjWaCRmQFHzGxnnwq9l+ZnFb916TQeHBfNpsecpOwS4s?= =?us-ascii?Q?pfvgjofRVaMZFHdUfARwpeRzJTOzU/1wNqplLi0jz3k30dTE85eHYUdmhW/a?= =?us-ascii?Q?88G9+qUHPE+uItxhLgTgo7ImW+WPXhmuFeeNW/tNziapZ7OkTn0E3Gs3rdgX?= =?us-ascii?Q?c0x809xiv+q8RZTqiQnwqjTOW5cnEUaTs+e9Fv8OgI10wRh1hwDDux8CI8NE?= =?us-ascii?Q?CWjopPt26CqQUwdrYou0/Whvj+ZAbJi53OyOH1F9RfSFOx5QDThGXSxCM5Mx?= =?us-ascii?Q?DoheKqQq9Fi89USJZg3epLujjHl8lkEzYW839gwevGEpQa+hmJh/ULqP1D6t?= =?us-ascii?Q?NO4twDLt8uBJD41NvVKXqf1KsVVGShvXwi7hBTRa6VNL/batQcxmHyNZQ++T?= =?us-ascii?Q?vmy96Ydw72dsH2Ha8f2hmHs5pr1RWew4dE5zu1lRNS21xOBYDdLW2EhIUvZm?= =?us-ascii?Q?Awl4jkkXkBDwcOP8416uu5dIbCES?= Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084BA2A760E6C4397B0C83B9B349DM6PR08MB5084namp_" 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: 19fb2451-aef8-4cf8-22da-08d92d152ed6 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2021 20:12:05.2105 (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: aABSEyKh7cpoklY0/YkNEj3kvFyzP8MB24qnxfdWDD1hL1WK4WE0zZPskFPhVlULXfG1HM+Qywvm5TafSJSxwA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2939 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 11 Jun 2021 20:12:16 -0000 --_000_DM6PR08MB5084BA2A760E6C4397B0C83B9B349DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I raised an issue in the verdt project about pyang checking for revision-la= bel: pyang --ietf should check if a module has a revision-label * Issue #99 * ne= tmod-wg/yang-ver-dt (github.com) From: netmod On Behalf Of Sterne, Jason (Nokia - = CA/Ottawa) Sent: Tuesday, June 8, 2021 1:39 PM To: netmod@ietf.org Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 YANG Versioning Weekly Call Minutes - 2021-06-08 Submodule vs Module in module versioning draft: - avoid 'artifact', put "submodule or module" everywhere it is applicable - Reshad: add "or submodules" in most places. Non duplicate revision dates: - revision-label is just another label for that revision date - we won't say anything in our drafts about non-duplicate revision dates in= a revision history. This is something for YANG NEXT. YANG SemVer Draft - IETF 110 feedback Raise github issue in verdt *and* against pyang to flag when a module or su= bmodule is missing a revision label Raise github issue to review the IANA guidelines (in our 2 drafts) with IAN= A folks We discussed pre-release version precedence - can't assume precedence of pre-release versions - wipe out the pre-release revision history when publishing the final versi= on (SHOULD) ? or when publishing each pre-release version? Put this guidan= ce in Module Revision Handling (instead of Semver ?) - Joe to propose wording Rgds, Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB5084BA2A760E6C4397B0C83B9B349DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I raised an issue in the verdt project about pyang c= hecking for revision-label:

pyang --ietf should check if a module has a revision-label &midd= ot; Issue #99 · netmod-wg/yang-ver-dt (github.com)

 

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: Tuesday, June 8, 2021 1:39 PM
To: netmod@ietf.org
Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

 

YANG Versioning Weekly Call Minutes - 2021-06-08

 

Submodule vs Module in module versioning draft:=

- avoid 'artifact', put "submodule or module&qu= ot; everywhere it is applicable

- Reshad: add "or submodules" in most plac= es.

 

Non duplicate revision dates:

- revision-label is just another label for that revi= sion date

- we won't say anything in our drafts about non-dupl= icate revision dates in a revision history. This is something for YANG NEXT= .

 

YANG SemVer Draft - IETF 110 feedback

 

Raise github issue in verdt *and* against pyang to f= lag when a module or submodule is missing a revision label

 

Raise github issue to review the IANA guidelines (in= our 2 drafts) with IANA folks

 

We discussed pre-release version precedence

- can't assume precedence of pre-release versions

- wipe out the pre-release revision history when pub= lishing the final version (SHOULD) ?  or when publishing each pre-rele= ase version? Put this guidance in Module Revision Handling (instead of Semv= er ?)

- Joe to propose wording

 

Rgds,

Jason

 

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

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

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

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

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

Tap to join from a mobile device (attendees only)

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

--_000_DM6PR08MB5084BA2A760E6C4397B0C83B9B349DM6PR08MB5084namp_-- From nobody Sun Jun 13 18:10: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 1848D3A18B4; Sun, 13 Jun 2021 18:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQcGBxg2u_nS; Sun, 13 Jun 2021 18:09:55 -0700 (PDT) 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 448DB3A18B3; Sun, 13 Jun 2021 18:09:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D2EBE38B27; Sun, 13 Jun 2021 21:10:57 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AM1pyRuQRnEb; Sun, 13 Jun 2021 21:10:57 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 498D738B25; Sun, 13 Jun 2021 21:10:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EBD422B3; Sun, 13 Jun 2021 21:09:52 -0400 (EDT) From: Michael Richardson To: netmod@ietf.org cc: anima@ietf.org, tools-discuss@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] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 01:10:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm not a regular netmod reader. I subscribe via IMAP to look into what's going on. If I'm asking a FAQ, I appologize as I didn't find anything in the 25K messages archived. I saw Christian's message in 2019 about org-rfc-export. I'm not sure if I should Reply-To: tools or netmod. I'm looking for advice on how to manage things. A summary of my questions: 1) how to process yang files with YYYY-DD-MM into XML. 2) how to generate yang tree files. 3) how do I get my YANG includes downloaded, and do I put them into my repo? 4) how to do this with MT Makefiles? When we were working on RFC8995 and RFC8366, in the days before Martin Thompson's makefile was around, I just put pyang processing into my simple Makefile. It's here: https://github.com/anima-wg/anima-bootstrap/blob/mas= ter/Makefile The perl script at: https://github.com/anima-wg/anima-bootstrap/blob/master= /insert-figures was then developed to insert stuff into the XML. It's rather hacky in some= ways. It started it's life as just something to find the latest @YYYY-MM-DD yang file which the Makefile created. (Kent wrote that sed line three quarters of a decade ago, and the sed line now is old enough to trick-or-treat) Over time, it grew the ability to insert other bits of code or diagrams. I keep using it, even when I've moved to Markdown because it inserts the right artwork stuff, and knows to deal with YANG stuff. I also keep using = my Makefile, because except for the simplest uses, the MT ones are too complicated for me to hack. With kramdown source, I can mostly just add stuff to the MT Makefile to generate the files I need, and then mostly (without insert-figures), I can use the ::include mechanism in kramdown to get the right things. But, no magic YYYY-MM-DD stuff. So now I am collaborating with some co-authors which want to stick to XMLv3 rather than kramdown, and whose understanding of Makefiles is poor. I want to stick with the normal stuff so that all the github/etc. tooling works for everyone involved. I'm looking for advice on how do this this? =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+93Q3WUFAmDGrGAACgkQgItw+93Q 3WWc3Qf+N+XVM1joi4OF1bvfU6VxbuPodS/6wVwcLgR05yN+0yAZWq51BK+76rfo vE8YcjmP9h0ENRP7UxG1FOGudtdYTBclJMEtsf6SCTPt+LHvFRR/GiamPutWDVn8 W6r3Fbtouh3Xw9HzbezrVslA6T6R8EItVTa0BFZR+UWgXFG3UrFgDcLgs9iguwEb k8qunerfRdY2+pfUgusIuJGSbZC4cfOtloIYsWy8r1rlvNEP2xwrVblBaZwuw6qc 1eNPmhdaY0D0wdJD62kILFsQZihF2TiBe3Id9qc2mczM0bN5wyeqRSInVbUgVnpH JWL3zaMZVlvAkId3GsCpOB3wRRr/KA== =ocdM -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 13 18:19: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 467A83A1901; Sun, 13 Jun 2021 18:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0686TecFvlk; Sun, 13 Jun 2021 18:19:35 -0700 (PDT) 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 493783A1900; Sun, 13 Jun 2021 18:19:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6BC9838B32; Sun, 13 Jun 2021 21:20:37 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 41CqVSoLRIo6; Sun, 13 Jun 2021 21:20:36 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 08F5D38B25; Sun, 13 Jun 2021 21:20:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A59062B3; Sun, 13 Jun 2021 21:19:31 -0400 (EDT) From: Michael Richardson to: netmod@ietf.org, tools-discuss@ietf.org, anima@ietf.org In-Reply-To: <6795.1623632992@localhost> References: <6795.1623632992@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] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 01:19:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > 3) how do I get my YANG includes downloaded, and do I put them into m= y repo? RFC8995 has been published. It has a YANG module, ietf-voucher-request, which is derived from the RFC83= 66 ietf-voucher. RFC8366 has: ietf-voucher@2018-05-09 The DT still points at: https://www.yangcatalog.org/yang-search/module_details.php?module=3Dietf= -voucher@2017-10-25.yang but search on that page leads me to: https://www.yangcatalog.org/yang-search/module_details.php?module=3Dietf-= voucher which has the 2018-05-09 version, although I don't know how to reference it except for search for it. But, finally, it's even at: /usr/local/lib/python3.7/dist-packages/pyang-2.3.2-py3.7.egg/share/yang/= modules/ietf so including ietf-voucher should not be a problem. It seems that the yang modules ought to go into a different package than the pyang itself, and ideally, I'd like to be able to rsync it. I'd further li= ke if pyang could download stuff and cache it like xml2rfc (and kdrfc) does. Until that point, what should I do? I have been just putting the .yang fil= es into my repository where I derive stuff from them. How do I get the DT to be updated on YANG pointers? =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+93Q3WUFAmDGrqMACgkQgItw+93Q 3WWlOAf/X8XTldFIzPsaLgN4TCWRb7LidPRQdVorqJYC8t+SLWBArZJMcsc+eby8 1IUHERKHGpOzqAi1fjP0nvSrHps/DTNViDh9PYFSZjbZWXvZKjSAw1iG0ZFumf1V eoFzaUyeIA4HMTfGCvdy85zH0/XSDaqJ5P3hGeuyG6OIrfGxMo52IdfLB8AmvO3p 83pkz2Z9dSLmCris40XNxfVILAoJEyaqhW8XbW3M/KXSsIaTBuJ6Rwv+WRdon0B+ sntsW5iIlPwElPgu+vTrvahDCs+x23o+vIQlR/AvC3sUalyrXsi7ECPvXdNVRSSy xCZBbPzgnM5j8SttT4EKEJJEK+8/dA== =Gvty -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 13 18:33:48 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3345C3A197F; Sun, 13 Jun 2021 18:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_yAQm4k4L1e; Sun, 13 Jun 2021 18:33:24 -0700 (PDT) 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 3F9F83A197D; Sun, 13 Jun 2021 18:33:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 27AFA38B3C; Sun, 13 Jun 2021 21:34:27 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HVYvRGfkUJo2; Sun, 13 Jun 2021 21:34:26 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A2A2B38B2B; Sun, 13 Jun 2021 21:34:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 41BD92B3; Sun, 13 Jun 2021 21:33:22 -0400 (EDT) From: Michael Richardson To: netmod@ietf.org, anima@ietf.org, core@ietf.org In-Reply-To: <6795.1623632992@localhost> References: <6795.1623632992@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] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 01:33:29 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > 3) how do I get my YANG includes downloaded, and do I put them into m= y repo? The other part of the question is how to manage the various extensions that are occuring. What I know about so far: (ascii art warning. fixed font nee= ded) https://www.yangcatalog.org/yang-search/impact_analysis/ietf-voucher@2018-0= 5-09 RFC8355(voucher) ----> RFC8995(voucher-request) \ \ |\ |\ | \ | \ | ietf-anima-constrained-voucher | ietf-anima-constrained-voucher | [ietf-constrained-voucher] | [ietf-constrained-voucher-requ= est] | | \ \ |\ \ | \ \ | ietf-anima-brski-cloud ietf-anima-brski-async-enroll | [ietf-redirected-voucher] [ietf-async-voucher-request] \ \ \ richardson-anima-voucher-delegation [ietf-delegated-voucher] * ietf-{redirected,delegated}-voucher are probably bad names, and it should be ietf-voucher-{redirected,delegated}. Just noticed that. So far, we haven't needed to mix anything from voucher extensions into voucher-requests extensions. But, having a constrained-voucher which is also a delegated-voucher does ma= ke sense. Since the constrained-voucher users the yang-sid to serialize to CBOR, I don't know exactly how that is going to work. I would sure like be sure that we know to mix and match these groupings. I suspect that one has to write a new YANG file importing all the different groupings? I also suspect that it might be time for RFC8366bis that just wraps these things all up into a single document. =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+93Q3WUFAmDGseIACgkQgItw+93Q 3WUPKwf+LNv8YQPCr8DxBYRvmCIb10Sa8STETR7lFhHJALBwT3t+VcruU4rE2/xd LUZlMrFoW15NnmfgarWeIKUFmDoGRR+wN+wH3Tt1wfc/NMZhgYcJJkxBC6wVgqCG FQw98d5lTJObhzYpxvd4wYf2KHBpVRQoYb7YKzHqJ+2LygIhrL6XiQ5LaAyu8MCc K3SSM29cvRxx1qE0h35dpcbTN4mu+pbtHIa5PhaKA4ObavXXLLwo8dis3aJBUbWl ANnNiHCNA17FER01fFT+9xgZrEGxQ3XV+CXR5cVX/66pjGV/gkdzWwx5jrAry2RP 5eGEDW67yK7Ar5q+6tnHPOLOOB+DPA== =w26b -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 13 21:36: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 06D7E3A10E5; Sun, 13 Jun 2021 21:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2WDO2Syv0e1D; Sun, 13 Jun 2021 21:36:11 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::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 EDC1D3A10E2; Sun, 13 Jun 2021 21:36:10 -0700 (PDT) Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G3JYL26F5z2xFl; Mon, 14 Jun 2021 06:36:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Carsten Bormann In-Reply-To: <6795.1623632992@localhost> Date: Mon, 14 Jun 2021 06:36:05 +0200 Cc: netmod@ietf.org, tools-discuss@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6795.1623632992@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 04:36:15 -0000 On 14. Jun 2021, at 03:09, Michael Richardson = wrote: >=20 > 1) how to process yang files with YYYY-DD-MM into XML. > 2) how to generate yang tree files. > 3) how do I get my YANG includes downloaded, and do I put them into my = repo? > 4) how to do this with MT Makefiles? I people could tell me what they need, we could develop a feature in = kramdown-rfc to handle this. (This would presumably also include support for YANG-SID files.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 14 00:40: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 3CCFC3A192D; Mon, 14 Jun 2021 00:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qey_uGacUV5y; Mon, 14 Jun 2021 00:40:01 -0700 (PDT) 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 B18A63A192A; Mon, 14 Jun 2021 00:39:59 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id E28E7140957; Mon, 14 Jun 2021 09:39:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1623656396; bh=fVipS/i1U8L4hea/To3h6yyD46Of52wRPKvstZapnSc=; h=From:To:Date; b=XWI1fu5sr7v3imQLedPZTxEvOfmtY+aDzkkU+vQRGA4Kyx8BVwEN3+VhQl8rl649c R2SbkHqWrGkQZF4jDHsOEtlsjeOw/Hycmz02dKomcCYv3plD9jioASXKPA1gGLjjBH wncM9TanGWyPpu7sRxMm1TnrJgt9v8erHkNAQ82E= From: Ladislav Lhotka To: Michael Richardson , netmod@ietf.org Cc: tools-discuss@ietf.org, anima@ietf.org In-Reply-To: <6795.1623632992@localhost> References: <6795.1623632992@localhost> Mail-Followup-To: Michael Richardson , netmod@ietf.org, tools-discuss@ietf.org, anima@ietf.org Date: Mon, 14 Jun 2021 09:39:55 +0200 Message-ID: <87o8c87v3o.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 07:40:07 -0000 Hi Michael, you can check my project YANG-I-D [1] for some ideas. The most elegant way of including YANG modules in RFCs would be to treat th= e RFC source as a compound XML document combining xml2rfc with YANG modules= in the YIN syntax - if only xml2rfc could process it. Lada [1] https://github.com/llhotka/YANG-I-D Michael Richardson writes: > Hi, I'm not a regular netmod reader. > I subscribe via IMAP to look into what's going on. If I'm asking a FAQ, I > appologize as I didn't find anything in the 25K messages archived. > I saw Christian's message in 2019 about org-rfc-export. > I'm not sure if I should Reply-To: tools or netmod. > > I'm looking for advice on how to manage things. > A summary of my questions: > > 1) how to process yang files with YYYY-DD-MM into XML. > 2) how to generate yang tree files. > 3) how do I get my YANG includes downloaded, and do I put them into my re= po? > 4) how to do this with MT Makefiles? > > When we were working on RFC8995 and RFC8366, in the days before Martin > Thompson's makefile was around, I just put pyang processing into my simple > Makefile. It's here: https://github.com/anima-wg/anima-bootstrap/blob/m= aster/Makefile > > The perl script at: https://github.com/anima-wg/anima-bootstrap/blob/mast= er/insert-figures > was then developed to insert stuff into the XML. It's rather hacky in so= me ways. > It started it's life as just something to find the latest @YYYY-MM-DD yang > file which the Makefile created. (Kent wrote that sed line three quarters= of > a decade ago, and the sed line now is old enough to trick-or-treat) > Over time, it grew the ability to insert other bits of code or diagrams. > I keep using it, even when I've moved to Markdown because it inserts the > right artwork stuff, and knows to deal with YANG stuff. I also keep usin= g my > Makefile, because except for the simplest uses, the MT ones are too > complicated for me to hack. > > With kramdown source, I can mostly just add stuff to the MT Makefile to > generate the files I need, and then mostly (without insert-figures), I can > use the ::include mechanism in kramdown to get the right things. But, no > magic YYYY-MM-DD stuff. > > So now I am collaborating with some co-authors which want to stick to XML= v3 > rather than kramdown, and whose understanding of Makefiles is poor. I wa= nt > to stick with the normal stuff so that all the github/etc. tooling works = for > everyone involved. > > I'm looking for advice on how do this this? > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > 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 Mon Jun 14 03:21:54 2021 Return-Path: <0100017a0a0a837e-ed759916-40e8-4856-9eb3-16fb586a0834-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 3790F3A1EE6; Mon, 14 Jun 2021 03:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=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 OudcpgNqrbdF; Mon, 14 Jun 2021 03:21:41 -0700 (PDT) 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 983823A1EE5; Mon, 14 Jun 2021 03:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1623666099; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=ZjVEsQ72C2pu3v6sZtp1pEUhbayay5VvXxOxUBGqcrg=; b=kQOLARn1sI+eV4DRXIUbuvCcxEVdghlLYeFSaSfFnroUc0QGr9ihTpuRg+RZFtzV FFa9k/hzIf4PdDUlyETVIJ+6wny7SVcmh0r6FjDhPhrAthCITWYNQBO2o9CbKOrJFIX wPSNg8G7Rjlh0N9ibeP7/rhzp1KAX4gtg/fSVNFA= Content-Type: multipart/alternative; boundary=Apple-Mail-77300609-97C4-4B11-99D8-B8C4879FF125 Content-Transfer-Encoding: 7bit From: Kent Watsen Mime-Version: 1.0 (1.0) Date: Mon, 14 Jun 2021 10:21:39 +0000 Message-ID: <0100017a0a0a837e-ed759916-40e8-4856-9eb3-16fb586a0834-000000@email.amazonses.com> References: <6795.1623632992@localhost> Cc: netmod@ietf.org, tools-discuss@ietf.org, anima@ietf.org In-Reply-To: <6795.1623632992@localhost> To: Michael Richardson X-Mailer: iPhone Mail (18A8395) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.14-54.240.8.83 Archived-At: Subject: Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 10:21:47 -0000 --Apple-Mail-77300609-97C4-4B11-99D8-B8C4879FF125 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael! There isn=E2=80=99t a standard of any sort, but as an active author of a lar= ge number of drafts, I=E2=80=99ve been force to automate as much as possible= : - validating the schema - validating examples - generating tree diagrams - stitching all off the above into an XML file - on a per-build basis=20 AFAIK, my system is more complete than used by other authors, most whom seem= to do it manually, with mixed results... I author in XML v3 with macros that get expanded in the source, you may have= linked my INSERT_TEXT_IN_FILE macro earlier, that =E2=80=98insert-figures=E2= =80=99 consumes. It=E2=80=99s effectively the same, with little improvement= s here and there.=20 There=E2=80=99s no =E2=80=9Ctool=E2=80=9D to do it*, each draft begins as a c= opy/paste of one prior, and then the Makefile, refs/validate-all.sh, and ref= s/gen-trees.sh files are tweaked as needed. For examples: see the top-10 r= epos listed here: https://github.com/netconf-wg.=20 * I was previously working on =E2=80=98xiax=E2=80=99 here: https://github.co= m/kwatsen/xiax.=20 K.=20 > On Jun 13, 2021, at 9:10 PM, Michael Richardson wr= ote: >=20 > =EF=BB=BF > Hi, I'm not a regular netmod reader. > I subscribe via IMAP to look into what's going on. If I'm asking a FAQ, I= > appologize as I didn't find anything in the 25K messages archived. > I saw Christian's message in 2019 about org-rfc-export. > I'm not sure if I should Reply-To: tools or netmod. >=20 > I'm looking for advice on how to manage things. > A summary of my questions: >=20 > 1) how to process yang files with YYYY-DD-MM into XML. > 2) how to generate yang tree files. > 3) how do I get my YANG includes downloaded, and do I put them into my rep= o? > 4) how to do this with MT Makefiles? >=20 > When we were working on RFC8995 and RFC8366, in the days before Martin > Thompson's makefile was around, I just put pyang processing into my simple= > Makefile. It's here: https://github.com/anima-wg/anima-bootstrap/blob/ma= ster/Makefile >=20 > The perl script at: https://github.com/anima-wg/anima-bootstrap/blob/maste= r/insert-figures > was then developed to insert stuff into the XML. It's rather hacky in som= e ways. > It started it's life as just something to find the latest @YYYY-MM-DD yang= > file which the Makefile created. (Kent wrote that sed line three quarters o= f > a decade ago, and the sed line now is old enough to trick-or-treat) > Over time, it grew the ability to insert other bits of code or diagrams. > I keep using it, even when I've moved to Markdown because it inserts the > right artwork stuff, and knows to deal with YANG stuff. I also keep using= my > Makefile, because except for the simplest uses, the MT ones are too > complicated for me to hack. >=20 > With kramdown source, I can mostly just add stuff to the MT Makefile to > generate the files I need, and then mostly (without insert-figures), I can= > use the ::include mechanism in kramdown to get the right things. But, no > magic YYYY-MM-DD stuff. >=20 > So now I am collaborating with some co-authors which want to stick to XMLv= 3 > rather than kramdown, and whose understanding of Makefiles is poor. I wan= t > to stick with the normal stuff so that all the github/etc. tooling works f= or > everyone involved. >=20 > I'm looking for advice on how do this this? >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consult= ing ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --Apple-Mail-77300609-97C4-4B11-99D8-B8C4879FF125 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael!

There isn=E2= =80=99t a standard of any sort, but as an active author of a large number of= drafts, I=E2=80=99ve been force to automate as much as possible:
=
  - validating the schema
  - validating e= xamples
  - generating tree diagrams
  - stitc= hing all off the above into an XML file
  - on a per-build ba= sis 

AFAIK, my system is more complete than us= ed by other authors, most whom seem to do it manually, with mixed results...=

I author in XML v3 with macros that get expanded i= n the source, you may have linked my INSERT_TEXT_IN_FILE macro earlier, that= =E2=80=98insert-figures=E2=80=99 consumes.  It=E2=80=99s effectively t= he same, with little improvements here and there. 

=
There=E2=80=99s no =E2=80=9Ctool=E2=80=9D to do it*, each draft begins a= s a copy/paste of one prior, and then the Makefile, refs/validate-all.sh, an= d refs/gen-trees.sh files are tweaked as needed.   For examples: see th= e top-10 repos listed here: h= ttps://github.com/netconf-wg. 

* I was pre= viously working on =E2=80=98xiax=E2=80=99 here: https://github.com/kwatsen/xiax. 
K. 

On J= un 13, 2021, at 9:10 PM, Michael Richardson <mcr+ietf@sandelman.ca> wr= ote:

=EF= =BB=BF
Hi, I'm not a regular netmod reader.
= I subscribe via IMAP to look into what's going on.  If I'm asking= a FAQ, I
appologize as I didn't find anything in the 25K me= ssages archived.
I saw Christian's message in 2019 about org= -rfc-export.
I'm not sure if I should Reply-To: tools or net= mod.

I'm looking for advice on how to manag= e things.
A summary of my questions:
=
1) how to process yang files with YYYY-DD-MM into XML.
<= span>2) how to generate yang tree files.
3) how do I get my Y= ANG includes downloaded, and do I put them into my repo?
4) h= ow to do this with MT Makefiles?

When we we= re working on RFC8995 and RFC8366, in the days before Martin
Thompson's makefile was around, I just put pyang processing into my simple<= /span>
Makefile.  It's here:  https://github.com/anima-wg= /anima-bootstrap/blob/master/Makefile

The p= erl script at: https://github.com/anima-wg/anima-bootstrap/blob/master/inser= t-figures
was then developed to insert stuff into the XML. &= nbsp;It's rather hacky in some ways.
It started it's life as= just something to find the latest @YYYY-MM-DD yang
file whi= ch the Makefile created. (Kent wrote that sed line three quarters of<= br>a decade ago, and the sed line now is old enough to trick-or-treat)=
Over time, it grew the ability to insert other bits of code= or diagrams.
I keep using it, even when I've moved to Markd= own because it inserts the
right artwork stuff, and knows to= deal with YANG stuff.  I also keep using my
Makefile, b= ecause except for the simplest uses, the MT ones are too
com= plicated for me to hack.

With kramdown sour= ce, I can mostly just add stuff to the MT Makefile to
genera= te the files I need, and then mostly (without insert-figures), I can<= br>use the ::include mechanism in kramdown to get the right things. &n= bsp;But, no
magic YYYY-MM-DD stuff.
<= br>So now I am collaborating with some co-authors which want to stick t= o XMLv3
rather than kramdown, and whose understanding of Mak= efiles is poor.  I want
to stick with the normal stuff s= o that all the github/etc. tooling works for
everyone involv= ed.

I'm looking for advice on how do this t= his?

--
Michael Richardson &= lt;mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T consulting )<= /span>
          = ;Sandelman Software Works Inc, Ottawa and Worldwide
<= br>


________________= _______________________________
Anima mailing listAnima@ietf.org
https://www.ietf.org/mailman/listinfo/= anima
= --Apple-Mail-77300609-97C4-4B11-99D8-B8C4879FF125-- From nobody Mon Jun 14 03:34:37 2021 Return-Path: <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-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 92A423A1F3A for ; Mon, 14 Jun 2021 03:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwxqHS2veIAf for ; Mon, 14 Jun 2021 03:34:30 -0700 (PDT) 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 59DDD3A1F41 for ; Mon, 14 Jun 2021 03:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1623666869; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=l5L3QCes85WIcIFw32xwZJLyP6sBFoZmJjRe12J7tdk=; b=W/GASY3dnrvEDmSn2aGeQ9LY0PaDARWRCQn3rfH7awCx0TLzrshFZsVf4jz1QOSy iYHqNalCWzD4olQ+wHamtuXGZKfX7X1omuG11zSedFpBtiJ4sKZFUkmoO4NjN5zM8my 5ZRX/BUTNmvz6kM5Dad4HX/Q3sbTmF/zrZIaP+L8= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kent Watsen Mime-Version: 1.0 (1.0) Date: Mon, 14 Jun 2021 10:34:28 +0000 Message-ID: <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-000000@email.amazonses.com> References: Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , netmod@ietf.org In-Reply-To: To: Andy Bierman X-Mailer: iPhone Mail (18A8395) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.14-54.240.48.93 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 14 Jun 2021 10:34:36 -0000 > Good thing we are not discussing YANG-next... Sarcasm? ;) I do wonder if it=E2=80=99s not about time we make another go at that effort= ...perhaps a 111-hum on interest? That said, there=E2=80=99s a world apart from WG-interest and author-commitm= ents. In either case, said effort wouldn=E2=80=99t complete for some time, which m= ay be disagreeable to the versioning rollout.=20 Kent= From nobody Mon Jun 14 07:09: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 A17CB3A25A4; Mon, 14 Jun 2021 07:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M20WMcZ8lxSc; Mon, 14 Jun 2021 07:09:40 -0700 (PDT) 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 2A6393A259B; Mon, 14 Jun 2021 07:09:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0708D38C35; Mon, 14 Jun 2021 10:10:44 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wUEbUDVQMhUE; Mon, 14 Jun 2021 10:10:43 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 83DB738C2D; Mon, 14 Jun 2021 10:10:43 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2FFDE236; Mon, 14 Jun 2021 10:09:37 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: netmod@ietf.org, tools-discuss@ietf.org, anima@ietf.org In-Reply-To: References: <6795.1623632992@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] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 14:09:46 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 14. Jun 2021, at 03:09, Michael Richardson = wrote: >> >> 1) how to process yang files with YYYY-DD-MM into XML. >> 2) how to generate yang tree files. >> 3) how do I get my YANG includes downloaded, and do I put them into = my repo? >> 4) how to do this with MT Makefiles? > I people could tell me what they need, we could develop a feature in > kramdown-rfc to handle this. One possibility is that kramdown-rfc ought to look for, and include the latest foo-YYYY-MM-DD.yang file, when told to ::include foo.yang. Alternatively, it could perhaps do the YYYY-MM-DD substitution itself. > (This would presumably also include support for YANG-SID files.) That's mostly just a question about including the results, and it's not that hard thing to add to the main Makefile. But, as I said, I xml2rfc doesn't have a useful include functionality, for when not working with kramdown. =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+93Q3WUFAmDHYyAACgkQgItw+93Q 3WV3aQgAmGkXaZLl6M1ymcKws6YKMg4TII1n2Az07W9kfq5s9mgwtvYdF38y4QKz QeoRViqDTTLDKcyaUTyh8UkA0rKSsdxr+TklpF6AnPrWR4N4h5ItRMyDeYK9P/b1 icv8BXdTVfCYAfNqaS5kzRVXKc+gTb4WaXCtjUAdeGsrZdk/878/p1ihx9baBBmb By8Yhk6LMEmBszEKxhjiI+fRIlQzc9f25aRqRjCMnMl45PmnyscSWJT6i1bY3Rkp cFHmo5tR2Jj3i9i6Wfom0yX3dug/t47QF0tKRnuKlCL/4VKxIOjwjjLBjmgXr9lM WC80t4UYOMBfZ8Tj4vIuCJ/QpTUZug== =F6vk -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 14 07:19:57 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 29A5B3A25FC for ; Mon, 14 Jun 2021 07:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piyKsO3n2_Cx for ; Mon, 14 Jun 2021 07:19:51 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6349E3A25F8 for ; Mon, 14 Jun 2021 07:19:51 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id b37so4388946ljr.13 for ; Mon, 14 Jun 2021 07:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=laJzQ34Q7Qk4Fvr84PiWyaSZE69NHs6qHIOX4lEULlw=; b=hbsjxW2dlGgnzDn0IrSRSp5W5fpvwvQnOqis7e8NoQcZRuCyhm4rwwkoBNWQXU7B30 4miKy0a+bxrJ40m/nbCJopz5/i+cQjoWz3QvhOVu6ynsmVUb8vk2xtWA7tPElRlzrxTE q46Bges8nHdoZ2icgSV4e9+TEeYsN4gSG400PdvaKRGd3oNYQ77+CL6vbnYhWb+68XPU pwTmrRZPaBnYiRwbepiOdDP0XKu0fAyZ/5iJpVmo7l06lyQIM7syam7Srjf5UHfRU7UX /IjjiSkH0kdmKMxhpiYUb5ZA5rb7Cg3j6TmOBVjFbUekfgTHiMucOSmpYZOMBvKVry6y 7TGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=laJzQ34Q7Qk4Fvr84PiWyaSZE69NHs6qHIOX4lEULlw=; b=XXRBAras9aFajX/jDnBa8vgLgl7+Ib/ELscvwuGeNGrk1kZ9evbVjsnb1Su25y9kkg p0y2N2ShJ2kxsl+L3CbLr4X0nZa5tzZtsm7bfwiFck0jqff3SHTF6FlE+QbjwrRMtRbv j42fWDcHaVPbj7aFg/Ua7BXnM1LLw6X8yBQepGl3OlPhOBrJYjRi1+hnlacXWomF2IEm 87pQRXWAxRYZLzuV7xPte7isgqi4jR/Up/5nFdpZmNQCCQ5wE5JiQlNW75S0a00uiVkH iq2kptHTPK0aJRsE0UN+Xc4ELn0TBb6wuuj1+ejhXlRJzU7uxOGmSW49X+IRLhGxwJD7 Zq+Q== X-Gm-Message-State: AOAM533+wzmdZH96b/5/kgTI0FmeSClEuXkZFu+Uc8U/GKH92e3QI5o+ y1ErNCRMVuqX3HYjdZkWcsksnsKPHd5VQVofNKS+tmH0oqGKuw== X-Google-Smtp-Source: ABdhPJwihFBbY+2tLbl+fZC49D8H7g13xXbfBKlYG9Ql+lTKWK3ix1eezaj1+g8ExBb3tt6JBT4DXOarpt5QA5lnZd0= X-Received: by 2002:a2e:908a:: with SMTP id l10mr13543502ljg.160.1623680388663; Mon, 14 Jun 2021 07:19:48 -0700 (PDT) MIME-Version: 1.0 References: <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-000000@email.amazonses.com> In-Reply-To: <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-000000@email.amazonses.com> From: Andy Bierman Date: Mon, 14 Jun 2021 07:19:37 -0700 Message-ID: To: Kent Watsen Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , NetMod WG Content-Type: multipart/alternative; boundary="000000000000cba12005c4ba8c2e" Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 14 Jun 2021 14:19:56 -0000 --000000000000cba12005c4ba8c2e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 14, 2021 at 3:34 AM Kent Watsen wrote: > > > > Good thing we are not discussing YANG-next... > > Sarcasm? ;) > No. The NETMOD WG has repeatedly decided not to produce a new YANG language version in which the yang-version string is changed. > I do wonder if it=E2=80=99s not about time we make another go at that > effort...perhaps a 111-hum on interest? > > That said, there=E2=80=99s a world apart from WG-interest and author-comm= itments. > > In either case, said effort wouldn=E2=80=99t complete for some time, whic= h may be > disagreeable to the versioning rollout. I agree there is little WG interest for this work. > > > Kent > Andy --000000000000cba12005c4ba8c2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 14, 2021 at 3:34 AM Kent = Watsen <kent+ietf@watsen.net> wrote:

> Good thing we are not discussing YANG-next...

Sarcasm?=C2=A0 ;)



I do wonder if it=E2=80=99s not about time we make another go at that effor= t...perhaps a 111-hum on interest?

That said, there=E2=80=99s a world apart from WG-interest and author-commit= ments.

In either case, said effort wouldn=E2=80=99t complete for some time, which = may be disagreeable to the versioning rollout.

<= div>I agree there is little WG interest for this work.
<= /div> --000000000000cba12005c4ba8c2e-- From nobody Mon Jun 14 08:02: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 618433A27C2; Mon, 14 Jun 2021 08:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001] autolearn=no 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 GWUqQPDZ2fUO; Mon, 14 Jun 2021 08:02:35 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::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 883303A27AC; Mon, 14 Jun 2021 08:02:20 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G3ZRr6BYJz2xGR; Mon, 14 Jun 2021 17:02:16 +0200 (CEST) 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: <16776.1623679777@localhost> Date: Mon, 14 Jun 2021 17:02:16 +0200 Cc: anima@ietf.org, tools-discuss@ietf.org, netmod@ietf.org X-Mao-Original-Outgoing-Id: 645375736.406337-96927f24cec31a4d1e4e51c805b6ccc7 Content-Transfer-Encoding: quoted-printable Message-Id: <1CA387C6-6058-46DC-882B-BCBEB848FE7B@tzi.org> References: <6795.1623632992@localhost> <16776.1623679777@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 15:02:44 -0000 > One possibility is that kramdown-rfc ought to look for, and include = the > latest foo-YYYY-MM-DD.yang file, when told to ::include foo.yang. > Alternatively, it could perhaps do the YYYY-MM-DD substitution itself. How about {::include foo-????-??-??.yang} and, if there is no such file, kramdown-rfc expands the wild card in the = directory and uses the numerically latest file? (There might also be a use-case for actually including all these files, = so I=E2=80=99m still in thinking mode, but I think this is close.) > for when not working with kramdown. What? :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 14 08:37: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 8A6C33A2848; Mon, 14 Jun 2021 08:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 HIToMUOvZkyP; Mon, 14 Jun 2021 08:36:59 -0700 (PDT) Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8584F3A2847; Mon, 14 Jun 2021 08:36:59 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [142.169.78.190]) by relay.sandelman.ca (Postfix) with ESMTPS id 1ABF41F456; Mon, 14 Jun 2021 15:36:55 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 49E3E1A293E; Mon, 14 Jun 2021 11:36:53 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , netmod@ietf.org, tools-discuss@ietf.org, anima@ietf.org In-reply-to: References: <6795.1623632992@localhost> Comments: In-reply-to Carsten Bormann message dated "Mon, 14 Jun 2021 06:36:05 +0200." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Mon, 14 Jun 2021 11:36:53 -0400 Message-ID: <73347.1623685013@dooku> Archived-At: Subject: Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 15:37:05 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 14. Jun 2021, at 03:09, Michael Richardson > wrote: >>=20 >> 1) how to process yang files with YYYY-DD-MM into XML. 2) how to >> generate yang tree files. 3) how do I get my YANG includes >> downloaded, and do I put them into my repo? 4) how to do this with = MT >> Makefiles? > I people could tell me what they need, we could develop a feature in > kramdown-rfc to handle this. (This would presumably also include > support for YANG-SID files.) But, part of the question is, how does one do this with just XML. As wonderful as kramdown is, and it's always my preference, sometimes it is hard to convince a design team that has started on XML to go that way. (sunk cost fallacy, etc.) I looked at Kent's XIAX repo documentation, and what I saw was that it might take XML as input, paste the YANG in, but leave enough meta-data in the XML= so that the XML can be processed again. So this is an in-place edit. I worry that such a workflow would be confusing to some authors who might edit in the wrong place. Kent, I didn't look extensively at that repo you said to clone. As to editing in YIN, which is an XML syntax way to represent YANG.... well... I don't mind if someone wants to store YANG that way, but I sure don't want to edit that way. So at this point, the best I can do is to bring my "insert-figures" hack in= to a repo, rename the XML to another name, and generate draft-foobar.xml in the top-Makefile. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmDHd5QACgkQlUzhVv38 QpCZuAf9FHyv0a2iMvPSTrOLhp1OIiDIIm8GfOBPd1xxc4zugnXcDxC9VHiebSuJ w1n/3XHbneKJeaVd/CUbrHWbCHmIOE+gKS21Bqtkqofen+k0+adZdClBXoMqc/2B VxTmAKb4ymUMHHWwnnDg5hlT6OPcyzyvCltuA8g0gmZLdJLGdi+tEjUZQqHMArT8 KLVyYmkVFU2/nI5DIAtmLfSQQEyIem8OlQEjZT0CxkGUCYR2SSO+2tQR99JLU+zu rCWZ6EZ97v+6LnP8HPiMRY+ISWnWnAQ9BlS23CvJ9g2nH/OlEUBPtZXlEAjJtYUe GT+73Jcl4oeMrNDc20VqFj/9ivQvpw== =CpWQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 14 08:57: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 A31973A28F4; Mon, 14 Jun 2021 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y-CqFS0jQXo8; Mon, 14 Jun 2021 08:57:09 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.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 A807E3A28EF; Mon, 14 Jun 2021 08:57:08 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G3bg36wPqz2xGV; Mon, 14 Jun 2021 17:57:03 +0200 (CEST) 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: <73347.1623685013@dooku> Date: Mon, 14 Jun 2021 17:57:03 +0200 Cc: netmod@ietf.org, tools-discuss@ietf.org, anima@ietf.org X-Mao-Original-Outgoing-Id: 645379023.395463-411fa978bdf2c1252e12286f1d8b4ae1 Content-Transfer-Encoding: quoted-printable Message-Id: <43902CCE-95BC-49FD-8637-2D975B364E82@tzi.org> References: <6795.1623632992@localhost> <73347.1623685013@dooku> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 15:57:12 -0000 I can=E2=80=99t help you with your dark desires to use XML, but I would = propose the following fix for that: =E2=80=94 use xi:include or src=3D for the XML source (I forget which = one works), with a static name =E2=80=94 simply generate a symlink from the most recent .yang to the = static name in the Makefile =E2=80=94 use --expand for generating the submission XML. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 14 09:26: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 390883A29CA; Mon, 14 Jun 2021 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 AenTT3mY7HpE; Mon, 14 Jun 2021 09:26:22 -0700 (PDT) Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDEF3A29C4; Mon, 14 Jun 2021 09:26:22 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [142.169.78.190]) by relay.sandelman.ca (Postfix) with ESMTPS id 679661F456; Mon, 14 Jun 2021 16:26:20 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id F2FCE1A293E; Mon, 14 Jun 2021 12:26:18 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , anima@ietf.org, tools-discuss@ietf.org, netmod@ietf.org In-reply-to: <1CA387C6-6058-46DC-882B-BCBEB848FE7B@tzi.org> References: <6795.1623632992@localhost> <16776.1623679777@localhost> <1CA387C6-6058-46DC-882B-BCBEB848FE7B@tzi.org> Comments: In-reply-to Carsten Bormann message dated "Mon, 14 Jun 2021 17:02:16 +0200." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Mon, 14 Jun 2021 12:26:18 -0400 Message-ID: <77018.1623687978@dooku> Archived-At: Subject: Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 16:26:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> One possibility is that kramdown-rfc ought to look for, and include >> the latest foo-YYYY-MM-DD.yang file, when told to ::include foo.yang. >> Alternatively, it could perhaps do the YYYY-MM-DD substitution itsel= f. cb> How about cb> {::include foo-????-??-??.yang} cb> and, if there is no such file, kramdown-rfc expands the wild card in cb> the directory and uses the numerically latest file? You'd use shell globs? I think it might be better to use PCRE. It might be better to have this as "winclude" cb> (There might also be a use-case for actually including all these cb> files, so I=E2=80=99m still in thinking mode, but I think this is c= lose.) >> for when not working with kramdown. cb> What? :-) Yes, it causes me confusion too. Basically, I'm trying to contribute YANG modules (as pull-requests) to draf= ts for which I'm not an author, and I don't really want to have to convince th= em to upgrade. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmDHgyoACgkQlUzhVv38 QpArNgf+P4lJTqC+4r4keQdMWy18Duv0rtX3pnsrUN94koUAkmW9D6WrmncBchIC fEyhgn7dobYPmEYxvKDiUbwXjwwkJdPr0WH0Ezzn4+0855sc/F5Yh1Id0B724zB0 UBuYbuwgO7utXXzVc6Eb5jyMJfiOMKSb9/3kVNunaBfbtbmPTCj2XOSXPY5lAJu7 YM8wOeZaydyR5PjQjTmD3y+lYIezgEQk/bPeZF63EyCM63QjZsLqUwi2UgfKKvLA BSAKmca/zHF8PPuZk6gV6WrA+yORcp82VyuuX/81rMJLiCYv+tIFt+Lg0F9M0gLr GmriXYowOAzgI2t3eaK3TQYCFZCJDw== =lt9d -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 14 09:30:16 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 2A0C33A2A18; Mon, 14 Jun 2021 09:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUcPmTPjLRoq; Mon, 14 Jun 2021 09:29:57 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.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 2F7803A2A30; Mon, 14 Jun 2021 09:29:55 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G3cNv75YQz2xFl; Mon, 14 Jun 2021 18:29:51 +0200 (CEST) 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: <77018.1623687978@dooku> Date: Mon, 14 Jun 2021 18:29:51 +0200 Cc: anima@ietf.org, tools-discuss@ietf.org, netmod@ietf.org X-Mao-Original-Outgoing-Id: 645380991.372005-ff9ca5730f593e22c641e6770cccfa47 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6795.1623632992@localhost> <16776.1623679777@localhost> <1CA387C6-6058-46DC-882B-BCBEB848FE7B@tzi.org> <77018.1623687978@dooku> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 16:30:05 -0000 On 2021-06-14, at 18:26, Michael Richardson = wrote: >=20 > cb> How about >=20 > cb> {::include foo-????-??-??.yang} >=20 > cb> and, if there is no such file, kramdown-rfc expands the wild = card in > cb> the directory and uses the numerically latest file? >=20 > You'd use shell globs? Yes. Any need to go beyond that? > I think it might be better to use PCRE. Much more typing and backslash-mangling, and I don=E2=80=99t see the use = case. > It might be better to have this as "winclude" So =E2=80=98loseclude=E2=80=99 would be including all matches? (What does the =E2=80=9Cw=E2=80=9D stand for?) > cb> (There might also be a use-case for actually including all = these > cb> files, so I=E2=80=99m still in thinking mode, but I think this = is close.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 14 09:34: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 0D5B83A29E1; Mon, 14 Jun 2021 09:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=akamai.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 K1q3bx1K8DFi; Mon, 14 Jun 2021 09:29:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 B22FE3A29D4; Mon, 14 Jun 2021 09:29:16 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 15EGJqHj027921; Mon, 14 Jun 2021 17:29:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=JkpzYK7sEzaj55XkAZYDRDang2ELy5m5iriy4hKlF2Q=; b=LotbUVmLZmx999XySNjHOpkHjfoIW6YytZhy2Tt/qt3sWCu8qoU+SQthNgvepvOQIbgH EQRr/En5O942rqoTxQ2wSoaWIJOjx5bDnY4RFPRI0G5WTGtKY5JeBELkdslQ1G6FsGz2 hH60A/LU9zESAZbzHUyW9z8X5D8mAsvnT3Ojuk/CL9Ohd22a5LSSLIQOPM/0eMx+0Ag7 zeABihip5XhAn1Lowru1fCWfkIw/QB/ncqXILjGPUqDkdweLNNzCwgH6VnPwTykTKCCN b5ix6hDDA3Voq2uBRt1pRXDtus7qW5BFykQ8jqTPTgrtikw0HIEohQ1kr/BByjKlggD3 8g== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 395kctmga9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jun 2021 17:29:13 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 15EGL3Ae003415; Mon, 14 Jun 2021 12:28:43 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint4.akamai.com with ESMTP id 394r9020en-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Jun 2021 12:28:43 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 14 Jun 2021 11:28:43 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.018; Mon, 14 Jun 2021 11:28:42 -0500 From: "Salz, Rich" To: Michael Richardson , Carsten Bormann , "tools-discuss@ietf.org" Thread-Topic: [Tools-discuss] [Anima] looking for practical advice on managing YANG source in XML format RFCs Thread-Index: AQHXYNbgNrCylkBqFkKA590kAXCo0asT3/WAgAAOtQCAABd7AP//vZyA Date: Mon, 14 Jun 2021 16:28:41 +0000 Message-ID: References: <6795.1623632992@localhost> <16776.1623679777@localhost> <1CA387C6-6058-46DC-882B-BCBEB848FE7B@tzi.org> <77018.1623687978@dooku> In-Reply-To: <77018.1623687978@dooku> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21060600 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-14_10:2021-06-14, 2021-06-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 suspectscore=0 mlxlogscore=733 bulkscore=0 spamscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106140104 X-Proofpoint-ORIG-GUID: 4FQ1C9ub-qr7R0ZyuVkBqFJi5bn6K25N X-Proofpoint-GUID: 4FQ1C9ub-qr7R0ZyuVkBqFJi5bn6K25N X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-14_10:2021-06-14, 2021-06-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 clxscore=1011 phishscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=677 adultscore=0 priorityscore=1501 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106140104 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.32) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint4 Archived-At: X-Mailman-Approved-At: Mon, 14 Jun 2021 09:34:10 -0700 Subject: Re: [netmod] [Tools-discuss] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 16:29:30 -0000 TmV0bW9kIGFuZCBhbmltYSBtb3ZlZCB0byBiY2MuDQoNCj4gICAgWW91J2QgdXNlIHNoZWxsIGds b2JzPw0KICAgIEkgdGhpbmsgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIHVzZSBQQ1JFLg0KICANCkhv cnJpYmxlIGlkZWEgdG8gdXNlIFBDUkUgaW5zdGVhZCBvZiBnbG9icy4NCg0KDQo= From nobody Mon Jun 14 09:38:08 2021 Return-Path: <0100017a0b63209f-789f601b-574a-44c7-b870-ec9bbe870c75-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 C8B503A1F47 for ; Mon, 14 Jun 2021 09:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khjGZYRLpj1T for ; Mon, 14 Jun 2021 09:38:05 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEEE3A1F4C for ; Mon, 14 Jun 2021 09:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1623688683; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=z5dl1WDDOLnPBG15RJpnuB+ejQQS/4XxiXU0qzpUqVk=; b=CQE+PgwyiAYW1e2snCXGm8Zgjb/5a0UL5NECPVDp/pvl/27GlTu1KyKNsgy0vZ72 BiLn66KqpwyHThqdFZNbUhVZfZ5JsYufBnnB6KM1pjUdvYWHUX6WhogxDBOApv1dB2r cCzj2EDwrFxEaETL7GQzU8Z1HDsPp8ePdkM0HA30= From: Kent Watsen Message-ID: <0100017a0b63209f-789f601b-574a-44c7-b870-ec9bbe870c75-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DDD45F4E-FB1B-44A5-AD5C-72A093E32B62" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 14 Jun 2021 16:38:03 +0000 In-Reply-To: Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" To: Andy Bierman References: <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.14-54.240.8.31 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 14 Jun 2021 16:38:07 -0000 --Apple-Mail=_DDD45F4E-FB1B-44A5-AD5C-72A093E32B62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > > Good thing we are not discussing YANG-next... >=20 > Sarcasm? ;) >=20 > No. The NETMOD WG has repeatedly decided not to produce a new YANG = language > version in which the yang-version string is changed.=20 That=E2=80=99s not possibly true. It's a matter of =E2=80=9Cwhen", not = =E2=80=9Cif=E2=80=9D, unless you=E2=80=99re anticipating YANG moving to = HISTORIC. K. --Apple-Mail=_DDD45F4E-FB1B-44A5-AD5C-72A093E32B62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


> Good thing we are not discussing = YANG-next...

Sarcasm?  ;)

No. The NETMOD WG has repeatedly = decided not to produce a new YANG language
version = in which the yang-version string is = changed. 

That=E2=80=99s not possibly true.   It's a = matter of =E2=80=9Cwhen", not =E2=80=9Cif=E2=80=9D, unless you=E2=80=99re = anticipating YANG moving to HISTORIC.


K.

= --Apple-Mail=_DDD45F4E-FB1B-44A5-AD5C-72A093E32B62-- From nobody Mon Jun 14 10:01:56 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E683A2B02 for ; Mon, 14 Jun 2021 10:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPhMnzD-EFdy for ; Mon, 14 Jun 2021 10:01:50 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E83C3A2AFE for ; Mon, 14 Jun 2021 10:01:50 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id 131so21175901ljj.3 for ; Mon, 14 Jun 2021 10:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j1rY8saGJg/LKE+NANmwbaxHhuA6FAJ3xH1CYGmSn/I=; b=EBdaxGCW1JWgBhjZflI2L0If4UwSb5fXF6ZGapzWxYcoBaLPCH+WyyZgeCzLsJvvPJ mDTdl5d1ppaCGsMbgEKdp4X51loIxQBoCDRYtBuc9PnCI8aleDg+fmwzyXHc2WeJ3Vta RfHn1EpoAHYcIHhb+bfPlNk0zgQ2u1R8YPY98j8kFW20UeN2OM1ys3UjnRbDhBAKElL4 t5lJhdkj1g/OraThTjLe53ixRveHHdvxKwR29pcQlFouZ2uFGmlrTeK+tIGSZpBNtEVb UWOrB7JywhNnd2Fa6xn5ooZmgrmH1NChrdo8cFsQgmV6MqkWMZPC3jMi5TEmgXhEdcyP KA9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j1rY8saGJg/LKE+NANmwbaxHhuA6FAJ3xH1CYGmSn/I=; b=s2y8boyQVGrvavvXbTyspGldPzuRHQ2ZrEr3n84Ho1ZWqWZk+jxGHdCaynftTnyPTo dgVTKjLfLnqzRB0gSWfEZAdstGNL4quy1bI6bqMHA9badylETgMFjLdRRmXmPyegsp7O RmbeXtAIUicn1j9/gFJxr3cv4f0/4K3xlQKFMeGnlXjUS8zY75y3q45FjzwrJlbeyX2X NctsTq9eKvNCf9hjDMefPqeczvB8zd2lyOhWRB8vPH+v0YSFFmQFOL8pSnWMlu3vhPg5 53XqUSbW8siYPmSD7iScZFbsvND+30moGbmBLcRYEQMHIckCuqWGRMYbxtaydvc15tL2 45+A== X-Gm-Message-State: AOAM53340mNVSVhxsrXbWP5tApLBdN9vIvM6Q+MYbOR1++VGmXMWOXhr g0H5IJXzhvnGivff06cp2XsUsPdLXzfSTKpTIBoKEA== X-Google-Smtp-Source: ABdhPJy/05ywR4/c3TXaW8JeEw8xbWJ9QCKwhSgKJSaE20WI3O0eDiqPrw+1P8FeWw0bYh1HrAdvFTnKxj/1KrJDkoY= X-Received: by 2002:a05:651c:1318:: with SMTP id u24mr14934754lja.91.1623690105607; Mon, 14 Jun 2021 10:01:45 -0700 (PDT) MIME-Version: 1.0 References: <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-000000@email.amazonses.com> <0100017a0b63209f-789f601b-574a-44c7-b870-ec9bbe870c75-000000@email.amazonses.com> In-Reply-To: <0100017a0b63209f-789f601b-574a-44c7-b870-ec9bbe870c75-000000@email.amazonses.com> From: Andy Bierman Date: Mon, 14 Jun 2021 10:01:34 -0700 Message-ID: To: Kent Watsen Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f8693d05c4bccfe6" Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 14 Jun 2021 17:01:55 -0000 --000000000000f8693d05c4bccfe6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 14, 2021 at 9:38 AM Kent Watsen wrote: > > > > Good thing we are not discussing YANG-next... >> >> Sarcasm? ;) >> > > No. The NETMOD WG has repeatedly decided not to produce a new YANG langua= ge > version in which the yang-version string is changed. > > > That=E2=80=99s not possibly true. It's a matter of =E2=80=9Cwhen", not = =E2=80=9Cif=E2=80=9D, unless > you=E2=80=99re anticipating YANG moving to HISTORIC. > > I meant the current work is using extensions instead of new language statements. Not that the yang-version will never be changed in the future. It is not a matter of "when" if new functionality is added via extensions. In theory the WG could add new functionality to YANG 1.1 this way for years= . In practice it might be difficult to achieve widespread interoperability if nobody agrees what "YANG next" actually contains. Also, YANG 1.1 clearly says a tool MAY skip over and ignore ANY external statement, so it is problematic to use extension-stmt as if it was defining real statements. It is better to have a tool clearly fail with an "unsupported YANG version" error than it is to silently ignore external statements. K. > > Andy --000000000000f8693d05c4bccfe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



I meant the current work is using extensions instead of ne= w language statements.
Not that the yang-version will never be ch= anged in the future.

It is not a matter of "w= hen" if new functionality is added via extensions.
In theory= the WG could add new functionality to YANG 1.1 this way for years.
In practice it might be difficult to achieve widespread interoperability= if nobody
agrees what "YANG next"=C2=A0 actually conta= ins. Also, YANG 1.1 clearly says a tool MAY
skip over and ignore = ANY external statement, so it is problematic to use extension-stmt
as if it was defining real statements. It is better to have a tool clearl= y fail
with an "unsupported YANG version" error than it= is to silently ignore external statements.



K.

=

Andy
=C2=A0
 --000000000000f8693d05c4bccfe6-- From nobody Mon Jun 14 10:16:43 2021 Return-Path: <0100017a0b866f67-8f4f2e4e-6c67-41cc-9c7c-b49057826adb-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 8E2123A2B6D for ; Mon, 14 Jun 2021 10:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VlIEwd9ZBRf for ; Mon, 14 Jun 2021 10:16:41 -0700 (PDT) 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 3A3763A2B69 for ; Mon, 14 Jun 2021 10:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1623690997; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=zeamsk9bOoAFCpAvP+JgHnSIzU7eae/Tfm4LmYCrjwU=; b=eX948kyNCX3DnwYh5te8cDo1UXq1yAxPS6B9WtvmFSdxQfXqGQozuGgNbNtvsq7i Tr81cQr8dYhlV0YNYreBuqpwrzcx6rnUT/r+5dsGOfuK1J8mhh3fEN9VhJ4c/3s8lGv DgNS1mQKzERSuTJTfmm6xh0RTM9sVGZ1Sooj36dA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Kent Watsen In-Reply-To: Date: Mon, 14 Jun 2021 17:16:37 +0000 Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017a0b866f67-8f4f2e4e-6c67-41cc-9c7c-b49057826adb-000000@email.amazonses.com> References: <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-000000@email.amazonses.com> <0100017a0b63209f-789f601b-574a-44c7-b870-ec9bbe870c75-000000@email.amazonses.com> To: Andy Bierman X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.14-54.240.8.96 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 14 Jun 2021 17:16:43 -0000 > I meant the current work is using extensions instead of new language = statements. > Not that the yang-version will never be changed in the future. Ah, okay. > It is not a matter of "when" if new functionality is added via = extensions. > In theory the WG could add new functionality to YANG 1.1 this way for = years. > In practice it might be difficult to achieve widespread = interoperability if nobody > agrees what "YANG next" actually contains. Also, YANG 1.1 clearly = says a tool MAY > skip over and ignore ANY external statement, so it is problematic to = use extension-stmt > as if it was defining real statements. It is better to have a tool = clearly fail > with an "unsupported YANG version" error than it is to silently ignore = external statements. Agreed. K. From nobody Mon Jun 14 10:40: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 8EBB23A2C00 for ; Mon, 14 Jun 2021 10:40:51 -0700 (PDT) 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.698, 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 kDRtJ8e1CZ1W for ; Mon, 14 Jun 2021 10:40:46 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2103.outbound.protection.outlook.com [40.107.244.103]) (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 8B8513A2C04 for ; Mon, 14 Jun 2021 10:40:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ef1h4EE7K354RIYlR8gYTejGOAH4GxFjA2bzj0VUU0s8kCwsyCGfJ1BOpawiWby2dcc0r/N1A+VVK9JXtNwtr8BsJHG2yLlGbztvgOueUPHmDjNnoPjOIdZ0Ztf2/D7CIlmsrPxtNAhlR5TNZa3xR6SpEGIO7fv+DLxcP/blpcJjO8CkjML3jSuVlhlo8nYWhOwei3vX3wunjGIE1v1/DgzTLb67fZQRmXA2j5mR6RxZAqAjQSVXq88r+XR0o8a2IGMg617MlqHrcyzjUarE0j9zreob0hd8D/fw6peHpMLkIJ+iXNV10svL2kE5fOn0QCvUQYe151VhICaVSINuZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AwJP8uqijN4Rzz6xFhFY0D/R6NKuVMbNZR/oiPT80CY=; b=AKdHBtelBzDIVZbovhRbmEorULoqFesfuD759Urp8qjnoNYGhakkJdpn0eQWY34nSGawbPd/SHobAuI3eQfaqUL2dGrkASJCxbGwPT9v8hb+VBIyFrIbyanl5a78aLjQ6TfJBtokRss10p8B9uz2CFCd2Sn1wNu+i2DbZk7yWF6R+KfbiR6oDUr5kSB4nI7M01wg+uDrBfEzas118wE1/yw43i7GbuuyZQduUMhW7Hy7f1OtUqqr+z1m4YSs0fCchwv6timTiW+AvnSFZvAtW+4Md6NyF+8tRfzEOiSur8w3gsbLRjyXhRfYDvJBwLLn5o+KRH4quViOg4wcKE38rQ== 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=AwJP8uqijN4Rzz6xFhFY0D/R6NKuVMbNZR/oiPT80CY=; b=wOqn6Ye/kZEAFexvPn1SWnKauNPgMIxU3F7k/6R5ruUpCcujFNSbIvudI3xHqteN1JabVSVwPum1EVuiawTNyoOU71w4N1/9487+gi27divR7XOsNzya5WGf4BerwO/oOwXnG+O/HUKAgG7NTLQ5BJG9tTUxJQf5oIQY71Bc29I= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6265.namprd08.prod.outlook.com (2603:10b6:5:1e9::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.25; Mon, 14 Jun 2021 17:40:43 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::f431:78d:76de:1ba5]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::f431:78d:76de:1ba5%7]) with mapi id 15.20.4219.025; Mon, 14 Jun 2021 17:40:43 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Kent Watsen , Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 Thread-Index: AddcjRHyR82Br9bERdeXBXT0W+r1igAAXpcAAABV89AAO6xogADikSEAAAfdAIAABNWwgAAA0kIAAACGjoAAAIHScA== Date: Mon, 14 Jun 2021 17:40:43 +0000 Message-ID: References: <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-000000@email.amazonses.com> <0100017a0b63209f-789f601b-574a-44c7-b870-ec9bbe870c75-000000@email.amazonses.com> <0100017a0b866f67-8f4f2e4e-6c67-41cc-9c7c-b49057826adb-000000@email.amazonses.com> In-Reply-To: <0100017a0b866f67-8f4f2e4e-6c67-41cc-9c7c-b49057826adb-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2607:f2c0:e4ae:97:c11:cf9a:5e78:5637] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6d7c7b76-f369-4709-a379-08d92f5b88fb x-ms-traffictypediagnostic: DM6PR08MB6265: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1oJsz11/L/Y82YD+M8FdiBZoJ6sAOMV22LjNUEYoshy2Fp6HpLnyBMv8VuLME3zBraDq6S/qKVqz4yv5Bosxk/7cyQdAeQs9vCDUV1nFiymSNZhrmi0izIMkKpYpEB4+1M6TKDY8joLU2p54MQoFatDBnQU/UTu/Qvy/fAz1tHxDsTBZgqqAGbekAZeHeMe36t4nk+pAt4naXNLnMIKhUbJZuPIVNg4H6zTSGSsWQ8sXeWG/Do10cHX1+zMY/1/cOisChuAG+fVYCNiZjsUeky49f28QggJ0S3QYB2rw9yohrTDu3LOGy/HjlYVdZn06gwCYs0JrT32x/nlyUYPShNJY5h98JIu3BWHRDwwJqJW6BnD/jMXwSWidpTsDQZuoekfsGdWQvULF7yDvNw5k0ZiTdtUxr0E+d8VkGd9ullNZezugpiN5KIgUqTFVOBFpPRNriUw1kBWlHbI+/Pm1Xub0KA9FWBANzB10SX+sexlQFs0OZHjsGLAORAHwzx1txdlSOGqQGCmyZiZdsd5znUU0I5ftSv56HqBaCkmdWAUd+vvpuoL0tradj0KoOWh0XonZvkjy2WcjZX/bdrlAbwxj0/J1qBOz+IC3+XTOnRQ= 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)(346002)(396003)(39860400002)(136003)(376002)(8936002)(71200400001)(33656002)(5660300002)(66446008)(66556008)(66476007)(66946007)(478600001)(76116006)(86362001)(64756008)(8676002)(38100700002)(9686003)(52536014)(55016002)(122000001)(110136005)(4326008)(186003)(2906002)(83380400001)(53546011)(6506007)(316002)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?dmuyNFvOgcaJT2gfxsCbpocIRkI1ZmW7JTGCJxPocTgPI+/10qQgs2Md7pPO?= =?us-ascii?Q?87AemEOYimi3jXuDAyX/v9X31Mpek9BsVbxcK8lwhChITa7BHzdh6EFxCeoT?= =?us-ascii?Q?Hbeh9+f7fi2bAS++g3Yw8rGlQEyaRObFYTf5BdEi63Hy10nRytR8Yt8cXf92?= =?us-ascii?Q?qLWWe5CJplhRlBBLDVnp1DYjNLJAVAbggMe4W6sCa8Unl2Fctlw4AFM8/PXY?= =?us-ascii?Q?Lq9Pz602n3irMpgZWOUue8f+TPd3ms0LNZ0zjyxH9Uv+nRXsAAiRvcsWPRAn?= =?us-ascii?Q?TkaCPcVl2KTQyuO4CVqVqv+SX5njZBkP9IvFsXEo9Ptc4KwVaUvhN9gfvTTN?= =?us-ascii?Q?/FDSUY9+GJww+EklKvIIZrxDtQKTrPgVIa6hG7rPmPNUWPbeB9/GJC9kG9re?= =?us-ascii?Q?30GEC2+kQ2axtG7wfhRXgXrcIpJqzFxAPCa7LL6Z4iPLfkKNRFSTltDo6+Fo?= =?us-ascii?Q?7NnhR/mJtBN8EYrUSL/f1vnwTVB8guxUTsSXmBDudncx2VoPgTSDPCf+snL/?= =?us-ascii?Q?JuAK0CL5Fcx39DZ8Qc8HmYlCliwZMtNkzZOg/l8KtlCmSL4ammTXvcSg+5ZI?= =?us-ascii?Q?IQ0E6p3UuD8eCguJaKbCCeaDiQei3guBj9yvGIFtkZESPv4D/SsYakruFMU0?= =?us-ascii?Q?IQc6FnTy/qsqrAtcVtUnnCpSoiawOhpZEV4Xibrdo4bfhzne6WKwz/rwXm62?= =?us-ascii?Q?pus/09kykvogaOgE5adook1nzwlJtSH8PxEq/tolIf51ASYDOu/i/efC2piE?= =?us-ascii?Q?QzxABxpvdrdx2vc3KgcfJmvcENhhV69wZCkNp2JoerytAaV2RlDTC+BPhN70?= =?us-ascii?Q?c8fvdYCIHLKXc6DeG949FlktNtVR/6IG4I4T0OEBBCwaHo1B4ZEVQ3ROlQPG?= =?us-ascii?Q?TsBLYbZtiiw+dwDcXnL7NLb4ChAdaeiQuPFTRWWTDC3VuZYM1LeHhcI2KkNL?= =?us-ascii?Q?okWBtkmX3WhBmc3qj1uj+ruj82VDUeQOdP8ExrF8VRkdM5D+UOhtq/TrZm5D?= =?us-ascii?Q?XuVwFGOkApcJ9H5lWYUxv7M+n6B5eXee3vNNSK96vsq8K4xwVn+GJ+XUtubF?= =?us-ascii?Q?ew82ClA10w77eOBVVWoG1H09z12KEAs1QVVAnSo8RkIOjgdNxHpK6CSm5NhJ?= =?us-ascii?Q?WWFAoXayb6yYQnAamHyndBtI2tu7C9NOb0ViiQ22asImvxVSysvK+wjT8fBx?= =?us-ascii?Q?5Hds/mtLZ5k0s2PVqjyHeb965ikBHaZHNBXGSKWg+FMn/rh9V1Q3oITb2a5Q?= =?us-ascii?Q?QyGgIntu1S2W+IXrI71AjPjjv7jkBcsVhO76dkqrtQvKJ7udD8I60e17E4HO?= =?us-ascii?Q?3zghG74fm88sE87+zRVxjSgogmZzq3zuvTkbLiNSru8Z05FdVXWHCvqsn8Pk?= =?us-ascii?Q?cGqqIZQ=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" 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: 6d7c7b76-f369-4709-a379-08d92f5b88fb X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2021 17:40:43.5548 (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: Wt9wNADyhIYvZEXmEQKigOVb4yron7cBPLeOCSap9ROF6oaPtEqFWEbZDXsSqlih1rp37I4VX7x/EwbMq2kBWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6265 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 14 Jun 2021 17:40:52 -0000 Hi guys, I can understand that concern; and in particular for something like the new= import by "revision-or-derived". Ignoring that extension can mean tools ma= y not build the right schema (although is that any worse than today without= using import by revision ?). Despite that issue, I'd still advocate for revision-or-derived to be taken = to standard now. It is part of a few things that cause problems today that = really need to be addressed in the short term. But for things like the rev:non-backwards-compatible tag, and using YANG se= mver, do those actually cause any new problems (vs what they help solve) ? = It doesn't cause tools to build the wrong thing, or servers to implement th= e wrong thing. It only helps supply information about what is already happ= ening today (particularly in vendor modules, but also in standard modules) = that isn't being described at all (NBC changes that really do impact the cl= ient, but the module name is kept the same). The WG had a fair bit of discu= ssion 2-3 years ago that this versioning work was needed and should be adop= ted and progressed. That is still the case IMO. Jason > -----Original Message----- > From: Kent Watsen > Sent: Monday, June 14, 2021 1:17 PM > To: Andy Bierman > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; > netmod@ietf.org > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 >=20 >=20 > > I meant the current work is using extensions instead of new language > statements. > > Not that the yang-version will never be changed in the future. >=20 > Ah, okay. >=20 >=20 > > It is not a matter of "when" if new functionality is added via extensio= ns. > > In theory the WG could add new functionality to YANG 1.1 this way for > years. > > In practice it might be difficult to achieve widespread interoperabilit= y if > nobody > > agrees what "YANG next" actually contains. Also, YANG 1.1 clearly says= a > tool MAY > > skip over and ignore ANY external statement, so it is problematic to us= e > extension-stmt > > as if it was defining real statements. It is better to have a tool clea= rly fail > > with an "unsupported YANG version" error than it is to silently ignore > external statements. >=20 > Agreed. >=20 >=20 > K. >=20 From nobody Mon Jun 14 10:55: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 9AA493A2C78 for ; Mon, 14 Jun 2021 10:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPcUj_e8ZI5d for ; Mon, 14 Jun 2021 10:55:34 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 51CA93A2C74 for ; Mon, 14 Jun 2021 10:55:34 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id a1so22417405lfr.12 for ; Mon, 14 Jun 2021 10:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yvYJ1zLjtTUR3FPbr/lmxYCiRoY/X/QqUQgbH0TVM8c=; b=j+wuVZQsSud/MYyl1zua0AudbFcB3PhpXmAf8Pk+8S2tTA7Pn+GcdAKpAe2ImUOB5H 53owzqsznJKW2sApajZ0Bu0hH639L/duxc+UnCXts+BuQi4hebXofrsSBkuySrsa4dcz dV0OiDaOI8RcCKQVvps06wXizU4Wq6HRLhYTCDkjpMQjvWRkcGjMnMFarwvl2ZPthtTb PEN7DbsubiEGskBitqA+zLkIb1YqzntVcWpJuG83VTOdAzaljXU7ZthZSp6a4FCZc/6X VXvvNTEW1ofWl+cLOSe4titwDN52TtWWDdKvmp5zCRdjvs27w/umYFE1iuJgIugDtNZp vhiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yvYJ1zLjtTUR3FPbr/lmxYCiRoY/X/QqUQgbH0TVM8c=; b=H4VSA9cS6nW/UBEgRAD7qh0zyIfAZOh8jeCHz/G7vi35CZU0KC7WLocy3RgdHqWHmd 8D0QUfFYNkqkVmVPmYfvNrikiERHnk72B4WyYYM+QmDkvxPuO7T5r1kpXCSkWlH1Z4pB OzU79+B6grM/q63FWRU8puGmkPZMaqPKWHIK7D9JklABc0xh4tKOFIzC2r8k2siK2rKb 98NwC+2ZcQNV/Qfsup1Kz/SseGKRmb/rYQ9QY1zutP0bdZRcfdKP7r8a4+T5w7801R5C gx5LbpDD+zSxhKKRVA6A0De47i58HJA2xOQzj77lOC+vUMghiQe8FX3DPcQ3ByaKsX82 Fhdw== X-Gm-Message-State: AOAM5308X8O4xBh0dTCi+u4NVwjkMbEEgayu4WuMY5enX/QFJD1gUpeO bFdjFV7j6L3oOM6BXiqsv2iU9WnRD5K/FV4y/1KfzA== X-Google-Smtp-Source: ABdhPJxhlANpUNTfaI6r3Jq8WOvevHtnUemelOLh/ukYNbozYbwOKTdt8+B1BG+AXtkwW/MrLO2/cOQPIdzX40KdBGE= X-Received: by 2002:a05:6512:3604:: with SMTP id f4mr12828735lfs.553.1623693330855; Mon, 14 Jun 2021 10:55:30 -0700 (PDT) MIME-Version: 1.0 References: <0100017a0a164118-b7e3c4cc-177c-4211-b19a-9dcb77006dcd-000000@email.amazonses.com> <0100017a0b63209f-789f601b-574a-44c7-b870-ec9bbe870c75-000000@email.amazonses.com> <0100017a0b866f67-8f4f2e4e-6c67-41cc-9c7c-b49057826adb-000000@email.amazonses.com> In-Reply-To: From: Andy Bierman Date: Mon, 14 Jun 2021 10:55:19 -0700 Message-ID: To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000035cbea05c4bd9059" Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 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, 14 Jun 2021 17:55:40 -0000 --00000000000035cbea05c4bd9059 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 14, 2021 at 10:40 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.sterne@nokia.com> wrote: > Hi guys, > > I can understand that concern; and in particular for something like the > new import by "revision-or-derived". Ignoring that extension can mean tools > may not build the right schema (although is that any worse than today > without using import by revision ?). > > Despite that issue, I'd still advocate for revision-or-derived to be taken > to standard now. It is part of a few things that cause problems today that > really need to be addressed in the short term. > > But for things like the rev:non-backwards-compatible tag, and using YANG > semver, do those actually cause any new problems (vs what they help solve) > ? It doesn't cause tools to build the wrong thing, or servers to implement > the wrong thing. It only helps supply information about what is already > happening today (particularly in vendor modules, but also in standard > modules) that isn't being described at all (NBC changes that really do > impact the client, but the module name is kept the same). The WG had a fair > bit of discussion 2-3 years ago that this versioning work was needed and > should be adopted and progressed. That is still the case IMO. > > The all-or-none approach to the versioning work is producing more "none" than "all". ;-) YANG was designed to be used in a linear and singular release train. This is clearly not the way the real world can use YANG. Ignoring this pain point is making the problem worse over time. There are many corner-cases that the DT is spending a lot of time on that do not cause the deployment problems that a revision label could solve. My original point: Fix this problem with the best engineering solution possible even if that means a new YANG language version. Import-by-semver should not be super-complicated and it should not be optional for a compiler to use. Import-by-exact-revision is flawed and not worth preserving. Jason > Andy > > > -----Original Message----- > > From: Kent Watsen > > Sent: Monday, June 14, 2021 1:17 PM > > To: Andy Bierman > > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; > > netmod@ietf.org > > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08 > > > > > > > I meant the current work is using extensions instead of new language > > statements. > > > Not that the yang-version will never be changed in the future. > > > > Ah, okay. > > > > > > > It is not a matter of "when" if new functionality is added via > extensions. > > > In theory the WG could add new functionality to YANG 1.1 this way for > > years. > > > In practice it might be difficult to achieve widespread > interoperability if > > nobody > > > agrees what "YANG next" actually contains. Also, YANG 1.1 clearly > says a > > tool MAY > > > skip over and ignore ANY external statement, so it is problematic to > use > > extension-stmt > > > as if it was defining real statements. It is better to have a tool > clearly fail > > > with an "unsupported YANG version" error than it is to silently ignore > > external statements. > > > > Agreed. > > > > > > K. > > > > --00000000000035cbea05c4bd9059 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 14, 2021 at 10:40 AM Ster= ne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:
Hi guys,

I can understand that concern; and in particular for something like the new= import by "revision-or-derived". Ignoring that extension can mea= n tools may not build the right schema (although is that any worse than tod= ay without using import by revision ?).

Despite that issue, I'd still advocate for revision-or-derived to be ta= ken to standard now. It is part of a few things that cause problems today t= hat really need to be addressed in the short term.

But for things like the rev:non-backwards-compatible tag, and using YANG se= mver, do those actually cause any new problems (vs what they help solve) ? = It doesn't cause tools to build the wrong thing, or servers to implemen= t the wrong thing.=C2=A0 It only helps supply information about what is alr= eady happening today (particularly in vendor modules, but also in standard = modules) that isn't being described at all (NBC changes that really do = impact the client, but the module name is kept the same). The WG had a fair= bit of discussion 2-3 years ago that this versioning work was needed and s= hould be adopted and progressed. That is still the case IMO.


The all-or-none approach to the versio= ning work is producing more "none" than "all". ;-)

YANG was designed to be used in a linear and singular = release train.
This is clearly not the way the real world can use= YANG.
Ignoring this pain point is making the problem worse over = time.

There are many corner-cases that the DT is s= pending a lot of time on that
do not cause the deployment problem= s that a revision label could solve.

My original p= oint: Fix this problem with the best engineering solution possible
even if that means a new YANG language version.=C2=A0 Import-by-semver sh= ould
not be super-complicated and it should not be optional for a= compiler to use.

Import-by-exact-revision is flaw= ed and not worth preserving.=C2=A0


Jason

Andy
=C2=A0

> -----Original Message-----
> From: Kent Watsen <kent+ietf@watsen.net>
> Sent: Monday, June 14, 2021 1:17 PM
> To: Andy Bierman <andy@yumaworks.com>
> Cc: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>;
> netmod@ietf.org
> Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08=
>
>
> > I meant the current work is using extensions instead of new langu= age
> statements.
> > Not that the yang-version will never be changed in the future. >
> Ah, okay.
>
>
> > It is not a matter of "when" if new functionality is ad= ded via extensions.
> > In theory the WG could add new functionality to YANG 1.1 this way= for
> years.
> > In practice it might be difficult to achieve widespread interoper= ability if
> nobody
> > agrees what "YANG next"=C2=A0 actually contains. Also, = YANG 1.1 clearly says a
> tool MAY
> > skip over and ignore ANY external statement, so it is problematic= to use
> extension-stmt
> > as if it was defining real statements. It is better to have a too= l clearly fail
> > with an "unsupported YANG version" error than it is to = silently ignore
> external statements.
>
> Agreed.
>
>
> K.
>

--00000000000035cbea05c4bd9059-- From nobody Mon Jun 14 11:03:56 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7773A2CB3; Mon, 14 Jun 2021 11:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si41ffG2LzOj; Mon, 14 Jun 2021 11:03:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6583A2CB6; Mon, 14 Jun 2021 11:03:47 -0700 (PDT) Received: from dooku.sandelman.ca (desktop4.sandelman.ca [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 110651F456; Mon, 14 Jun 2021 18:03:46 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 779311A293E; Mon, 14 Jun 2021 14:03:43 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: anima@ietf.org, tools-discuss@ietf.org, netmod@ietf.org In-reply-to: References: <6795.1623632992@localhost> <16776.1623679777@localhost> <1CA387C6-6058-46DC-882B-BCBEB848FE7B@tzi.org> <77018.1623687978@dooku> Comments: In-reply-to Carsten Bormann message dated "Mon, 14 Jun 2021 18:29:51 +0200." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jun 2021 14:03:43 -0400 Message-ID: <81889.1623693823@dooku> Archived-At: Subject: Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 18:03:54 -0000 Carsten Bormann wrote: cb> How about >> cb> {::include foo-????-??-??.yang} >> cb> and, if there is no such file, kramdown-rfc expands the wild card in cb> the directory and uses the numerically latest file? >> >> You'd use shell globs? > Yes. Any need to go beyond that? >> I think it might be better to use PCRE. > Much more typing and backslash-mangling, and I don=E2=80=99t see the = use case. DOS/Windows people don't get shell globs, and "?" is not something they kno= w. >> It might be better to have this as "winclude" > So =E2=80=98loseclude=E2=80=99 would be including all matches? hah. > (What does the =E2=80=9Cw=E2=80=9D stand for?) wildcard. cb> (There might also be a use-case for actually including all these cb> files, so I=E2=80=99m still in thinking mode, but I think this is c= lose.) -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Mon Jun 14 11:38: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 B31133A2DBC; Mon, 14 Jun 2021 11:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cdYl8XySKo3T; Mon, 14 Jun 2021 11:38:15 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E92C03A2D6C; Mon, 14 Jun 2021 11:38:14 -0700 (PDT) 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 04789811F1; Mon, 14 Jun 2021 18:38:13 +0000 (UTC) From: Christian Hopps Message-Id: <6CA55CB9-CBF9-48C7-B925-892020D2ED72@chopps.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_447CE31D-42C5-404F-89C7-41AF110B8409" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 14 Jun 2021 14:38:12 -0400 In-Reply-To: <16776.1623679777@localhost> Cc: Carsten Bormann , anima@ietf.org, tools-discuss@ietf.org, netmod@ietf.org To: Michael Richardson References: <6795.1623632992@localhost> <16776.1623679777@localhost> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs 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, 14 Jun 2021 18:38:20 -0000 --Apple-Mail=_447CE31D-42C5-404F-89C7-41AF110B8409 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I didn=E2=80=99t think you were actually looking for a non-xml solution, = but as you mentioned in an earlier mail there=E2=80=99s my org-rfc setup = which makes all this yang stuff pretty simple. The source of the YANG = module is in the single org-mode formatted draft source, along with = support for YANG validation of the module and examples, generating YANG = trees, downloading YANG dependencies etc.. :) An example use: = https://github.com/choppsv1/draft-chopps-netmod-geo-location = Thanks, Chris. > On Jun 14, 2021, at 10:09 AM, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >> On 14. Jun 2021, at 03:09, Michael Richardson = wrote: >>>=20 >>> 1) how to process yang files with YYYY-DD-MM into XML. >>> 2) how to generate yang tree files. >>> 3) how do I get my YANG includes downloaded, and do I put them into = my repo? >>> 4) how to do this with MT Makefiles? >=20 >> I people could tell me what they need, we could develop a feature in >> kramdown-rfc to handle this. >=20 > One possibility is that kramdown-rfc ought to look for, and include = the > latest foo-YYYY-MM-DD.yang file, when told to ::include foo.yang. > Alternatively, it could perhaps do the YYYY-MM-DD substitution itself. >=20 >> (This would presumably also include support for YANG-SID files.) >=20 > That's mostly just a question about including the results, and it's = not that > hard thing to add to the main Makefile. >=20 > But, as I said, I xml2rfc doesn't have a useful include functionality, = for > when not working with kramdown. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_447CE31D-42C5-404F-89C7-41AF110B8409 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I didn=E2=80=99t think you were actually looking for a = non-xml solution, but as you mentioned in an earlier mail there=E2=80=99s = my org-rfc setup which makes all this yang stuff pretty simple. The = source of the YANG module is in the single org-mode formatted draft = source, along with support for YANG validation of the module and = examples, generating YANG trees, downloading YANG dependencies etc.. = :)

An example = use: https://github.com/choppsv1/draft-chopps-netmod-geo-location

Thanks,
Chris.

On Jun = 14, 2021, at 10:09 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Carsten Bormann <cabo@tzi.org> wrote:
On 14. Jun 2021, at 03:09, Michael Richardson = <mcr+ietf@sandelman.ca> wrote:

1) how to process yang files = with YYYY-DD-MM into XML.
2) how to generate yang tree = files.
3) how do I get my YANG includes downloaded, and do = I put them into my repo?
4) how to do this with MT = Makefiles?

I people could tell me = what they need, we could develop a feature in
kramdown-rfc = to handle this.

One = possibility is that kramdown-rfc ought to look for, and include the
latest foo-YYYY-MM-DD.yang file, when told to ::include = foo.yang.
Alternatively, it could perhaps do the = YYYY-MM-DD substitution itself.

(This would presumably also include support for = YANG-SID files.)

That's mostly = just a question about including the results, and it's not that
hard thing to add to the main Makefile.

But, as I said, I xml2rfc doesn't have a useful include = functionality, for
when not working with kramdown.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T= consulting )
=           Sandelman = Software Works Inc, Ottawa and Worldwide




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

= --Apple-Mail=_447CE31D-42C5-404F-89C7-41AF110B8409-- From nobody Tue Jun 15 10:56: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 A38FF3A382A; Tue, 15 Jun 2021 10:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eIAC-r7P0j7P; Tue, 15 Jun 2021 10:56:38 -0700 (PDT) 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 091803A382B; Tue, 15 Jun 2021 10:56:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7726E38C31; Tue, 15 Jun 2021 13:57:47 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6zXu5TqyMv3E; Tue, 15 Jun 2021 13:57:47 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 068BA38C2E; Tue, 15 Jun 2021 13:57:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5AEFB240; Tue, 15 Jun 2021 13:56:36 -0400 (EDT) From: Michael Richardson To: netmod@ietf.org, anima@ietf.org, Kent Watsen In-Reply-To: References: 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-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 15 Jun 2021 17:56:43 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable stfries wrote: > New assertion type for the voucher necessary for > agent-proximity. Likely to enhance the enum in the YANG module for the > voucher in [RFC > 8366](https://datatracker.ietf.org/doc/html/rfc8366#section-5.3) Kent, how do we do add a new enum? Does the grouping help us at all? We need to do this for both voucher and voucher-request. > enum agent-proximity { description "Indicates that the voucher has =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+93Q3WUFAmDI6dQACgkQgItw+93Q 3WWywQf+Mtu06J2FOPDV8FfjtYFaH2PZm0qHAwUC3N3WYZjbd0gw8vkWPy48wesa oISDNcF2Jg0gzXip77Izsyj98zbDSyElSN5b19uw9ElrlsE5PySX4muaOw8xTDIP DEqfAM7M2Zp1lOnQR2glb3Rv8fMYEDRwYwqoF/RjdpU9HgQ4Y7nc+kvdvCbojQZe B0hOMDRRmEsndHfCDYxGYCy0AGF4826VxE7Px6WIKVE/B1Gz9mtpQmwK2rdW4V8k dYCZbyQ4znzeg/vDq754pe9Ic+DVGhpMOsO6rwTJMf+XKyyPrIQXyiFr8L8JHlmT ypHEW4WfkqXN8IFLq7pKO/HjxJsmQw== =2Ejd -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 15 13:08: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 A13E33A3C2A for ; Tue, 15 Jun 2021 13:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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 snco8TGfWwyv for ; Tue, 15 Jun 2021 13:08:12 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2132.outbound.protection.outlook.com [40.107.237.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178E43A3C78 for ; Tue, 15 Jun 2021 13:08:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J4i08uEUzb99Kcfg2AaQxn6h1kPte8cktBVKJengv9n26wrC8uEpUJapnVNu7ZEOqjpBYW0VnmZSRVzAwlPq69jUuDhOImSxwMPvI7u10SDv0KkJKtZFKB9PxHOyF6smSNXCTgn4Y9zqJd5PtaepXwNtn2ov2500hDkvPY8ZWFcT2mS8LRDt7zse5melL9nPlVHE1xQXA/rp5QHDCU79BSt3gl1qfSSvvWOK7O8oRTJU9AuSbzLIsWIKlS8oKSbW42KXL0dqD2F92/jo+gAzf3KthLEZs88tO6vVScMJHTNvfcEYoRP1zj9tVfeJEdlXfQzlck2E75tDWALBhNt3Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LF1azRcNpPJV0a5nK3k0dhP1LqwcQQadgji+Jk3nwLw=; b=hZRfK+DMucndiMWyuSEOh5RoV6j34B6ps4Jj/Fhl0FTay/lQx7+49vNOJ5SmZmY1X/iFkSHi3bgd9Xew75UKo0SYtDD1yFQ7SvfPoJhdN/L2BsbFBWzmhNkAFzJHngL8cgah3p35MjD+SIdYx5pjFp427gx+k/G9Tx6M35a+51mmj1F10eDOwB6wVXlLkhGbhpL6XuMWqixZ1+K7lMztxGXOeGkZYk10GoEvgUfxUP8AlTJk+SP4nu8JtxJoYz9WxYT4R51wKf+ihWdZOYeFhjAIy1Ej+zImBYJko9mzn55+f48oWzAmGDSGy1WV2gUdg7Hi9KXfcIfNxK2evtiriQ== 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=LF1azRcNpPJV0a5nK3k0dhP1LqwcQQadgji+Jk3nwLw=; b=RIZmHhFuwj+nYahnx72dNvZyfmyvctwMDUIpH9vbZ/G3q7YyUxYsGcdJgH2J22Yt6eHmhtYNV+oNfPd6l6lvKcKBSIdzQ/QZKkxx3Quf4wsYbB7u6xwQ51P23+Jf0IdanBu0dWrdYadfFp4hv8spCWnFTM89oDz4A+mzsPx1Mcc= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB4700.namprd08.prod.outlook.com (2603:10b6:5:11::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21; Tue, 15 Jun 2021 20:08:04 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::f431:78d:76de:1ba5]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::f431:78d:76de:1ba5%7]) with mapi id 15.20.4219.025; Tue, 15 Jun 2021 20:08:04 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-06-15 Thread-Index: AddiIe+2lheUcJ/pRwS2xTl3umPBBA== Date: Tue, 15 Jun 2021 20:08:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9dae424-b734-48dd-5a44-08d9303948ba x-ms-traffictypediagnostic: DM6PR08MB4700: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sFMr6KA+tx+18IIC/IF65u2ha5b5xZDC/0RDZ6Xdy2KuqGlxBFVsTfHBUmND1lc8XqsCsZXh9Ot5MEHBXAx9sN7NGg9qPzr3T4VykXW/4SIEVP7S1uNH5KEJpBTJwa5mw/mDYtF2rQB5SMOhT7r0v7+KedNCgk3r2X41ABA+c9fDkQdIiR8ZdChaaiEcmnxezfKNrjngi1l7oz+f4g2XnCu0coWgSgplGg3uUOn1jGSKcLne4WEJGmTPGEAeR9o+qtrfe2FWtMiMQzQkzV/WhergSEODXmbGqoh6tpy4d0L8iyizjbaM6tUnb33LOX7AEKPBHayzvZeQRT81ljueHUxLMz5rkzuSYhso7+R9C7Sa/X8h4/e8rkCWOsD6DZoayX4/4r7Te1PH8e90co9BHiTI9WwctF/XfEHcBp/SoNxQUnSGQ4M84hWRV9twwqSzjk9jV3y2kxPL5iOzFipyLtV7v4H+6ct8c7YjtVUo+aYBfa9aygQN/ND18Fuq4oudgdoqyTQCaFY1UxyY0rEhfot1YPxj+C8NOEfypDzJ6O2vWYO8OVrQQGGuYs1FDIB6kB28fHiA10vmKW+HCY89AfDwJ6LBNdi/uxQIf4hSLTnCWbgvmaRRYi0TanuvoEVXnXnWZpDfmrUO4Vv5szIM1LAfaOn2xdY05+PPXnjLYUmn1OcmtxLXteeR/U+Zk0i0KwMQlm/uNHexzYwjCg7R0GGKvbW27b2L+h64geW8D0U= 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)(136003)(39850400004)(346002)(396003)(376002)(186003)(2906002)(122000001)(83380400001)(6916009)(71200400001)(966005)(33656002)(86362001)(76116006)(478600001)(26005)(64756008)(66946007)(66556008)(66476007)(66446008)(38100700002)(55016002)(8676002)(7696005)(9686003)(6506007)(316002)(52536014)(8936002)(5660300002)(16799955002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?0URDPux9leiYmiIJfBSQ0zpetYTdQxgUDMBimZQkDMrTMIVX0smxPni2xjgW?= =?us-ascii?Q?1cIax9M6n93DnEt2Ppkmw/Ce9RyAst1wYnXaScRpAng8debe29/8Z5lysVz9?= =?us-ascii?Q?Q2fMeI8hVC5XRaRVtdRZizqVk/WPvRd0OvJysdjUXlWj3mdSMC3DWjPvvX3s?= =?us-ascii?Q?4SiqSRf7/v2DQDZDa2/pl/yo1cvHPPwLBUauKQ8tZdJGOuIvcEYeiakhrsgY?= =?us-ascii?Q?gN/nEy3tD/zOJwvlnAHY5M7SnZiTg6ukHa6exal4yh4v/7d60JTUL+aVIvDO?= =?us-ascii?Q?9vSd4rF4slU3bnpKGCiOAEKL4C8su+L+WiModGjMkGxoNIuoif+unATXH3uL?= =?us-ascii?Q?G5Gb7w9WraTByYN6lYuHrzSBsGq92SWEWM0MHNkLODRK0CcoZ5U/JQnN2+iA?= =?us-ascii?Q?h/7oOXmoMpWrdLypF9S7ur017/aIB9/WHklI3kv9zdX/YyUgkeBElOuSXryA?= =?us-ascii?Q?IeOgMB8aIZB8pksvAw7d85m62Tn6X/qvioxgrWLRlkelVpQWjanRrIKn8c0X?= =?us-ascii?Q?78APXbau+0eV5wnBi9XZ2WPU/NDfaW+Lf1S3fxcuLj+ItCG+iG8hLQotTBgY?= =?us-ascii?Q?QFEy1yfEd4Ns8xzRLw15MTdjmxcLdm2nmwq0Xtcsvg9tOUJ5Bxf+2Fwh0zPx?= =?us-ascii?Q?nyoL6YZ5NN7Duga+SfehQayvW7AFC9x4uA/M3/ymLqDP3+hGZ/csmeDRpV0P?= =?us-ascii?Q?clHf6kuzjWU+uVC1gxZD7ZG7YRbtMOGl1LPHNG7/LoOenCctHO8SqnfsVou4?= =?us-ascii?Q?gNEN4U4tpwCf7HPHQ1gYYhnutYNwey2TCIIY2DuN+aG/4AP24Zft2P1gHrzL?= =?us-ascii?Q?JHIdLoBupKhyYBkkGGMB6nrmmiPboOKTe9SybZceQR0jqJ8otVIy+MbLg9TZ?= =?us-ascii?Q?AFxv1Cf3Ryz2pOPyUWFDG0SdPMz6jc148HJv28uJcLw8/AwPoAkzfBw3ZTNZ?= =?us-ascii?Q?a8IvpPzWowcoXq9p56ucV9CNZNvhXYxrWMif/l62ikHoCssLmHsQz7Q5aSRN?= =?us-ascii?Q?pN5KmOxfRK3eL0CU1zoLMBbQnqmEJPFAWFK8nKruiLd+fz/1tywTA4g2xYoA?= =?us-ascii?Q?EJ/voD9CLjkeBfHKnet/TxKUnrm4L6EIaCsURrf0lwrZEVda1vnc6jvCqcOn?= =?us-ascii?Q?tBt8UhmjegtFklDE0clDSlJ8qItMMmrsKbn0dgAnz2BeuITyuZWPH43C9hIp?= =?us-ascii?Q?VakmcKCoGlD2dCF+9qUb0k6uc4s+YyZtB1BgyL98PuSk2rfi90QTlJU0t5Pt?= =?us-ascii?Q?36mIZ8D6xFjoPu35FUOonaXkOjCHkI9Z6kMefjBtm2tzpp+e+pQJtMWCouUy?= =?us-ascii?Q?FD7QPPD4F68toIphFC1tRaPB?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084C95472FD9765D950AB729B309DM6PR08MB5084namp_" 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: b9dae424-b734-48dd-5a44-08d9303948ba X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2021 20:08:03.9508 (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: b1evyh5xyLWaebrOm9hKp5HBJVG6LJR8I6RA27uzg3cs3LQ2biyADJdeHC5DVypWgZyLR+i+zR9MN4FC+mMiqg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4700 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-15 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, 15 Jun 2021 20:08:19 -0000 --_000_DM6PR08MB5084C95472FD9765D950AB729B309DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-06-15 We only discussed the module versioning draft today. - remove the MUST NOT in the YANG module where it talks about substatements= of the new extensions Include the following text as part of section 7.1 author guidelines: In some cases a module or submodule revision that is not strictly NBC by th= e definition in section 3.1.2 of this specification may include the "non-ba= ckwards-compatible" statement. Here is an example when adding the statemen= t may be desirable: * A "config false" leaf had its value space expanded (for examp= le, a range was increased, or additional enums were added) and the author o= r server implementor feels there is a significant compatibility impact for = clients and users of the module or submodule We decided to avoid this example for now: * A complex or subtle change in a server implementation occurre= d and the compatibility impact to clients or users of the module or submodu= le aren't clear. it is better to err on the side of flagging this change as= NBC to alert users of a possible impact. But we may want to add these as examples (need some wordsmithing): - leaf description change example - if you aren't sure about a change, mark it NBC NBC tag -> only for modules ? revision-label -> can be used in modules and submodules ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB5084C95472FD9765D950AB729B309DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-06-15

 

We only discussed the module versioning draft today.=

 

- remove the MUST NOT in the YANG module where it ta= lks about substatements of the new extensions

 

Include the following text as part of section 7.1 au= thor guidelines:

 

In some cases a module or submodule revision that is= not strictly NBC by the definition in section 3.1.2 of this specification = may include the "non-backwards-compatible"  statement. Here = is an example when adding the statement may be desirable:

•       &nb= sp;     A "config false" leaf had its value s= pace expanded (for example, a range was increased, or additional enums were= added) and the author or server implementor feels there is a significant c= ompatibility impact for clients and users of the module or submodule

 

We decided to avoid this example for now:=

•       &nb= sp;     A complex or subtle change in a server implemen= tation occurred and the compatibility impact to clients or users of the mod= ule or submodule aren't clear. it is better to err on the side of flagging = this change as NBC to alert users of a possible impact.

 

But we may want to add these as examples (need some = wordsmithing):

- leaf description change example

- if you aren't sure about a change, mark it NBC

 

NBC tag -> only for modules ?

revision-label -> can be used in modules and subm= odules

 

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

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

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

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

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

Tap to join from a mobile device (attendees only)

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

--_000_DM6PR08MB5084C95472FD9765D950AB729B309DM6PR08MB5084namp_-- From nobody Wed Jun 16 15:44:49 2021 Return-Path: <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-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 26FC63A0954; Wed, 16 Jun 2021 15:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=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 kNSq7dDOfLX2; Wed, 16 Jun 2021 15:44:32 -0700 (PDT) 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 7FFBF3A0926; Wed, 16 Jun 2021 15:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1623883471; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=1SyggUeLOpH3aq+q2guuk1H2VmGN4WCIMfhFs5Obo1c=; b=L5viNIUWqJxBHtxrGyyKsJj5q3DgRkVHsF+j/YA9DiUvkcGW905NB9XU1pHlxVpG b62ghITZ/2tR2N2QIBs83pVCYSyHSHzN5qodX+L6usYExaKSgNrX3RdEmkERRlp0fht BjH3CYT2yxgYgTA/koNQfmkfFkoGGbpWkCtsga30= From: Kent Watsen Message-ID: <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E088290F-809E-4331-95D3-347D99199E00" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 16 Jun 2021 22:44:31 +0000 In-Reply-To: <19872.1623779796@localhost> Cc: "netmod@ietf.org" , anima@ietf.org To: Michael Richardson References: <19872.1623779796@localhost> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.16-54.240.48.94 Archived-At: Subject: Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 16 Jun 2021 22:44:44 -0000 --Apple-Mail=_E088290F-809E-4331-95D3-347D99199E00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, >> New assertion type for the voucher necessary for >> agent-proximity. Likely to enhance the enum in the YANG module for = the >> voucher in [RFC >> 8366](https://datatracker.ietf.org/doc/html/rfc8366#section-5.3) >=20 > Kent, how do we do add a new enum? > Does the grouping help us at all? > We need to do this for both voucher and voucher-request. Firstly, because it took me quite some time to put this message in = context, for everyone else, here=E2=80=99s a link to GitHub Issue #18: = https://github.com/anima-wg/anima-brski-async-enroll/issues/18 = . I=E2=80=99m unsure what it is trying to be accomplished but, generally, = either an =E2=80=9Caugment=E2=80=9D and a module-revision can be used to = add an enum. K. --Apple-Mail=_E088290F-809E-4331-95D3-347D99199E00 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Michael,

New assertion type for the voucher necessary = for
agent-proximity. Likely to enhance the enum in the = YANG module for the
voucher in [RFC
8366](https://datatracker.ietf.org/doc/html/rfc8366#section-5.3)<= br class=3D"">

Kent, how do we do add a new = enum?
Does the grouping help us at all?
We = need to do this for both voucher and voucher-request.

Firstly, because it took me quite some time to put = this message in context, for everyone else, here=E2=80=99s a link to = GitHub Issue #18: https://github.com/anima-wg/anima-brski-async-enroll/issues/18<= /a>.




= --Apple-Mail=_E088290F-809E-4331-95D3-347D99199E00-- From nobody Wed Jun 16 16:02: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 979213A0A6F for ; Wed, 16 Jun 2021 16:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzcAy56XVnYG for ; Wed, 16 Jun 2021 16:01:56 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 7F8433A0A68 for ; Wed, 16 Jun 2021 16:01:56 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id a21so1115450ljj.1 for ; Wed, 16 Jun 2021 16:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fG9Am0Fnu7ocSB3b4MM5yM6o0FGixVld3352VX0pQ28=; b=QB4+fu3LDWFWHj7h8bsNeXjW7iiT6gSBYgtwZgzM8ZsI8aDU1eMbDXey0xAhZUMBUb 2UhwA/K3NohtoIqPV1KhFz7skTjlRPiy8rvMqP0dX9+gOYLFZkfCnScpDP+u92i57mUz c5iTXGU620ouQWic/6Ih6dYHJhJqcw6pEdmH6NYFBcL1VCztRwWNvRxudk7p+FYzYeg1 lqYthezSTcss3wCXDUqf6GQyNikEDua6kn33hRpqeaFdq/UHRAVFt62FkfiiC/eYdHBF XzEY6EK0JesvKBVwxqOZ+Grz4tN7rOrRl8AeLmMZd+vtiqrDDVN+HUJwXcedxFw2h7/G Il/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fG9Am0Fnu7ocSB3b4MM5yM6o0FGixVld3352VX0pQ28=; b=rSPMgGeP+L838SPsZ+heh0twkjuS0mbBzz52WgZk2g8qFMtGnYDsW5vYRVg3gzjfJN NGvxuJmmf9rS7wEuJ8QRA/fH4N+u/nAoMiKF96wljYGChM/nCEfr1kHnsWjlPx4bWZ9u HZ749qsstK5zTUvjwW/6OXDaB+XwJEy5DCl5kCfQhpOXxNw6vXgxx6HIz+t1LvupcNT9 ZV+/POru3dspEvcBEzbMwLqNNoJ3EEnbVWY+Gl1+tkTZhdz9pDE/8q3pOKOkiTb1dCck Hb8v4YE6d/E7laMH2KBm+O2Ssv7NOw1EOVUoSbpkYgIjFzGd1+WrCe6tkLoDliuVk8Tr uM6Q== X-Gm-Message-State: AOAM533wYyqXR+EVhs3ZK8LPE2dKshlNwMiFXRVGy2FFH5yPHk7124B+ rmwDfAYE90TY4Z8HCGVsXefWucmt61ZXpugbUsC1Jg== X-Google-Smtp-Source: ABdhPJwdCGaWsjP2uciFMSnSRSU585GOhOxCCh2y3Ool6tlcvdPRWSqwWKyL+uMO1SOk9rFlzUAWv/P6Ip3ih1H3sbs= X-Received: by 2002:a2e:584e:: with SMTP id x14mr1198552ljd.91.1623884513938; Wed, 16 Jun 2021 16:01:53 -0700 (PDT) MIME-Version: 1.0 References: <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> In-Reply-To: <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> From: Andy Bierman Date: Wed, 16 Jun 2021 16:01:43 -0700 Message-ID: To: Kent Watsen Cc: Michael Richardson , anima@ietf.org, "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009c206205c4ea1327" Archived-At: Subject: Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 16 Jun 2021 23:02:03 -0000 --0000000000009c206205c4ea1327 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 16, 2021 at 3:45 PM Kent Watsen wrote: > > Hi Michael, > > New assertion type for the voucher necessary for > agent-proximity. Likely to enhance the enum in the YANG module for the > voucher in [RFC > 8366](https://datatracker.ietf.org/doc/html/rfc8366#section-5.3) > > > Kent, how do we do add a new enum? > Does the grouping help us at all? > We need to do this for both voucher and voucher-request. > > > Firstly, because it took me quite some time to put this message in > context, for everyone else, here=E2=80=99s a link to GitHub Issue #18: > https://github.com/anima-wg/anima-brski-async-enroll/issues/18. > > I=E2=80=99m unsure what it is trying to be accomplished but, generally, e= ither an > =E2=80=9Caugment=E2=80=9D and a module-revision can be used to add an enu= m. > > An enumeration type is hard-wired. No enums can be added via augmentation. You have to "deviate replace" the type-stmt to add an enum externally, or you have to update the module and add the enum inline. I > K. > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000009c206205c4ea1327 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 16, 2021 at 3:45 PM Kent = Watsen <kent+ietf@watsen.net> wrote:

Hi Michael,

=

Firstly, because it took me quite so= me time to put this message in context, for everyone else, here=E2=80=99s a= link to GitHub Issue #18:=C2=A0https://github.com/anima-= wg/anima-brski-async-enroll/issues/18.

I=E2=80= =99m unsure what it is trying to be accomplished but, generally, either an = =E2=80=9Caugment=E2=80=9D and a module-revision can be used to add an enum.=



An enumeration type is hard-wired.
No enums can be added vi= a augmentation.
You have to "deviate replace" the type-= stmt to add an enum externally,
or you have to update the module = and add the enum inline.


I
K.


Andy
=C2=A0

___________________________________= ____________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--0000000000009c206205c4ea1327-- From nobody Wed Jun 16 23:22: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 786D63A0D52; Wed, 16 Jun 2021 23:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.796 X-Spam-Level: X-Spam-Status: No, score=-6.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, 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 Rgf2DsujN8fz; Wed, 16 Jun 2021 23:22:06 -0700 (PDT) Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com [194.138.20.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFEEA3A0CDC; Wed, 16 Jun 2021 23:22:05 -0700 (PDT) Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle2.siemens.com (Postfix) with ESMTPS id DD95B46881F; Thu, 17 Jun 2021 08:22:02 +0200 (CEST) Received: from DEMCHDC8A2A.ad011.siemens.net (demchdc8a2a.ad011.siemens.net [139.25.226.108]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id 3483B1A25B2BA; Thu, 17 Jun 2021 08:22:00 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC8A2A.ad011.siemens.net (139.25.226.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 17 Jun 2021 08:21:59 +0200 Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2176.014; Thu, 17 Jun 2021 08:21:59 +0200 From: "Fries, Steffen" To: Kent Watsen , Michael Richardson CC: "anima@ietf.org" , "netmod@ietf.org" Thread-Topic: [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) Thread-Index: AQHXYwFgLCrCFxBCxkyTYyGOI/zAxKsXupsw Date: Thu, 17 Jun 2021 06:21:59 +0000 Message-ID: References: <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> In-Reply-To: <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> Accept-Language: en-US, de-DE 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-06-17T06:21:58Z; 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=8f3ce4b5-a281-4609-9a7e-6fab1bf4adff; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [144.145.220.66] Content-Type: multipart/alternative; boundary="_000_dd79da0017844ae7b6026e4a911a30d9siemenscom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 17 Jun 2021 06:22:17 -0000 --_000_dd79da0017844ae7b6026e4a911a30d9siemenscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudA0KTmV3IGFzc2VydGlvbiB0eXBlIGZvciB0aGUgdm91Y2hlciBuZWNlc3NhcnkgZm9y DQphZ2VudC1wcm94aW1pdHkuIExpa2VseSB0byBlbmhhbmNlIHRoZSBlbnVtIGluIHRoZSBZQU5H IG1vZHVsZSBmb3IgdGhlDQp2b3VjaGVyIGluIFtSRkMNCjgzNjZdKGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODM2NiNzZWN0aW9uLTUuMzxodHRwczovL2V1cjAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4MzY2JTIzc2VjdGlvbi01LjMmZGF0YT0w NCU3QzAxJTdDY2VmOTc2M2MtMTQ5Yy00ODgxLWI5YzItNWZlZGMyNzc2NjNhJTQwYWQwMTEuc2ll bWVucy5jb20lN0M4ZjBkZWY4MzMwNzQ0NTUyNzRlYjA4ZDkzMTE4NWU1MiU3QzM4YWUzYmNkOTU3 OTRmZDRhZGRhYjQyZTE0OTVkNTVhJTdDMSU3QzAlN0M2Mzc1OTQ4MDM1ODE0Njg1MTMlN0NVbmtu b3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENK QlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMjAwMCZzZGF0YT1yek1iNGtJZjJLRm9kcVRQ UW4wdCUyRlBSNFFhMzZzd01IUDV2cGM5MHc1VkklM0QmcmVzZXJ2ZWQ9MD4pDQoNCktlbnQsIGhv dyBkbyB3ZSBkbyBhZGQgYSBuZXcgZW51bT8NCkRvZXMgdGhlIGdyb3VwaW5nIGhlbHAgdXMgYXQg YWxsPw0KV2UgbmVlZCB0byBkbyB0aGlzIGZvciBib3RoIHZvdWNoZXIgYW5kIHZvdWNoZXItcmVx dWVzdC4NCg0KRmlyc3RseSwgYmVjYXVzZSBpdCB0b29rIG1lIHF1aXRlIHNvbWUgdGltZSB0byBw dXQgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQsIGZvciBldmVyeW9uZSBlbHNlLCBoZXJl4oCZcyBh IGxpbmsgdG8gR2l0SHViIElzc3VlICMxODogaHR0cHM6Ly9naXRodWIuY29tL2FuaW1hLXdnL2Fu aW1hLWJyc2tpLWFzeW5jLWVucm9sbC9pc3N1ZXMvMTg8aHR0cHM6Ly9ldXIwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmFu aW1hLXdnJTJGYW5pbWEtYnJza2ktYXN5bmMtZW5yb2xsJTJGaXNzdWVzJTJGMTgmZGF0YT0wNCU3 QzAxJTdDY2VmOTc2M2MtMTQ5Yy00ODgxLWI5YzItNWZlZGMyNzc2NjNhJTQwYWQwMTEuc2llbWVu cy5jb20lN0M4ZjBkZWY4MzMwNzQ0NTUyNzRlYjA4ZDkzMTE4NWU1MiU3QzM4YWUzYmNkOTU3OTRm ZDRhZGRhYjQyZTE0OTVkNTVhJTdDMSU3QzAlN0M2Mzc1OTQ4MDM1ODE0Nzg0NjklN0NVbmtub3du JTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRp STZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMjAwMCZzZGF0YT1CMWMlMkZHOUlTMlVtdjdLJTJG cEIlMkJLS1pXdnloQjFCcTBiTFJYJTJGcklSc1NaVGMlM0QmcmVzZXJ2ZWQ9MD4uDQoNCknigJlt IHVuc3VyZSB3aGF0IGl0IGlzIHRyeWluZyB0byBiZSBhY2NvbXBsaXNoZWQgYnV0LCBnZW5lcmFs bHksIGVpdGhlciBhbiDigJxhdWdtZW504oCdIGFuZCBhIG1vZHVsZS1yZXZpc2lvbiBjYW4gYmUg dXNlZCB0byBhZGQgYW4gZW51bS4NCg0KW3N0Zl0gVGhhbmsgeW91IGZvciB0aGUgaGludC4gSW4g b25lIG9mIHRoZSB1c2UgY2FzZXMgb2YgQlJTS0ktQUUgYSByZWdpc3RyYXItYWdlbnQgYWN0aW5n IG9uIGJlaGFsZiBvZiB0aGUgcmVnaXN0cmFyIGlzIHVzZWQgdG8gZmFjaWxpdGF0ZSB0aGUgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIHBsZWRnZSBhbmQgcmVnaXN0cmFyLiBJbiB0aGlzIGNhc2UgdGhl IE1BU0Egc2hvdWxkIGFzc2VydCDigJxhZ2VudC1wcm94aW1pdHnigJ0gaW5zdGVhZCBvZiDigJxw cm94aW1pdHnigJ0gdG8gc2hvdywgdGhhdCB0aGVyZSB3YXMgbm8gZGlyZWN0IGNvbm5lY3Rpb24g YmV0d2VlbiB0aGUgcGxlZGdlIGFuZCB0aGUgcmVnaXN0cmFyLiBBbHNvLCBhcyB0aGUgcGxlZGdl IGRvZXMgbm90IHZlcmlmeSBhIHNpZ25hdHVyZSBvZiB0aGUgcmVnaXN0cmFyLCB0aGlzIGFzc2Vy dGlvbiBpcyB3ZWFrZXIgdGhhbiDigJxwcm94aW1pdHnigJ0gYnV0IHN0cm9uZ2VyIHRoYW4g4oCc bG9nZ2Vk4oCdLiBUbyBhY2hpZXZlIHRoaXMgd2UgaW50ZW5kZWQgdG8gZW5oYW5jZSB0aGUgY3Vy cmVudCBlbnVtIHdpdGggdGhlIG5ldyBhc3NlcnRpb24gdHlwZS4NCg0KQmVzdCByZWdhcmRzDQpT dGVmZmVuDQo= --_000_dd79da0017844ae7b6026e4a911a30d9siemenscom_ 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 OnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgS2VudDxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OZXcgYXNzZXJ0aW9uIHR5 cGUgZm9yIHRoZSB2b3VjaGVyIG5lY2Vzc2FyeSBmb3I8YnI+DQphZ2VudC1wcm94aW1pdHkuIExp a2VseSB0byBlbmhhbmNlIHRoZSBlbnVtIGluIHRoZSBZQU5HIG1vZHVsZSBmb3IgdGhlPGJyPg0K dm91Y2hlciBpbiBbUkZDPGJyPg0KODM2Nl0oPGEgaHJlZj0iaHR0cHM6Ly9ldXIwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIu aWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGcmZjODM2NiUyM3NlY3Rpb24tNS4zJmFtcDtkYXRhPTA0 JTdDMDElN0NjZWY5NzYzYy0xNDljLTQ4ODEtYjljMi01ZmVkYzI3NzY2M2ElNDBhZDAxMS5zaWVt ZW5zLmNvbSU3QzhmMGRlZjgzMzA3NDQ1NTI3NGViMDhkOTMxMTg1ZTUyJTdDMzhhZTNiY2Q5NTc5 NGZkNGFkZGFiNDJlMTQ5NWQ1NWElN0MxJTdDMCU3QzYzNzU5NDgwMzU4MTQ2ODUxMyU3Q1Vua25v d24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pC VGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MyMDAwJmFtcDtzZGF0YT1yek1iNGtJZjJLRm9k cVRQUW4wdCUyRlBSNFFhMzZzd01IUDV2cGM5MHc1VkklM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODM2NiNzZWN0aW9uLTUuMzwvYT4p PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQpLZW50LCBob3cgZG8gd2UgZG8gYWRkIGEgbmV3IGVudW0/PGJyPg0KRG9lcyB0aGUgZ3JvdXBp bmcgaGVscCB1cyBhdCBhbGw/PGJyPg0KV2UgbmVlZCB0byBkbyB0aGlzIGZvciBib3RoIHZvdWNo ZXIgYW5kIHZvdWNoZXItcmVxdWVzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaXJzdGx5LCBiZWNh dXNlIGl0IHRvb2sgbWUgcXVpdGUgc29tZSB0aW1lIHRvIHB1dCB0aGlzIG1lc3NhZ2UgaW4gY29u dGV4dCwgZm9yIGV2ZXJ5b25lIGVsc2UsIGhlcmXigJlzIGEgbGluayB0byBHaXRIdWIgSXNzdWUg IzE4OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZhbmltYS13ZyUyRmFuaW1h LWJyc2tpLWFzeW5jLWVucm9sbCUyRmlzc3VlcyUyRjE4JmFtcDtkYXRhPTA0JTdDMDElN0NjZWY5 NzYzYy0xNDljLTQ4ODEtYjljMi01ZmVkYzI3NzY2M2ElNDBhZDAxMS5zaWVtZW5zLmNvbSU3Qzhm MGRlZjgzMzA3NDQ1NTI3NGViMDhkOTMxMTg1ZTUyJTdDMzhhZTNiY2Q5NTc5NGZkNGFkZGFiNDJl MTQ5NWQ1NWElN0MxJTdDMCU3QzYzNzU5NDgwMzU4MTQ3ODQ2OSU3Q1Vua25vd24lN0NUV0ZwYkda c2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dp TENKWFZDSTZNbjAlM0QlN0MyMDAwJmFtcDtzZGF0YT1CMWMlMkZHOUlTMlVtdjdLJTJGcEIlMkJL S1pXdnloQjFCcTBiTFJYJTJGcklSc1NaVGMlM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8vZ2l0 aHViLmNvbS9hbmltYS13Zy9hbmltYS1icnNraS1hc3luYy1lbnJvbGwvaXNzdWVzLzE4PC9hPi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKA mW0gdW5zdXJlIHdoYXQgaXQgaXMgdHJ5aW5nIHRvIGJlIGFjY29tcGxpc2hlZCBidXQsIGdlbmVy YWxseSwgZWl0aGVyIGFuIOKAnGF1Z21lbnTigJ0gYW5kIGEgbW9kdWxlLXJldmlzaW9uIGNhbiBi ZSB1c2VkIHRvIGFkZCBhbiBlbnVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bc3RmXSBUaGFu ayB5b3UgZm9yIHRoZSBoaW50LiBJbiBvbmUgb2YgdGhlIHVzZSBjYXNlcyBvZiBCUlNLSS1BRTxi Pg0KPC9iPmEgcmVnaXN0cmFyLWFnZW50IGFjdGluZyBvbiBiZWhhbGYgb2YgdGhlIHJlZ2lzdHJh ciBpcyB1c2VkIHRvIGZhY2lsaXRhdGUgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBwbGVkZ2Ug YW5kIHJlZ2lzdHJhci4gSW4gdGhpcyBjYXNlIHRoZSBNQVNBIHNob3VsZCBhc3NlcnQg4oCcYWdl bnQtcHJveGltaXR54oCdIGluc3RlYWQgb2Yg4oCccHJveGltaXR54oCdIHRvIHNob3csIHRoYXQg dGhlcmUgd2FzIG5vIGRpcmVjdCBjb25uZWN0aW9uIGJldHdlZW4gdGhlDQogcGxlZGdlIGFuZCB0 aGUgcmVnaXN0cmFyLiBBbHNvLCBhcyB0aGUgcGxlZGdlIGRvZXMgbm90IHZlcmlmeSBhIHNpZ25h dHVyZSBvZiB0aGUgcmVnaXN0cmFyLCB0aGlzIGFzc2VydGlvbiBpcyB3ZWFrZXIgdGhhbiDigJxw cm94aW1pdHnigJ0gYnV0IHN0cm9uZ2VyIHRoYW4g4oCcbG9nZ2Vk4oCdLiBUbyBhY2hpZXZlIHRo aXMgd2UgaW50ZW5kZWQgdG8gZW5oYW5jZSB0aGUgY3VycmVudCBlbnVtIHdpdGggdGhlIG5ldyBh c3NlcnRpb24gdHlwZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0ZWZmZW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_dd79da0017844ae7b6026e4a911a30d9siemenscom_-- From nobody Thu Jun 17 00:48:58 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7384C3A1176; Thu, 17 Jun 2021 00:48:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162391613140.8434.1051643473343940780@ietfa.amsl.com> Date: Thu, 17 Jun 2021 00:48:51 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-geo-location-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 07:48:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : A YANG Grouping for Geographic Locations Author : Christian Hopps Filename : draft-ietf-netmod-geo-location-10.txt Pages : 25 Date : 2021-06-17 Abstract: This document defines a generic geographical location YANG grouping. The geographical location grouping is intended to be used in YANG models for specifying a location on or in reference to Earth or any other astronomical object. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netmod-geo-location-10.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-geo-location-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 17 00: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 D62DE3A117C; Thu, 17 Jun 2021 00:50:44 -0700 (PDT) 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 vGtxursxBW-W; Thu, 17 Jun 2021 00:50:38 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 95F2C3A1193; Thu, 17 Jun 2021 00:50:38 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A269A80F37; Thu, 17 Jun 2021 07:50:37 +0000 (UTC) References: <162142641389.26028.16682502889430351090@ietfa.amsl.com> <0872384B-C41A-4F2F-8D5D-736C78265B89@ericsson.com> User-agent: mu4e 1.5.13; emacs 27.2 From: Christian Hopps To: Francesca Palombini Cc: Christian Hopps , The IESG , "draft-ietf-netmod-geo-location@ietf.org" , "netmod-chairs@ietf.org" , "netmod@ietf.org" , "kent+ietf@watsen.net" Date: Thu, 17 Jun 2021 03:49:22 -0400 In-reply-to: <0872384B-C41A-4F2F-8D5D-736C78265B89@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] Francesca Palombini's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) 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, 17 Jun 2021 07:50:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Francesca Palombini writes: > Hi Chris, > > Inline. I've posted a new version with the updated IANA registry changes. https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/10/ Thanks, Chris. > > Thanks, > Francesca > > =EF=BB=BFOn 27/05/2021, 00:04, "Christian Hopps" wrot= e: > > > Francesca Palombini via Datatracker writes: > > > Francesca Palombini has entered the following ballot position for > > draft-ietf-netmod-geo-location-08: Discuss > > > > > > > -------------------------------------------------------------------= --- > > DISCUSS: > > -------------------------------------------------------------------= --- > > > > Thank you for the work on this document, and thank you to the sheph= erd for a > > very well-written shepherd write up. > > > > I have a couple of DISCUSS points related to the IANA section, and = some non > > blocking question. > > > > Francesca > > > > 1. ----- > > > > The allocation policy for this registry is First Come, First Ser= ved, > > [RFC8126] as the intent is simply to avoid duplicate values. > > > > FP: RFC 8126 specifies: > > > > When creating a new registry with First Come First Served as the > > registration policy, in addition to the contact person field or > > reference, the registry should contain a field for change contro= ller. > > Having a change controller for each entry for these types of > > registrations makes authorization of future modifications more c= lear. > > See Section 2.3. > > > > The current registry dos not contain contact person, nor reference,= nor change > > controller fields. > > I honestly have no idea what to put in that field for the referenced = standards. Certainly we can't just point people at the defining standards o= r people who wrote them as they have no reason to pay attention to our YANG= groupings IANA registry. Should I put myself, or the NETMOD working group = perhaps? > > FP: For the value you register in this document, I think it would make se= nse to have the reference to this document. For change controller, it is qu= ite common to have IESG. That would mean two changes: > - add 2 columns: "Reference" and "Change control" to table 3, where Refer= ence is > [This document] and Change control is IESG, for all rows. (You don't need= to add > one column for contact person, I have noticed it is quite common for IANA > registry to use that same Reference column to point either to a standard = or to a > contact person) > - add a sentence stating that "Reference" can point to the document doing= the registration or the contact person, as defined by RFC 8126. > > > 2. ----- > > > > It should be noted that [RFC5870] also creates a registry for > > Geodetic Systems (it calls CRS); however, this registry has a ve= ry > > strict modification policy. The authors of [RFC5870] have the s= tated > > goal of making CRS registration hard to avoid proliferation of C= RS > > values. As our module defines alternate systems and has a broad= er > > (beyond Earth) scope, the registry defined below is meant to be = more > > easily modified. > > > > FP: Thanks for bringing this up - I want to confirm that we need th= is registry, > > and that we are not creating a way to bypass the CRS registration p= olicies by > > providing a different registry with a more lenient policy. > > > > FP: This was discussed during the telechat and is resolved, so as soon as= we agree on point 1. I will remove my DISCUSS. > > > > > -------------------------------------------------------------------= --- > > COMMENT: > > -------------------------------------------------------------------= --- > > > > > > 3. ----- > > > > [WGS84] National Imagery and Mapping Agency., "National Image= ry > > and Mapping Agency Technical Report 8350.2, Third > > Edition.", 3 January 2000, > info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf= >. > > > > FP: I support Lars DISCUSS, and add the following normative referen= ce to the > > list - link is broken. A quick google search found this: > > https://protect2.fireeye.com/v1/url?k=3D8c4dc9b7-d3d6f09a-8c4d892c-= 8692dc8284cb-c0df19b629553d9e&q=3D1&e=3D7e44c916-ff47-4dae-b193-a89283c4947= 2&u=3Dhttps%3A%2F%2Fgis-lab.info%2Fdocs%2Fnima-tr8350.2-wgs84fin.pdf , whic= h I assume is the > > wanted reference... but I don't think that we should be relying on = informal > > communities to maintain normative references to our documents, can = we do better? > > I removed the URLs -- obviously they are not stable. So we can procee= d with the normal document title, author, and publication date. > > FP: I see that there was discussion with Lars about it, so I will leave i= t up to you and Rob to decide the best way forward. However I do agree with= Lars (and quoting him) that: > ".. since you'd want those references to be easily and unambiguously find= able by readers/implementers, including them is usually very helpful, espec= ially for normative references, which are basically required reading." So m= y preference would be to keep the URI to the most stable possible link. > > > 4. ----- > > > > choice "latitude" and "longitude" are specified as fractions of > > decimal degrees, and the "height" value is in fractions of meter= s. > > For the Cartesian choice "x", "y" and "z" are in fractions of me= ters. > > > > FP: I have the feeling that the document is specifying both numeric= data > > expected and unit at the same time "fraction of _insert unit_". For= the sake of > > clarity, I think it would be best to split this up, so change the "= fraction of > > meters" to "meters, expressed in floating point". TODO: check that = format is > > defined. > > It is specifying units and their format, I felt this was simply conci= se, but not confusing. Do you feel strongly about this? FWIW we use YANG de= cimal64 not floating point in the YANG grouping. > > FP: No I don't feel strongly about this, and as you say that is defined i= n the YANG grouping. It's fine keeping it this way, thanks for the answer. > > > 5. ----- > > > > FP: After looking for a while: does a stable reference exist for th= e list of > > astronomical bodies and their name (rather than just saying it is m= aintained by > > IAU)? I only found the following for stars: > > https://protect2.fireeye.com/v1/url?k=3D815a5923-dec1600e-815a19b8-= 8692dc8284cb-37bc0f18508bb22e&q=3D1&e=3D7e44c916-ff47-4dae-b193-a89283c4947= 2&u=3Dhttps%3A%2F%2Fwww.iau.org%2Fpublic%2Fthemes%2Fnaming_stars%2F . I als= o found the page for the > > corresponding WG, which defined the guidelines for naming stars. I = was > > wondering if there is a reference to these guidelines for all astro= nomical > > bodies. What I am especially concerned about is that I was not able= to verify > > that we will not incur on encoding problems, if IAU changes their n= aming > > conventions, given the following text in the document: > > > > '67p/churyumov-gerasimenko (a comet). The value sho= uld > > be comprised of all lower case ASCII characters not > > including control characters (i.e., values 32..64, = and > > 91..126). Any preceding 'the' in the name should no= t be > > No I don't have a stable reference. It was very hard to track all of = what I have, down. The best I could do was just point at the IAU. > > FP: I see that Roman has the same comment as me in his DISCUSS, I'll let = you and Rob solve with him. The point is that without a clear reference, th= e description of "An astronomical body as named by the International Astro= nomical Union (IAU) " becomes hard to enforce. > > Thanks, > Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmDK/swACgkQLh2DDte4 MCUPdBAAm9Uiv3U5jEQRf+tLey4DAoKJ2gnTbgcoVlqpZgLXAfk7wXyoLmkfx7KR aZR+MSgTwQFbJRG3h/f0thblmQ0kje0bFbvQ8530y1PtVSsUwpzrmD0qJKfrRuzz 9c9YBx+O9VQI7st4JasYB0Yx6ge86ELFuOCtScZO7Ey5uc75QD2MkUeas4Eb3nrS 8tx7KCqSgChBO5YKYyGH9k3NFrmvqyiZB+kE6YvWoxOZf9P1DKNorpmgKzc/I+eD aafWsxkyCuDt1ZmQSbJqPca/xIvhdLcFFDsTSN6qdfc56sTXkkjGKf8G+16uJqhs CDqlUt5p/HSKxYY3AICgvitIDAE58QPb+AXVp/zdQ6LgUbagUyuH4BK4PQMMAYUd ZmtAH2cwlpWUeAy8HY2SlkDzDMtXvmPNqHSTtHyGIfgG6/g1meq7o2OdGe4vhWqv tFLuvLG3VOTyCU+2SCOrhZaCqL7do2DoCO1gL+1bMKjZDO5/KlWo/2m29F0yJs9I YN+PAYx+em3Lv22tTYkf+fCZrnGWMlF5AcnGLe4LPfEfNb/F9l3sGQD5ebZtSiSo cY9kl9GK0vuHT+/KJmo/gmCcu4jvvWDlCvXHf4lRx7mZ9wraOyVOkFxhBBhBNHFi YOj9s+eWdaSXR0HfvQKz7MjJ0PQXrBfQSb6TbBPg6JmJIuZ7ylk= =dq9g -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 17 03:53:40 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3563A19B3; Thu, 17 Jun 2021 03:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lQu1hPkD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FgB0Oo1O 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 3qt84QxvliZG; Thu, 17 Jun 2021 03:53:35 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9D33A19B5; Thu, 17 Jun 2021 03:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24674; q=dns/txt; s=iport; t=1623927214; x=1625136814; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4mznZUSyz1cUxVTI/6bm7lwbcV2JQMXG8GDyVoslXjk=; b=lQu1hPkDbbBmHzcqXTZgUTWCtjlDXLs2BAlcZw4t4ixSgtXWYMOd4zp8 C8a5Dq8QPjvHMtDHBXDUO2O4gh71Fk1eDPJDdz5rVGpyIemDULpI9AExi BBpGI64s91IcY/8oIBuGd9b4Pzs+2kQAOLSK1mzVkF97PNx/HhjYutiPl k=; X-IPAS-Result: =?us-ascii?q?A0CkAgAmKctgl4QNJK1QCh4BAQsSDECBTAuBU1F+WhMkM?= =?us-ascii?q?QuEPYNIA4U5iQIDgQ2JPoUOiF6BY4EuFIERA1QLAQEBDQEBLRICBAEBhFACF?= =?us-ascii?q?4JVAiU1CA4CBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQFohWgNh?= =?us-ascii?q?kUBAQEEEhERDAEBNwELBAIBBgIRAQMBAQMCERUCAgIfERUCBggCBAENBQgTB?= =?us-ascii?q?4JPAYJVAy8BA4pMjzQBgToCih96gTKBAYIHAQEGBASFNg0LgjEJgRAqgnuED?= =?us-ascii?q?oEXgVCDeiccgUlEgRVDgio2PoIggV0SAQcEBgIBBgIaBTECBYJYNoIugi4uP?= =?us-ascii?q?gYBFygLARgEIiEKBSECLQkbCB0cJQQNEgUCDwMhDwiROoM0iEiMHk2PKYFEO?= =?us-ascii?q?lsKgx6KEI4PhXQSg16BQolikBGGW5RHgQ+CGIdjhUqPVC4DGAOEWAIEAgQFA?= =?us-ascii?q?g4BAQaBVQE3a3BwFYMkCUcXAg6OHxmDV4peczgCBgEJAQEDCXyGIAIPFweBB?= =?us-ascii?q?wEyQxsBAQ?= IronPort-PHdr: A9a23:vPzO3hfmFAXUeMTZRYVzCldVlGM/r4qcDmcuAtIPgLZDd6Hl+I7tb wTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pNVcFhMwakhZmDJuDDkv2f/XuYik/W sNYWwwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4= IronPort-HdrOrdr: A9a23:NQu8+qOxb4EnR8BcT33155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHPlOkMks1NaZLUjbUQ6TTL2KgrGSuAEIdxeOk9K1kJ 0QD5SWa+eATmSS7/yKmjVQeuxIqLLsnczY5pa9854ud3AWV0gK1XYeNu/vKDwPeOAwP+tBKH Pz3LsimxOQPVAsKuirDHgMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlql9yZbdwkK7aYp8G DDnQC8zL6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+40ow3TX+0KVjbZaKvu/VQMO0biSAZER4Y HxSiIbToNOArXqDzqISFXWqlPdOX0Vmg7fIBej8AveSIrCNW8H4w4rv/MHTvMfgHBQ4O2UmZ g7rF6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOLFuJYO5gLZvt3+9Kq1wVh4SKbpXZt VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06GlODTlIZssKY3jBKlDQhpnFoi/A3jzMF7tYwWpNE7+ PLPuBhk6xPVNYfaeZ4CP0aScW6B2TRSVbHMX6UI17gCKYbUki956IfII9FrN1CXaZ4gqfatK 6xJG+whFRCMn4GU/f+qaGj2iq9N1lVcw6duP1j2w== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.83,280,1616457600"; d="scan'208";a="702163771" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2021 10:53:33 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 15HArXwI029505 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Jun 2021 10:53:33 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 17 Jun 2021 05:53:32 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 17 Jun 2021 05:53:32 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 17 Jun 2021 05:53:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iAmBcn9KaRnhbw+cF9TCh4UlO9TuOFO20+keQowf7FkQznEhmeccq/V3Da5fQqEhFNayocirMZdVJXqbYH47f6lSkT0aLhz0hQw10i0/owrn2MudDiXNSXn6QufVnq+JDPzGd29HZHzyO0HTlugL1fAwjeqGcsC0JswjAmf7+M7sOZz/tz2B/bgCDo82ongCwyImwOu61KtKyDYq5PDEt6YDctRaTdt9P3wRFp/HfsLyCtdPh9jB9CRDJ4iJmICNQG7eJvG/uW3WpkWVRmGJ1m8FoWt+GRHl7obZgmoQq24XE0+XsXEz3FrnXfScxxmufbPplZG8fRIVmtOywJuNHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4mznZUSyz1cUxVTI/6bm7lwbcV2JQMXG8GDyVoslXjk=; b=W1zRTG22QOt4G2oVNUBGHzgnpw19PxwAtR0MfMZdPjaA3jPOQwPaZMwJFiNayiQ6SpZcXQVgVqcnCelSmspQim2I83sFQn8EUVqjSzfp5O/GtLq2TPb+BNItuitF/NicCr1FMoIR4YTD3FmV+JpT+dO9LOgebplJnbYn9+s/9p8TqBtN5lTWl+oGnmq7fbhrzJV33WA2xQITejpkj/AvW8Gs6c7HuMmhoPO76Y3hY836ku5Sq4dJCYzwU9nY4wAwaZfKyCnvGFbK1Va8h+HqE7AD6kAFRwj1QsUaCSy04dkEvTPmNSs9kFEHzvw9FCLp7adMxZIx/CYBVHEEWRBdOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4mznZUSyz1cUxVTI/6bm7lwbcV2JQMXG8GDyVoslXjk=; b=FgB0Oo1OpKaHjDNns9jrsi6Zg2Y+CDcN8dlZvzpfbZ04JLCZcJDs/1bCBagjGR868g/KfDVFrTIk4nu8hv8Blx8MoGf3THK0Gk4P3fk2nR6tXX32eyOHxrhVQ8fFYPMgxel8ZHI3UmeTuzv9EuSCsFSq3DMgj7v8PUulvYTNfbo= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM5PR1101MB2251.namprd11.prod.outlook.com (2603:10b6:4:53::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.22; Thu, 17 Jun 2021 10:53:30 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c%6]) with mapi id 15.20.4219.026; Thu, 17 Jun 2021 10:53:30 +0000 From: "Rob Wilton (rwilton)" To: Alexander L Clemm , joel jaeggli CC: NetMod WG Chairs , "draft-ietf-netmod-nmda-diff.all@ietf.org" , "netmod@ietf.org" Thread-Topic: AD review of draft-ietf-netmod-nmda-diff-07 Thread-Index: Adat+a/3DPT1aCJSTfuydcCuPD9V4wAX4/YAAAExU4AAtpAc8BgpU+wAAAMUy5AAAXn4AAHzy1VgAABxjAAAC8qHgA24FI6ABKUFiUA= Date: Thu, 17 Jun 2021 10:53:30 +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: clemm.org; dkim=none (message not signed) header.d=none;clemm.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f7744100-c68a-4ab8-d3db-08d9317e2535 x-ms-traffictypediagnostic: DM5PR1101MB2251: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZOfVw9X+IiDRZBQl6LVM0eumKYKpfMcTd0wA+dqKt/R5o6iCWzIrDmUXns7d0qYTHVAyfSlOlJPgwib/nYizWQr7M9pEpVWZoinclw4A6MU5AE6eVwqOpxzZkOKtD0wrIOY6GPxvJ+Iqb1bXY0L9brSxVyevIRPNxh3elPTqGwImlp5iMdqgj8A5zdGkhcX5JPfCFEmxowda632VTTQPNSAcOGTUn9t3V20gYgi9/uq60gyNzYVNrgQj9m92WOk/u33YumzO9l2jwkLbNhVB58QD2vWclallzCvXjEwbeV/QICO7f9+o6DHxpLJXW0JsNqgvTSsaRHGwR+nfJflXZ6oJ0kSuObiGvne7vCOITdZwki+K2qZXtYT1Y2TVwMMwJzf8+lDoRIwyDF0P+bCcs7gsK/F5oe72VjCClFJd8imxxO7C0Co1eLWApYCaQ/hsEjYNWON+r3QkxDMu3wFQ9JPA2ev0XoxAKb8pQc/FMA2qhMs+tw92k2/NkGczOl9IBv86dGF+6BXfGseX2FE/ywvvLBj3E1+bzwsesMBs+bNT8W57qfRbMv2sWZONX0tzZS8fA64rV1sF5zX4uY0ANgRpWOonqMf0DcdEG3Dx1CA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(346002)(396003)(136003)(376002)(52536014)(6506007)(8676002)(30864003)(53546011)(478600001)(7696005)(66556008)(5660300002)(110136005)(83380400001)(8936002)(54906003)(66476007)(64756008)(33656002)(2906002)(26005)(55016002)(9686003)(71200400001)(66446008)(86362001)(186003)(4326008)(316002)(66946007)(38100700002)(76116006)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TWIyVEdId3NFQ29NNTFlRkdSRFJPZDk4R1VsMzFGZXY2YlZ3M1dkeHdrUVZs?= =?utf-8?B?Mk5wMXFlZ1E2VWVTU0NLeW5CTHd3eTVJNGVzYzRJRWM2S3A5R0dabVVuYzUr?= =?utf-8?B?K0ZaMHpYSXZTa21iMWd1blp3QlBwU0NOTEpzQ2Nqb2NQZ0d0amhMd3NNNEZG?= =?utf-8?B?L2ZiUEt4bGF3d2NGNlQ1ZmptMTJ4cjdicXdiQnF0dml6YUIzUGU2Z25JZy9B?= =?utf-8?B?N3V5MFB1cnNBdUxFWE9ZTllDRUdBRkpDYUZyaWFFazgzbnB3OXVPTVVIbEEx?= =?utf-8?B?RlFmc3FWRWlVN2t0N1cvVFJRMFNFcUE1UUNTWXFHbVg4S2llMHNjSUJKbEcx?= =?utf-8?B?eTNtdUxSNXVVek9zVHNUczF2UXdBU1Jsb09xRVhnRytCNnJZTjMvdzVGUGlH?= =?utf-8?B?eTJwRU0yT2R2ODZvRkxPL0lPRlFJM3owZUtEWVlkNXRvTTRwc050Q0kwd0Zr?= =?utf-8?B?MFRMTkxNeHh4NzUzY1p1NWxKanU0SkpHNXhLUzFyOFBhWFhOYTRmNkovbjN3?= =?utf-8?B?Q3JXcjlWT0VCWEo4Zjh1WHZ4azROWGlHd05CMkFlWHBLNHVlR3dUcnJsamFN?= =?utf-8?B?dklhcHpMaDN4WitseXBpbkM3U2x5ZzBvSnMyY0RlZ1NabzB2Zy9CYlErc1R4?= =?utf-8?B?aDFLZDgzamM5MXZZQTdJaDRMSkhRd0IrYU55VlZ6VVpscFRZdE5YaEV6Qmxo?= =?utf-8?B?cXpDS3FzMi9yMkxIY1JqZStHQTJqcGpGSDRmRlNrbU82dDBwV0U3WHZNU1Rh?= =?utf-8?B?ZkVrcEYvaFliWUdyKy9iTjFSRUI1OFFQUDNQRnhXODMvdWU5bXBiT25tekgr?= =?utf-8?B?L3pNNnZDbUlJNzl1bEJDM3BLMXBKOEhmNm1iT3FlVlFzQyt6S2lZb20zZi9l?= =?utf-8?B?N2VycFRsa2doejVodE1TbUpqdSt5Z0NvcVo4NzVaV2lPTmxRdXh5cHNiN2U3?= =?utf-8?B?dDZaSkU4c0U1MW5FTDdXQklMODBLcHZqcVBTcHBaTkxZRFFSTklEdkptWkFQ?= =?utf-8?B?ZFhpWmN6Z0E0NHB0aFUzQTAyWUZTSlh1TlFLcmprenUzaWcvd2hFVloxWlBi?= =?utf-8?B?TllHd1hzSU5WZWV3MW51UnBQOUxHZG9SRDF1WWhiZ2RDOCs4SlY3bDlEeHlC?= =?utf-8?B?S3N0WGNCWjNBS0VBc1h5T2cxQ3AzL1RJZXRQeWpHNDc5WHRiN0JaWUFkam9U?= =?utf-8?B?VFRMM3VtUjk3RDR5VkJhQ0ppTXN3aU1CU3BqYUp4OCsrQUc0ODB6UzFqSldN?= =?utf-8?B?MytIR3hIbGRsbHpxTkVhbXBQbUZJK3IwTWRCTGJpRlUwdW42TWhVdk5iRVlh?= =?utf-8?B?N2tsNUFKb1R0WGEyWWxDaGxuM0xaRFNpUVpyWEI4U2s2ME5tY04yQ25KNFJS?= =?utf-8?B?UEovZllnU3ZtaVFSUUZQVG1nU05xaGJKSXM1VGpiSFlMSy8vV0ExUlJOMjNS?= =?utf-8?B?MHlHSDVGTW5qTEJvRGJmejF4eTVsc1ZFQW5aRFVKVTVUaWtKUXI4NmtxanVz?= =?utf-8?B?Lzl0eHZDR0U5S3JGRWhmckZLYmxFS1pTUm5SK1pZUk9zdSsrZlk4R05qSGU4?= =?utf-8?B?cVI0dTVwaG03anFKb0JBK0hOQjFFZkRQWERmSVNRcnhOVkpHeHl4am1USE9Z?= =?utf-8?B?enAvM0YrcGZqNlBDajRoTlBBNnV1OGRPRUczMi9pSXlheW16OEpVOG9SdHRD?= =?utf-8?B?S2owVjFzNEFKcGtjWENHTjFhb1Q5OHg5aU9SeTgvbHhTZHk2cldSVDdaclJK?= =?utf-8?Q?vrLb0ALYt99IGYH7URLQ1cp4whr9vL+7SWj6cR/?= x-ms-exchange-transport-forked: True 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: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7744100-c68a-4ab8-d3db-08d9317e2535 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 10:53:30.7947 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: z7EuU5ZTHgsuGsIgxk8KpfXE9xErDTiPrE+d1/sWAaMB5OvyE44Ok5N/ujykeIPwOYf2Ug1wwTFwETmPkmDQVg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2251 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 10:53:40 -0000 SGkgQWxleCwNCg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlcy4NCg0KSSBtaXNzZWQgdGhhdCB0aGUg SUFOQSBDb25zaWRlcmF0aW9ucyAoc2VjIDgpLCB0aGUgcmVmZXJlbmNlIHNob3VsZCBiZSB0byBS RkMgNjAyMCBiZWNhdXNlIHRoYXQgZGVmaW5lcyB0aGUgWUFORyBtb2R1bGUgcmVnaXN0cnksIHNv IHBsZWFzZSBjYW4geW91IGZpeCB0aG9zZSB0d28gcmVmZXJlbmNlcyBmcm9tIDc5NTAgdG8gNjAy MCwgYW5kIGFsc28gYWRkIDYwMjAgdG8gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzLg0KDQpBIGNv dXBsZSBvZiBtaW5vciBuaXRzIG9uIHRoZSBsYXRlc3QgdmVyc2lvbjoNCg0Kcy9zdGF0aXN0aWNz L3N0YXRpc3RpY3MuLyAoc2Vjb25kIHBhcmFncmFwaCBpbiB0aGUgaW50cm8pDQpzL2luY3VyZS9p bmN1ci8NCg0KSWYgeW91IGNhbiBwbGVhc2UgdXBkYXRlIHRoZXNlIGFuZCBwaW5nIG1lLCBJJ2xs IGtpY2sgb2ZmIHRoZSBJRVRGIExDLg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5kZXIgTCBDbGVtbSA8bHVkd2lnQGNsZW1t Lm9yZz4NCj4gU2VudDogMjQgTWF5IDIwMjEgMjA6MDkNCj4gVG86IGpvZWwgamFlZ2dsaSA8am9l bGphQGdtYWlsLmNvbT47IFJvYiBXaWx0b24gKHJ3aWx0b24pDQo+IDxyd2lsdG9uQGNpc2NvLmNv bT4NCj4gQ2M6IE5ldE1vZCBXRyBDaGFpcnMgPG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc+OyBkcmFm dC1pZXRmLW5ldG1vZC1ubWRhLQ0KPiBkaWZmLmFsbEBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1kYS1kaWZm LTA3DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBSb2IsIHRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlv dXIgQUQgcmV2aWV3IcKgIFdlIGhhdmUganVzdCBwb3N0ZWQgYSBuZXcNCj4gcmV2aXNpb24gLTA4 IHRha2luZyB5b3VyIGNvbW1lbnRzIGludG8gYWNjb3VudC7CoCBQbGVhc2UgZmluZCBhdHRhY2hl ZA0KPiBhbmQgYmVsb3cgbXkgcmVwb25zZXMgdG8geW91ciBjb21tZW50cyAoaW5saW5lLCBkZWxp bWl0ZWQgPEFDPjsNCj4gYXBvbG9naWVzIGZvciBoYXZpbmcgdGFrZW4gc28gbG9uZykuDQo+IA0K PiBUaGFua3MNCj4gDQo+IC0tLSBBbGV4DQo+IA0KPiANCj4gDQo+IEhpLA0KPiANCj4gSGVyZSBp cyBteSBBRCByZXZpZXcgZm9yIGRyYWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi0wNy7CoCBBcG9s b2dpZXMgZm9yDQo+IHRoZSBkZWxheS4NCj4gDQo+IFRoYW5rIHlvdSBmb3Igd3JpdGluZyB0aGlz IGRvY3VtZW50LCBJIHRoaW5rIHRoYXQgaXQgaXMgdXNlZnVsLCBhbmQNCj4gbG9va3MgbGlrZSBp dCBpcyBpbiBnb29kIHNoYXBlLg0KPiANCj4gDQo+IE1haW4gY29tbWVudHM6DQo+IA0KPiAxLiBT aG91bGQgdGhlcmUgYmUgYW55IHRleHQgYWJvdXQgaG93IHRvIGZpbmQgb3V0IHdoYXQgZGF0YXN0 b3JlcyBhcmUNCj4gc3VwcG9ydGVkIGJ5IGEgZGV2aWNlP8KgIEUuZy4sIHBvaW50aW5nIHRoZW0g dG8gZWl0aGVyIFlBTkcgbGlicmFyeSwgb3INCj4gcHJvdG9jb2wgc3BlY2lmaWMgbWVjaGFuaXNt cyBpbiB0aGUgY2FzZSBvZiBSRVNUQ09ORi4NCj4gDQo+IDxBQz4gUmVwbHk6IE5vdGUgc3VyZSB0 aGlzIGlzIG5lZWRlZCwgYW5kIHdoZXJlIHdlIHdvdWxkIGV2ZW4gc2F5IGl0IGluDQo+IHRoZSB0 ZXh0LsKgIFBlcmhhcHMgaW4gdGhlIEludHJvZHVjdGlvbiwgd2hlcmUgd2UgaW50cm9kdWNlIE5N REEsIGENCj4gc2VudGVuY2Ugb2YgdGhlIHNvcnQ6ICJUbyBpZGVudGlmeSB3aGljaCBkYXRhc3Rv cmVzIGFyZSBzdXBwb3J0ZWQgYnkgYQ0KPiBnaXZlbiBkZXZpY2UsIC4uLiIuDQo+IElmIHdlIHdh bnRlZCB0byB0aGlzLCBvbmUgcXVlc3Rpb24gaXMsIGhvdyBpcyB0aGlzIGFjdHVhbGx5IGRvbmU/ IFJGQw0KPiA4MzQyIG1ha2VzIG5vIHN0YXRlbWVudCBhYm91dCB0aGlzOyBpdCBkZWZpbmVzIGlk ZW50aXRpZXMgYW5kIHR5cGVkZWZzDQo+IGJ1dCBubyBjYXBhYmlsaXRpZXMgb3IgZGF0YSBtb2Rl bCB0aGF0IHdvdWxkIGluZGljYXRlIHRoZSBjYXBhYmlsaXRpZXMuDQo+IDwvQUM+DQo+IA0KPiAy LiBJdCBtaWdodCBiZSBoZWxwZnVsIHRvIGFkZCBhIGNvbW1lbnQgYWJvdXQgcG90ZW50aWFsIGlz c3VlcyB0aGF0DQo+IGNvdWxkIGFyaXNlIGJ5IGNvbXBhcmluZyA8cnVubmluZz4gdG8gPG9wZXJh dGlvbmFsPiwgaS5lLiwgYWRkaXRpb25hbA0KPiBkaWZmZXJlbmNlcyBjb3VsZCBiZSByZXBvcnRl ZCBkdWUgdG8gaW5hY3RpdmUgY29uZmlndXJhdGlvbiBhbmQgdGVtcGxhdGUNCj4gcHJvY2Vzc2lu ZyBiZXR3ZWVuIDxydW5uaW5nPiBhbmQgPG9wZXJhdGlvbmFsPi4NCj4gDQo+IDxBQz4gUmVwbHk6 IEkgbW9kaWZpZWQgdGhlIGxhc3Qgc2VudGVuY2UgaW4gdGhlIGZvdXJ0aCBwYXJhZ3JhcGggaW4g dGhlDQo+IEludHJvZHVjdGlvbiBhcyBmb2xsb3dzOg0KPiAiVGhpcyBjYW4gYmUgdGhlIGNhc2Ug ZHVlIHRvIGNlcnRhaW4gY29uZGl0aW9ucyBub3QgYmVpbmcgbWV0LCBjZXJ0YWluDQo+IHBhcnRz IG9mIHRoZSBjb25maWd1cmF0aW9uIG5vdCBwcm9wYWdhdGluZyBiZWNhdXNlIGNvbnNpZGVyZWQg aW5hY3RpdmUsDQo+IHJlc291cmNlIGRlcGVuZGVuY2llcyBub3QgYmVpbmcgcmVzb2x2ZWQsIG9y IGV2ZW4gaW1wbGVtZW50YXRpb24gZXJyb3JzDQo+IGluIGNvcm5lciBjb25kaXRpb25zLiINCj4g SSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIHRlbXBsYXRlIHByb2Nlc3NpbmcgaXNzdWU7 IGNhbiB5b3UgcGxlYXNlDQo+IGVsYWJvcmF0ZT8NCj4gPC9BQz4NCj4gDQo+IDMuIEkgd291bGQg cHJlZmVyIGlmICdleGNsdWRlPW9yaWdpbicgd2FzIGluIHRoZSByZXZlcnNlIHNlbnNlIGFuZA0K PiBwZXJoYXBzIGNhbGxlZCAncmVwb3J0LW9yaWdpbicgaW5zdGVhZC7CoCBXaXRoIHRoZSByZXZl cnNlIHNlbnNlIGl0IHNlZW1zDQo+IHRvIGJlIHNhZmVyIGlmIG5ldyBkYXRhc3RvcmVzIGFyZSBk ZWZpbmVkLCB3aGVyZSBvdGhlcndpc2UgdGhlIGJlaGF2aW91cg0KPiBjb3VsZCBlbmQgYmVpbmcg dW5kZXIgc3BlY2lmaWVkLg0KPiANCj4gPEFDPiBSZXBseTogVXBkYXRlZCBpdCBwZXIgZGlzY3Vz c2lvbiBpbiB0aGUgbWFpbCB0aHJlYWQuDQo+IDwvQUM+DQo+IA0KPiANCj4gNC4gU2hvdWxkIHRo ZXJlIGJlIGFuIG9wdGlvbiB0byBmaWx0ZXIgb24gb3JpZ2luIG1ldGFkYXRhP8KgIEUuZy4sIG9u bHkNCj4gaW5jbHVkZSB2YWx1ZXMgdGhhdCBjb21lIGZyb20gaW50ZW5kZWQuwqAgT3RoZXJ3aXNl LCB0aGluZ3MgbGlrZSBJUA0KPiBhZGRyZXNzZXMgbGVhcm5lZCBmcm9tIERIQ1AgbWF5IGFsd2F5 cyB0dXJuIHVwIGFzIGRpZmZlcmVuY2VzLg0KPiANCj4gPEFDPiBSZXBseTogYWNjZXB0aW5nIHBy b3Bvc2VkIGNoYW5nZSBwZXIgdGhlIGVtYWlsIGRpc2N1c3Npb24NCj4gQ2hhbmdlZCAiZXhjbHVk ZS1vcmlnaW4iIHRvICJyZXBvcnQtb3JpZ2luIiwgd2l0aCBuZXcgZGVzY3JpcHRpb24gYXMNCj4g Zm9sbG93czoNCj4gwqDCoMKgwqDCoCBsZWFmIHJlcG9ydC1vcmlnaW4gew0KPiDCoMKgwqDCoMKg wqDCoCB0eXBlIGVtcHR5Ow0KPiDCoMKgwqDCoMKgwqDCoCBkZXNjcmlwdGlvbg0KPiDCoMKgwqDC oMKgwqDCoMKgwqAgIldoZW4gdGhpcyBsZWFmIGlzIHByb3ZpZGVkLCBvcmlnaW4gbWV0YWRhdGEg aXMNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgaW5jbHVkZWQgYXMgcGFydCBvZiBSUEMgb3V0cHV0 LiBXaGVuIHRoaXMgbGVhZiBpcw0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoCBvbWl0dGVkLCBvcmln aW4gbWV0YWRhdGEgaW4gY29tcGFyaXNvbnMgdGhhdCBpbnZvbHZlDQo+IMKgwqDCoMKgwqDCoMKg wqDCoMKgIDxvcGVyYXRpb25hbD4gaXMgYnkgZGVmYXVsdCBvbWl0dGVkLiI7DQo+IMKgwqDCoMKg wqAgfQ0KPiANCj4gQW5hbG9nb3VzIGNoYW5nZSBpbiB0aGUgZGF0YSBtb2RlbCBvdmVydmlldzoN Cj4gInJlcG9ydC1vcmlnaW46IFdoZW4gc2V0LCB0aGlzIHBhcmFtZXRlciBpbmRpY2F0ZXMgdGhh dCBvcmlnaW4gbWV0YWRhdGENCj4gc2hvdWxkIGJlIGluY2x1ZGVkIGFzIHBhcnQgb2YgUlBDIG91 dHB1dC4gV2hlbiB0aGlzIHBhcmFtZXRlciBpcw0KPiBvbWl0dGVkLCBvcmlnaW4gbWV0YWRhdGEg aW4gY29tcGFyaXNvbnMgdGhhdCBpbnZvbHZlIDxvcGVyYXRpb25hbD4gaXMgYnkNCj4gZGVmYXVs dCBvbWl0dGVkLiINCj4gDQo+IFVwZGF0ZWQgYWxzbyB0aGUgb3V0cHV0IHBhcmFtZXRlciBkZXNj cmlwdGlvbiBvZiAiZGlmZmVyZW5jZXMiIGFjY29yZGluZ2x5Og0KPiANCj4gUHJldmlvdXM6DQo+ IFdoZW4gdGhlIHRhcmdldCBkYXRhc3RvcmUgaXMgPG9wZXJhdGlvbmFsPiwgIm9yaWdpbiIgbWV0 YWRhdGEgaXMNCj4gaW5jbHVkZWQgYXMgcGFydCBvZiB0aGUgcGF0Y2guDQo+IE5ldzoNCj4gV2hl biB0aGUgdGFyZ2V0IGRhdGFzdG9yZSBpcyA8b3BlcmF0aW9uYWw+IGFuZCB0aGUgaW5wdXQgcGFy YW1ldGVyDQo+ICJyZXBvcnQtb3JpZ2luIiBpcyBzZXQsICJvcmlnaW4iIG1ldGFkYXRhIGlzIGlu Y2x1ZGVkIGFzIHBhcnQgb2YgdGhlIHBhdGNoLg0KPiANCj4gQWxzbyB1cGRhdGVkIHRoZSBleGFt cGxlczoNCj4gDQo+IE5ldyBSUEMgcmVxdWVzdCAoTkVUQ09ORik6DQo+IA0KPiA8cnBjIG1lc3Nh Z2UtaWQ9IjEwMSINCj4gwqDCoMKgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv bmY6YmFzZToxLjAiPg0KPiDCoCA8Y29tcGFyZSB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpu czp5YW5nOmlldGYtbm1kYS1jb21wYXJlIg0KPiDCoMKgwqDCoMKgIHhtbG5zOmRzPSJ1cm46aWV0 ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1kYXRhc3RvcmVzIj4NCj4gwqDCoMKgIDxzb3VyY2U+ ZHM6b3BlcmF0aW9uYWw8L3NvdXJjZT4NCj4gwqDCoMKgIDx0YXJnZXQ+ZHM6aW50ZW5kZWQ8L3Rh cmdldD4NCj4gwqDCoMKgIDxyZXBvcnQtb3JpZ2luLz4NCj4gwqDCoMKgIDx4cGF0aC1maWx0ZXIN Cj4gwqDCoMKgwqDCoMKgwqAgeG1sbnM6aWY9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzpp ZXRmLWludGVyZmFjZXMiPg0KPiDCoMKgwqDCoMKgIC9pZjppbnRlcmZhY2VzDQo+IMKgwqDCoCA8 L3hwYXRoLWZpbHRlcj4NCj4gwqAgPC9jb21wYXJlPg0KPiA8L3JwYz4NCj4gDQo+IChSUEMgcmVw bHkgcmVtYWlucyB0aGUgc2FtZSkNCj4gDQo+IE5ldyBSUEMgcmVxdWVzdCAoUkVTVENPTkYpOg0K PiANCj4gUE9TVCAvcmVzdGNvbmYvb3BlcmF0aW9ucy9pZXRmLW5tZGEtY29tcGFyZTpjb21wYXJl IEhUVFAvMS4xDQo+IEhvc3Q6IGV4YW1wbGUuY29tDQo+IENvbnRlbnQtVHlwZTogYXBwbGljYXRp b24veWFuZy1kYXRhK2pzb24NCj4gQWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLWQNCj4geyAiaWV0 Zi1ubWRhLWNvbXBhcmU6aW5wdXQiIHsNCj4gwqDCoCAic291cmNlIiA6ICJpZXRmLWRhdGFzdG9y ZXM6b3BlcmF0aW9uYWwiLA0KPiDCoMKgICJ0YXJnZXQiIDogImlldGYtZGF0YXN0b3JlczppbnRl bmRlZCIsDQo+IMKgwqAgInJlcG9ydC1vcmlnaW4iIDogbnVsbCwNCj4gwqDCoCAieHBhdGgtZmls dGVyIiA6ICIvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMiDQo+IMKgwqAgfQ0KPiB9DQo+IA0K PiAoYWdhaW4sIFJQQyByZXBseSByZW1haW5zIHRoZSBzYW1lKQ0KPiANCj4gPC9BQz4NCj4gDQo+ IA0KPiA1LiBJJ20gbm90IHRoYXQga2VlbiBvbiB0aGUgIlBvc3NpYmxlIEZ1dHVyZSBFeHRlbnNp b25zIiBzZWN0aW9uIG9mIGFuDQo+IFJGQy7CoCBQZXJzb25hbGx5LCBJIHdvdWxkIHByZWZlciB0 aGF0IHRoaXMgc2VjdGlvbiBpcyBkZWxldGVkLCBidXQgaWYNCj4geW91IHdpc2ggdG8gcmV0YWlu IGl0LCB0aGVuIHBsZWFzZSBjYW4geW91IG1vdmUgaXQgdG8gYW4gYXBwZW5kaXguDQo+IA0KPiA8 QUM+IE1vdmVkIHNlY3Rpb24gOCB0byBhbiBhcHBlbmRpeC4gSWYgdGhlcmUgYXJlIG9iamVjdGlv bnMgdG8gdGhhdCwgd2UNCj4gY2FuIGFsc28gZGVsZXRlIGl0IGVudGlyZWx5LCBidXQgbXkgcHJl ZmVyZW5jZSB3b3VsZCBiZSBmb3IgaXQgdG8gcmVtYWluDQo+IGFzIEkgdGhpbmsgdGhlIGRpc2N1 c3Npb24gaXMgdXNlZnVsIGFzIGl0IGFsc28gb3V0bGluZXMgc29tZSBwcmFjdGljYWwNCj4gY29u c2lkZXJhdGlvbnMuDQo+IDwvQUM+DQo+IA0KPiBJJ3ZlIGFsc28gaW5jbHVkZWQgc29tZSBtaW5v ciBjb21tZW50cyBpbmxpbmUgYmVsb3csIGFuZCBzb21lIG5pdHMgYXQNCj4gdGhlIGVuZDoNCj4g DQo+IMKgwqDCoCBBYnN0cmFjdA0KPiANCj4gwqDCoMKgwqDCoMKgIFRoaXMgZG9jdW1lbnQgZGVm aW5lcyBhbiBSUEMgb3BlcmF0aW9uIHRvIGNvbXBhcmUgbWFuYWdlbWVudA0KPiDCoMKgwqDCoMKg wqAgZGF0YXN0b3JlcyB0aGF0IGNvbXBseSB3aXRoIHRoZSBOTURBIGFyY2hpdGVjdHVyZS4NCj4g DQo+IFRoZSBhYnN0cmFjdCBpcyBwZXJoYXBzIHNvbWV3aGF0IHRlcnNlLsKgIFBlcmhhcHM6DQo+ IA0KPiDCoMKgwqAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBSUEMgb3BlcmF0aW9uIHRv IGNvbXBhcmUgdGhlDQo+IMKgwqDCoCBjb250ZW50cyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQgZGF0 YXN0b3JlcyB0aGF0IGNvbXBseSB3aXRoDQo+IMKgwqDCoCB0aGUgTk1EQSBhcmNoaXRlY3R1cmUg YW5kIHJldHVybiB0aGUgZGlmZmVyZW5jZXMgaW4gdGhlDQo+IMKgwqDCoCBZQU5HLVBhdGNoIGZv cm1hdC4NCj4gDQo+IA0KPiDCoMKgwqAgMS7CoCBJbnRyb2R1Y3Rpb24NCj4gDQo+IMKgwqDCoMKg wqDCoCBUaGUgcmV2aXNlZCBOZXR3b3JrIE1hbmFnZW1lbnQgRGF0YXN0b3JlIEFyY2hpdGVjdHVy ZSAoTk1EQSkNCj4gwqDCoMKgwqDCoMKgIFtSRkM4MzQyXSBpbnRyb2R1Y2VzIGEgc2V0IG9mIG5l dyBkYXRhc3RvcmVzIHRoYXQgZWFjaCBob2xkIFlBTkctDQo+IMKgwqDCoMKgwqDCoCBkZWZpbmVk IGRhdGEgW1JGQzc5NTBdIGFuZCByZXByZXNlbnQgYSBkaWZmZXJlbnQgInZpZXdwb2ludCIgb24g dGhlDQo+IMKgwqDCoMKgwqDCoCBkYXRhIHRoYXQgaXMgbWFpbnRhaW5lZCBieSBhIHNlcnZlci7C oCBOZXcgWUFORyBkYXRhc3RvcmVzIHRoYXQgYXJlDQo+IMKgwqDCoMKgwqDCoCBpbnRyb2R1Y2Vk IGluY2x1ZGUgPGludGVuZGVkPiwgd2hpY2ggY29udGFpbnMgdmFsaWRhdGVkIGNvbmZpZ3VyYXRp b24NCj4gwqDCoMKgwqDCoMKgIGRhdGEgdGhhdCBhIGNsaWVudCBhcHBsaWNhdGlvbiBpbnRlbmRz IHRvIGJlIGluIGVmZmVjdCwgYW5kDQo+IMKgwqDCoMKgwqDCoCA8b3BlcmF0aW9uYWw+LCB3aGlj aCBjb250YWlucyBhdCBsZWFzdCBjb25jZXB0dWFsbHkgb3BlcmF0aW9uYWwgc3RhdGUNCj4gwqDC oMKgwqDCoMKgIGRhdGEgKHN1Y2ggYXMgc3RhdGlzdGljcykgYXMgd2VsbCBhcyBjb25maWd1cmF0 aW9uIGRhdGEgdGhhdCBpcw0KPiDCoMKgwqDCoMKgwqAgYWN0dWFsbHkgaW4gZWZmZWN0Lg0KPiAN Cj4gSSB3b3VsZCBzdWdnZXN0IGRlbGV0aW5nICJhdCBsZWFzdCBjb25jZXB0dWFsbHkiLCBzaW5j ZSB0aGUgPG9wZXJhdGlvbmFsPg0KPiBkYXRhc3RvcmUgZG9lcyBjb250YWluIGFsbCBvcGVyYXRp b25hbCBzdGF0ZSwgYnV0IGl0IG1heSBiZSBpbXBsZW1lbnRlZA0KPiBhcyBhIHZpcnR1YWwgY29u c3RydWN0IHRoYXQgc3BhbnMgbXVsdGlwbGUgbm9kZXMgKGUuZy4sIGxpbmVjYXJkcykgYW5kDQo+ IHByb2Nlc3Nlcy4NCj4gDQo+IDxBQz4gQ2hhbmdlZA0KPiA8L0FDPg0KPiANCj4gwqDCoMKgwqDC oMKgIE5NREEgaW50cm9kdWNlcyBpbiBlZmZlY3QgYSBjb25jZXB0IG9mICJsaWZlY3ljbGUiIGZv ciBtYW5hZ2VtZW50DQo+IMKgwqDCoMKgwqDCoCBkYXRhLCBhbGxvd2luZyB0byBjbGVhcmx5IGRp c3Rpbmd1aXNoIGJldHdlZW4gZGF0YSB0aGF0IGlzIHBhcnQgb2YgYQ0KPiDCoMKgwqDCoMKgwqAg Y29uZmlndXJhdGlvbiB0aGF0IHdhcyBzdXBwbGllZCBieSBhIHVzZXIsIGNvbmZpZ3VyYXRpb24g ZGF0YSB0aGF0DQo+IMKgwqDCoMKgwqDCoCBoYXMgYWN0dWFsbHkgYmVlbiBzdWNjZXNzZnVsbHkg YXBwbGllZCBhbmQgdGhhdCBpcyBwYXJ0IG9mIHRoZQ0KPiDCoMKgwqDCoMKgwqAgb3BlcmF0aW9u YWwgc3RhdGUsIGFuZCBvdmVyYWxsIG9wZXJhdGlvbmFsIHN0YXRlIHRoYXQgaW5jbHVkZXMgYm90 aA0KPiDCoMKgwqDCoMKgwqAgYXBwbGllZCBjb25maWd1cmF0aW9uIGRhdGEgYXMgd2VsbCBhcyBz dGF0dXMgYW5kIHN0YXRpc3RpY3MuDQo+IA0KPiAiYWxsb3dpbmcgdG8gY2xlYXJseSBkaXN0aW5n dWlzaCIgPT4gZGlzdGluZ3Vpc2hpbmciDQo+ICJzdGF0dXMgYW5kIHN0YXRpc3RpY3MiID0+ICJz dGF0dXMgaW5mb3JtYXRpb24gYW5kIHN0YXRpc3RpY3MiDQo+IA0KPiA8QUM+IENoYW5nZWQNCj4g PC9BQz4NCj4gDQo+IMKgwqDCoMKgwqDCoCBBcyBhIHJlc3VsdCwgZGF0YSBmcm9tIHRoZSBzYW1l IG1hbmFnZW1lbnQgbW9kZWwgY2FuIGJlIHJlZmxlY3RlZCBpbg0KPiDCoMKgwqDCoMKgwqAgbXVs dGlwbGUgZGF0YXN0b3Jlcy7CoCBDbGllbnRzIG5lZWQgdG8gc3BlY2lmeSB0aGUgdGFyZ2V0IGRh dGFzdG9yZSB0bw0KPiDCoMKgwqDCoMKgwqAgYmUgc3BlY2lmaWMgYWJvdXQgd2hpY2ggdmlld3Bv aW50IG9mIHRoZSBkYXRhIHRoZXkgd2FudCB0byBhY2Nlc3MuDQo+IMKgwqDCoMKgwqDCoCBUaGlz IHdheSwgYW4gYXBwbGljYXRpb24gY2FuIGRpZmZlcmVudGlhdGUgd2hldGhlciB0aGV5IGFyZSAo Zm9yDQo+IMKgwqDCoMKgwqDCoCBleGFtcGxlKSBpbnRlcmVzdGVkIGluIHRoZSBjb25maWd1cmF0 aW9uIHRoYXQgaGFzIGJlZW4gYXBwbGllZCBhbmQgaXMNCj4gwqDCoMKgwqDCoMKgIGFjdHVhbGx5 IGluIGVmZmVjdCwgb3IgaW4gdGhlIGNvbmZpZ3VyYXRpb24gdGhhdCB3YXMgc3VwcGxpZWQgYnkg YQ0KPiDCoMKgwqDCoMKgwqAgY2xpZW50IGFuZCB0aGF0IGlzIHN1cHBvc2VkIHRvIGJlIGluIGVm ZmVjdC4NCj4gDQo+IFBlcmhhcHMgcmV3b3JkIHRoZSBsYXN0IHNlbnRlbmNlIHRvIG1hdGNoIHRo ZSBsb2dpY2FsIGRhdGEgZmxvdyBpbiB0aGUNCj4gc2VydmVyOg0KPiANCj4gwqDCoCBGb3IgZXhh bXBsZSwgYSBjbGllbnQgYXBwbGljYXRpb24gY2FuIGRpZmZlcmVudGlhdGUgd2hldGhlciB0aGV5 IGFyZQ0KPiDCoMKgIGludGVyZXN0ZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24gc3VwcGxpZWQgdG8g YSBzZXJ2ZXIgYW5kIHRoYXQgaXMNCj4gwqDCoCBzdXBwb3NlZCB0byBiZSBpbiBlZmZlY3QsIG9y IHRoZSBjb25maWd1cmF0aW9uIHRoYXQgaGFzIGJlZW4gYXBwbGllZA0KPiBhbmQgaXMNCj4gwqDC oCBhY3R1YWxseSBpbiBlZmZlY3Qgb24gdGhlIHNlcnZlci4NCj4gDQo+IDxBQz4gQ2hhbmdlZA0K PiA8L0FDPg0KPiANCj4gwqDCoMKgwqDCoMKgIFdoZW4gY29uZmlndXJhdGlvbiB0aGF0IGlzIGlu IGVmZmVjdCBpcyBkaWZmZXJlbnQgZnJvbSBjb25maWd1cmF0aW9uDQo+IMKgwqDCoMKgwqDCoCB0 aGF0IHdhcyBhcHBsaWVkLCBtYW55IGlzc3VlcyBjYW4gcmVzdWx0LsKgIEl0IGJlY29tZXMgbW9y ZSBkaWZmaWN1bHQNCj4gwqDCoMKgwqDCoMKgIHRvIG9wZXJhdGUgdGhlIG5ldHdvcmsgcHJvcGVy bHkgZHVlIHRvIGxpbWl0ZWQgdmlzaWJpbGl0eSBvZiBhY3R1YWwNCj4gwqDCoMKgwqDCoMKgIHN0 YXR1cyB3aGljaCBtYWtlcyBpdCBtb3JlIGRpZmZpY3VsdCB0byBhbmFseXplIGFuZCB1bmRlcnN0 YW5kIHdoYXQNCj4gwqDCoMKgwqDCoMKgIGlzIGdvaW5nIG9uIGluIHRoZSBuZXR3b3JrLsKgIFNl cnZpY2VzIG1heSBiZSBuZWdhdGl2ZWx5IGFmZmVjdGVkIChmb3INCj4gwqDCoMKgwqDCoMKgIGV4 YW1wbGUsIGJyZWFraW5nIGEgc2VydmljZSBpbnN0YW5jZSByZXN1bHRpbmcgaW4gc2VydmljZSBp cyBub3QNCj4gwqDCoMKgwqDCoMKgIHByb3Blcmx5IGRlbGl2ZXJlZCB0byBhIGN1c3RvbWVyKSBh bmQgbmV0d29yayByZXNvdXJjZXMgYmUNCj4gwqDCoMKgwqDCoMKgIG1pc2FsbG9jYXRlZC4NCj4g DQo+IFBlcmhhcHMgY2hhbmdlICJhY3R1YWwgc3RhdHVzIiB0byAiYWN0dWFsIG9wZXJhdGlvbmFs IHN0YXR1cyIuDQo+IA0KPiA8QUM+IENoYW5nZWQNCj4gPC9BQz4NCj4gDQo+IEkgYWxzbyBzdWdn ZXN0IGNoYW5naW5nIHRoZSBsYXN0IHNlbnRlbmNlIHRvOg0KPiANCj4gwqDCoMKgIFNlcnZpY2Vz IG1heSBiZSBuZWdhdGl2ZWx5IGFmZmVjdGVkIChlLmcuLCBkZWdyYWRpbmcgb3IgYnJlYWtpbmcg YQ0KPiBjdXN0b21lciBzZXJ2aWNlKSBvciBuZXR3b3JrIHJlc291cmNlcyBtYXkgYmUgbWlzYWxs b2NhdGVkLg0KPiANCj4gPEFDPiBDaGFuZ2VkDQo+IDwvQUM+DQo+IA0KPiANCj4gwqDCoMKgwqDC oMKgwqAgMy4gRGVmaW5pdGlvbnM6DQo+IA0KPiBJdCBzaG91bGQgcHJvYmFibHkgZGVmaW5lIHRo YXQgPGludGVuZGVkPiwgPG9wZXJhdGlvbmFsPiwgKGFuZCBwZXJoYXBzDQo+IDxydW5uaW5nPikg YXJlIHVzZWQgdG8gaW5kaWNhdGUgbmFtZXMgb2YgZGF0YXN0b3Jlcy4NCj4gDQo+IEl0IHNob3Vs ZCBhbHNvIGV4cGxhaW4gdGhhdCA8Y29tcGFyZT4gaXMgdXNlZCBhcyB0aGUgbmFtZSBvZiBhIFlB TkcgUlBDLg0KPiANCj4gPEFDPiBJIGFtIG5vdCBzdXJlIHdlIG5lZWQgdG8gZGVmaW5lIHRoZSBk YXRhc3RvcmVzLCBhcyB0aGV5IGhhdmUNCj4gYWxyZWFkeSBiZWVuIGRlZmluZWQgaW4gUkZDIDgz NDIuwqAgQWxzbywgdGhlIGZhY3QgdGhhdCA8Y29tcGFyZT4gaXMgdXNlZA0KPiBhcyB0aGUgbmFt ZSBvZiB0aGUgWUFORyBSUEMgaXMgZXZpZGVudCBmcm9tIHRoZSBkYXRhIG1vZGVsIGFuZCB3b3Vs ZA0KPiBmZWVsIHJlZHVuZGFudC7CoCBVbmxlc3MgeW91IGZlZWwgc3Ryb25nbHkgaXQgc2hvdWxk IGJlIGFkZGVkLCBJIHdvdWxkDQo+IHByZWZlciB0byBrZWVwIHRoaXMgYXMtaXMuDQo+IDwvQUM+ DQo+IA0KPiDCoMKgwqAgNC7CoCBEYXRhIE1vZGVsIE92ZXJ2aWV3DQo+IA0KPiDCoMKgwqDCoMKg wqAgQXQgdGhlIGNvcmUgb2YgdGhlIHNvbHV0aW9uIGlzIGEgbmV3IG1hbmFnZW1lbnQgb3BlcmF0 aW9uLCA8Y29tcGFyZT4sDQo+IMKgwqDCoMKgwqDCoCB0aGF0IGFsbG93cyB0byBjb21wYXJlIHR3 byBkYXRhc3RvcmVzIGZvciB0aGUgc2FtZSBkYXRhLg0KPiANCj4gU3VnZ2VzdCByZXdvcmRpbmcg dGhpcyBmaXJzdCBzZW50ZW5jZSB0bzoNCj4gDQo+IMKgIFRoZSBjb3JlIG9mIHRoZSBzb2x1dGlv biBpcyBhIG5ldyBtYW5hZ2VtZW50IG9wZXJhdGlvbiwgPGNvbXBhcmU+LA0KPiDCoCB0aGF0IGNv bXBhcmVzIHRoZSBkYXRhIHRyZWUgY29udGVudHMgb2YgdHdvIGRhdGFzdG9yZXMuDQo+IA0KPiA8 QUM+IENoYW5nZWQNCj4gPC9BQz4NCj4gDQo+IMKgwqDCoMKgwqDCoCBvwqAgdGFyZ2V0OiBUaGUg dGFyZ2V0IGlkZW50aWZpZXMgdGhlIGRhdGFzdG9yZSB0byBjb21wYXJlIGFnYWluc3QgdGhlDQo+ IMKgwqDCoMKgwqDCoMKgwqDCoCBzb3VyY2UuDQo+IA0KPiBTdWdnZXN0IGFkZGluZyBhbiBleGFt cGxlICIsIGUuZy4sIDxvcGVyYXRpb25hbD4uIg0KPiANCj4gPEFDPiBDaGFuZ2VkDQo+IDwvQUM+ DQo+IA0KPiDCoMKgwqDCoMKgwqAgb8KgIGZpbHRlci1zcGVjOiBUaGlzIGlzIGEgY2hvaWNlIGJl dHdlZW4gZGlmZmVyZW50IGZpbHRlciBjb25zdHJ1Y3RzDQo+IMKgwqDCoMKgwqDCoMKgwqDCoCB0 byBpZGVudGlmeSB0aGUgcG9ydGlvbnMgb2YgdGhlIGRhdGFzdG9yZSB0byBiZSByZXRyaWV2ZWQu wqAgSXQNCj4gwqDCoMKgwqDCoMKgwqDCoMKgIGFjdHMgYXMgYSBub2RlIHNlbGVjdG9yIHRoYXQg c3BlY2lmaWVzIHdoaWNoIGRhdGEgbm9kZXMgYXJlIHdpdGhpbg0KPiDCoMKgwqDCoMKgwqDCoMKg wqAgdGhlIHNjb3BlIG9mIHRoZSBjb21wYXJpc29uIGFuZCB3aGljaCBub2RlcyBhcmUgb3V0c2lk ZSB0aGUgc2NvcGUuDQo+IMKgwqDCoMKgwqDCoMKgwqDCoCBUaGlzIGFsbG93cyBhIGNvbXBhcmlz b24gb3BlcmF0aW9uIHRvIGJlIGFwcGxpZWQgb25seSB0byBhDQo+IMKgwqDCoMKgwqDCoMKgwqDC oCBzcGVjaWZpYyBwb3J0aW9uIG9mIHRoZSBkYXRhc3RvcmUgdGhhdCBpcyBvZiBpbnRlcmVzdCwg c3VjaCBhcyBhDQo+IMKgwqDCoMKgwqDCoMKgwqDCoCBwYXJ0aWN1bGFyIHN1YnRyZWUuwqAgKFRo ZSBmaWx0ZXIgZG93IG5vdCBjb250YWluIGV4cHJlc3Npb25zIHRoYXQNCj4gwqDCoMKgwqDCoMKg wqDCoMKgIHdvdWxkIG1hdGNoIHZhbHVlcyBkYXRhIG5vZGVzLCBhcyB0aGlzIGlzIG5vdCByZXF1 aXJlZCBieSBtb3N0IHVzZQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqAgY2FzZXMgYW5kIHdvdWxkIGNv bXBsaWNhdGUgdGhlIHNjaGVtZSwgZnJvbSBpbXBsZW1lbnRhdGlvbiB0bw0KPiDCoMKgwqDCoMKg wqDCoMKgwqAgZGVhbGluZyB3aXRoIHJhY2UgY29uZGl0aW9ucy4pDQo+IA0KPiBQZXJoYXBzICJw YXJ0cy9wYXJ0IiByYXRoZXIgdGhhbiAicG9ydGlvbnMvcG9ydGlvbiIuDQo+IA0KPiA8QUM+IENo YW5nZWQNCj4gPC9BQz4NCj4gDQo+IFN1Z2dlc3QgcmV3b3JkaW5nIHRoZSBsYXN0IHNlbnRlbmNl IHRvOg0KPiANCj4gwqDCoMKgIE5vdGUsIHRoZSBmaWx0ZXIgZG9lcyBub3QgYWxsb3cgZXhwcmVz c2lvbnMgdGhhdCBtYXRjaCBhZ2FpbnN0IGRhdGENCj4gbm9kZSB2YWx1ZXMgc2luY2UgdGhhdCBt YXkgaW5jdXIgaW1wbGVtZW50YXRpb24gZGlmZmljdWx0aWVzIGFuZCBpcyBub3QNCj4gcmVxdWly ZWQgZm9yIG5vcm1hbCB1c2UgY2FzZXMuDQo+IA0KPiA8QUM+IENoYW5nZWQNCj4gPC9BQz4NCj4g DQo+IMKgwqDCoMKgwqDCoCBvwqAgLi4uwqAgV2hlbiB0aGUgdGFyZ2V0IGRhdGFzdG9yZSBpcyA8 b3BlcmF0aW9uYWw+LCAib3JpZ2luIg0KPiDCoMKgwqDCoMKgwqDCoMKgwqAgbWV0YWRhdGEgaXMg aW5jbHVkZWQgYXMgcGFydCBvZiB0aGUgcGF0Y2guwqAgSW5jbHVkaW5nIG9yaWdpbg0KPiDCoMKg wqDCoMKgwqDCoMKgwqAgbWV0YWRhdGEgY2FuIGhlbHAgaW4gc29tZSBjYXNlcyBleHBsYWluIHRo ZSBjYXVzZSBvZiBhIGRpZmZlcmVuY2UsDQo+IMKgwqDCoMKgwqDCoMKgwqDCoCBmb3IgZXhhbXBs ZSB3aGVuIGEgZGF0YSBub2RlIGlzIHBhcnQgb2YgPGludGVuZGVkPiBidXQgdGhlIG9yaWdpbg0K PiDCoMKgwqDCoMKgwqDCoMKgwqAgb2YgdGhlIHNhbWUgZGF0YSBub2RlIGluIDxvcGVyYXRpb25h bD4gaXMgcmVwb3J0ZWQgYXMgInN5c3RlbSIuDQo+IA0KPiBJIHRoaW5rIHRoYXQgdGhpcyB0ZXN0 IG5lZWRzIHRvIHJlZmVyIGJhY2sgdG8gdGhlICdleGNsdWRlLW9yaWdpbicgb3INCj4gJ3JlcG9y dC1vcmlnaW4nIG9wdGlvbnMgc2luY2UgdGhlIG9yaWdpbiBtZXRhZGF0YSBpc24ndCBhbHdheXMg aW5jbHVkZWQuDQo+IA0KPiA8QUM+IFllcywgdGhpcyBpcyB1cGRhdGVkLCBwZXIgZWFybGllciBj b21tZW50Lg0KPiA8L0FDPg0KPiANCj4gDQo+IMKgwqDCoCA1LsKgIFlBTkcgRGF0YSBNb2RlbA0K PiANCj4gwqDCoMKgwqDCoMKgwqAgVGhlIGtleSB3b3JkcyAnTVVTVCcsICdNVVNUIE5PVCcsICdS RVFVSVJFRCcsICdTSEFMTCcsICdTSEFMTA0KPiDCoMKgwqDCoMKgwqDCoCBOT1QnLCAnU0hPVUxE JywgJ1NIT1VMRCBOT1QnLCAnUkVDT01NRU5ERUQnLCAnTk9UDQo+IFJFQ09NTUVOREVEJywNCj4g wqDCoMKgwqDCoMKgwqAgJ01BWScsIGFuZCAnT1BUSU9OQUwnIGluIHRoaXMgZG9jdW1lbnQgYXJl IHRvIGJlIGludGVycHJldGVkIGFzDQo+IMKgwqDCoMKgwqDCoMKgIGRlc2NyaWJlZCBpbiBCQ1Ag MTQgKFJGQyAyMTE5KSAoUkZDIDgxNzQpIHdoZW4sIGFuZCBvbmx5IHdoZW4sDQo+IMKgwqDCoMKg wqDCoMKgIHRoZXkgYXBwZWFyIGluIGFsbCBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4NCj4gDQo+ IEkgY291bGRuJ3Qgc2VlIHRoYXQgUkZDIDIxMTkgbGFuZ3VhZ2UgaXMgYWN0dWFsbHkgdXNlZCBp biB0aGUgWUFORw0KPiBtb2R1bGUsIHNvIHBlcmhhcHMgdGhpcyBjYW4gYmUgZGVsZXRlZD8NCj4g DQo+IDxBQz4gSSB0aG91Z2h0IHRoaXMgd2FzIGJvaWxlcnBsYXRlLCBidXQgSSB3aWxsIGJlIGhh cHB5IHRvIGRlbGV0ZSBpdCAtDQo+IHJlbW92ZWQNCj4gPC9BQz4NCj4gDQo+IMKgwqDCoMKgwqDC oMKgwqAgcnBjIGNvbXBhcmUgew0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkZXNjcmlwdGlvbg0K PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIk5NREEgY29tcGFyZSBvcGVyYXRpb24uIjsNCj4g DQo+IFBlcmhhcHMgIk5NREEgZGF0YXN0b3JlIGNvbXBhcmUgb3BlcmF0aW9uLiINCj4gDQo+IDxB Qz4gQ2hhbmdlZA0KPiA8L0FDPg0KPiANCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgYW55ZGF0YSBzb3VyY2UtdmFsdWUgew0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgd2hlbiAiLi4vb3BlcmF0aW9uID0gJ2RlbGV0ZSciDQo+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKyAib3IgLi4vb3BlcmF0aW9uID0gJ21lcmdlJyIN Cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArICJvciAuLi9vcGVy YXRpb24gPSAnbW92ZSciDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgKyAib3IgLi4vb3BlcmF0aW9uID0gJ3JlcGxhY2UnIg0KPiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgICsgIm9yIC4uL29wZXJhdGlvbiA9ICdyZW1vdmUnIjsNCj4g wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGRlc2NyaXB0aW9uDQo+IMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIlRoZSBhbnlkYXRhICd2YWx1ZScg aXMgb25seSB1c2VkIGZvciAnZGVsZXRlJywNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgICdtb3ZlJywgJ21lcmdlJywgJ3JlcGxhY2UnLCBhbmQgJ3JlbW92ZScN Cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG9wZXJhdGlvbnMu IjsNCj4gDQo+IEknbSBub3QgY29udmluY2VkIGhvdyB1c2VmdWwgdGhlIHdoZW4gc3RhdGVtZW50 IHJlYWxseSBpcyBpbiB0aGlzIGNhc2UsDQo+IHNpbmNlICdzb3VyY2UtdmFsdWUnIGlzbid0IG1h cmtlZCBhcyBtYW5kYXRvcnksIGEgc2VydmVyIGlzIGFsbG93ZWQgdG8NCj4gb21pdCBpdCB3aGVu IGl0IGRvZXNuJ3QgYXBwbHkgYW55d2F5Lg0KPiANCj4gPEFDPiBObyBjaGFuZ2UgbWFkZS7CoCBU aGUgcmVhc29uIHdoeSB0aGlzIGlzIHNwZWNpZmllZCBpcyB0aGF0IGluIGNhc2UNCj4gb2YgYSAi Y3JlYXRlIiBvcGVyYXRpb24sIGl0IHdvdWxkIG5vdCBtYWtlIHNlbnNlIHRvIGluY2x1ZGUgYSBz b3VyY2UNCj4gdmFsdWUuwqAgU3VyZSwgdGhpcyBpcyBzdXBwbGllZCBieSB0aGUgc2VydmVyLCBi dXQgc3RpbGwgSSBkbyB0aGluayB0aGVyZQ0KPiBpcyB2YWx1ZSB0byByZXRhaW4gdGhlIHN0YXRl bWVudCAtIHRoZXJlIGlzIGEgY2xpZW50IGFwcGxpY2F0aW9uDQo+IHNvbWV3aGVyZSB0aGF0IHdv dWxkIGJlIHZlcnkgc3VycHJpc2VkIGlmIGEgc2VydmVyIHdlcmUgdG8gcHJvdmlkZSBhDQo+IHNv dXJjZSB2YWx1ZSBoZXJlLi4uDQo+IDwvQUM+DQo+IA0KPiDCoMKgwqAgNi7CoCBFeGFtcGxlDQo+ IA0KPiDCoMKgwqDCoMKgwqAgPG9wZXJhdGlvbmFsPiBkb2VzIG5vdCBjb250YWluIG9iamVjdCAi ZGVzY3JpcHRpb24iIHRoYXQgaXMgY29udGFpbmVkDQo+IMKgwqDCoMKgwqDCoCBpbiA8aW50ZW5k ZWQ+LsKgIEFub3RoZXIgb2JqZWN0LCAiZW5hYmxlZCIsIGhhcyBkaWZmZXJlbmNlcyBpbiB2YWx1 ZXMsDQo+IMKgwqDCoMKgwqDCoCBiZWluZyAidHJ1ZSIgaW4gPG9wZXJhdGlvbmFsPiBhbmQgImZh bHNlIiBpbiA8aW50ZW5kZWQ+LsKgIEEgdGhpcmQNCj4gwqDCoMKgwqDCoMKgIG9iamVjdCwgIm5h bWUiLCBpcyB0aGUgc2FtZSBpbiBib3RoIGNhc2VzLsKgIFRoZSBvcmlnaW4gb2YgdGhlIG9iamVj dHMNCj4gwqDCoMKgwqDCoMKgIGluIDxvcGVyYXRpb25hbD4gaXMgImxlYXJuZWQiLCB3aGljaCBt YXkgaGVscCBleHBsYWluIHRoZQ0KPiDCoMKgwqDCoMKgwqAgZGlzY3JlcGFuY2llcy4NCj4gDQo+ IEkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgcHJvYmFibHkgcmVmcmFpbiBmcm9tIGNhbGxpbmcgdGhl bSBvYmplY3RzLA0KPiBwZXJoYXBzICJsZWFmIGluc3RhbmNlIiB3b3VsZCBiZSBiZXR0ZXI/wqAg UmF0aGVyIHRoYW4gImRpZmZlcmVuY2VzIGluDQo+IHZhbHVlcyIsIHBlcmhhcHMgImRpZmZlcmVu dCB2YWx1ZXMiLg0KPiANCj4gRS5nLiwNCj4gDQo+IMKgwqDCoMKgwqDCoCA8b3BlcmF0aW9uYWw+ IGRvZXMgbm90IGNvbnRhaW4gYW4gaW5zdGFuY2UgZm9yIGxlYWYgImRlc2NyaXB0aW9uIg0KPiB0 aGF0DQo+IMKgwqDCoMKgwqDCoCBpcyBjb250YWluZWQgaW4gPGludGVuZGVkPi7CoCBBbm90aGVy IGxlYWYsICJlbmFibGVkIiwgaGFzIGRpZmZlcmVudA0KPiDCoMKgwqDCoMKgwqAgdmFsdWVzIGlu IHRoZSB0d28gZGF0YXN0b3JlcywgYmVpbmcgInRydWUiIGluIDxvcGVyYXRpb25hbD4gYW5kDQo+ IMKgwqDCoMKgwqDCoCAiZmFsc2UiIGluIDxpbnRlbmRlZD4uwqAgQSB0aGlyZCBsZWFmLCAibmFt ZSIsIGhhcyB0aGUgc2FtZSBpbnN0YW5jZQ0KPiDCoMKgwqDCoMKgwqAgdmFsdWUgaW4gYm90aCBk YXRhc3RvcmVzLsKgIFRoZSBvcmlnaW4gb2YgdGhlIGxlYWYgaW5zdGFuY2VzIGluDQo+IMKgwqDC oMKgwqDCoCA8b3BlcmF0aW9uYWw+IGlzICJsZWFybmVkIiwgd2hpY2ggbWF5IGhlbHAgZXhwbGFp biB0aGUgZGlzY3JlcGFuY2llcy4NCj4gDQo+IDxBQz4gQ2hhbmdlZC7CoCBBbHRob3VnaCBJIHRo aW5rIGl0IHdvdWxkIGJlIGZhaXIgdG8gY2FsbCB0aGVtIG9iamVjdHMNCj4gYWxzbzsgUkZDIDgz NDIgdGFsa3MgYWJvdXQgb2JqZWN0cyB0b28uIDwvQUM+DQo+IA0KPiDCoMKgIC8vT1BFUkFUSU9O QUwNCj4gwqDCoCA8aW50ZXJmYWNlcw0KPiDCoMKgwqDCoMKgwqAgeG1sbnM9InVybjppZXRmOnBh cmFtczp4bWw6bnM6eWFuZzppZXRmLWludGVyZmFjZXMiDQo+IMKgwqDCoMKgwqDCoCB4bWxuczpv cj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtb3JpZ2luIj4NCj4gwqDCoMKgwqAg PGludGVyZmFjZSBvcjpvcmlnaW49Im9yOmxlYXJuZWQiPg0KPiDCoMKgwqDCoMKgwqAgPG5hbWU+ ZXRoMDwvbmFtZT4NCj4gwqDCoMKgwqDCoMKgIDxlbmFibGVkPnRydWU8L2VuYWJsZWQ+DQo+IA0K PiDCoMKgwqDCoMKgwqAgPC9pbnRlcmZhY2U+DQo+IMKgwqAgPC9pbnRlcmZhY2VzPg0KPiANCj4g VGhlcmUgaXMgYW4gZXh0cmEgbGluZSwgYW5kIGRvZGd5IGluZGVudGF0aW9uIGZvciAiPC9pbnRl cmZhY2U+Ii4NCj4gDQo+IDxBQz4gQ2hhbmdlZCwgZm9ybWF0dGVkIG5vdyBhcyBmb2xsb3dzOg0K PiAvL09QRVJBVElPTkFMDQo+IDxpbnRlcmZhY2VzDQo+IMKgwqDCoCB4bWxucz0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtaW50ZXJmYWNlcyINCj4gwqDCoMKgIHhtbG5zOm9yPSJ1 cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1vcmlnaW4iPg0KPiDCoCA8aW50ZXJmYWNl IG9yOm9yaWdpbj0ib3I6bGVhcm5lZCI+DQo+IMKgwqDCoCA8bmFtZT5ldGgwPC9uYW1lPg0KPiDC oMKgwqAgPGVuYWJsZWQ+dHJ1ZTwvZW5hYmxlZD4NCj4gwqAgPC9pbnRlcmZhY2U+DQo+IDwvaW50 ZXJmYWNlcz4NCj4gPC9BQz4NCj4gDQo+IE5pdHM6DQo+IA0KPiAicG9zc2libHkgZm9yIiA9PiAi cG9zc2libGUgZm9yIg0KPiAicmVmZXJlbmNlIGZvciB0aGUiID0+ICJ0aGUgcmVmZXJlbmNlIGRh dGEgdHJlZSBmb3IgdGhlIg0KPiAiaXMgYmFzaXMiID0+ICJpcyB0aGUgYmFzaXMiDQo+IA0KPiA8 QUM+IENoYW5nZWQsIGV4Y2VwdCAiYXMgcmVmZXJlbmNlIGZvciB0aGUiID0+ICJhcyB0aGUgcmVm ZXJlbmNlIGZvcg0KPiB0aGUiIChJIHRoaW5rIGRhdGEgdHJlZSB3b3VsZCBzb3VuZCBhIGJpdCBv ZGQgaW4gdGhlIGNvbnRleHQ7IGFsc28NCj4gZGF0YXN0b3JlIHdvdWxkIHBlcmhhcHMgYmUgbW9y ZSBhcHByb3ByaWF0ZSB0aGFuIGRhdGEgdHJlZSBoZXJlKS4NCj4gPC9BQz4NCj4gDQo+IA0KPiBU aGFua3MsDQo+IFJvYg0KDQo= From nobody Thu Jun 17 07:51: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 22FDD3A232E; Thu, 17 Jun 2021 07:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 W499Ztznx8YQ; Thu, 17 Jun 2021 07:51:05 -0700 (PDT) Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com [194.138.20.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB39E3A2314; Thu, 17 Jun 2021 07:51:04 -0700 (PDT) Received: from mail2.dc4ca.siemens.de (mail2.dc4ca.siemens.de [139.25.224.94]) by gw-eagle2.siemens.com (Postfix) with ESMTPS id 3C0934682AE; Thu, 17 Jun 2021 16:50:58 +0200 (CEST) Received: from DEMCHDC89ZA.ad011.siemens.net (demchdc89za.ad011.siemens.net [139.25.226.105]) by mail2.dc4ca.siemens.de (Postfix) with ESMTPS id 360E11951F727; Thu, 17 Jun 2021 16:50:58 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC89ZA.ad011.siemens.net (139.25.226.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 17 Jun 2021 16:50:57 +0200 Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2176.014; Thu, 17 Jun 2021 16:50:57 +0200 From: "Fries, Steffen" To: Kent Watsen CC: "anima@ietf.org" , "netmod@ietf.org" , "Werner, Thomas" Thread-Topic: Reuse of SZTP-CSR YANG definition in BRSKI-AE Thread-Index: AddjiC0D00j6GcKVSy+dSa8jk3TUtA== Date: Thu, 17 Jun 2021 14:50:57 +0000 Message-ID: <3a31e33678484625b9f4f3810e673e56@siemens.com> Accept-Language: en-US, de-DE 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-06-17T14:50:56Z; 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=33a5de5c-fd73-4a34-8009-87e02f4a84e1; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [144.145.220.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] Reuse of SZTP-CSR YANG definition in BRSKI-AE 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, 17 Jun 2021 14:51:19 -0000 Hi Kent,=20 There is a further YANG related question in the context of BRSKI-AE.=20 In one use case, the pledge has no direct connection to the registrar and a= registrar-agent communicates with the pledge. In that specific case we do = not have a TLS connection between the pledge and the registrar-agent and pr= otect the exchanged objects by an additional signature. This is done by emb= edding the necessary information into a JOSE object.=20 For the enrollment Michael was pointing to the YANG module in https://datat= racker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr to avoid a double defi= nition to transport a certification request. In BRSKI-AE we currently use a= PKCS#10 request, but using the defined ietf-sztp-csr would also allow to u= se other formats.=20 For the enrollment request created by the pledge we have defined the follow= ing JOSE object: { "alg": "ES256", "x5c": ["MIIB2jCC...dA=3D=3D"] } { "ietf-sztp-csr:csr": { "p10": "base64encodedvalue=3D=3D" } } { SIGNATURE } The question (https://github.com/anima-wg/anima-brski-async-enroll/issues/1= 0) now is, if this construct is possible, as we are just using a subset (sz= tp-csr:csr) of the YANG module " ietf-sztp-bootstrap-server" from draft-ie= tf-netconf-sztp-csr? The alternative would be to define an own module model= ed in a similar.=20 Best regards Steffen From nobody Thu Jun 17 08:05: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 49B303A2382; Thu, 17 Jun 2021 08:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt3ZhyG5u6kg; Thu, 17 Jun 2021 08:05:40 -0700 (PDT) Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com [194.138.20.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4657B3A237F; Thu, 17 Jun 2021 08:05:40 -0700 (PDT) Received: from mail3.dc4ca.siemens.de (mail3.dc4ca.siemens.de [139.23.14.198]) by gw-eagle2.siemens.com (Postfix) with ESMTPS id 26BF44682A3; Thu, 17 Jun 2021 17:05:35 +0200 (CEST) Received: from DEMCHDC8A2A.ad011.siemens.net (demchdc8a2a.ad011.siemens.net [139.25.226.108]) by mail3.dc4ca.siemens.de (Postfix) with ESMTPS id BCF6E27D840B; Thu, 17 Jun 2021 17:05:32 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC8A2A.ad011.siemens.net (139.25.226.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 17 Jun 2021 17:05:32 +0200 Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2176.014; Thu, 17 Jun 2021 17:05:32 +0200 From: "Fries, Steffen" To: Andy Bierman , Kent Watsen CC: Michael Richardson , "netmod@ietf.org" , "anima@ietf.org" , "Werner, Thomas" Thread-Topic: [Anima] [netmod] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) Thread-Index: AQHXYwO5qG4OVLZ5lUaNPr0y7qLU/qsYOWZg Date: Thu, 17 Jun 2021 15:05:32 +0000 Message-ID: References: <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US, de-DE 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-06-17T15:05:31Z; 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=05cb58e2-da39-44d6-8af1-91da9f905c38; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [144.145.220.66] Content-Type: multipart/alternative; boundary="_000_c8c4ea615bb2450c9a1a9fccb956909fsiemenscom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 17 Jun 2021 15:05:45 -0000 --_000_c8c4ea615bb2450c9a1a9fccb956909fsiemenscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmsgeW91IGZvciBwb2ludGluZyBvdXQgdGhhdCBpdCB3aWxsIG5vdCBi ZSBwb3NzaWJsZSB0byBoYXZlIGEgc3RyYWlnaHQgZm9yd2FyZCBlbmhhbmNlbWVudCBvZiB0aGUg ZW51bS4NCkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyB0byB0aGUgcG9pbnRzIHlvdSByYWlzZWQ6DQoN Cj5Gcm9tOiBBbmltYSBhbmltYS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphbmltYS1ib3VuY2Vz QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQo+QW4gZW51bWVyYXRpb24gdHlw ZSBpcyBoYXJkLXdpcmVkLg0KSGFyZHdpcmVkIGluIHRlcm1zIG9mIGEgZml4ZWQgZGVmaW5pdGlv biBvZiB2YWx1ZXMgZm9yIHRoZSBlbnVtIGluIFJGQyA4MzY2Pw0KDQo+Tm8gZW51bXMgY2FuIGJl IGFkZGVkIHZpYSBhdWdtZW50YXRpb24uDQpUaGF0IG1lYW5zIGp1c3QgdGhlIGRlZmluaXRpb24g b2YgYW4gYWRkaXRpb25hbCBlbnVtIHZhbHVlIGlzIG5vdCBlbm91Z2guDQoNCj5Zb3UgaGF2ZSB0 byAiZGV2aWF0ZSByZXBsYWNlIiB0aGUgdHlwZS1zdG10IHRvIGFkZCBhbiBlbnVtIGV4dGVybmFs bHksDQpBcyBJ4oCZbSBub3QgdG9vIGRlZXAgaW4gWUFORywgY291bGQgeW91IHByb3ZpZGUgbW9y ZSBpbmZvcm1hdGlvbiBvbiB0aGlzIHBhcnQ/ICBXb3VsZCB0aGlzIGJlIGFuIGFwcHJvYWNoIHRv IChqdXN0KSByZWRlZmluZSB0aGUgdHlwZSBlbnVtZXJhdGlvbiBpbiB0aGUgbGVhZiDigJxhc3Nl cnRpb27igJ0gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODM2NiNw YWdlLTExKSBhbmQgYWRkaW5nIHRoZSBuZXcgYXNzZXJ0aW9uIHR5cGUg4oCcYWdlbnQtcHJveGlt aXR54oCdPyBXb3VsZCB0aGlzIHJlcXVpcmUgdG8ga2VlcCBhbGwgZW51bXMgYWxyZWFkeSBkZWZp bmVkIGluIFJGQyA4MzY2IG9yIGNvdWxkIHdlIGp1c3QgdXNlIHRoZSBvbmVzIG5lY2Vzc2FyeSBp biBCUlNLSS1BRT8NCg0KPm9yIHlvdSBoYXZlIHRvIHVwZGF0ZSB0aGUgbW9kdWxlIGFuZCBhZGQg dGhlIGVudW0gaW5saW5lLg0KRG9lcyB0aGlzIHJlc3VsdCBpbiBhbiB1cGRhdGUgb2YgdGhlIG1v ZHVsZSDigJxpZXRmLXZvdWNoZXLigJ0gb3IgdG8gZGVmaW5lIGEgbmV3IG1vZHVsZSwgd2hpY2gg aW1wb3J0cyBhbmQgYXVnbWVudHMgdGhlIHZvdWNoZXIgYnkgYWRkaW5nIHRoZSBuZXcgZW51bT8N Cg0KQmVzdCByZWdhcmRzDQpTdGVmZmVuDQo= --_000_c8c4ea615bb2450c9a1a9fccb956909fsiemenscom_ 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 OnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFuZHksPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3IgcG9pbnRpbmcgb3V0IHRoYXQgaXQgd2lsbCBu b3QgYmUgcG9zc2libGUgdG8gaGF2ZSBhIHN0cmFpZ2h0IGZvcndhcmQgZW5oYW5jZW1lbnQgb2Yg dGhlIGVudW0uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBz b21lIHF1ZXN0aW9ucyB0byB0aGUgcG9pbnRzIHlvdSByYWlzZWQ6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPiZndDtGcm9tOjwvYj4gQW5pbWEgPGEgaHJlZj0ibWFpbHRvOmFuaW1hLWJvdW5j ZXNAaWV0Zi5vcmciPg0KYW5pbWEtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGI+T24gQmVoYWxmIE9m IDwvYj5BbmR5IEJpZXJtYW48YnI+DQomZ3Q7QW4gZW51bWVyYXRpb24gdHlwZSBpcyBoYXJkLXdp cmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFyZHdpcmVkIGluIHRl cm1zIG9mIGEgZml4ZWQgZGVmaW5pdGlvbiBvZiB2YWx1ZXMgZm9yIHRoZSBlbnVtIGluIFJGQyA4 MzY2Pw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtObyBlbnVtcyBjYW4gYmUgYWRkZWQg dmlhIGF1Z21lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YXQgbWVhbnMganVzdCB0aGUgZGVmaW5pdGlvbiBvZiBhbiBhZGRpdGlvbmFsIGVudW0gdmFsdWUg aXMgbm90IGVub3VnaC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtZb3UgaGF2 ZSB0byAmcXVvdDtkZXZpYXRlIHJlcGxhY2UmcXVvdDsgdGhlIHR5cGUtc3RtdCB0byBhZGQgYW4g ZW51bSBleHRlcm5hbGx5LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg SeKAmW0gbm90IHRvbyBkZWVwIGluIFlBTkcsIGNvdWxkIHlvdSBwcm92aWRlIG1vcmUgaW5mb3Jt YXRpb24gb24gdGhpcyBwYXJ0PyAmbmJzcDtXb3VsZCB0aGlzIGJlIGFuIGFwcHJvYWNoIHRvIChq dXN0KSByZWRlZmluZSB0aGUgdHlwZSBlbnVtZXJhdGlvbiBpbiB0aGUgbGVhZiDigJxhc3NlcnRp b27igJ0gKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZj ODM2NiNwYWdlLTExIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzgz NjYjcGFnZS0xMTwvYT4pDQogYW5kIGFkZGluZyB0aGUgbmV3IGFzc2VydGlvbiB0eXBlIOKAnGFn ZW50LXByb3hpbWl0eeKAnT8gV291bGQgdGhpcyByZXF1aXJlIHRvIGtlZXAgYWxsIGVudW1zIGFs cmVhZHkgZGVmaW5lZCBpbiBSRkMgODM2NiBvciBjb3VsZCB3ZSBqdXN0IHVzZSB0aGUgb25lcyBu ZWNlc3NhcnkgaW4gQlJTS0ktQUU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtvciB5b3Ug aGF2ZSB0byB1cGRhdGUgdGhlIG1vZHVsZSBhbmQgYWRkIHRoZSBlbnVtIGlubGluZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgdGhpcyByZXN1bHQgaW4gYW4gdXBk YXRlIG9mIHRoZSBtb2R1bGUg4oCcaWV0Zi12b3VjaGVy4oCdIG9yIHRvIGRlZmluZSBhIG5ldyBt b2R1bGUsIHdoaWNoIGltcG9ydHMgYW5kIGF1Z21lbnRzIHRoZSB2b3VjaGVyIGJ5IGFkZGluZyB0 aGUgbmV3IGVudW0/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3RlZmZlbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_c8c4ea615bb2450c9a1a9fccb956909fsiemenscom_-- From nobody Thu Jun 17 08: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 123803A237A for ; Thu, 17 Jun 2021 08:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jhpyzyA41Dc for ; Thu, 17 Jun 2021 08:19:04 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DF83A23F5 for ; Thu, 17 Jun 2021 08:19:04 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id q20so11173509lfo.2 for ; Thu, 17 Jun 2021 08:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l2jIQKSxt3sN5uz6aNPP1d0m5AtsKLwMKWD88sWPli0=; b=W2c/BqjyuHXgEf7va2ucJI7FxbDpN3Y2aU1pO3lu6je8PZlyGmmy81TApOTPmuBtcl F1BWS/ExG93p7gJfzFIG1PFmE7OzNcmixjeoYcem7+qNOFJyvpJqyDchMDpGWiTq6Qzg X5oxgN7KnYK8qu1Mc/T+5jjupMeWbhwivIMHgk5N7IACdeHc9dvH7Jm2FCbYtahJ9OO/ 00MVGchDdHHbs6kaCPlkFX/Zsv0VFDOeC22kWx7QYY9Tvbl+7aOipsNkJYSHd9P33v4M RlNOTQb5n4PamaZeCxyq+LfeSYNoI6QgYt9/kIMNncfBqnk/ZFBrdd69PTG5Khe1wAq1 EIKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l2jIQKSxt3sN5uz6aNPP1d0m5AtsKLwMKWD88sWPli0=; b=kFYeo3KhYXJoCwNUGygzCPb8TnXCI2ItYtZh07mSJpJGsYoglQU385Z7nsBnG7lRO8 4BSstolRiFafJLLQY0RvUFnto3dwkijiNjYSK/MrDyuBm1nHqT/8jYF6B8EiMNQwP0vN /on6Je1wwjHIdZvfW4CXGY+0d/a1A2gux560iXXleyf5Wy8wbiP0Qm8k6Vlb7MqE4V20 EUvwkNZZ6pZGG7Mz6LcxL8Bi7Kx+CYXIb8sqno2tb3dhIpQZspNeK8b7MiepzPVVZ7x5 3p0+2Yowu7Pkfpr/2Uv0j4Jr/F2ltRkfTQJHP3YSD4IDQbvFk22RimUuMSXXYZxpfKLH VQ1Q== X-Gm-Message-State: AOAM532YqZIW5o0Zvqem2vB7B089XEv09k2/kE2BIBxlWwp8P83n1H26 1NlIQY6HJy/JjSx365KWjNvrlO5emxFLa3S4gCgEzQ== X-Google-Smtp-Source: ABdhPJwYxanHpJIe3/KwQ5YxMO2SAGQqOD6ajRZ8RVaco2ThaUYhx6KijOLZ9lGMha4hELQ/lQvVQ8VUnpAyeIGbvB0= X-Received: by 2002:ac2:5310:: with SMTP id c16mr4350177lfh.512.1623943141860; Thu, 17 Jun 2021 08:19:01 -0700 (PDT) MIME-Version: 1.0 References: <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> In-Reply-To: From: Andy Bierman Date: Thu, 17 Jun 2021 08:18:51 -0700 Message-ID: To: "Fries, Steffen" Cc: Kent Watsen , Michael Richardson , "netmod@ietf.org" , "anima@ietf.org" , "Werner, Thomas" Content-Type: multipart/alternative; boundary="0000000000001b3ae505c4f7ba6e" Archived-At: Subject: Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 17 Jun 2021 15:19:09 -0000 --0000000000001b3ae505c4f7ba6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 17, 2021 at 8:05 AM Fries, Steffen wrote: > Hi Andy, > > > > Thank you for pointing out that it will not be possible to have a straigh= t > forward enhancement of the enum. > > I have some questions to the points you raised: > > > I am not really following this specific issue. I was just pointing out that YANG enumeration types cannot be augmented. It is the wrong terminology, since only schema nodes can be augmented. > *>From:* Anima anima-bounces@ietf.org *On Behalf Of *Andy Bierman > >An enumeration type is hard-wired. > > Hardwired in terms of a fixed definition of values for the enum in RFC > 8366? > > > > >No enums can be added via augmentation. > > That means just the definition of an additional enum value is not enough. > > > > >You have to "deviate replace" the type-stmt to add an enum externally, > > As I=E2=80=99m not too deep in YANG, could you provide more information o= n this > part? Would this be an approach to (just) redefine the type enumeration = in > the leaf =E2=80=9Cassertion=E2=80=9D ( > https://datatracker.ietf.org/doc/html/rfc8366#page-11) and adding the new > assertion type =E2=80=9Cagent-proximity=E2=80=9D? Would this require to k= eep all enums > already defined in RFC 8366 or could we just use the ones necessary in > BRSKI-AE? > > > https://datatracker.ietf.org/doc/html/rfc7950#section-7.20.3 > >or you have to update the module and add the enum inline. > > Does this result in an update of the module =E2=80=9Cietf-voucher=E2=80= =9D or to define a > new module, which imports and augments the voucher by adding the new enum= ? > > > > Best regards > > Steffen > Andy --0000000000001b3ae505c4f7ba6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 17, 2021 at 8:05 AM Fries= , Steffen <steffen.fries@si= emens.com> wrote:

Hi Andy,

=C2=A0

Thank you for pointing out that it will not be possi= ble to have a straight forward enhancement of the enum.

I have some questions to the points you raised:

=C2=A0


<= /div>
I am not really following this specific issue.
I was ju= st pointing out that YANG enumeration types cannot be augmented.
= It is the wrong terminology, since only schema nodes can be augmented.


=C2=A0

>From: Anima anima-bounces@ietf.org On Behalf Of Andy Bierman
>An enumeration type is hard-wired.

Hardwired in terms of a fixed definition of values f= or the enum in RFC 8366?

=C2=A0

>No enums can be added via augmentation.

That means just the definition of an additional enum= value is not enough. =C2=A0

=C2=A0

>You have to "deviate replace" the type= -stmt to add an enum externally,

As I=E2=80=99m not too deep in YANG, could you provi= de more information on this part?=C2=A0 Would this be an approach to (just)= redefine the type enumeration in the leaf =E2=80=9Cassertion=E2=80=9D (https://datatracker.ietf.org/doc/html/rfc8366#page-11) and adding the new assertion type =E2=80=9Cagent-proximity=E2=80=9D? Would= this require to keep all enums already defined in RFC 8366 or could we jus= t use the ones necessary in BRSKI-AE?

=C2=A0


<= /div>
https://datatracker.ietf.org/doc/html/rfc7950#section-7.20.3

=C2=A0

<= /u>

>or you have to update the module and add the enu= m inline.

Does this result in an update of the module =E2=80= =9Cietf-voucher=E2=80=9D or to define a new module, which imports and augme= nts the voucher by adding the new enum?

=C2=A0

Best regards

Steffen


<= div>
Andy
=C2=A0
--0000000000001b3ae505c4f7ba6e-- From nobody Thu Jun 17 09:13:06 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6AF3A2560; Thu, 17 Jun 2021 09:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 4NdDt114E7ZP; Thu, 17 Jun 2021 09:12:55 -0700 (PDT) Received: from gw-eagle1.siemens.com (gw-eagle1.siemens.com [194.138.20.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FAE3A257F; Thu, 17 Jun 2021 09:12:54 -0700 (PDT) Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle1.siemens.com (Postfix) with ESMTPS id 43F0F4F0339; Thu, 17 Jun 2021 18:12:49 +0200 (CEST) Received: from DEMCHDC8A1A.ad011.siemens.net (sop-solman.siemens.com [139.25.226.107]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id B7C7D1A280189; Thu, 17 Jun 2021 18:12:49 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 17 Jun 2021 18:12:49 +0200 Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2176.014; Thu, 17 Jun 2021 18:12:49 +0200 From: "Fries, Steffen" To: Andy Bierman CC: Kent Watsen , Michael Richardson , "netmod@ietf.org" , "anima@ietf.org" , "Werner, Thomas" Thread-Topic: [Anima] [netmod] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) Thread-Index: AQHXYwO5qG4OVLZ5lUaNPr0y7qLU/qsYOWZg///3M4CAACzS4A== Date: Thu, 17 Jun 2021 16:12:49 +0000 Message-ID: <06674cb9709f4bd6bc2af297b929163f@siemens.com> References: <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US, de-DE 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-06-17T16:12:48Z; 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=13e8d305-8e2d-4b70-ad16-2e3a6fdcef52; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [144.145.220.66] Content-Type: multipart/alternative; boundary="_000_06674cb9709f4bd6bc2af297b929163fsiemenscom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 17 Jun 2021 16:12:59 -0000 --_000_06674cb9709f4bd6bc2af297b929163fsiemenscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmtzIGZvciB0aGUgcmVmZXJlbmNlLiBJIGhhdmUgdG8gZGl2ZSBpbnRv IHRoYXQgYSBsaXR0bGUgZGVlcGVyLiBCYXNlZCBvbiB5b3VyIHByZXZpb3VzIGNvbW1lbnQsIGl0 IHdvdWxkIGJlIHBvc3NpYmxlIHRvIHVzZSB0aGUg4oCcZGV2aWF0ZSByZXBsYWNl4oCdIHRvIGFu ZCByZXBsYWNlIHRoZSBleGlzdGluZyBlbnVtIGluIHRoZSB2b3VjaGVyIGRlZmluaXRpb24gYnkg YW4gZW5oYW5jZWQgZW51bSBkZWZpbml0aW9uIGluIG91ciBkb2N1bWVudC4gSWYgSSB1bmRlcnN0 b29kIHRoaXMgcmlnaHQsIGl0IGlzIHByb2JhYmx5IHRoZSBlYXNpZXN0IHdheS4NCg0KQmVzdCBy ZWdhcmRzDQpTdGVmZmVuDQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29t Pg0KU2VudDogRG9ubmVyc3RhZywgMTcuIEp1bmkgMjAyMSAxNzoxOQ0KDQoNCkkgYW0gbm90IHJl YWxseSBmb2xsb3dpbmcgdGhpcyBzcGVjaWZpYyBpc3N1ZS4NCkkgd2FzIGp1c3QgcG9pbnRpbmcg b3V0IHRoYXQgWUFORyBlbnVtZXJhdGlvbiB0eXBlcyBjYW5ub3QgYmUgYXVnbWVudGVkLg0KSXQg aXMgdGhlIHdyb25nIHRlcm1pbm9sb2d5LCBzaW5jZSBvbmx5IHNjaGVtYSBub2RlcyBjYW4gYmUg YXVnbWVudGVkLg0KDQo+RnJvbTogQW5pbWEgYW5pbWEtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 YW5pbWEtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KPkFuIGVu dW1lcmF0aW9uIHR5cGUgaXMgaGFyZC13aXJlZC4NCkhhcmR3aXJlZCBpbiB0ZXJtcyBvZiBhIGZp eGVkIGRlZmluaXRpb24gb2YgdmFsdWVzIGZvciB0aGUgZW51bSBpbiBSRkMgODM2Nj8NCg0KPk5v IGVudW1zIGNhbiBiZSBhZGRlZCB2aWEgYXVnbWVudGF0aW9uLg0KVGhhdCBtZWFucyBqdXN0IHRo ZSBkZWZpbml0aW9uIG9mIGFuIGFkZGl0aW9uYWwgZW51bSB2YWx1ZSBpcyBub3QgZW5vdWdoLg0K DQo+WW91IGhhdmUgdG8gImRldmlhdGUgcmVwbGFjZSIgdGhlIHR5cGUtc3RtdCB0byBhZGQgYW4g ZW51bSBleHRlcm5hbGx5LA0KQXMgSeKAmW0gbm90IHRvbyBkZWVwIGluIFlBTkcsIGNvdWxkIHlv dSBwcm92aWRlIG1vcmUgaW5mb3JtYXRpb24gb24gdGhpcyBwYXJ0PyAgV291bGQgdGhpcyBiZSBh biBhcHByb2FjaCB0byAoanVzdCkgcmVkZWZpbmUgdGhlIHR5cGUgZW51bWVyYXRpb24gaW4gdGhl IGxlYWYg4oCcYXNzZXJ0aW9u4oCdIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL3JmYzgzNjYjcGFnZS0xMTxodHRwczovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUy Rmh0bWwlMkZyZmM4MzY2JTIzcGFnZS0xMSZkYXRhPTA0JTdDMDElN0NjZWY5NzYzYy0xNDljLTQ4 ODEtYjljMi01ZmVkYzI3NzY2M2ElNDBhZDAxMS5zaWVtZW5zLmNvbSU3Q2NjZGI2ZGE1MjRkMjQ5 NDcxMDVkMDhkOTMxYTMzZDY2JTdDMzhhZTNiY2Q5NTc5NGZkNGFkZGFiNDJlMTQ5NWQ1NWElN0Mx JTdDMCU3QzYzNzU5NTM5OTQ0MjkzMDcwMSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpv aU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAl M0QlN0MxMDAwJnNkYXRhPThWUnFBbmhYNlVnN0pmVVlKWWk2VlBEbXduWGNGZzNvYTFCOUdjTURm N2clM0QmcmVzZXJ2ZWQ9MD4pIGFuZCBhZGRpbmcgdGhlIG5ldyBhc3NlcnRpb24gdHlwZSDigJxh Z2VudC1wcm94aW1pdHnigJ0/IFdvdWxkIHRoaXMgcmVxdWlyZSB0byBrZWVwIGFsbCBlbnVtcyBh bHJlYWR5IGRlZmluZWQgaW4gUkZDIDgzNjYgb3IgY291bGQgd2UganVzdCB1c2UgdGhlIG9uZXMg bmVjZXNzYXJ5IGluIEJSU0tJLUFFPw0KDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTcuMjAuMzxodHRwczovL2V1cjAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRm Lm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM3OTUwJTIzc2VjdGlvbi03LjIwLjMmZGF0YT0wNCU3QzAx JTdDY2VmOTc2M2MtMTQ5Yy00ODgxLWI5YzItNWZlZGMyNzc2NjNhJTQwYWQwMTEuc2llbWVucy5j b20lN0NjY2RiNmRhNTI0ZDI0OTQ3MTA1ZDA4ZDkzMWEzM2Q2NiU3QzM4YWUzYmNkOTU3OTRmZDRh ZGRhYjQyZTE0OTVkNTVhJTdDMSU3QzAlN0M2Mzc1OTUzOTk0NDI5MzA3MDElN0NVbmtub3duJTdD VFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJ azFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZzZGF0YT1leXRxN1ZmJTJCWGdjRUlhOFRmc0Fv em1KOXNLSU5ONmElMkZIZ2RMckt2Sk5YOCUzRCZyZXNlcnZlZD0wPg0KDQoNCj5vciB5b3UgaGF2 ZSB0byB1cGRhdGUgdGhlIG1vZHVsZSBhbmQgYWRkIHRoZSBlbnVtIGlubGluZS4NCkRvZXMgdGhp cyByZXN1bHQgaW4gYW4gdXBkYXRlIG9mIHRoZSBtb2R1bGUg4oCcaWV0Zi12b3VjaGVy4oCdIG9y IHRvIGRlZmluZSBhIG5ldyBtb2R1bGUsIHdoaWNoIGltcG9ydHMgYW5kIGF1Z21lbnRzIHRoZSB2 b3VjaGVyIGJ5IGFkZGluZyB0aGUgbmV3IGVudW0/DQoNCkJlc3QgcmVnYXJkcw0KU3RlZmZlbg0K DQoNCkFuZHkNCg0K --_000_06674cb9709f4bd6bc2af297b929163fsiemenscom_ 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 OnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFuZHksIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MgZm9yIHRoZSByZWZlcmVuY2UuIEkgaGF2ZSB0byBkaXZlIGludG8gdGhhdCBhIGxpdHRsZSBk ZWVwZXIuIEJhc2VkIG9uIHlvdXIgcHJldmlvdXMgY29tbWVudCwgaXQgd291bGQgYmUgcG9zc2li bGUgdG8gdXNlIHRoZSDigJxkZXZpYXRlIHJlcGxhY2XigJ0gdG8gYW5kIHJlcGxhY2UgdGhlIGV4 aXN0aW5nIGVudW0gaW4gdGhlIHZvdWNoZXIgZGVmaW5pdGlvbiBieSBhbiBlbmhhbmNlZCBlbnVt IGRlZmluaXRpb24NCiBpbiBvdXIgZG9jdW1lbnQuIElmIEkgdW5kZXJzdG9vZCB0aGlzIHJpZ2h0 LCBpdCBpcyBwcm9iYWJseSB0aGUgZWFzaWVzdCB3YXkuIDxvOnA+DQo8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Rl ZmZlbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 NC44cHQiPjxiPkZyb206PC9iPiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZn dDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBEb25uZXJzdGFnLCAxNy4gSnVuaSAyMDIxIDE3OjE5PGJy Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgcmVhbGx5IGZvbGxvd2luZyB0 aGlzIHNwZWNpZmljIGlzc3VlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3YXMganVzdCBwb2ludGluZyBvdXQgdGhhdCBZQU5HIGVudW1lcmF0 aW9uIHR5cGVzIGNhbm5vdCBiZSBhdWdtZW50ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyB0aGUgd3JvbmcgdGVybWlub2xvZ3ksIHNp bmNlIG9ubHkgc2NoZW1hIG5vZGVzIGNhbiBiZSBhdWdtZW50ZWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj4mZ3Q7RnJvbTo8L2I+IEFuaW1hDQo8YSBocmVmPSJtYWlsdG86YW5pbWEtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc8L2E+DQo8Yj5P biBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCiZndDtBbiBlbnVtZXJhdGlvbiB0eXBl IGlzIGhhcmQtd2lyZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhh cmR3aXJlZCBpbiB0ZXJtcyBvZiBhIGZpeGVkIGRlZmluaXRpb24gb2YgdmFsdWVzIGZvciB0aGUg ZW51bSBpbiBSRkMgODM2Nj8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0O05vIGVu dW1zIGNhbiBiZSBhZGRlZCB2aWEgYXVnbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaGF0IG1lYW5zIGp1c3QgdGhlIGRlZmluaXRpb24gb2YgYW4gYWRk aXRpb25hbCBlbnVtIHZhbHVlIGlzIG5vdCBlbm91Z2guICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jmd0O1lvdSBoYXZlIHRvICZxdW90O2RldmlhdGUgcmVwbGFjZSZxdW90OyB0 aGUgdHlwZS1zdG10IHRvIGFkZCBhbiBlbnVtIGV4dGVybmFsbHksPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIEnigJltIG5vdCB0b28gZGVlcCBpbiBZQU5HLCBjb3Vs ZCB5b3UgcHJvdmlkZSBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgcGFydD8mbmJzcDsgV291bGQg dGhpcyBiZSBhbiBhcHByb2FjaCB0byAoanVzdCkgcmVkZWZpbmUgdGhlIHR5cGUgZW51bWVyYXRp b24gaW4gdGhlIGxlYWYg4oCcYXNzZXJ0aW9u4oCdICg8YSBocmVmPSJodHRwczovL2V1cjAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4MzY2JTIzcGFnZS0xMSZhbXA7ZGF0YT0w NCU3QzAxJTdDY2VmOTc2M2MtMTQ5Yy00ODgxLWI5YzItNWZlZGMyNzc2NjNhJTQwYWQwMTEuc2ll bWVucy5jb20lN0NjY2RiNmRhNTI0ZDI0OTQ3MTA1ZDA4ZDkzMWEzM2Q2NiU3QzM4YWUzYmNkOTU3 OTRmZDRhZGRhYjQyZTE0OTVkNTVhJTdDMSU3QzAlN0M2Mzc1OTUzOTk0NDI5MzA3MDElN0NVbmtu b3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENK QlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9OFZScUFuaFg2VWc3 SmZVWUpZaTZWUERtd25YY0ZnM29hMUI5R2NNRGY3ZyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODM2NiNw YWdlLTExPC9hPikNCiBhbmQgYWRkaW5nIHRoZSBuZXcgYXNzZXJ0aW9uIHR5cGUg4oCcYWdlbnQt cHJveGltaXR54oCdPyBXb3VsZCB0aGlzIHJlcXVpcmUgdG8ga2VlcCBhbGwgZW51bXMgYWxyZWFk eSBkZWZpbmVkIGluIFJGQyA4MzY2IG9yIGNvdWxkIHdlIGp1c3QgdXNlIHRoZSBvbmVzIG5lY2Vz c2FyeSBpbiBCUlNLSS1BRT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9ldXIwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIu aWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGcmZjNzk1MCUyM3NlY3Rpb24tNy4yMC4zJmFtcDtkYXRh PTA0JTdDMDElN0NjZWY5NzYzYy0xNDljLTQ4ODEtYjljMi01ZmVkYzI3NzY2M2ElNDBhZDAxMS5z aWVtZW5zLmNvbSU3Q2NjZGI2ZGE1MjRkMjQ5NDcxMDVkMDhkOTMxYTMzZDY2JTdDMzhhZTNiY2Q5 NTc5NGZkNGFkZGFiNDJlMTQ5NWQ1NWElN0MxJTdDMCU3QzYzNzU5NTM5OTQ0MjkzMDcwMSU3Q1Vu a25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlM Q0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1leXRxN1ZmJTJC WGdjRUlhOFRmc0Fvem1KOXNLSU5ONmElMkZIZ2RMckt2Sk5YOCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM3OTUwI3NlY3Rpb24tNy4y MC4zPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7b3IgeW91IGhhdmUgdG8gdXBkYXRlIHRo ZSBtb2R1bGUgYW5kIGFkZCB0aGUgZW51bSBpbmxpbmUuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkRvZXMgdGhpcyByZXN1bHQgaW4gYW4gdXBkYXRlIG9mIHRoZSBtb2R1 bGUg4oCcaWV0Zi12b3VjaGVy4oCdIG9yIHRvIGRlZmluZSBhIG5ldyBtb2R1bGUsIHdoaWNoIGlt cG9ydHMgYW5kIGF1Z21lbnRzIHRoZSB2b3VjaGVyIGJ5IGFkZGluZyB0aGUgbmV3IGVudW0/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+U3RlZmZlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_06674cb9709f4bd6bc2af297b929163fsiemenscom_-- From nobody Thu Jun 17 09:42:47 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB0C3A2657 for ; Thu, 17 Jun 2021 09:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8omHOkF88WZg for ; Thu, 17 Jun 2021 09:42:32 -0700 (PDT) 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 191883A265A for ; Thu, 17 Jun 2021 09:42:31 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id d2so9892241ljj.11 for ; Thu, 17 Jun 2021 09:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vzHtHQPKL1RhoFaDIVEl8hADN2PnNtT+Kbs44qv1n7M=; b=Qj7LRwUDAZPtO+xw0kitQfg9Ot9Z/z6tYBNEK09ZwuBkpHPGarlJwnb7Acf5drM1Zf W36pse4Yf/YsTNq2kYxnJ5xWTCk3YmMs0/ej/7ZOddAwmjCZU/PHl4/FIruP/W0t8reT 2/SWjfLm8bHBbjbDKhDQIJUUjzRNi4dAlQexur138jI0W2FJfnD50vMeWfUWGsONpiKM Xk8Jmlo2zEhBFh2vMbIan0Qoc1/+iueA7XWhxyxCSN0Rq6BKXoFKttqbVT1GVAb7MrM2 eLSwLbYjGhke+pEBeTBjoFhIC2RJNG9ufx2VIeEm6whLO/yXEFABBU+ty8bUjjCFzy1H nBwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vzHtHQPKL1RhoFaDIVEl8hADN2PnNtT+Kbs44qv1n7M=; b=AycaSvw05J8PVktw31uXCC0owPNohc76/+6RAM3am/XYeuKzPAKIbyM3Ws/AzCNBlc fBHClriDti3hVzGlrtRVvWsqUW+fII385/x/gL6e2TDVFkuGnDVERzXp0XT9CMgw3xAx dxD1BmpCo6TztaoeldHxww++E+U6wWY2lfaW9v81On6eRYgWIjDGVS0lnVmCCrod1vKd WiO8BibcqXdkqSg9yuWcIpD6fS0yOey2sXTNIYEslDc93mV8r2Bv2Psjt4FDQzYMiPme gcTOBPZyjlov+PgVmWsiBzl4ci8BCpD5b5QkliqA/A7088QvfZ6JqY0hyxINH4WjRdH7 gOzg== X-Gm-Message-State: AOAM532DkiIaw1KfBbDXzqvp8FczXDnHFKBBmXf0c1ndsRZ5RRjObSgr MaOVHZ3tOSiUAgfCaq0pONO271IOlSHdrLqGz2IJaA== X-Google-Smtp-Source: ABdhPJzymNarYzd2kn5gbgH3CrgurrujlhCOd2fRum+e5tw29HLXyB02zU6sjDRw29GLigrWUzS52QjA3AHatUrXDHY= X-Received: by 2002:a2e:908a:: with SMTP id l10mr5352733ljg.160.1623948147796; Thu, 17 Jun 2021 09:42:27 -0700 (PDT) MIME-Version: 1.0 References: <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> <06674cb9709f4bd6bc2af297b929163f@siemens.com> In-Reply-To: <06674cb9709f4bd6bc2af297b929163f@siemens.com> From: Andy Bierman Date: Thu, 17 Jun 2021 09:42:17 -0700 Message-ID: To: "Fries, Steffen" Cc: Kent Watsen , Michael Richardson , "netmod@ietf.org" , "anima@ietf.org" , "Werner, Thomas" Content-Type: multipart/alternative; boundary="0000000000007bbe9405c4f8e47d" Archived-At: Subject: Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 17 Jun 2021 16:42:37 -0000 --0000000000007bbe9405c4f8e47d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 17, 2021 at 9:12 AM Fries, Steffen wrote: > Hi Andy, > > > > Thanks for the reference. I have to dive into that a little deeper. Based > on your previous comment, it would be possible to use the =E2=80=9Cdeviat= e replace=E2=80=9D > to and replace the existing enum in the voucher definition by an enhanced > enum definition in our document. If I understood this right, it is probab= ly > the easiest way. > > > Deviations are not allowed in IETF modules. You probably need to update the module that has the leaf with the enumeration type. > Best regards > > Steffen > > > Andy > *From:* Andy Bierman > *Sent:* Donnerstag, 17. Juni 2021 17:19 > > > > > I am not really following this specific issue. > > I was just pointing out that YANG enumeration types cannot be augmented. > > It is the wrong terminology, since only schema nodes can be augmented. > > > > *>From:* Anima anima-bounces@ietf.org *On Behalf Of *Andy Bierman > >An enumeration type is hard-wired. > > Hardwired in terms of a fixed definition of values for the enum in RFC > 8366? > > > > >No enums can be added via augmentation. > > That means just the definition of an additional enum value is not enough. > > > > >You have to "deviate replace" the type-stmt to add an enum externally, > > As I=E2=80=99m not too deep in YANG, could you provide more information o= n this > part? Would this be an approach to (just) redefine the type enumeration = in > the leaf =E2=80=9Cassertion=E2=80=9D ( > https://datatracker.ietf.org/doc/html/rfc8366#page-11 > ) > and adding the new assertion type =E2=80=9Cagent-proximity=E2=80=9D? Woul= d this require to > keep all enums already defined in RFC 8366 or could we just use the ones > necessary in BRSKI-AE? > > > > > > https://datatracker.ietf.org/doc/html/rfc7950#section-7.20.3 > > > > > > > >or you have to update the module and add the enum inline. > > Does this result in an update of the module =E2=80=9Cietf-voucher=E2=80= =9D or to define a > new module, which imports and augments the voucher by adding the new enum= ? > > > > Best regards > > Steffen > > > > > > Andy > > > --0000000000007bbe9405c4f8e47d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 17, 2021 at 9:12 AM Fries= , Steffen <steffen.fries@si= emens.com> wrote:

Hi Andy,

=C2=A0

Thanks for the reference. I have to dive into that a= little deeper. Based on your previous comment, it would be possible to use= the =E2=80=9Cdeviate replace=E2=80=9D to and replace the existing enum in = the voucher definition by an enhanced enum definition in our document. If I understood this right, it is probably the easiest wa= y.

=C2=A0


<= /div>

Deviations are not allowed in IETF modules.
<= div>You probably need to update the module that has the leaf with the enume= ration type.

=C2=A0

Best regards

Steffen

=C2=A0


<= /div>
Andy
=C2=A0

=

From: Andy Bierma= n <andy@yumawork= s.com>
Sent: Donnerstag, 17. Juni 2021 17:19
=C2=A0

=C2=A0

I am not really following this specific issue.

I was just pointing out that YANG enumeration types = cannot be augmented.

It is the wrong terminology, since only schema nodes= can be augmented.

=C2=A0

>From: Anima anima-bounces@i= etf.org On Behalf Of Andy Bierman
>An enumeration type is hard-wired.

Hardwired in terms of a fixed definition of values f= or the enum in RFC 8366?

=C2=A0

>No enums can be added via augmentation.

That means just the definition of an additional enum= value is not enough. =C2=A0

=C2=A0

>You have to "deviate replace" the type= -stmt to add an enum externally,

As I=E2=80=99m not too deep in YANG, could you provi= de more information on this part?=C2=A0 Would this be an approach to (just)= redefine the type enumeration in the leaf =E2=80=9Cassertion=E2=80=9D (https://datatracker.ietf.= org/doc/html/rfc8366#page-11) and adding the new assertion type =E2=80=9Cagent-proximity=E2=80=9D? Would= this require to keep all enums already defined in RFC 8366 or could we jus= t use the ones necessary in BRSKI-AE?

=C2=A0

=C2=A0

=C2=A0

=C2=A0

>or you have to update the module and add the enu= m inline.

Does this result in an update of the module =E2=80= =9Cietf-voucher=E2=80=9D or to define a new module, which imports and augme= nts the voucher by adding the new enum?

=C2=A0

Best regards

Steffen

=C2=A0

=C2=A0

Andy

=C2=A0

--0000000000007bbe9405c4f8e47d-- From nobody Thu Jun 17 11:48:09 2021 Return-Path: <0100017a1b4d2e94-aeaaa06e-8dc0-4163-a747-692e72b0d75c-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 0BBCC3A29E2; Thu, 17 Jun 2021 11:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=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 cgLbv8s6saFw; Thu, 17 Jun 2021 11:48:02 -0700 (PDT) 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 78E213A29E0; Thu, 17 Jun 2021 11:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1623955681; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=bzPs4wRZY8xfpGAf8DQ0qziX1ApN1INApsWNjcMhyM8=; b=EAEIcT+DVkqL0If/Np6KPcZTXzNf6HmE9V1D5kgC9SH5d1tKMdWVroOgRxah34GK E0I/dgte/80sD+0AP5jikUIRm0wpg440Cpu75M9KCg4+UyguE125hz33OUXsEGgRO25 8KQVT3g6VUoMlOWD29F6lrWerHGfOjLLdkgvgVq4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Kent Watsen In-Reply-To: <3a31e33678484625b9f4f3810e673e56@siemens.com> Date: Thu, 17 Jun 2021 18:48:01 +0000 Cc: "anima@ietf.org" , "netmod@ietf.org" , "Werner, Thomas" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017a1b4d2e94-aeaaa06e-8dc0-4163-a747-692e72b0d75c-000000@email.amazonses.com> References: <3a31e33678484625b9f4f3810e673e56@siemens.com> To: "Fries, Steffen" X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.17-54.240.48.90 Archived-At: Subject: Re: [netmod] Reuse of SZTP-CSR YANG definition in BRSKI-AE 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, 17 Jun 2021 18:48:07 -0000 [future threads about SZTP should CC NETCONF, the WG that = published/maintains SZTP] Hi Steffen, > Hi Kent,=20 >=20 > There is a further YANG related question in the context of BRSKI-AE.=20= >=20 > In one use case, the pledge has no direct connection to the registrar = and a registrar-agent communicates with the pledge. In that specific = case we do not have a TLS connection between the pledge and the = registrar-agent and protect the exchanged objects by an additional = signature. This is done by embedding the necessary information into a = JOSE object.=20 > For the enrollment Michael was pointing to the YANG module in = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr to = avoid a double definition to transport a certification request. In = BRSKI-AE we currently use a PKCS#10 request, but using the defined = ietf-sztp-csr would also allow to use other formats.=20 >=20 > For the enrollment request created by the pledge we have defined the = following JOSE object: > { > "alg": "ES256", > "x5c": ["MIIB2jCC...dA=3D=3D"] > } > { > "ietf-sztp-csr:csr": { > "p10": "base64encodedvalue=3D=3D" > } > } > { > SIGNATURE > } >=20 > The question = (https://github.com/anima-wg/anima-brski-async-enroll/issues/10) now is, = if this construct is possible, as we are just using a subset = (sztp-csr:csr) of the YANG module " ietf-sztp-bootstrap-server" from = draft-ietf-netconf-sztp-csr? This is not possible. > The alternative would be to define an own module modeled in a similar.=20= You can do this. > Best regards > Steffen K. From nobody Thu Jun 17 13:55:53 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BDC3A2DC1; Thu, 17 Jun 2021 13:55:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162396334377.4342.14139997395551695610@ietfa.amsl.com> Date: Thu, 17 Jun 2021 13:55:43 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-nmda-diff-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 20:55:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Comparison of NMDA datastores Authors : Alexander Clemm Yingzhen Qu Jeff Tantsura Andy Bierman Filename : draft-ietf-netmod-nmda-diff-09.txt Pages : 19 Date : 2021-06-17 Abstract: This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-nmda-diff-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-nmda-diff-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 17 15:09:53 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 193033A3070; Thu, 17 Jun 2021 15:09:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: "The IESG" Cc: draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, Kent Watsen , kent+ietf@watsen.net X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Francesca Palombini Message-ID: <162396779107.24412.11170806791302205147@ietfa.amsl.com> Date: Thu, 17 Jun 2021 15:09:51 -0700 Archived-At: Subject: [netmod] Francesca Palombini's No Objection on draft-ietf-netmod-geo-location-10: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 22:09:51 -0000 Francesca Palombini has entered the following ballot position for draft-ietf-netmod-geo-location-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to the authors for addressing my concerns, and thank you to the shepherd for a very well-written shepherd write up. Francesca From nobody Thu Jun 17 15:10:40 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7B83A307C; Thu, 17 Jun 2021 15:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzWc9w6DisTK; Thu, 17 Jun 2021 15:10:27 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60063.outbound.protection.outlook.com [40.107.6.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17EC3A307A; Thu, 17 Jun 2021 15:10:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PAmWVIrzoED/8nwZNGMIZ5nMoBnuoxqVZI77Ftm7YSSBuRGVdLRw/qAX04vRqtr4RJ3S7UkjlTjZwKVVR7s0MORQaGMR9pks+bKTeXgfKtuBacyZNPFYoy1PoPjG42FS2is/RT+8IYvYh+ru1DrGOIK1JAbCMvASDTifgfIQTdMrykFqmbmR2NPaQfvEtgFP+J1maJFcqmoBlKm5oTNyqn/coUvOCK7IH34snij3zHETyv+3eJKb+5btMogGdHmFZGAc+NC0x3t99YIu9NIsQGiryHt1CBw3sLP8Yg+NFXSVxYwwmqDiA2mLJV0ZsSBvQUEHs8SroP9blM9wS2HXIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eHNG7xWDefH7ltgiNCOxRI7LdxLN7DKoVsLrq4n1wF4=; b=aBjvWoaZiRbYdOMIcBfJKC4WHojG6csfHi68YUA4zRdWFSfRxKOMtI7Vd2nCGVm6RWPwGpbhxTn4rfJDza4fV1wmMVaW1gT3vOpq+M56NRognAuzVznR+fH3diYCXDe/uu6KfmuNYZpefk3OxTZTiMLPko24RQaCFRhuD4lYEI3ls24WOjz5jfKQJMASgFkpT5YltzYI+ngoWv3BxPwIcGMMWOqESyYDTW9NvzbkL7kdVnQTbvOSywqBd/ryIq0hPbUcO5YPuOI4B3fVGaQ1+fn2F+9WpkFYCQTsW5WbFMCUz2vhnnAVizP5EfjHjMlncXKrifGrgg0dMtD9pcxfpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eHNG7xWDefH7ltgiNCOxRI7LdxLN7DKoVsLrq4n1wF4=; b=axTQbzBGx9AuntyAKnYkpn+s6hORFpii4HJIVi8LJHFJHjL3gpC6Vw1tyDBPG+dPtEMlfc3teObz2rrVipSpJn9MJBIUTM8SKUceyzq3N6iUtsLRts2UO7D7076W2M6rzP61s16pgcHAQz3cw4ZNvRqOG4MmWTvzm2Y0AxvtNX8= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2683.eurprd07.prod.outlook.com (2603:10a6:3:98::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.13; Thu, 17 Jun 2021 22:10:20 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6ce5:7088:a9a8:15d9]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6ce5:7088:a9a8:15d9%7]) with mapi id 15.20.4242.014; Thu, 17 Jun 2021 22:10:20 +0000 From: Francesca Palombini To: Christian Hopps CC: The IESG , "draft-ietf-netmod-geo-location@ietf.org" , "netmod-chairs@ietf.org" , "netmod@ietf.org" , "kent+ietf@watsen.net" Thread-Topic: Francesca Palombini's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) Thread-Index: AQHXTKicqz2cNR7DgUuMysdLRMkUxKr2WqsAgBjSyoCACNPLAIABEhOA Date: Thu, 17 Jun 2021 22:10:20 +0000 Message-ID: <4895EC52-2A2B-4C1A-B63C-B2E29F2B8062@ericsson.com> References: <162142641389.26028.16682502889430351090@ietfa.amsl.com> <0872384B-C41A-4F2F-8D5D-736C78265B89@ericsson.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21061301 authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 11238bc4-cb82-47e4-5cd1-08d931dcb251 x-ms-traffictypediagnostic: HE1PR0701MB2683: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nNG0EaIzKfbK7lFuLXXDxJzJnM0MzeXh6AdyyRVXKkQ2+rXEXbfs5qWbBCyQb+fU1UUemlH0rsW/PhnRg+3r3Tem/3cGN/4WsDbbT+llh4e860wNGRyeDBaBNpp2zFgtcB0gQFVGA8PXJPXbdPo1FR7IHwacH/jAcwok7AfCW3Ip02k4+LlMsmPbm7NadSd/KkUUBZ+D3XF9FvULT4hWKG3Dn1VAd+ELARHofFVH1gWgblrp9p8qS61spYAWML1dH6Ew1qeiC3uCHlHR3i5EeR6FiCZytc/BM+wBHarHA7LL4/Z2aO36W1yRkBlgLTA/tw05kEJ96AD7Fe4O1vrDW8a+2XN5q6BUOTh0Ic5j/3xQEoKLR/6wLcLDAbF/mEM8rc6P3JEgmh5r+5OTV+cg//2qCuAM4ddr86Zn7wT0eyzTWfpZ9ANmsRwdkA7d5vgPwJg60+9rzlGVzIIHXF97ksSpxrs92BNmBeJh99IqMouJwMvvJyDahDckPuoGUU/NF8T/beEfnTk5vhTxXR7hMfhvpfTfWH+bR2zZs2Qt8CEOzmuMr2iyrgwk9kqnwrXmyHXnZZe6xp7Mvr8SAHQIN5HMpcfgG+d/laiP6aovoo3u7zNjhWHfUhNLBUDlC/vO9GUbP12tjjCozmlL+Wi/+r0Q2CLOtqmJnkp+y6QnabvXuFITyh0tcVtd5lvTFj9wx88DQk8fQ5a0Um5qurRxtZuOljOsTNJ9pfCj9Zz1Vrby8JJ9DRlGJNOEFAIGXNJxPdWAnIStmXUzSV3ODvqq0A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(376002)(136003)(396003)(346002)(6512007)(71200400001)(36756003)(122000001)(38100700002)(478600001)(66446008)(966005)(83380400001)(2906002)(4326008)(33656002)(8936002)(2616005)(6506007)(44832011)(76116006)(66556008)(66946007)(6916009)(6486002)(8676002)(316002)(5660300002)(54906003)(186003)(64756008)(86362001)(66476007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?N0lUcHM5V0xwREV1Y1J6d01hREJsQVVYWE9IbmM5bWd6UGF1UUVUcGpHd3FC?= =?utf-8?B?U3U0cmRMNVNSVjdIUFM4cS9iOWJOR2dBV3JIUWFjVlNkY0lqRW5kdm1vZHNR?= =?utf-8?B?cHJ2eTlnMXJmVWFSdUJ5Z0FyZTBrdXJoUjRHMTFLdmtrRENGMGw0K3U4Ny9T?= =?utf-8?B?ZjhJMWY4VEE1MGxKVVluZzJlL2tnNWlmczc1UkpjUkkxZFN0djYyc0ZWQVN5?= =?utf-8?B?Wjg0ZWpKS3QvL3dFVnFURUZaYVM5TXlQRDNFL1FqMS94dmJwVm85eTdpZVZP?= =?utf-8?B?RU1ySXlLS1YraXpDWjMwY2JpVk1wTHBlNnk3Q3laK0JtUzI2dURicEY5aTIx?= =?utf-8?B?a2orMWJoQlJHUzNKQmJuZlVJUGhEcUEwaXBEUHJxblM2Ry9ON2dZSHUrcGc3?= =?utf-8?B?dmRGVlJEZURPTFFwcU1iNS9tS3Z3OTJnUTJ4blNJZ3RDVUxuZjBSQzlRTnhX?= =?utf-8?B?WXVvcG9VaURJQ1k1MXRKNVdIcitRdllkbU5tQ25LT0cwRm5xYVR5dzlxTENs?= =?utf-8?B?U0NhT21YNTRwcjNZVUV2UGJ5aWZLRUVNamNRM2dVTmRQeXdSUG91WTlYUWhS?= =?utf-8?B?UlU1b1RucXhNTDVobGE2Ri8yM2lhUWMyZFpqMHRiM0k0VnhkWkM4MXY4Wkdx?= =?utf-8?B?KzRid3NMdUN6VkN2dUtRY0x5blNNellKbTkrUTRJRzErYUpsbnlWVnBydkhG?= =?utf-8?B?VmNNdXNkbnVZMGhEL0RzTVoweXBPaFpPNjhzdTl6cndmZXRiS000eWY0MU1a?= =?utf-8?B?RTZVTlU0akFmSS9wbVA0V3NBeTNTS1F6ZHdhQ3N1WG1HR1JlWnRMNjZzallZ?= =?utf-8?B?K0EwM0ptckVsVjQwWU43ZEVXOWdRRWFFNzRKUTdrQmVEZE9LQXBwTEFMWnFo?= =?utf-8?B?d2xYQ1hmYnRLaWpNOWFrZWxpbTd1Tm1EMlpNVjNwSERPRlBMTlNJRGRnc2JJ?= =?utf-8?B?aWZGbTg4Q0ExcVg4MDFPSjc5TUJGbEJRc1JyTDdjMjBsbFlDZkZqWDNzZ1Mz?= =?utf-8?B?OUJCQVRtNVZldXp5N0hXY0xYQlkvSUppbnlyZ0FSVjFMSVFwZDhYU2dRTWI0?= =?utf-8?B?M2J5eWNHY0NkMDR4NFZyRW9uSE55L0Zaak1hdUorc1lVUjh2NlcrK2FtWFdo?= =?utf-8?B?SW8yN1puSkRQNkN3RnlXblRpNFIxZmdSM2VKUU94bzdpdWpSSmpDS0FVcG5B?= =?utf-8?B?dElKUU1pM1Y3Q3o5OFcwM3BNdnJEZmZwcFg2c0JLaWRSSlZwTzd0bWhsU0x0?= =?utf-8?B?V1cwQWszckg3bWhpNGdsc2I5d09BcGxhMk5vb3FnYUVhVEpzWDgzcDV3WGFw?= =?utf-8?B?NE1xN1I0c25xekdtSVlFTC80c2tEVEdMRHhCYUdhaFAveVJFenBpVFVHUVhn?= =?utf-8?B?OW1hS1pxRlUrQTVtOGtPTW4wbmVsaXJLbXcwZjJhY1IxUkxFcExIbm0zVFdu?= =?utf-8?B?QTdnSTl3SitGUXpyZTdKbkhCQ2ZBS3BXc1FrSzRmclYyRXBzNmRqWSttQTNx?= =?utf-8?B?bVllMEpDYlgxNmNROXRqSWRrTEhsTmxEb0cvcDlqTUpYWkI1WUlxWTJRcTZk?= =?utf-8?B?emZGRzNUOHBSaHBmV2dKQit4UDBZK0hMaGdmTVNhV2ZTTnNVU01SRit5WTQ0?= =?utf-8?B?QmNJa3BLWVB3VTBSSWhpTStvbjdWQU1WWEh4NXBtYTVqUGRvT0lWN0hLTTZk?= =?utf-8?B?N2QzNkdOUnZPb1l5OXV3Y0FPUVdmb04xdlVqOTNuV3Zzd0ZmTEFjRXRVMERK?= =?utf-8?B?ZXFKcC95VWtVejJ0YXlWYlh6Vm5FdjVISUhUUzdicVRwSkR5L21sR2tDSG9a?= =?utf-8?B?dWJOOUpyS29pYVUySk1WVThqSTU3RGx2Z2FRaVJnaVNMWjhWOU9xVlgxQjV3?= =?utf-8?B?RnVHU3NFbVByYlFIaUpKcU5JZ1loL25kOHNRM2xSSjNUY3c9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <89FFEB1610E2654D928DAAD45160A598@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11238bc4-cb82-47e4-5cd1-08d931dcb251 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 22:10:20.2389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3MiA85+WErerfGF6NWJLcrpGf+A6O20RwF4qm5JxOCBPK9YUggivFAM5UpN3jeQQa4GBc4j8Qj1fIRC+PehUvwi58hCVFSlSEOSoZ83ihqdiac5q1SWzTCIFnYDxTA7M X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2683 Archived-At: Subject: Re: [netmod] Francesca Palombini's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) 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, 17 Jun 2021 22:10:34 -0000 SGkgQ2hyaXMsIA0KDQpUaGFuayB5b3UsIEkgY2xlYXJlZCBteSBkaXNjdXNzLg0KDQpGcmFuY2Vz Y2ENCg0K77u/T24gMTcvMDYvMjAyMSwgMDk6NTIsICJDaHJpc3RpYW4gSG9wcHMiIDxjaG9wcHNA Y2hvcHBzLm9yZz4gd3JvdGU6DQoNCg0KICAgIEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNj YS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPiB3cml0ZXM6DQoNCiAgICA+IEhpIENocmlzLA0KICAg ID4NCiAgICA+IElubGluZS4NCg0KICAgIEkndmUgcG9zdGVkIGEgbmV3IHZlcnNpb24gd2l0aCB0 aGUgdXBkYXRlZCBJQU5BIHJlZ2lzdHJ5IGNoYW5nZXMuDQoNCiAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1nZW8tbG9jYXRpb24vMTAvDQoNCiAg ICBUaGFua3MsDQogICAgQ2hyaXMuDQoNCg0KICAgID4NCiAgICA+IFRoYW5rcywNCiAgICA+IEZy YW5jZXNjYQ0KICAgID4NCiAgICA+IO+7v09uIDI3LzA1LzIwMjEsIDAwOjA0LCAiQ2hyaXN0aWFu IEhvcHBzIiA8Y2hvcHBzQGNob3Bwcy5vcmc+IHdyb3RlOg0KICAgID4NCiAgICA+DQogICAgPiAg ICAgRnJhbmNlc2NhIFBhbG9tYmluaSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+ IHdyaXRlczoNCiAgICA+DQogICAgPiAgICAgPiBGcmFuY2VzY2EgUGFsb21iaW5pIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgID4gICAgID4gZHJhZnQt aWV0Zi1uZXRtb2QtZ2VvLWxvY2F0aW9uLTA4OiBEaXNjdXNzDQogICAgPiAgICAgPg0KICAgID4N CiAgICA+ICAgICA+DQogICAgPiAgICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiAgICAgPiBESVND VVNTOg0KICAgID4gICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+ IFRoYW5rIHlvdSBmb3IgdGhlIHdvcmsgb24gdGhpcyBkb2N1bWVudCwgYW5kIHRoYW5rIHlvdSB0 byB0aGUgc2hlcGhlcmQgZm9yIGENCiAgICA+ICAgICA+IHZlcnkgd2VsbC13cml0dGVuIHNoZXBo ZXJkIHdyaXRlIHVwLg0KICAgID4gICAgID4NCiAgICA+ICAgICA+IEkgaGF2ZSBhIGNvdXBsZSBv ZiBESVNDVVNTIHBvaW50cyByZWxhdGVkIHRvIHRoZSBJQU5BIHNlY3Rpb24sIGFuZCBzb21lIG5v bg0KICAgID4gICAgID4gYmxvY2tpbmcgcXVlc3Rpb24uDQogICAgPiAgICAgPg0KICAgID4gICAg ID4gRnJhbmNlc2NhDQogICAgPiAgICAgPg0KICAgID4gICAgID4gMS4gLS0tLS0NCiAgICA+ICAg ICA+DQogICAgPiAgICAgPiAgICBUaGUgYWxsb2NhdGlvbiBwb2xpY3kgZm9yIHRoaXMgcmVnaXN0 cnkgaXMgRmlyc3QgQ29tZSwgRmlyc3QgU2VydmVkLA0KICAgID4gICAgID4gICAgW1JGQzgxMjZd IGFzIHRoZSBpbnRlbnQgaXMgc2ltcGx5IHRvIGF2b2lkIGR1cGxpY2F0ZSB2YWx1ZXMuDQogICAg PiAgICAgPg0KICAgID4gICAgID4gRlA6IFJGQyA4MTI2IHNwZWNpZmllczoNCiAgICA+ICAgICA+ DQogICAgPiAgICAgPiAgICBXaGVuIGNyZWF0aW5nIGEgbmV3IHJlZ2lzdHJ5IHdpdGggRmlyc3Qg Q29tZSBGaXJzdCBTZXJ2ZWQgYXMgdGhlDQogICAgPiAgICAgPiAgICByZWdpc3RyYXRpb24gcG9s aWN5LCBpbiBhZGRpdGlvbiB0byB0aGUgY29udGFjdCBwZXJzb24gZmllbGQgb3INCiAgICA+ICAg ICA+ICAgIHJlZmVyZW5jZSwgdGhlIHJlZ2lzdHJ5IHNob3VsZCBjb250YWluIGEgZmllbGQgZm9y IGNoYW5nZSBjb250cm9sbGVyLg0KICAgID4gICAgID4gICAgSGF2aW5nIGEgY2hhbmdlIGNvbnRy b2xsZXIgZm9yIGVhY2ggZW50cnkgZm9yIHRoZXNlIHR5cGVzIG9mDQogICAgPiAgICAgPiAgICBy ZWdpc3RyYXRpb25zIG1ha2VzIGF1dGhvcml6YXRpb24gb2YgZnV0dXJlIG1vZGlmaWNhdGlvbnMg bW9yZSBjbGVhci4NCiAgICA+ICAgICA+ICAgIFNlZSBTZWN0aW9uIDIuMy4NCiAgICA+ICAgICA+ DQogICAgPiAgICAgPiBUaGUgY3VycmVudCByZWdpc3RyeSBkb3Mgbm90IGNvbnRhaW4gY29udGFj dCBwZXJzb24sIG5vciByZWZlcmVuY2UsIG5vciBjaGFuZ2UNCiAgICA+ICAgICA+IGNvbnRyb2xs ZXIgZmllbGRzLg0KICAgID4NCiAgICA+ICAgICBJIGhvbmVzdGx5IGhhdmUgbm8gaWRlYSB3aGF0 IHRvIHB1dCBpbiB0aGF0IGZpZWxkIGZvciB0aGUgcmVmZXJlbmNlZCBzdGFuZGFyZHMuIENlcnRh aW5seSB3ZSBjYW4ndCBqdXN0IHBvaW50IHBlb3BsZSBhdCB0aGUgZGVmaW5pbmcgc3RhbmRhcmRz IG9yIHBlb3BsZSB3aG8gd3JvdGUgdGhlbSBhcyB0aGV5IGhhdmUgbm8gcmVhc29uIHRvIHBheSBh dHRlbnRpb24gdG8gb3VyIFlBTkcgZ3JvdXBpbmdzIElBTkEgcmVnaXN0cnkuIFNob3VsZCBJIHB1 dCBteXNlbGYsIG9yIHRoZSBORVRNT0Qgd29ya2luZyBncm91cCBwZXJoYXBzPw0KICAgID4NCiAg ICA+IEZQOiBGb3IgdGhlIHZhbHVlIHlvdSByZWdpc3RlciBpbiB0aGlzIGRvY3VtZW50LCBJIHRo aW5rIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gaGF2ZSB0aGUgcmVmZXJlbmNlIHRvIHRoaXMgZG9j dW1lbnQuIEZvciBjaGFuZ2UgY29udHJvbGxlciwgaXQgaXMgcXVpdGUgY29tbW9uIHRvIGhhdmUg SUVTRy4gVGhhdCB3b3VsZCBtZWFuIHR3byBjaGFuZ2VzOg0KICAgID4gLSBhZGQgMiBjb2x1bW5z OiAiUmVmZXJlbmNlIiBhbmQgIkNoYW5nZSBjb250cm9sIiB0byB0YWJsZSAzLCB3aGVyZSBSZWZl cmVuY2UgaXMNCiAgICA+IFtUaGlzIGRvY3VtZW50XSBhbmQgQ2hhbmdlIGNvbnRyb2wgaXMgSUVT RywgZm9yIGFsbCByb3dzLiAoWW91IGRvbid0IG5lZWQgdG8gYWRkDQogICAgPiBvbmUgY29sdW1u IGZvciBjb250YWN0IHBlcnNvbiwgSSBoYXZlIG5vdGljZWQgaXQgaXMgcXVpdGUgY29tbW9uIGZv ciBJQU5BDQogICAgPiByZWdpc3RyeSB0byB1c2UgdGhhdCBzYW1lIFJlZmVyZW5jZSBjb2x1bW4g dG8gcG9pbnQgZWl0aGVyIHRvIGEgc3RhbmRhcmQgb3IgdG8gYQ0KICAgID4gY29udGFjdCBwZXJz b24pDQogICAgPiAtIGFkZCBhIHNlbnRlbmNlIHN0YXRpbmcgdGhhdCAiUmVmZXJlbmNlIiBjYW4g cG9pbnQgdG8gdGhlIGRvY3VtZW50IGRvaW5nIHRoZSByZWdpc3RyYXRpb24gb3IgdGhlIGNvbnRh Y3QgcGVyc29uLCBhcyBkZWZpbmVkIGJ5IFJGQyA4MTI2Lg0KICAgID4NCiAgICA+ICAgICA+IDIu IC0tLS0tDQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRo YXQgW1JGQzU4NzBdIGFsc28gY3JlYXRlcyBhIHJlZ2lzdHJ5IGZvcg0KICAgID4gICAgID4gICAg R2VvZGV0aWMgU3lzdGVtcyAoaXQgY2FsbHMgQ1JTKTsgaG93ZXZlciwgdGhpcyByZWdpc3RyeSBo YXMgYSB2ZXJ5DQogICAgPiAgICAgPiAgICBzdHJpY3QgbW9kaWZpY2F0aW9uIHBvbGljeS4gIFRo ZSBhdXRob3JzIG9mIFtSRkM1ODcwXSBoYXZlIHRoZSBzdGF0ZWQNCiAgICA+ICAgICA+ICAgIGdv YWwgb2YgbWFraW5nIENSUyByZWdpc3RyYXRpb24gaGFyZCB0byBhdm9pZCBwcm9saWZlcmF0aW9u IG9mIENSUw0KICAgID4gICAgID4gICAgdmFsdWVzLiAgQXMgb3VyIG1vZHVsZSBkZWZpbmVzIGFs dGVybmF0ZSBzeXN0ZW1zIGFuZCBoYXMgYSBicm9hZGVyDQogICAgPiAgICAgPiAgICAoYmV5b25k IEVhcnRoKSBzY29wZSwgdGhlIHJlZ2lzdHJ5IGRlZmluZWQgYmVsb3cgaXMgbWVhbnQgdG8gYmUg bW9yZQ0KICAgID4gICAgID4gICAgZWFzaWx5IG1vZGlmaWVkLg0KICAgID4gICAgID4NCiAgICA+ ICAgICA+IEZQOiBUaGFua3MgZm9yIGJyaW5naW5nIHRoaXMgdXAgLSBJIHdhbnQgdG8gY29uZmly bSB0aGF0IHdlIG5lZWQgdGhpcyByZWdpc3RyeSwNCiAgICA+ICAgICA+IGFuZCB0aGF0IHdlIGFy ZSBub3QgY3JlYXRpbmcgYSB3YXkgdG8gYnlwYXNzIHRoZSBDUlMgcmVnaXN0cmF0aW9uIHBvbGlj aWVzIGJ5DQogICAgPiAgICAgPiBwcm92aWRpbmcgYSBkaWZmZXJlbnQgcmVnaXN0cnkgd2l0aCBh IG1vcmUgbGVuaWVudCBwb2xpY3kuDQogICAgPiAgICAgPg0KICAgID4NCiAgICA+IEZQOiBUaGlz IHdhcyBkaXNjdXNzZWQgZHVyaW5nIHRoZSB0ZWxlY2hhdCBhbmQgaXMgcmVzb2x2ZWQsIHNvIGFz IHNvb24gYXMgd2UgYWdyZWUgb24gcG9pbnQgMS4gSSB3aWxsIHJlbW92ZSBteSBESVNDVVNTLg0K ICAgID4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiAgICAg PiBDT01NRU5UOg0KICAgID4gICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gICAgID4NCiAgICA+ ICAgICA+DQogICAgPiAgICAgPiAzLiAtLS0tLQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+ICAg IFtXR1M4NF0gICAgTmF0aW9uYWwgSW1hZ2VyeSBhbmQgTWFwcGluZyBBZ2VuY3kuLCAiTmF0aW9u YWwgSW1hZ2VyeQ0KICAgID4gICAgID4gICAgICAgICAgICAgICBhbmQgTWFwcGluZyBBZ2VuY3kg VGVjaG5pY2FsIFJlcG9ydCA4MzUwLjIsIFRoaXJkDQogICAgPiAgICAgPiAgICAgICAgICAgICAg IEVkaXRpb24uIiwgMyBKYW51YXJ5IDIwMDAsIDxodHRwOi8vZWFydGgtDQogICAgPiAgICAgPiAg ICAgICAgICAgICAgIGluZm8ubmdhLm1pbC9HYW5kRy9wdWJsaWNhdGlvbnMvdHI4MzUwLjIvd2dz ODRmaW4ucGRmPi4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBGUDogSSBzdXBwb3J0IExhcnMg RElTQ1VTUywgYW5kIGFkZCB0aGUgZm9sbG93aW5nIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gdGhl DQogICAgPiAgICAgPiBsaXN0IC0gbGluayBpcyBicm9rZW4uIEEgcXVpY2sgZ29vZ2xlIHNlYXJj aCBmb3VuZCB0aGlzOg0KICAgID4gICAgID4gaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92 MS91cmw/az04YzRkYzliNy1kM2Q2ZjA5YS04YzRkODkyYy04NjkyZGM4Mjg0Y2ItYzBkZjE5YjYy OTU1M2Q5ZSZxPTEmZT03ZTQ0YzkxNi1mZjQ3LTRkYWUtYjE5My1hODkyODNjNDk0NzImdT1odHRw cyUzQSUyRiUyRmdpcy1sYWIuaW5mbyUyRmRvY3MlMkZuaW1hLXRyODM1MC4yLXdnczg0ZmluLnBk ZiAsIHdoaWNoIEkgYXNzdW1lIGlzIHRoZQ0KICAgID4gICAgID4gd2FudGVkIHJlZmVyZW5jZS4u LiBidXQgSSBkb24ndCB0aGluayB0aGF0IHdlIHNob3VsZCBiZSByZWx5aW5nIG9uIGluZm9ybWFs DQogICAgPiAgICAgPiBjb21tdW5pdGllcyB0byBtYWludGFpbiBub3JtYXRpdmUgcmVmZXJlbmNl cyB0byBvdXIgZG9jdW1lbnRzLCBjYW4gd2UgZG8gYmV0dGVyPw0KICAgID4NCiAgICA+ICAgICBJ IHJlbW92ZWQgdGhlIFVSTHMgLS0gb2J2aW91c2x5IHRoZXkgYXJlIG5vdCBzdGFibGUuIFNvIHdl IGNhbiBwcm9jZWVkIHdpdGggdGhlIG5vcm1hbCBkb2N1bWVudCB0aXRsZSwgYXV0aG9yLCBhbmQg cHVibGljYXRpb24gZGF0ZS4NCiAgICA+DQogICAgPiBGUDogSSBzZWUgdGhhdCB0aGVyZSB3YXMg ZGlzY3Vzc2lvbiB3aXRoIExhcnMgYWJvdXQgaXQsIHNvIEkgd2lsbCBsZWF2ZSBpdCB1cCB0byB5 b3UgYW5kIFJvYiB0byBkZWNpZGUgdGhlIGJlc3Qgd2F5IGZvcndhcmQuIEhvd2V2ZXIgSSBkbyBh Z3JlZSB3aXRoIExhcnMgKGFuZCBxdW90aW5nIGhpbSkgdGhhdDoNCiAgICA+ICIuLiBzaW5jZSB5 b3UnZCB3YW50IHRob3NlIHJlZmVyZW5jZXMgdG8gYmUgZWFzaWx5IGFuZCB1bmFtYmlndW91c2x5 IGZpbmRhYmxlIGJ5IHJlYWRlcnMvaW1wbGVtZW50ZXJzLCBpbmNsdWRpbmcgdGhlbSBpcyB1c3Vh bGx5IHZlcnkgaGVscGZ1bCwgZXNwZWNpYWxseSBmb3Igbm9ybWF0aXZlIHJlZmVyZW5jZXMsIHdo aWNoIGFyZSBiYXNpY2FsbHkgcmVxdWlyZWQgcmVhZGluZy4iIFNvIG15IHByZWZlcmVuY2Ugd291 bGQgYmUgdG8ga2VlcCB0aGUgVVJJIHRvIHRoZSBtb3N0IHN0YWJsZSBwb3NzaWJsZSBsaW5rLg0K ICAgID4NCiAgICA+ICAgICA+IDQuIC0tLS0tDQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAg Y2hvaWNlICJsYXRpdHVkZSIgYW5kICJsb25naXR1ZGUiIGFyZSBzcGVjaWZpZWQgYXMgZnJhY3Rp b25zIG9mDQogICAgPiAgICAgPiAgICBkZWNpbWFsIGRlZ3JlZXMsIGFuZCB0aGUgImhlaWdodCIg dmFsdWUgaXMgaW4gZnJhY3Rpb25zIG9mIG1ldGVycy4NCiAgICA+ICAgICA+ICAgIEZvciB0aGUg Q2FydGVzaWFuIGNob2ljZSAieCIsICJ5IiBhbmQgInoiIGFyZSBpbiBmcmFjdGlvbnMgb2YgbWV0 ZXJzLg0KICAgID4gICAgID4NCiAgICA+ICAgICA+IEZQOiBJIGhhdmUgdGhlIGZlZWxpbmcgdGhh dCB0aGUgZG9jdW1lbnQgaXMgc3BlY2lmeWluZyBib3RoIG51bWVyaWMgZGF0YQ0KICAgID4gICAg ID4gZXhwZWN0ZWQgYW5kIHVuaXQgYXQgdGhlIHNhbWUgdGltZSAiZnJhY3Rpb24gb2YgX2luc2Vy dCB1bml0XyIuIEZvciB0aGUgc2FrZSBvZg0KICAgID4gICAgID4gY2xhcml0eSwgSSB0aGluayBp dCB3b3VsZCBiZSBiZXN0IHRvIHNwbGl0IHRoaXMgdXAsIHNvIGNoYW5nZSB0aGUgImZyYWN0aW9u IG9mDQogICAgPiAgICAgPiBtZXRlcnMiIHRvICJtZXRlcnMsIGV4cHJlc3NlZCBpbiBmbG9hdGlu ZyBwb2ludCIuIFRPRE86IGNoZWNrIHRoYXQgZm9ybWF0IGlzDQogICAgPiAgICAgPiBkZWZpbmVk Lg0KICAgID4NCiAgICA+ICAgICBJdCBpcyBzcGVjaWZ5aW5nIHVuaXRzIGFuZCB0aGVpciBmb3Jt YXQsIEkgZmVsdCB0aGlzIHdhcyBzaW1wbHkgY29uY2lzZSwgYnV0IG5vdCBjb25mdXNpbmcuIERv IHlvdSBmZWVsIHN0cm9uZ2x5IGFib3V0IHRoaXM/IEZXSVcgd2UgdXNlIFlBTkcgZGVjaW1hbDY0 IG5vdCBmbG9hdGluZyBwb2ludCBpbiB0aGUgWUFORyBncm91cGluZy4NCiAgICA+DQogICAgPiBG UDogTm8gSSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0IHRoaXMsIGFuZCBhcyB5b3Ugc2F5IHRo YXQgaXMgZGVmaW5lZCBpbiB0aGUgWUFORyBncm91cGluZy4gSXQncyBmaW5lIGtlZXBpbmcgaXQg dGhpcyB3YXksIHRoYW5rcyBmb3IgdGhlIGFuc3dlci4NCiAgICA+DQogICAgPiAgICAgPiA1LiAt LS0tLQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+IEZQOiBBZnRlciBsb29raW5nIGZvciBhIHdo aWxlOiBkb2VzIGEgc3RhYmxlIHJlZmVyZW5jZSBleGlzdCBmb3IgdGhlIGxpc3Qgb2YNCiAgICA+ ICAgICA+IGFzdHJvbm9taWNhbCBib2RpZXMgYW5kIHRoZWlyIG5hbWUgKHJhdGhlciB0aGFuIGp1 c3Qgc2F5aW5nIGl0IGlzIG1haW50YWluZWQgYnkNCiAgICA+ICAgICA+IElBVSk/IEkgb25seSBm b3VuZCB0aGUgZm9sbG93aW5nIGZvciBzdGFyczoNCiAgICA+ICAgICA+IGh0dHBzOi8vcHJvdGVj dDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9ODE1YTU5MjMtZGVjMTYwMGUtODE1YTE5YjgtODY5MmRj ODI4NGNiLTM3YmMwZjE4NTA4YmIyMmUmcT0xJmU9N2U0NGM5MTYtZmY0Ny00ZGFlLWIxOTMtYTg5 MjgzYzQ5NDcyJnU9aHR0cHMlM0ElMkYlMkZ3d3cuaWF1Lm9yZyUyRnB1YmxpYyUyRnRoZW1lcyUy Rm5hbWluZ19zdGFycyUyRiAuIEkgYWxzbyBmb3VuZCB0aGUgcGFnZSBmb3IgdGhlDQogICAgPiAg ICAgPiBjb3JyZXNwb25kaW5nIFdHLCB3aGljaCBkZWZpbmVkIHRoZSBndWlkZWxpbmVzIGZvciBu YW1pbmcgc3RhcnMuIEkgd2FzDQogICAgPiAgICAgPiB3b25kZXJpbmcgaWYgdGhlcmUgaXMgYSBy ZWZlcmVuY2UgdG8gdGhlc2UgZ3VpZGVsaW5lcyBmb3IgYWxsIGFzdHJvbm9taWNhbA0KICAgID4g ICAgID4gYm9kaWVzLiBXaGF0IEkgYW0gZXNwZWNpYWxseSBjb25jZXJuZWQgYWJvdXQgaXMgdGhh dCBJIHdhcyBub3QgYWJsZSB0byB2ZXJpZnkNCiAgICA+ICAgICA+IHRoYXQgd2Ugd2lsbCBub3Qg aW5jdXIgb24gZW5jb2RpbmcgcHJvYmxlbXMsIGlmIElBVSBjaGFuZ2VzIHRoZWlyIG5hbWluZw0K ICAgID4gICAgID4gY29udmVudGlvbnMsIGdpdmVuIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiB0aGUg ZG9jdW1lbnQ6DQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAgICAgICAgICAgICAgICc2N3Av Y2h1cnl1bW92LWdlcmFzaW1lbmtvIChhIGNvbWV0KS4gVGhlIHZhbHVlIHNob3VsZA0KICAgID4g ICAgID4gICAgICAgICAgICAgICAgIGJlIGNvbXByaXNlZCBvZiBhbGwgbG93ZXIgY2FzZSBBU0NJ SSBjaGFyYWN0ZXJzIG5vdA0KICAgID4gICAgID4gICAgICAgICAgICAgICAgIGluY2x1ZGluZyBj b250cm9sIGNoYXJhY3RlcnMgKGkuZS4sIHZhbHVlcyAzMi4uNjQsIGFuZA0KICAgID4gICAgID4g ICAgICAgICAgICAgICAgIDkxLi4xMjYpLiBBbnkgcHJlY2VkaW5nICd0aGUnIGluIHRoZSBuYW1l IHNob3VsZCBub3QgYmUNCiAgICA+DQogICAgPiAgICAgTm8gSSBkb24ndCBoYXZlIGEgc3RhYmxl IHJlZmVyZW5jZS4gSXQgd2FzIHZlcnkgaGFyZCB0byB0cmFjayBhbGwgb2Ygd2hhdCBJIGhhdmUs IGRvd24uIFRoZSBiZXN0IEkgY291bGQgZG8gd2FzIGp1c3QgcG9pbnQgYXQgdGhlIElBVS4NCiAg ICA+DQogICAgPiBGUDogSSBzZWUgdGhhdCBSb21hbiBoYXMgdGhlIHNhbWUgY29tbWVudCBhcyBt ZSBpbiBoaXMgRElTQ1VTUywgSSdsbCBsZXQgeW91IGFuZCBSb2Igc29sdmUgd2l0aCBoaW0uIFRo ZSBwb2ludCBpcyB0aGF0IHdpdGhvdXQgYSBjbGVhciByZWZlcmVuY2UsIHRoZSBkZXNjcmlwdGlv biBvZiAgIkFuIGFzdHJvbm9taWNhbCBib2R5IGFzIG5hbWVkIGJ5IHRoZSBJbnRlcm5hdGlvbmFs IEFzdHJvbm9taWNhbCBVbmlvbiAoSUFVKSAiIGJlY29tZXMgaGFyZCB0byBlbmZvcmNlLg0KICAg ID4NCiAgICA+ICAgICBUaGFua3MsDQogICAgPiAgICAgQ2hyaXMuDQoNCg== From nobody Fri Jun 18 06:36:29 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7913A43A2; Fri, 18 Jun 2021 06:36:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk CC: Joel Jaeggli , draft-ietf-netmod-nmda-diff@ietf.org, joelja@gmail.com, netmod-chairs@ietf.org, netmod@ietf.org, rwilton@cisco.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <162402338485.5279.11208804807970562462@ietfa.amsl.com> Date: Fri, 18 Jun 2021 06:36:25 -0700 Archived-At: Subject: [netmod] Last Call: (Comparison of NMDA datastores) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 13:36:26 -0000 The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'Comparison of NMDA datastores' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-07-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3084/ From nobody Fri Jun 18 13:10:42 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 E7DEB3A09F9; Fri, 18 Jun 2021 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 c0ig5Wb5FXCz; Fri, 18 Jun 2021 13:09:55 -0700 (PDT) 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 659D93A09F6; Fri, 18 Jun 2021 13:09:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2A44A38E0B; Fri, 18 Jun 2021 16:11:14 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ib46nNH40nyF; Fri, 18 Jun 2021 16:11:11 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 80C1738E09; Fri, 18 Jun 2021 16:11:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 399A252; Fri, 18 Jun 2021 16:09:49 -0400 (EDT) From: Michael Richardson To: Andy Bierman , "Fries\, Steffen" , Kent Watsen , "netmod\@ietf.org" , "anima\@ietf.org" , "Werner\, Thomas" In-Reply-To: References: <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> <06674cb9709f4bd6bc2af297b929163f@siemens.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] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 18 Jun 2021 20:10:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kent, my appologies for not putting enough context with my email. Andy, thanks for the clarification. As I understand, in order to add a new assertion to RFC8366's leaf "assertion", we have to revise RFC8366. Question: was it a mistake to make this an assertion, if we wanted to be able extend it? Can we do this via IANA registry in some way instead? =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+93Q3WUFAmDM/YwACgkQgItw+93Q 3WWqHwf+M4VT13L6ggV2zSq8bFmW2aWT5HiFGchexHSMy3jvNiGKADB7PLMvOIO8 7qPCbhRuHZg3xyhcf26DNxx+WhoYpqeRv2rojiSXTO65F/GRaANPhWJq78PMkXfe XE92YYeTH/KHIjU5IwIPky7EcA/TNlhSlX8l+5GmM9WJIfKqr5ShGAHqnVhOhbeL qI1ZCLVA1u8z1CtFxDkjIKhi7FGQEl9RToPlgkZLxqOBTt1TSHD8HFUdngtTjXMZ SsqVLYuqwMjaaiaoKk3SwVABGwn9QWMJCO8Jk0mSVsUBfs4jmm43GPDn7vKommy8 OVbpy3HKr3aOrJGmQP9BPmJp29JcIg== =txxC -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 18 13:47:38 2021 Return-Path: <0100017a20e0cf30-e926da4a-8fa5-44f7-ad08-21cbde8f7622-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 471D43A0C5F; Fri, 18 Jun 2021 13:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=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 r9lmvXa7wHft; Fri, 18 Jun 2021 13:47:23 -0700 (PDT) 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 739043A0C60; Fri, 18 Jun 2021 13:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1624049242; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ORJAyW1BS0fDaz03PGD991+u9dOAWmYKe9UAJZkf7YM=; b=Pd7J0c10swLngzR0Gx1BPXBShw2VFL74SijwTBdQUcOCGwlYruHudkdsgoi3XIeh GUk4WdKOIwU1q4IfHrtiVsHMZb8pt1Qj1iRSYKfEQSmz6yZyEBK/nuk6gdzuBD+V0nQ FOGM0exUsG3/4a97ur34k01OKdsqwHibJVEDkOnA= From: Kent Watsen Message-ID: <0100017a20e0cf30-e926da4a-8fa5-44f7-ad08-21cbde8f7622-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_487897D6-4C95-42FD-B4E4-87CEB484DCD3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 18 Jun 2021 20:47:21 +0000 In-Reply-To: <32390.1624046989@localhost> Cc: Andy Bierman , "Fries, Steffen" , "netmod@ietf.org" , "anima@ietf.org" , "Werner, Thomas" To: Michael Richardson References: <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> <06674cb9709f4bd6bc2af297b929163f@siemens.com> <32390.1624046989@localhost> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.18-54.240.48.95 Archived-At: Subject: Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 18 Jun 2021 20:47:28 -0000 --Apple-Mail=_487897D6-4C95-42FD-B4E4-87CEB484DCD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 18, 2021, at 4:09 PM, Michael Richardson = wrote: >=20 >=20 > Kent, my appologies for not putting enough context with my email. > Andy, thanks for the clarification. >=20 > As I understand, in order to add a new assertion to RFC8366's leaf > "assertion", we have to revise RFC8366. >=20 > Question: was it a mistake to make this an assertion, if we wanted to > be able extend it? > Can we do this via IANA registry in some way instead? In hindsight, a more extensible solution would=E2=80=99ve been to define = "leaf assertion=E2=80=9D using =E2=80=9Ctype identityref=E2=80=9D = instead of =E2=80=9Ctype enumeration=E2=80=9D, as then external modules = could define additional =E2=80=9Cidentity=E2=80=9D statements. As Andy = points out, the only way new enums can be added is via a module = revision. An IANA registry cannot be used to extend RFC 8366 now=E2=80=A6if that = were desired, it would have had to be defined by RFC 8366. A revision = of RFC 8366 could define such behavior, but then would might wonder why = not use the revision to instead flip "leaf assertion=E2=80=9D to =E2=80=9C= type identityref=E2=80=9D. FWIW, "leaf assertion=E2=80=9D is not used by SZTP (RFC 8572). K. --Apple-Mail=_487897D6-4C95-42FD-B4E4-87CEB484DCD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 18, 2021, at 4:09 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Kent, my appologies for not putting enough context with my = email.
Andy, thanks for the clarification.
As I understand, in order to add a new assertion to = RFC8366's leaf
"assertion", we have to revise RFC8366.

Question: was it a mistake to make this an = assertion, if we wanted to
be able extend it?
Can we do this via IANA registry in some way instead?

In hindsight, a more extensible solution would=E2=80=99ve = been to define "leaf assertion=E2=80=9D using =E2=80=9Ctype = identityref=E2=80=9D instead of =E2=80=9Ctype enumeration=E2=80=9D, as = then external modules could define additional =E2=80=9Cidentity=E2=80=9D = statements.  As Andy points out, the only way new enums can be = added is via a module revision.

An = IANA registry cannot be used to extend RFC 8366 now=E2=80=A6if that were = desired, it would have had to be defined by RFC 8366.  A revision = of RFC 8366 could define such behavior, but then would might wonder why = not use the revision to instead flip "leaf = assertion=E2=80=9D to =E2=80=9Ctype = identityref=E2=80=9D.

FWIW, "leaf assertion=E2=80=9D is not used by SZTP (RFC = 8572).

K.

= --Apple-Mail=_487897D6-4C95-42FD-B4E4-87CEB484DCD3-- From nobody Fri Jun 18 13:48: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 1C50D3A0C75 for ; Fri, 18 Jun 2021 13:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKiJBqLGfn65 for ; Fri, 18 Jun 2021 13:48:42 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7650D3A0CB2 for ; Fri, 18 Jun 2021 13:48:41 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id u11so4752464ljh.2 for ; Fri, 18 Jun 2021 13:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jwMWp6MKSh3AfiQSGboZ+KzRiVk+DtcKqK6V0rqaCG0=; b=dD8bL4CXtC2aQy4gfLXStQaOjz3wkk0xOe22XLyLAHTVm60sIJnXLTc00VE3PvJSCS +W3vd0CPsRPHLY+iff6F20mrARSOErYtA/pOhwxPLUEtT4aBvFgTKWMFvb1OrmTAhro7 QtIeJxmRBlOrYqepaEuubEmJsgXukYeBgkBTTeVPWpJNLN+tyDJPHOoQmkV9yRQMEdnt wpmoz10XBQAIcsCLXzhWau8107RFbIqGbcUth7bF7k3yY/rpfjmBVZ5PU03Gks/5TITb vKjjfpVVjxvyipRZNnmTOu2hIHt6xtLbYc5oYLkEFLpjiZzYjLw4jCHeI9tL8tlGR583 O8Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jwMWp6MKSh3AfiQSGboZ+KzRiVk+DtcKqK6V0rqaCG0=; b=SmYkYQw1axEeKUGkaXMG8uVRJ91AJ3pZfZY1k2FPPytb4TRWmJVCxmNaBy8fa60N5E sT7QhxWhLPSS6ZWoixNWvaQay/SrQEQwno4SYXfwfQ0jJLAnKcOFV5URLFRumdpB9/ZB W8O/vKg2cnHVaxfiZeucYeCdvAZLJlrSz5ZdxhFgfp71ULMxyfrdLYHNrHkl0JCLiNPt xue9RJTJzyZReMJ7awO5M5u9zV/5jkTyKQdAmohRr3bKu6xVxvMDHAI8phEJRapNLsp8 J5kUC2TU8BftG2kIX1gd0DG0cUcuRRhQzDGePufJjFllqZdHvzTubvM4zKiyGfHzewtz HhHA== X-Gm-Message-State: AOAM532hls/3dj6OZ/H3V9qbftZ4Rf4IgcD3oV8iHq8PwLoFWM351BNs SQHwv+v2cCbI2DlZVqAcOjCXKrqoNOIsWhectma5Sg== X-Google-Smtp-Source: ABdhPJzyJgEMdDryrL1IoBeiBkN7Gl9n+RRw4xBufwvGifKdqBCnTYN3NmTOXEjVlv+VZSyYavredZC4O+fOX3tQ9gQ= X-Received: by 2002:a2e:898c:: with SMTP id c12mr13696lji.298.1624049318593; Fri, 18 Jun 2021 13:48:38 -0700 (PDT) MIME-Version: 1.0 References: <162402338485.5279.11208804807970562462@ietfa.amsl.com> In-Reply-To: <162402338485.5279.11208804807970562462@ietfa.amsl.com> From: Andy Bierman Date: Fri, 18 Jun 2021 13:48:27 -0700 Message-ID: To: Last Call Cc: Joel Jaeggli , draft-ietf-netmod-nmda-diff@ietf.org, NetMod WG Chairs , NetMod WG , Robert Wilton Content-Type: multipart/alternative; boundary="000000000000bb9f5805c51072c3" Archived-At: Subject: Re: [netmod] Last Call: (Comparison of NMDA datastores) to Proposed Standard 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, 18 Jun 2021 20:48:47 -0000 --000000000000bb9f5805c51072c3 Content-Type: text/plain; charset="UTF-8" Hi, I tried to get a couple companies interested in this draft but it did not really work for them. There is low demand for an NMDA diff but high demand for a more general "YANG data compare" operation. The main issues raised were: 1) can only compare 2 datastores Want to compare a datastore to a backup (or more generally a URI, ala copy-config) 2) The output is only YANG Patch Want a "config" container that can be used with the "edit-config" operation. NETCONF clients cannot use the YANG patch format to edit a datastore with the differences 3) Not interested in the complex filtering and "origin" attributes Not applicable to the use-case. The main use-case: 1) make a backup of a server (or already have a common baseline shared across servers) 2) make config changes to the server and test them out 3) get a diff that can be used as a "patch" to the backup 4) apply the patch to different servers (that are running a compatible config as the backup or baseline) I realize there are no standard "backup" and "restore" operations so I am not suggesting that the draft be redone to support this use-case. Andy On Fri, Jun 18, 2021 at 6:36 AM The IESG wrote: > > The IESG has received a request from the Network Modeling WG (netmod) to > consider the following document: - 'Comparison of NMDA datastores' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-07-02. Exceptionally, comments > may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document defines an RPC operation to compare management > datastores that comply with the NMDA architecture. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ > > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/3084/ > > > > > > > --000000000000bb9f5805c51072c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I tried to get a couple companies= =C2=A0interested in this draft but it did not really work for them.
There is low demand for an NMDA diff but high demand for a more general = "YANG data compare" operation.

The main = issues raised were:

1) can only compare 2 datastor= es
=C2=A0 =C2=A0 Want to compare a datastore to a backup (or more= generally a URI, ala copy-config)

2) The output i= s only YANG Patch
=C2=A0 =C2=A0 Want a "config" contain= er that can be used with the "edit-config" operation.
= =C2=A0 =C2=A0 NETCONF clients cannot use the YANG patch format to edit a da= tastore with the differences

3) Not interested in = the complex filtering and "origin" attributes
=C2=A0 = =C2=A0 Not applicable to the use-case.

The main us= e-case:

=C2=A0 1) make a backup of a server (or al= ready have a common baseline shared across servers)
=C2=A0 2) mak= e config changes to the server and test them out
=C2=A0 3) get a = diff that can be used as a "patch" to the backup
=C2=A0= 4) apply the patch to different servers (that are running a compatible con= fig as the backup or baseline)

I realize there are= no standard "backup" and "restore" operations so I am = not suggesting
that the draft be redone to support this use-case.=

=C2=A0
Andy

<= br>
On Fri,= Jun 18, 2021 at 6:36 AM The IESG <iesg-secretary@ietf.org> wrote:

The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'Comparison of NMDA datastores'<= br> =C2=A0 <draft-ietf-netmod-nmda-diff-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final=
comments on this action. Please send substantive comments to the
last-call@ietf.org<= /a> mailing lists by 2021-07-02. Exceptionally, comments may
be sent to iesg@ietf.org= instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document defines an RPC operation to compare management =C2=A0 =C2=A0datastores that comply with the NMDA architecture.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-= ietf-netmod-nmda-diff/


The following IPR Declarations may be related to this I-D:

=C2=A0 =C2=A0https://datatracker.ietf.org/ipr/3084/






--000000000000bb9f5805c51072c3-- From nobody Fri Jun 18 15:23: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 51C303A1256; Fri, 18 Jun 2021 15:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCad8rLFdrd5; Fri, 18 Jun 2021 15:23:17 -0700 (PDT) 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 27B4F3A1250; Fri, 18 Jun 2021 15:23:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 494DA38DF7; Fri, 18 Jun 2021 18:24:35 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z1xKj4mYWWPb; Fri, 18 Jun 2021 18:24:33 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5CA3D38DF4; Fri, 18 Jun 2021 18:24:33 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B68D03E8; Fri, 18 Jun 2021 18:23:10 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: Andy Bierman , "Fries\, Steffen" , "netmod\@ietf.org" , "anima\@ietf.org" , "Werner\, Thomas" In-Reply-To: <0100017a20e0cf30-e926da4a-8fa5-44f7-ad08-21cbde8f7622-000000@email.amazonses.com> References: <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> <06674cb9709f4bd6bc2af297b929163f@siemens.com> <32390.1624046989@localhost> <0100017a20e0cf30-e926da4a-8fa5-44f7-ad08-21cbde8f7622-000000@email.amazonses.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] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18) 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, 18 Jun 2021 22:23:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kent Watsen wrote: > An IANA registry cannot be used to extend RFC 8366 now=E2=80=A6if tha= t were > desired, it would have had to be defined by RFC 8366. A revision of > RFC 8366 could define such behavior, but then would might wonder why > not use the revision to instead flip "leaf assertion=E2=80=9D to =E2= =80=9Ctype > identityref=E2=80=9D. Yes, okay, so if we have to revise 8366, then this sounds like something we should do. > FWIW, "leaf assertion=E2=80=9D is not used by SZTP (RFC 8572). =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+93Q3WUFAmDNHM4ACgkQgItw+93Q 3WXEgQgAtMqsLCdCGOdgEiEMRqd/sr5NkwizfkCdkjhTiTwyuatxvzoRAFJUb2k/ 3cpiN2Et2vYXOPIiMxE/VfOHwuXG8STWXZWGAwoDtT2kqajQP9dQ5k4Z7/wBhHpm gM/F0HIGGTeXdVNLdeBDlGfaQdB+2YQR8DiyzGNArTaiGGGUkbz+VU7IlqJIMszA J93slp4yEsYJzldfdpBYRKCzokyh9p55WXhSyza/bHmcY0IIKwq3TOmLdIySG6UE VLDCDNjfkPp7N89v+xRMx8SRJQKse6GpPAcTmKLTkUDirOJwulR6c9cY6OiGTrAX fpi34BLqcdl1tpbDVXrvnZzNktYQuQ== =06/y -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 21 01:38: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 BB97C3A288A; Mon, 21 Jun 2021 01:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.996 X-Spam-Level: X-Spam-Status: No, score=-9.996 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MU9bJROE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Nx1/b0CZ 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 MKdlpc3EDqVa; Mon, 21 Jun 2021 01:38:22 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70753A2888; Mon, 21 Jun 2021 01:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9219; q=dns/txt; s=iport; t=1624264702; x=1625474302; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=MtcPHKkn7IsUX2ain5qruebpApoWxieaOE4Y83tPpu4=; b=MU9bJROE2/IyvNUuSi5vQ7B9dVZAikDMKAfgHP880Z8bNCG440cTyo2B oqTOqrIsi4dBvSlACWQieYMnLqbbj/jro7Z9tuNh2yTuQvGUTuDdczoH7 rEaDa06b40TpsV1FwsU83hq4psCoh3zN1xAiW2tBmZ3jEGoGOmZVYgRtW 4=; X-IPAS-Result: =?us-ascii?q?A0CRAgCDT9Bgl5hdJa1QCh4BAQsSDECBTAuBU1F+WjcxC?= =?us-ascii?q?4gFA4U5iGqBEI5OikKBLoElA1QLAQEBDQEBMQ4CBAEBhFACgm0CJTUIDgIEA?= =?us-ascii?q?QEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFaA2GSBYoBgEBJRIBE?= =?us-ascii?q?QE+QiYBBAENDRqCTwGCVQMvAQOaWQGBOgKKH3iBNIEBggcBAQYEBIU9GIIxC?= =?us-ascii?q?YE6gnuKbyccgUlEgRVDgiqFCwUQGoNLggwigi4RWwYBFk0BAw0aARtWPANHD?= =?us-ascii?q?RATCA4CEgUROJBoI4wLnm4Kgx+KFIcwjFMSg16BQ4lkBIYtkDyVWIIYnTMPD?= =?us-ascii?q?haERAICAgIEBQIOAQEGgVYCNS2BLnAVO4JpCUcXAg6OHxmDV4peczgCBgoBA?= =?us-ascii?q?QMJfIlQgTUBgRABAQ?= IronPort-PHdr: A9a23:6l+CTByPDgamCMvXCzPFngc9DxPP8531MxIbrJ09hOEGfqei+sHkO 0rSrbVogUTSVIrWo/RDl6LNsq/mVGBBhPTJsH0LfJFWERNQj8IQkl8hDdKLT0rhI62iYykzB s8XUlhj8jmyOlRUH8CrYVrUrzWy4DceFw+5OxByI7H+G5XZiIK80OXhk6A= IronPort-HdrOrdr: A9a23:NHhlz6jadSLulVcIR0upXtLGcnBQX1p13DAbv31ZSRFFG/FwyP rOoB1L73HJYWgqN03IwerwRZVpQRvnhPlICPoqTMuftW7dySWVxeBZnMTfKljbexEWmdQtrp uIH5IObeEYbmIKzPoSgjPIaerIqePvmMvD6IuurAYOcegAUdAH0+4NMHfiLqQAfng+OXNWLu v52uN34x6bPVgHZMWyAXcIG8LZocfQqZ7gaRkaQzY69Qinl1qTmf7HOind+i1bfyJEwL8k/2 SAuRf+/L+fv/ayzQKZ/3PP7q5RhMDqxrJ4dY+xY4kuW3fRYzSTFcBcso65zXcISSaUmRAXee z30lId1gJImirsly+O0EPQMkLboUkTAjfZuCGlaD3Y0JfErPZQMbsduWqfGSGpsXbI9esMoZ 5jziaXsYFaAgjHmzm479/UVwtynk7xunY6l/UP5kYvGrf2RYUh5LD3xnklWKvo3RiKnLwPAa 1rFoXR9fxWeVSVYzTQuXRu2sWlWjA2Eg2dSkYPt8SJ23wO9UoJgncw1YgahDMN5Zg9Q55L66 DNNblpjqhHSosTYbhmDOkMTMOrAijGQA7KMmiVPVP7fZt3cU4la6SHlondwdvaNKDg4KFC6q gpYWkowlLaIXieevFm9Kc7hywlbl/NLQjQ9g== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.83,289,1616457600"; d="scan'208";a="710162865" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jun 2021 08:38:20 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 15L8cKaD024078 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Jun 2021 08:38:20 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Mon, 21 Jun 2021 03:38:20 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 21 Jun 2021 04:38:19 -0400 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 21 Jun 2021 03:38:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N8tg6kLCMCBhFmIcZeUM9rPvjJEX/7l8rfcH6Ra5vgE/u8gCcRy1+qx/1OloFblnS43MW2PJ98t1sr1St9m1/o+gSMvtNjhi4eYUvz2a0VcUvlpDDtUp2b16hsLcNIwQCUeYA7admoGlYPqYVaeGGFCu2GWlXIsGieHjaeozjVMJiYwTb3HBpuzqwpp3Dj+KmRCKEkP+cM9tT3IyRjNiX33SjFEoq1/5TVgd/gRLJ6bmrEjRrIwxYBGTan42uDSkfZnq1WNCaRXoRO4lKaXhFYIIe5JRvSLlh2TpcCYx6CpPZwdAP8JJnzM1SHW4YgIJtg36RCmmjpsdtbOtSNo3ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e+nt4heIpuVUiSNurkHFItjnrgEGaIVEVbkRVShnH8M=; b=cQq1JfiHSRBrlo6nG+XonARRgJVzKRD+yds9UtUx8nP+b9NdJBnNI9weBxoRbjXq1lY/8Jp4gaZeBkTcHS4n7ciJrEPx7NRzG/vPon577XVCMPKWRP4ovXQdI1CItSvOHz/3SlIQyy2tL6/axwQ5vLFs7bSLP2HcSWrByNxci4y4QmBsmCh9PXfb2OGHVFvPBsFjVl7pVs6OgZqRvJUtLy+Z/cRqsal/zhTwPKjbClPRDP4Wj/hd02YsdFdC0PBnqMnJ/9RrNCmDH2tLgQgF/gNBCUebY0OTB+9sfz1nczlAGq2cai6wMdOpHrWG+CQLf1FtvO8SG4n41VGCY0iiLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e+nt4heIpuVUiSNurkHFItjnrgEGaIVEVbkRVShnH8M=; b=Nx1/b0CZH72WxdKtYy9uKEstC9t7ZTm+CpCFJJQ0NKCSKKEa7u4DvfdK6tVFmaVM9pL5xK9M/DBPDg6vng1oq41r+H/sVL8CGOCu23kB/ylxMd/jRG/c4ryuX9rGf79E75ojTRk6kfQt4gAFFvQU28Rs2rjG3U+mwINub9S9WWU= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM5PR1101MB2249.namprd11.prod.outlook.com (2603:10b6:4:5a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Mon, 21 Jun 2021 08:38:18 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c%5]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 08:38:17 +0000 From: "Rob Wilton (rwilton)" To: "netmod@ietf.org" , "draft-ietf-netmod-yang-instance-file-format@ietf.org" CC: NetMod WG Chairs Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4Frzcw== Date: Mon, 21 Jun 2021 08:38:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5d796d06-b58a-4ef8-07d5-08d9348feb26 x-ms-traffictypediagnostic: DM5PR1101MB2249: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2EYYwEjJwo1vozEqJk9dN0cd7mUiLL2yg4Hrcog/7TSn+ScAL6IzRdwYhxcYSPKPFlJKw+WhnWqxSvW9kPgPz1W8dzCzZGtaUtjSt/l9wIRH7cyAs2Gupf6IH21jyoLPugyrheHzOdiK0hlw6l8KwO7n93pbLsnlG6QHXtcR+QfiUAIExZGs/hEsYfDqp22l1eB9j+6PVbyYS/jpAFb75UYzVWcIFCDGpRGIuFWlBc/KQ++7WaQXVk+ck6Ka6LPS07Ci8d8sI2Q6ikdVPcnLgcaluCz5LHHfyHmsCtApThqBdoL4OX7mVCIDn1HOcD+r02MXWcWpKRX7j9t3T2ZEv1PTO+nZbEAmie+pnE5/3xe8T/FybIPkMVIcNB/gu6ZFFnUp3jC8hQKplNkO4eML9VGIVXxiYtzVvK+OsZJMwYx2WQiBf/GOtPkLlWF7IRDqYa41pp2oBOyu43tKkXtptf7L8AgVgL4joKeu7toFMXwqwA03eNojXGmBsD5SAdVlax179TGciaB31kw7vAUyLBFiKyjw9WKT6KA0Sykw905n7+7ZOoOVGnYJVODF1c/N9A2rj5RA4KT41iUu2XmNDPzyOOHFDbf0A/bQ+6ZQBWc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(39860400002)(376002)(136003)(366004)(7696005)(8936002)(55016002)(186003)(110136005)(478600001)(33656002)(52536014)(4326008)(316002)(2906002)(9686003)(66476007)(71200400001)(66446008)(64756008)(6506007)(38100700002)(450100002)(66946007)(8676002)(83380400001)(122000001)(86362001)(76116006)(66556008)(5660300002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?l01y298dNJFLAo+N+ybfCr9jRnDAM6VymLVW9yY8R+jY57s9TBXO3DYDKY/3?= =?us-ascii?Q?z6lJ1XMCtD/pNDOpFUHIgB+QmqHjXRpv9qzS4hmfw5rt3qh0sBa7HS5Nux6x?= =?us-ascii?Q?OGSoTIoaiAS8WrN9GGeo/nvhb7RTCkSzYryaMlH/DD0z+uecIiVdEFqZOozB?= =?us-ascii?Q?hnyBb+5Kp+xer4I7fCLttKzD9nX9WsM6Zh+FXibMueZ3laTBJUYuVleLUlMe?= =?us-ascii?Q?9ijTZOG/9rJNdW95OGjpruq/u7OagcnS+NgwIsQahGf5BmWeJgjPGUWVOoen?= =?us-ascii?Q?CTjW1LGoAK3822Ze+AlgKzx0vf4Re2UVDxmHlSeeke9AdKIB46Pc1YjFtpnz?= =?us-ascii?Q?1bxEo/aCLNuRVO92utdqDWwlNloaVwHELW5rfOxKiCvGLQWjm0hmQFOhCReQ?= =?us-ascii?Q?THoFSHnmgvCz/MmrgTyipmxzYhyuBgewg+fs7eVEGt6YFeb7LK3EpxSxYBsD?= =?us-ascii?Q?XQ5HXmJq5dwuLKWvcU/cP0dSzGsN9HDYf5q2YuyIABxtjA3uvuJ1pPaycXDA?= =?us-ascii?Q?xivhNs7LSGrcANiGYzM50+HXnULaRVrOfx2742Z6qopt0uGz/8b/MZsfAxlO?= =?us-ascii?Q?mPJW+kVU0uv7tHvGo83dk9ZlcBvcxVdAmRumb/xVNb1pVb8Peot1bSsO66mQ?= =?us-ascii?Q?Ayj5kOB16GoFGwmJIfm803YcXKH5gvXiX9CLm48voBETRknzOuP51Ar3aM4T?= =?us-ascii?Q?slYsV5gp8iFAtCO/JMHbnaD+7IBEY12dwYg0UAaH5WnOvIorC00leR9M9D8T?= =?us-ascii?Q?PPyiqO2x1IcFZXCaQwxrksrirXWEbgVo71QyxqE1TdQCWaRv9RECOVOY/ool?= =?us-ascii?Q?TuKfKpZNIx4K1QUUOuryRm4NGDvgiuI+HpC5nioFqFsJDEf2OM6+XLpO6yz/?= =?us-ascii?Q?I3/KgEpg7yUCpqLHj7AjWl+ZO6Rpk8VAx3ScPhcnsZMV0RAz1QcrMpKrb6pG?= =?us-ascii?Q?m9coi1QbGSXJzy7IoRpADL+UUtMEyRtDd0A/bu8F73BMly4EABqgEA8oph7c?= =?us-ascii?Q?hXYJpINiAX7K4iApBtqFnHjMk9oHCVTtOFxU1gxgPbhV4jbNm3B/gC3++NOt?= =?us-ascii?Q?KuUilelMvscPEETqhty9X42b1lixxwbRhxh/qd42J2tvNVjFLkphkGCNMsHF?= =?us-ascii?Q?nj0+nD62+Jrp16xZjKKLf5qPjEZsmt6qeoViyvHGp3o5/w6ZE3qKFIUNiy6E?= =?us-ascii?Q?dPI9JLBkRZksirGHATSKAQpvkVeTDZl7EWRim9YgSCuTSRUlSZOlanmGWD+M?= =?us-ascii?Q?ilZ+LTvYs5rxQ2FlyLPqoFT5F0mBbMP57fohl5QTBtfVOSO+AMrqUxIlkN1c?= =?us-ascii?Q?Y/o7Ey47Ibw3s4aYUvFVjYrB?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d796d06-b58a-4ef8-07d5-08d9348feb26 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2021 08:38:17.9233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mSpjley4hHqOmMvNFXFePGUkhBRs0pKy7owfPt4vO2o96oEyTk4AVdoysyuzq57CVfjB3S9Eh84iYSzxsDEBzw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2249 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format 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, 21 Jun 2021 08:38:27 -0000 Hi, Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13. Thanks for this document, I think that it represents important useful work for advancing the YANG ecosystem. This document is in good shape, and I mostly have minor comments but with a few more significant comments. Main comments: 1. An instance data set MAY contain data for any number of YANG modules; if needed it MAY carry the complete configuration and state data for a server. Default values SHOULD NOT be included. This document recommends that default values SHOULD NOT be included, but there are cases where they are useful, and e.g., NMDA recommends that "in-use" values (effectively including default values) are returned. Further, there is no way for a consumer of the file to know whether default values are included or not. Hence, I would recommend that the instance-data-set defines an "includes-defaults" leaf that indicates whether default values are included in the dataset, the leaf can default to them not being included in the dataset. Further, I would suggest weakening "Default values SHOULD NOT be included" = to something like: "Default values should be excluded where they do not provide additional useful data." 2. In the YANG Module: feature inline-content-schema { description "This feature indicates that inline content-schema option is supported. Support for this feature might be documented only via out-of-band documentation."; } =20 What is the benefit of having 'inline-content-schema' as a feature? It seems to potentially add complexity without any benefit, given that the device originating the instance data file would effectively choose whether to use the inline-content-schema, hence I suggest that it might be simpler just to remove the feature definition. =20 =20 3. In the YANG Module: "case inline", description: The first item is either ietf-yang-library or some other YANG module that contains a list of YANG modules with their name, revision-date, supported-features, and deviations. The usage of revision '2019-01-04' of the 'ietf-yang-library' module MUST be supported. Using other modules, module versions MAY also be supported. This seems to make interop for consumers of instance data files hard, since the schema can be defined by any arbitrary YANG module without updating thi= s module. I would suggest that it is safer to limit this to the two currentl= y published versions of YANG library. If additional modules are supported in future, then I think that it would b= e safer to create a new version of this YANG module that documents what other module formats can be used. 4. In the YANG Module: list "revision" Is revision expected to be unique, if provided? If so, should this be explicitly stated in the YANG module description? 5. In the YANG Module: Is an instance-data file allowed to contain both a revision and also a timestamp? If so, is there any constraints on the values. If not, then wo= uld it make sense to put them under a choice? 6. References: - RFC 6020 needs to be normative for the IANA YANG module registration. Minor comments: 7.=20 Abstract: There is a need to document data defined in YANG models when a live server is unavailable. Data is often needed at design or implementation time or needed when a live running server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. =20 I suggest combining the first 2 sentences to: There is a need to document data defined in YANG models at design, implementation time or when a live server is unavailable. 8. Sec 1. Introduction: I suggest tweaking 2nd sentence to: Data is often needed at design, implementation time, or when a live running server is unavailable.=20 9. =20 Sec 2. Instance Data File Format: o a default attribute as defined in [RFC6243] section 6. and in [RFC8040] section 4.8.9. =20 I would suggest putting default in quotes. E.g., "a 'default' attribute, a= s defined ...". For the two other bullets in the list, it might read better as "metadata, as defined ..." and "origin metadata, as specified ..." 10. Sec 2. Instance Data File Format: instance-data-set-name ['@' ( revision-date / timestamp ) ] (i) Possibly helpful to clarify that the revision-date and timestamp take t= he same format as they are encoded in the equivalent leaves in the YANG file.=20 (ii) Would it be helpful to include an example without a revision-date? (iii) I also note that no recommendation is made as to whether a date or ti= mestamp is included (which I think is okay). 11. Sec: 2.2 Examples (i) Should the module name start with example-acme-system-ext and acme.exam= ple.com (ii) Would it be helpful for some/all of the examples to also give the file= name that they would be expected to use? 12. YANG Module: (i) I note that the module only indicates Balazs as an author and not Benoi= t (which=20 differs from the draft authors). (ii) "format-version" Please ensure that there is an RFC editor note to update this value if the module gets changed in anyway during reviews or RFC editor process. (iii) "case simplified-inline", description: The value SHALL start with the module name. If the module contains a revision statement the revision date SHALL be included in the leaf-list entry. If other methods (e.g., revision-label) are defined to identify individual module revisions those MAY be used instead of using a revision date. I wonder whether it would be clearer to merge the second and third sentence= s into one: The value SHALL start with the module name. If the module contains a revision statement the revision date SHALL be included in the leaf-list entry, unless other methods (e.g., revision-label) are defined to identify individual module revisions, when those MAY be used instead of using a revision date. =20 If you agree to this change, then please update the equivalent text in the = inline case as well. =20 (iv) Should the example version of YANG library used match the mandatory to supp= ort version (in the YANG module)? (v) I also note that the content schema case statement order differs from how t= hey are described earlier in the document. Does it make sense to align them? = Is one of the content-schema-specs the default approach, i.e., does it make sense to spec= ify a default for the choice statement? 13. IANA section 5.2. YANG Module Name Registration This document registers one YANG module in the YANG Module Names registry [RFC6020]. =20 Please change to: =20 This document registers a YANG module in the YANG Module Names registry [RFC6020]. Following the format in [RFC6020], the following registrations are requested: Grammar Warnings (generated, by tool): Section: 2, draft text: Later as other YANG encodings (e.g., CBOR) are defined, further instance da= ta formats may be specified.=20 Warning: Comparison requires than, not 'then' nor 'as'. Suggested change: "Later, as other ..." Section: 2.1.1, draft text: The anydata inline-schema carries instance data (conforming to the inline-= modules) that actually specifies the content defining YANG modules includin= g revision, supported features, deviations and any relevant additional data= (e.g., revision labels, described by [REF]) as alternative to the revision= date).=20 Warning: Unpaired symbol: '(' seems to be missing Section: 4, draft text: Because of this the the security considerations template for YANG models in= section 3.7.1 in [REF] is not followed.=20 Warning: Maybe you need to remove one determiner so that only the or the i= s left. Suggested change: "the" Section: 4, draft text: Depending on the nature of the instance data, instance data files MAY need = to be handled in a secure way.=20 Warning: Consider replacing this phrase with the adverb securely to avoid = wordiness. Suggested change: "securely" Section: C.1, draft text: Server capabilities include:=20 - data defined in "ietf-yang-library": YANG modules, submodules, features,= deviations, schema-mounts, and datastores supported ([REF]) - alarms supported ([REF]) - data nodes and subtrees that support or do not support on-change notifica= tions ([REF]) - netconf-capabilities in ietf-netconf-monitoring Warning: Please add a punctuation mark at the end of paragraph. Suggested change: "ietf-netconf-monitoring." Thanks, Rob From nobody Mon Jun 21 01:45: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 26C263A28C4; Mon, 21 Jun 2021 01:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.996 X-Spam-Level: X-Spam-Status: No, score=-9.996 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TPS9lUkD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qP9fta1o 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 1pEncHpxD8eS; Mon, 21 Jun 2021 01:45:10 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7B53A28C2; Mon, 21 Jun 2021 01:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10629; q=dns/txt; s=iport; t=1624265110; x=1625474710; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=jGBN9zedwM8Yi0w8V8b3jyQwS+k7IepjjxD26dcU9Ms=; b=TPS9lUkDzscSJHBGfkvAYrXdPSL0P8qpLaZOT6l92tzrkKBLPEjZFzyC AhVpUcG0WKAr69hfX1QyBfE1FvXEeQmoOmFL/RBt5J4omuPZ6R99oraOd s84F8dlxgneWjynjITSwmZDpr60l1nqQUuVgojPgOekGjcwAIamLLF46+ g=; X-IPAS-Result: =?us-ascii?q?A0AaAgBoUNBgl4oNJK1agQmBV4FTUX5aNzELiAUDhTmIa?= =?us-ascii?q?o9eikKBLoElA1QLAQEBDQEBMQ4CBAEBhFACgm0CJTQJDgIEAQEBAQMCAwEBA?= =?us-ascii?q?QEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFaA2GSBYVEwYBATUCAREBLRFCJgEEA?= =?us-ascii?q?QkEDRqCTwGCVQMvAQMLmkwBgToCih94gQEzgQGCBwEBBgQEhT0YgjEDBoE6g?= =?us-ascii?q?nuLFhyBSUSBFUOHShqDS4IugwEZBgIVGTQEFBMcEIECA0cNBBoFBw8eAhORO?= =?us-ascii?q?TmLU55uCoMfkUSMUxKDXosnBJZplViCGJ0zAxAJARaERAIEAgQFAg4BAQaBV?= =?us-ascii?q?DktgS5wFTuCaVAXAg6DO4pwDQmDToUUhUpzOAIGCgEBAwl8iwUBgRABAQ?= IronPort-PHdr: A9a23:VY2YhhA2C/kFDFxvNtyMUyQVdBdPi9zP1kY965c7hfRJaKvwt5jhP UmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBXhMIk4MaygonBsPWCEDnIrjtdSNpV MhHXUVuqne8N0UdEc3iZlrU93u16zNaGhj2OQdvYOrvHYuHhMWs3Of08JrWMG11 IronPort-HdrOrdr: A9a23:jpm+9KtpEn96SvqLu3vaQ3Bf7skC9oMji2hC6mlwRA09TyXGra GTdaUguyMc1gx/ZJh5o6H8BEGBKUmskqKdkrNhQYtKOzOW9ldATbsSorcKpgeBJ8SQzJ8n6U 4NSdkaNDSSNyk6sS+Z2njDLz9I+rDum8rE6Za8vhVQpGpRGsddBnJCe36m+zpNNXB77PQCZf 6hz/sCgwDlVWUcb8y9CHVAdfPEvcf3mJXvZgNDLwI76SGV5AnYqILSIly95FMzQjlPybAt/S zuiAri/JiutPm911v1y3LT1ZJLg9Hso+EzR/Bky/JlaAkEuDzYILiJaIfy+wzdZ9vfrmrCpe O85ivI+f4Dsk85MFvF+ScFkDOQrwrGo0WSt2Nwx0GT+vAQgFkBepd8bUUzSGqC16NohqAM7I tbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0VbWIyUs4ZkWUkxjIcLH7AJlOP1Kk3VO 11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA2PTEQOstGcl2E+pgE182IIgMgE2nsQ/pM0TJdJo+ zCL6RzjblLCssbd7h0CusNSda+TmbNXRXPOmSPJkmPLtBMB5sMke+A3FwR3pDnRHUl9upBpH 3xaiIuiYdpQTOcNSSn5uw/zvniehTMYQjQ X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.83,289,1616457600"; d="scan'208";a="730413654" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jun 2021 08:45:09 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 15L8j5J2017487 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Jun 2021 08:45:08 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 21 Jun 2021 03:45:07 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 21 Jun 2021 03:45:06 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 21 Jun 2021 03:45:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oOC2Ysv75DPmM+JvFnd8qnJ/a4btnniqsb+RMzh3dQDR7TbrV4srZLhyHTiVWTKAb/HUSCqdrhMLEHERmwzGkeFB+mareAU7Yk1jx/EcSHA6OqxzHhPXWGx+zgrO+N2fUkRaCDj/ntp+O6z3lmZO/3CmmCHrnrRWyItE2XiWEZ4g02SR6JGxZ95cDWdXn91CvBichTKvOMjOXIuNJt54OIGO8Sjiaj5HUH7xZcGXDyarwgjXXW8YiQYvomWw45PxxaIcuxLXYQAJLh2jR0/QtoKHRyu0UjAi1sMbaq63vLJecEgYTXdSqvQBVKNlNHDnWpCltTjimH+9G7/vFPAAbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=70jycd7fUrphTtQirEPbi2NuAn+6OMa5NgdCUvPb7ts=; b=CwoOCDeKdoFIg3YazfauoD9AabWwCMlrcSomOH3GZDVKw0tFECZ2maZwqPAJSdw8FrCn9ZU1Bo49/X0tPmXwhZWXv61NExT8kVAX2Dlk98asgyD0YE3rw+VORv2ECXenmeisNv0LYEvRKd+NX3gaMdj9WMjFYVAbeDqNqSIo7VbesgVNQIokDnxtTFYTZskYYz7R4ahXukhaCWaIX+9SGtp97yozhht2CEuwHow0G4t/m8wZLj+5HHmRpZfaq4FIRnKrsUtNoYdzd1LP5YC8a6uph2/KkOS54imsIQcBD3WaxMPx/BNoSLlP7Wq69vyguVMdLbnqbQtrYxxRq9UfIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=70jycd7fUrphTtQirEPbi2NuAn+6OMa5NgdCUvPb7ts=; b=qP9fta1oi7mcL9wnVVxj3HB6uCc+ZcJAUF5q5fGYgoR3mpmepxA1+nSRp4k/JYzVm/S0PMEyJt+cEhLvkDzy+dOuSCHreCyKtDzu1eSI2/kWHi3gRlO6HchX2Q+DgBNSIYiBsQHIMS5SwS4138mN34D03o6GqMIo+xIgsNPKf0Q= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM4PR11MB5341.namprd11.prod.outlook.com (2603:10b6:5:390::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Mon, 21 Jun 2021 08:45:05 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c%5]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 08:45:05 +0000 From: "Rob Wilton (rwilton)" To: "netmod@ietf.org" , "draft-ietf-netconf-notification-capabilities@ietf.org" CC: NetMod WG Chairs Thread-Topic: AD review of draft-ietf-netconf-notification-capabilities Thread-Index: AddmeRIyRipJy+knSnCwVIYs/HEmSg== Date: Mon, 21 Jun 2021 08:45:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4e265d01-c4d7-466b-dc5f-08d93490de03 x-ms-traffictypediagnostic: DM4PR11MB5341: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RzJBNhnSMiL6el6BHr+BRS2eB1Y71PNYidq4l7/kqVmNui5WRkYbdWtSVK2jUUnorKsAhlnpD40uDjDb6RULsesAAhyAF+VWfxJpRQjUhLyvPNIrQYOC8X5y3s6zSKBhfx/Kq9WFx2j/nM21OUeMxmQduNUVsgiC7tJ9oeDM/Z/TezIuDYZZ6ribV+6G2OzA1YLZcnKRpgM9pHnNfhrHFOXSW0ZjS3cqAGlLo6iCERQT+Msx4sJ8Pvth1iQ5w2MdJtvuJQDk8/2pYtLauiIlokN2qY9tMDbgDaL3z7NJ98wbIVoeUpJHaSHHlLZRYQl/6l6hcJqooXUWJ08889wOCWgYILwoDBXo8o5m5BSPWHlJ1y/BXkC+c17c91YLJm+j6WmONi2WH90C2H5kN7wPJCIXdmxa2RgLd9djROwMrpFqrNLxf4XXxZ5gAQC2hq49Q+4k26vyDoOBgFD/3LaSGOO68M7jtuUaGWz+9ih/mMOqQh3YnBcAU4aqtc0KnPUSjZhQ8ZexOqx0TWl9kYSGoZQBtm66JfTD+XgR0WRkPaydZddDIwk//QHvNjiR1pwc4bdX+MmuIOResAtgo0uRqRvveL+ra9EFhjFAJGX+LeinLGI45gR1l1TLcDogV+nPmYaAMFMmTqEHZp0/v5eBqaKrffmL010eVzSmZVzgL0vzxELr6TSd568At/E/Chq1mNzrmjmSZ2VrNIKFR/4NZIGyB/o6GY1D9xEg/KA5lSU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(346002)(366004)(39860400002)(136003)(8676002)(52536014)(33656002)(66446008)(4326008)(478600001)(8936002)(71200400001)(5660300002)(83380400001)(15650500001)(66556008)(2906002)(9686003)(55016002)(26005)(316002)(86362001)(122000001)(7696005)(38100700002)(186003)(110136005)(66946007)(66476007)(450100002)(64756008)(76116006)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?EIEsJSSzssqZF+m8MVpsWLpzt9EQMPiyttDMkDK944+jsbQH+JWdgQ/pXch1?= =?us-ascii?Q?6CK9rS+Q8f4aNmMFFuOYkq9bLcKPpuJPWJydPZhB9MaZgL8v797TYQ99QoPf?= =?us-ascii?Q?f5ikGNBMBoV71tIEkEzl+WNZVwd6p7eiBeSnn7T1DrX+Cg5h3Wz+6Kzw28D3?= =?us-ascii?Q?jsA4wD5wtGjIXy7LXIUd935Ykvw+4EVAdMyerZZGOWhcUeExtSMkAqDBkN5y?= =?us-ascii?Q?rKf7euCU2pj0vLzN5jitpHf3hjFhgDh9KHRbkdqzbE8Orf38EZlrh7f6Yva/?= =?us-ascii?Q?1SjEGrLQG2D0jJiKyedzR6Kfj7TEiy7f/YqnPpVV3KuGCRUJsAmX6EWv7Qe8?= =?us-ascii?Q?f+WmKg+dIjzR2rmNTQIGrC93eY+zLtKtbRxQaXjpnOYP6esRFd/zLvQ8Ly6V?= =?us-ascii?Q?v5hUYHOYnpEW4oHopJ+tcD1GGvIw6kntcMzEXKVvZd+gIGZfdu8qoflIrGiB?= =?us-ascii?Q?IvX2UEk14mc++FtUcoNA57wvvHdY3ITguh2zEyXyhUNbS2Ul4mnmhKNfuWIH?= =?us-ascii?Q?pa1g1xXzV1Z6++qkLh2nFFcjuq4VHQN4zw/Vdaimb7d/JXdnMWcPtxdG4qkn?= =?us-ascii?Q?aw9nPCoEysvXgI1YBpvCgbyD4wJ+t+S2i/qWel/M6UR78pRAXPfsEQwBDxJw?= =?us-ascii?Q?mvlAqoThqn6WGEUcY1VKj8GelK2pXM7B3Xg0rAfVZCitEIHhlMW3wOYHlZwD?= =?us-ascii?Q?eufby6aBq2uyEZ88AtWRzh6gq0LnM9naI56MgBh6YgIT40wZr0yemo+/eU3H?= =?us-ascii?Q?zRR+jhm/fDjFWNt93M3+EH1WAZAwNOrUwcOHHadqJnX45eZox3/b8jIHgez6?= =?us-ascii?Q?fH0XIjgBFNCE5mPWUB62tVl0nbrTOGbupCr6Ef0K8FGYkGpyv8fKIz6ObTV8?= =?us-ascii?Q?Paqkz45CMlVdNpM42DeNWIrGwH1C0kPVf6E3l+uv2OtOLeKUxg0jS+b6j6rB?= =?us-ascii?Q?se1/0z8BiXAyLxxWh9oSCCYiZELTpRErMfq0Je5R8zf8g2y1jU2068EE3VF9?= =?us-ascii?Q?Zkuy190STJ3wmIYIZjPkIYeaq4oMZOMTv4A059WsGpXfuZ7QT0pIO4/WX5Fg?= =?us-ascii?Q?V8/moJVhE22v3pWv/yS0p8k3iBFVu2nQ6YkT1n11LDWsAImKAB0kpk34JR6M?= =?us-ascii?Q?jQNZguUVL8mmUMcAZ4/iqW9Krvw4ogQoAz9czfYam1Kp7LD8m497kqthWlKa?= =?us-ascii?Q?CgDlrKBX2CD5Hsf/IDS0q9eHc7ew6gJlGB/7yNgFPxmoKIEpcKuAbc8T13Nr?= =?us-ascii?Q?Ms3H3oiELckslBhU/L6KIlKybCLIhA94oKapSweK0DAVkxlc/oZlyVUUNAep?= =?us-ascii?Q?Sn5eo+Z8mCs+DOwhhyZSgmbw?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e265d01-c4d7-466b-dc5f-08d93490de03 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2021 08:45:05.3858 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vvO2emx2jbEskR9+qJqm35axWrXKq97xBVdm09GPpqJE61JcT5osfEWgeP1vttNLbE/LNcH/YmOzjyuqHBLtCA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5341 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: [netmod] AD review of draft-ietf-netconf-notification-capabilities 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, 21 Jun 2021 08:45:15 -0000 Hi, Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16 Thanks for this draft, sorry for the delay in reviewing. It looks like it = is in good shape. I think that most of my comments are minor or cosmetic suggestions to poten= tially improve the phrasing of the text. 1. Abstract: The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG related system capabilities for servers. The module can be used to report capability information from the server at run-time or implementation- time, per the YANG Instance Data File Format. Suggest "by making use of" rather than "per". 2. 1. Introduction There is a need to publish this capability information as it is part of the contract between the server and client. Suggest "contract" -> "API contract". 3. There is a need to publish this capability information as it is part of the contract between the server and client. Examples include maximum size of data that can be stored or transferred, information about counters (whether a node supports "on-change" telemetry), etc. Such capabilities are often dependent on a vendor's implementation or the available resources at deployment. Many such capabilities are specific to either the complete system, individual YANG datastores [RFC8342] or specific parts of the YANG schema, or even individual data nodes. It is a goal of this document to provide a common way of representing such capabilities in a format that is: Suggest: maximum -> the maximum "or specific" -> ", specific" 4. o available in identical format both at implementation-time and run- time =20 Suggest: "in an identical", and a period at the end. 5. If the information is not documented in a way available to the NMS designer, but only as instance data from the network node once it is deployed, the NMS implementation will be delayed Suggest: "way available" =3D> "way that is readily available" 6. The network operator needs to plan his management practices and NMS implementation before he even decides to buy the specific network node type. Suggest: "him" -> "their", "he even decides" -> "they decide" 7. Run-time information is needed: =20 Suggest: Run-time capability information is needed: 8. o to check that capability information provided earlier, at implementation-time is what the publisher has implemented. Suggest: "at implementation-time, is" 9. To find a capability value for a specific data node in a specific datastore the user SHALL: =20 Please clarify that the capability value is selected by the relative path to the datanode defining the capability. i.e., the same name/path must be used both under the system level and per datastore level capabilties. 10. 2) If the datastore entry is found within that entry, process all per-node-capabilities entries in the order they appear in the list. The first entry that specifies the specific capability and has a node-selector selecting the specific data node defines the capability value. I'm not sure this is required, but perhaps consider adding text to make it = clear that longest path matching can be achieved by ordering more specific matches before less specific matches. 11. // augmentation point for system level capabilities Suggest: "Augmentation ... capabilities." I would also suggest using a blo= ck style comment so this doesn't get lost.=09 12.=20 Only one specific datastore can be specified e.g., ds:conventional is not allowed."; =20 Suggest changing to: Only specific datastores can be specified. E.g., ds:conventional, which represents a set of configuration datastores, must not be used"; 13. description "A method to select all or some nodes within a datastore."; "some or all" would flow better. 14. // augmentation point for datastore or data node level // capabilities Suggest: "Augmentation ... capabilities." I would also suggest using a blo= ck style comment so this doesn't get lost. 15. 5.2. YANG Module (ietf-notification-capabilities) - capabilities related to the throughput of notification data the publisher can support. (Note that for a specific subscription the publisher MAY still allow only longer periods or smaller updates depending on e.g., actual load conditions.) =20 Suggest: "data that the publisher" "specific subscription, the" "still allow" -> "allow" "e.g., -> ", e.g., " =20 16. bit config-changes { description "The publisher is capable of sending notifications for 'config false' nodes for the relevant scope and subscription type."; =09 I presume that this should this be 'config true' nodes? 17. description "Type for defining whether 'on-change' or 'periodic' notifications are supported 'config false' data nodes, 'config true' date nodes, no data nodes, or all data nodes. =09 Suggest: "supported for 'config false'", "date" -> "data As an optional minor nit, it might be worth putting 'all' at the beginning of the list rather than the end. 18. "Indicates the minimal update period that is supported for a 'periodic' subscription. A subscription request to the selected data nodes with a smaller period than what this leaf specifies will result in a 'period-unsupported' error."; Is "will result" right here, or should it be "MAY result" or "is likely to = result"? I.e., is the server guaranteeing that it won't handle a smaller update for = the given capability under any circumstance? The same question also applies to the "supported-update-period". 19. "The change types that can be excluded in YANG-Push subscriptions."; =09 Suggest adding something like "for the selected data nodes." 20. 7.2. The YANG Module Names Registry This document registers two YANG modules in the YANG Module Names registry. Following the format in [RFC7950], the the following registrations are requested: =20 This should be (along with a normative reference to RFC 6020): This document registers two YANG modules in the YANG Module Names registry [RFC6020]. Following the format in [RFC6020], the the followin= g registrations are requested: 21. 9.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . =20 This needs to be a normative reference (for the IANA registry) definition. 22. Appendix A. Instance data example #1 Suggest changing: "the running, and operational datastores" =3D> "the running and operational= datastores". '"on-change" only' -> '"on-change", only' 'reported "on-change" as they' -> 'reported "on-change", as they' 23. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NOTE: '\' line wrapping per BCP YYY (RFC YYY= Y) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This can be updated to "NOTE: '\' line wrapping per RFC 8792". 24. "only has running, and operational" -> "only has running and operational" 25. false" data from the operational datastore. Statistics are not reported on-change only two important counters, for these a smaller dampening period is possible. =09 Suggest: false" data from the operational datastore. Statistics are not reported on-change except for two important counters, where a small dampening period is mandated. =09 Spelling/grammar warnings (generated by tool): Potentially incorrect spellings: sheperds, getconfig Grammar Warnings: Section: 1, draft text: Servers and/or a publishers often have capabilities, values describing ope= rational behavior, that need to be conveyed to clients, which is enabled by= the YANG modules described in this document.=20 Warning: The plural noun "publishers" cannot be used with the article "a".= Did you mean a publisher or publishers? Suggested change: "a publisher" Section: 1, draft text: It is a goal of this document to provide a common way of representing such = capabilities in a format that is:=20 - vendor independent - machine readable - available in identical format both at implementation-time and run-time Warning: This word is normally spelled with hyphen. Suggested change: "machine-readable" Section: 1, draft text: It is a goal of this document to provide a common way of representing such = capabilities in a format that is:=20 - vendor independent - machine readable - available in identical format both at implementation-time and run-time Warning: Please add a punctuation mark at the end of paragraph. Suggested change: "run-time." Section: 1, draft text: Moreover the decision to buy the node type sometimes depends on these manag= ement possibilities.=20 Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Moreover," Section: 1.1, draft text: "Implementation-time information": Information about the server's behavior= that is made available during the implementation of the server, available = from a source other then a running server.=20 Warning: Did you mean other than? Suggested change: "other than" Section: 3, draft text: These include:=20 - Supported (reporting) periods for "periodic" subscriptions - Maximum number of objects that can be sent in an update - The set of datastores or data nodes for which "periodic" notification is = supported Warning: Please add a punctuation mark at the end of paragraph. Suggested change: "supported." Section: 7.2, draft text: Following the format in [RFC7950], the the following registrations are requ= ested: Warning: Maybe you need to remove one determiner so that only the or the i= s left. Suggested change: "the" Section: Appendix C, draft text: In this latter case it is really the server functionality that is discussed Warning: Please add a punctuation mark at the end of paragraph. Suggested change: "discussed." Thanks, Rob From nobody Tue Jun 22 04:02:26 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 481EF3A208B; Tue, 22 Jun 2021 04:02:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, Kent Watsen , kent+ietf@watsen.net X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <162435973927.21471.15597921981632790947@ietfa.amsl.com> Date: Tue, 22 Jun 2021 04:02:19 -0700 Archived-At: Subject: [netmod] Lars Eggert's Abstain on draft-ietf-netmod-geo-location-10: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 11:02:19 -0000 Lars Eggert has entered the following ballot position for draft-ietf-netmod-geo-location-10: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I disagree with the approach taken to deal with unstable URLs used in -08 for various normative references (e.g., [EGM08] , [EGM96]), which was to remove the URLs and leave future implementers hoping they can track down the correct spec manually. --- Section 2.3, paragraph 2, comment: > 3-dimensional vector value. The components of the vector are > "v-north", "v-east" and "v-up" which are all given in fractional In the formulas in the text rendering of the document, these components are called "v_{north}", etc. It would be good to use a single variant in both the text and any formulas. This document uses RFC2119 keywords, but does not contain the recommended RFC8174 boilerplate. (It contains some text with a similar beginning.) ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 2, nit: - might be the location of data center, a rack in an internet exchange - ^ + might be the location of data center, a rack in an Internet exchange + ^ Section 2.5, paragraph 1, nit: > development of this module, the question of whether it would support data su > ^^^^^^^^^^^^^^^^^^^^^^^ Wordiness: Consider shortening this phrase. Section 3, paragraph 17, nit: > describes this motion at the the time given by the timestamp. For a > ^^^^^^^ Maybe you need to remove one determiner so that only "the" or "the" is left. Section 4, paragraph 4, nit: > lts For test "A.1.2.1" the YANG geo location object either includes a CRS ("r > ^^^^^^^^^^^^ This word is normally spelled as one. Section 5.1.4, paragraph 4, nit: > value, the YANG grouping supports the ignore case but not the relative case. > ^^^^^^^^^^ After 'the', do not use a verb. Make sure that the spelling of 'ignore' is correct. If 'ignore' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 7, paragraph 6, nit: > e than standard configuration. Some of the readable data nodes in this YANG m > ^^^^^^^^^^^ If the text is a generality, 'of the' is not necessary. "Appendix A.", paragraph 3, nit: > ure 2: Example YANG module using geo location. Below is the YANG tree for the > ^^^^^^^^^^^^ This word is normally spelled as one. "Appendix A.", paragraph 7, nit: > Figure 3: Example XML data of geo location use. Appendix B. Acknowledgments > ^^^^^^^^^^^^ This word is normally spelled as one. These URLs in the document did not return content: * http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html * http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf * https://www.rfc-editor.org/info/rfcXXXX These URLs in the document can probably be converted to HTTPS: * http://www.iau.org * http://docs.opengeospatial.org/is/12-007r2/12-007r2.html * http://portal.opengeospatial.org/files/?artifact_id=27810 From nobody Tue Jun 22 05:20: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 78D853A230C; Tue, 22 Jun 2021 05:20:08 -0700 (PDT) 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 g8aSbJZQUScI; Tue, 22 Jun 2021 05:20:03 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 435013A2306; Tue, 22 Jun 2021 05:20:03 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 358B080E60; Tue, 22 Jun 2021 12:20:02 +0000 (UTC) References: <162435973927.21471.15597921981632790947@ietfa.amsl.com> User-agent: mu4e 1.5.13; emacs 27.2 From: Christian Hopps To: Lars Eggert Cc: The IESG , draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net Date: Tue, 22 Jun 2021 08:02:02 -0400 In-reply-to: <162435973927.21471.15597921981632790947@ietfa.amsl.com> Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] Lars Eggert's Abstain on draft-ietf-netmod-geo-location-10: (with COMMENT) 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, 22 Jun 2021 12:20:09 -0000 --=-=-= Content-Type: text/plain; format=flowed Lars Eggert via Datatracker writes: > Lars Eggert has entered the following ballot position for > draft-ietf-netmod-geo-location-10: Abstain > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I disagree with the approach taken to deal with unstable URLs used in -08 > for various normative references (e.g., [EGM08] , [EGM96]), which was to > remove the URLs and leave future implementers hoping they can track down > the correct spec manually. So you really think someone who cares to the detail level of a sub-specifications of the WGS-84 geodesic standard only has a "hope" of finding said sub-specification? This YANG grouping isn't supposed to be teaching people about geodesic data, they are expected to know that. Keeping that in mind, I think inserting best-guess URLs that have already been shown to be ephemeral, may be inferior to the expected readers own knowledge, in a standards document reference, seems a rather poor choice. If there is no give here, I of course will give up and put some reference back in, so the thing can progress. > --- > > Section 2.3, paragraph 2, comment: >> 3-dimensional vector value. The components of the vector are >> "v-north", "v-east" and "v-up" which are all given in fractional > > In the formulas in the text rendering of the document, these components are > called "v_{north}", etc. It would be good to use a single variant in both the > text and any formulas. > > This document uses RFC2119 keywords, but does not contain the recommended > RFC8174 boilerplate. (It contains some text with a similar beginning.) Document text: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Boilerplate from RFC8174: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. "It contains some text with a similar beginning" might be the worst one can make the above difference sound w/o actually being un-factual. I will add the missing 2 words. Thanks, Chris. > > ------------------------------------------------------------------------------- > All comments below are about very minor potential issues that you may choose to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > Section 1, paragraph 2, nit: > - might be the location of data center, a rack in an internet exchange > - ^ > + might be the location of data center, a rack in an Internet exchange > + ^ > > Section 2.5, paragraph 1, nit: >> development of this module, the question of whether it would support data su >> ^^^^^^^^^^^^^^^^^^^^^^^ > Wordiness: Consider shortening this phrase. > > Section 3, paragraph 17, nit: >> describes this motion at the the time given by the timestamp. For a >> ^^^^^^^ > Maybe you need to remove one determiner so that only "the" or "the" is left. > > Section 4, paragraph 4, nit: >> lts For test "A.1.2.1" the YANG geo location object either includes a CRS ("r >> ^^^^^^^^^^^^ > This word is normally spelled as one. > > Section 5.1.4, paragraph 4, nit: >> value, the YANG grouping supports the ignore case but not the relative case. >> ^^^^^^^^^^ > After 'the', do not use a verb. Make sure that the spelling of 'ignore' is > correct. If 'ignore' is the first word in a compound adjective, use a hyphen > between the two words. Note: This error message can occur if you use a verb as > a noun, and the word is not a noun in standard English. > > Section 7, paragraph 6, nit: >> e than standard configuration. Some of the readable data nodes in this YANG m >> ^^^^^^^^^^^ > If the text is a generality, 'of the' is not necessary. > > "Appendix A.", paragraph 3, nit: >> ure 2: Example YANG module using geo location. Below is the YANG tree for the >> ^^^^^^^^^^^^ > This word is normally spelled as one. > > "Appendix A.", paragraph 7, nit: >> Figure 3: Example XML data of geo location use. Appendix B. Acknowledgments >> ^^^^^^^^^^^^ > This word is normally spelled as one. > > These URLs in the document did not return content: > * http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html > * http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf > * https://www.rfc-editor.org/info/rfcXXXX > > These URLs in the document can probably be converted to HTTPS: > * http://www.iau.org > * http://docs.opengeospatial.org/is/12-007r2/12-007r2.html > * http://portal.opengeospatial.org/files/?artifact_id=27810 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmDR1XEACgkQLh2DDte4 MCX0vQ//TSMg0OnX1cveKSxKrMPunwZ/x9TO1o2tI48XkgVqBIpXioNqyzceO231 j7uLoy7xHpjTJRwP43a5F2RGYZOOyYG4SKUeJjBFyOo4YQIFXBLYRyadmtfuwuSm DlT+6TQAePJXndoKXJMHjaP+Rk8TfX9lHhZRKBV0igvwQ13QgMy4RZUuadH5C7FW 1tdogEkGf16R+ri0MUCOaDauOGtxusLmevpFqFqEsc+G57qafnEiP87EBYYHY5pg DwE5ZTpcRZvdrhEOy+NF7/JRAR6Vo8Fagt5jKZLIK+bdptncXhq5MA6VUn0fQ7F4 Pf9uXbbsDGMViQwIYZMccE89ntJngp7oqdGnbxLSj9s/chWQ6Dw05uOEx/5LyqDj etBen+3kALJZpzbAEiO1oe/m1+SPjywnUvV6//bAcqAM8u8MYDs0V53qWVazKtZG h7T9yDidott8uVMtqQv+/E8XzovRB9NTNNgie7LEXlm42caLdyBS2Xy4ryLcXhK+ BAs2pEBwodkD5GPkYV9Mok2TpLiIuUUhGyIENhFzmGLsQb78ifoIaMBEUVCfWNDM 8x/S9GizpzxtfCvltIqxABuSt88HqMuichz/FF+Z3KQ8QfKcBHqz7uUUgjnf8jYU s4a1M1st0Uk115AwH6qAh3SaDxAIdky2grEywgFoXLtrJCIU5U8= =VGlV -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 22 05:26: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 41C483A232A; Tue, 22 Jun 2021 05:26:03 -0700 (PDT) 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=eggert.org 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 XpjfjhhmjB8H; Tue, 22 Jun 2021 05:25:58 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 9F5333A232E; Tue, 22 Jun 2021 05:25:57 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 45CEC60031C; Tue, 22 Jun 2021 15:25:49 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1624364749; bh=oJiMHst8rvJY+QmZ2ZKT8jzYMq/VnU5WiVqjM4gq7VQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=xlStApP6RHJK644nmyrfZnmfrfPJM2sxdB68aImvMgdCWCySGxto2HDbrdg0OgAyi D2fl59FdfatO4dQ6Gt/PIK7J8qKfGASbxjkvMDmkG8Pi8pAVDhOZASbcDcIlG7sIPK /O2gG9ahvVyOihuo8RupwLPq+s6cpQZv//VkluKs= From: Lars Eggert Message-Id: <12A150FA-7167-488B-B3CE-0CAE8E39AA49@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_7255FBD5-A037-4C7B-8BB7-FCD20F6E83C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 22 Jun 2021 15:25:48 +0300 In-Reply-To: Cc: The IESG , draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net To: Christian Hopps References: <162435973927.21471.15597921981632790947@ietfa.amsl.com> X-MailScanner-ID: 45CEC60031C.A3006 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [netmod] Lars Eggert's Abstain on draft-ietf-netmod-geo-location-10: (with COMMENT) 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, 22 Jun 2021 12:26:03 -0000 --Apple-Mail=_7255FBD5-A037-4C7B-8BB7-FCD20F6E83C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, this ballot position does not block this document from moving forward. Thanks, Lars > On 2021-6-22, at 15:02, Christian Hopps wrote: >=20 >=20 > Lars Eggert via Datatracker writes: >=20 >> Lars Eggert has entered the following ballot position for >> draft-ietf-netmod-geo-location-10: Abstain >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I disagree with the approach taken to deal with unstable URLs used in = -08 >> for various normative references (e.g., [EGM08] , [EGM96]), which was = to >> remove the URLs and leave future implementers hoping they can track = down >> the correct spec manually. >=20 > So you really think someone who cares to the detail level of a = sub-specifications of the WGS-84 geodesic standard only has a "hope" of = finding said sub-specification? This YANG grouping isn't supposed to be = teaching people about geodesic data, they are expected to know that. >=20 > Keeping that in mind, I think inserting best-guess URLs that have = already been shown to be ephemeral, may be inferior to the expected = readers own knowledge, in a standards document reference, seems a rather = poor choice. >=20 > If there is no give here, I of course will give up and put some = reference back in, so the thing can progress. >=20 >> --- >>=20 >> Section 2.3, paragraph 2, comment: >>> 3-dimensional vector value. The components of the vector are >>> "v-north", "v-east" and "v-up" which are all given in fractional >>=20 >> In the formulas in the text rendering of the document, these = components are >> called "v_{north}", etc. It would be good to use a single variant in = both the >> text and any formulas. >>=20 >> This document uses RFC2119 keywords, but does not contain the = recommended >> RFC8174 boilerplate. (It contains some text with a similar = beginning.) >=20 > Document text: >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119] [RFC8174] when, and only when, they appear in all capitals, > as shown here. >=20 >=20 > Boilerplate from RFC8174: >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > BCP 14 > [RFC2119] [RFC8174] when, and only when, they appear in all capitals, > as shown here. >=20 > "It contains some text with a similar beginning" might be the worst = one can make the above difference sound w/o actually being un-factual. I = will add the missing 2 words. >=20 > Thanks, > Chris. >=20 >>=20 >> = --------------------------------------------------------------------------= ----- >> All comments below are about very minor potential issues that you may = choose to >> address in some way - or ignore - as you see fit. Some were flagged = by >> automated tools (via https://github.com/larseggert/ietf-reviewtool), = so there >> will likely be some false positives. There is no need to let me know = what you >> did with these suggestions. >>=20 >> Section 1, paragraph 2, nit: >> - might be the location of data center, a rack in an internet = exchange >> - ^ >> + might be the location of data center, a rack in an Internet = exchange >> + ^ >>=20 >> Section 2.5, paragraph 1, nit: >>> development of this module, the question of whether it would support = data su >>> ^^^^^^^^^^^^^^^^^^^^^^^ >> Wordiness: Consider shortening this phrase. >>=20 >> Section 3, paragraph 17, nit: >>> describes this motion at the the time given by the timestamp. For a >>> ^^^^^^^ >> Maybe you need to remove one determiner so that only "the" or "the" = is left. >>=20 >> Section 4, paragraph 4, nit: >>> lts For test "A.1.2.1" the YANG geo location object either includes = a CRS ("r >>> ^^^^^^^^^^^^ >> This word is normally spelled as one. >>=20 >> Section 5.1.4, paragraph 4, nit: >>> value, the YANG grouping supports the ignore case but not the = relative case. >>> ^^^^^^^^^^ >> After 'the', do not use a verb. Make sure that the spelling of = 'ignore' is >> correct. If 'ignore' is the first word in a compound adjective, use a = hyphen >> between the two words. Note: This error message can occur if you use = a verb as >> a noun, and the word is not a noun in standard English. >>=20 >> Section 7, paragraph 6, nit: >>> e than standard configuration. Some of the readable data nodes in = this YANG m >>> ^^^^^^^^^^^ >> If the text is a generality, 'of the' is not necessary. >>=20 >> "Appendix A.", paragraph 3, nit: >>> ure 2: Example YANG module using geo location. Below is the YANG = tree for the >>> ^^^^^^^^^^^^ >> This word is normally spelled as one. >>=20 >> "Appendix A.", paragraph 7, nit: >>> Figure 3: Example XML data of geo location use. Appendix B. = Acknowledgments >>> ^^^^^^^^^^^^ >> This word is normally spelled as one. >>=20 >> These URLs in the document did not return content: >> * = http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html >> * http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf >> * https://www.rfc-editor.org/info/rfcXXXX >>=20 >> These URLs in the document can probably be converted to HTTPS: >> * http://www.iau.org >> * http://docs.opengeospatial.org/is/12-007r2/12-007r2.html >> * http://portal.opengeospatial.org/files/?artifact_id=3D27810 --Apple-Mail=_7255FBD5-A037-4C7B-8BB7-FCD20F6E83C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDR1swACgkQVLXDCb9w wVe0FRAAgAvx2H+CIfEKiFnAm/Fdpxgnmu2Q+nLaq39j1sWVwZ6MSKYRSuCUcKpN +Sfvq8uBmx3ytEAIEXe8dZMYymQCDYihWvZ/Mh4vUHH8sFswjMwQVJ+K7UWjGdTV P5MQm806hPOsHsMt4KY1UgClbIxZ/5vPlnbTtAzBaDVfQdtKzrjvjYTrVT9pQPRB 0FEsG02qLxBmfuGMQiLv8ldTqkXtT9YuB9gbt2sEfD9Ena6+3Q6oUjbq/C62T1UZ /T9Do9B1YybNEWKYz6A2ysPNGu5BFufUtFgdDt25HHkGP2+s6m2o5+03YUYzXTLf 9GveeZGl3JG8xOWAWffKm3c35d2spiTYH844ynin9lGKp2yBZOcRdCYZV1k7E6Zs UmZiY1pre731tZR/wZQGV+Sh4983W1PazJ3uGFvciSHSFCxGnVslLvnXWBrJSWga WJUlNzzvowVjRXvmU13bfgxSkfa2GjXI4aMQsbyhtpcM+TDBlqZWdyrxnEN3SqOH t8nI5j6pYbZNHCds1VXctcy8RVnn4je3KvOkTndVNRIXqAx2hNaEuxpvMQgrbbGZ g0GGdGaQQIrj4yGe8tJ5bRQHZXO3E/pZNXTRIAR1dxd8JzeMJvpXB6ItRW8OjoS/ eiIjU+nN+sBLJGBD/ANNcwuwo24QvXVEru6Ocjk0bXotbq6yRlg= =H8Gp -----END PGP SIGNATURE----- --Apple-Mail=_7255FBD5-A037-4C7B-8BB7-FCD20F6E83C7-- From nobody Tue Jun 22 08:38: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 322EA3A08E4 for ; Tue, 22 Jun 2021 08:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9VPc6v4M_LY for ; Tue, 22 Jun 2021 08:38:05 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2134.outbound.protection.outlook.com [40.107.237.134]) (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 9B6C63A08E3 for ; Tue, 22 Jun 2021 08:38:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BLVb6z0BRiTAekSir2ar+BjINIz0su0pON5eq8z59X2131G8DEHjkM3avg0DFnuJy9T+RhoSUL4/eDwynWO0ZHnvOXtCKdTd7cVCEHyeb/J/S2VIu/aBSYuG8B6dsBJfhHSvEjWt3hm3DSxCLCW/pxfF7LFx099KO8Ypd6kzDE5NHQaIwwyhc0bCohCZBe7YDZArLRvSS89p40cFY5K62t0Q1X0co1PBixUyfWYrNHRtSemcieTc1rPQ/sJwvvpTf4pPg5/Mwpoyfi8S4BZx7ja9g0evvqZfoyOFMxtNXfQUEGWChwWxHaMTwq6jNr+5TIFyMNQGIhOHU1Pb9nFL8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2IczMGr3YfNzjv72+YVYecy+A+ZM7KlxoNziCBO5hm4=; b=cA6DJK+VL73C2l/XNgDX8NR8hpVPFn/fcj25gxwE/rFVoH1Zs+yQaIzoZZWzzWXDF/j8F27mBDxPHQ/IV2Ecr44p31VlFaG+2q9SZcRjwTJMPUuQb7qD5dnJwDO28NjOe83NgTA6EBP1e7I+17irNaFaa40tVAefD98giOP+/OIUQ39ZmPZdi90zGnwy5dCO1/bQLS0aA8oIGoCIMGnpGOQSb7dyMNjIPbjjUqleC/X/o/Ad9PPE675uLNv7WyxYeW3L386JH10KBSGD81S3sMxXo6yOpKixQ7mXHzOu4Km2hsreUlF/pOOIZAWNymfNaVqi34oF58NWzr3W129ESg== 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=2IczMGr3YfNzjv72+YVYecy+A+ZM7KlxoNziCBO5hm4=; b=CaGLFoJD2BhSIRXQ1UiydX2TcPM9aYuaHVsbtEouggXUpmDHvfo16+3yYyVV4OfNukVx/VtqsIYIu4jk/Puvzu2+kZ9wb9ye3BQiWerE6KLgclUBu97iw4BKS7OvzXQgv4JpCQHDdkNpKW1lS09J7gjyGZlhgS563mkJQr3Qt/c= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DS7PR08MB6880.namprd08.prod.outlook.com (2603:10b6:5:38f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Tue, 22 Jun 2021 15:38:01 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::f431:78d:76de:1ba5]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::f431:78d:76de:1ba5%7]) with mapi id 15.20.4242.023; Tue, 22 Jun 2021 15:38:01 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-06-22 Thread-Index: AddnfHhRXxO05yFFRUmrjtX4fkMkJQ== Date: Tue, 22 Jun 2021 15:38:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.25.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: af925268-7198-49a5-9ad1-08d93593b85c x-ms-traffictypediagnostic: DS7PR08MB6880: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dfRTj4IUEHozZtvg4KNY6vKTc76g+K4DL6ADDP3+NJL6UmegtQN1e2aUM2lV0DLRH4Y62OqsCCyThJclUBQ3jXqnCd7FEMirnT8MmbW8DM94kV9LPF6UqBL/8Lw9sgPj9AVMY+gqeSOWsxzIUOIfNbt6hqBAZAwpypmLgTpqW8OxC2UGSqBjts6A16LjOP1y0+5QTeQKSsNwTu9YASHDI7C7sGquAzpOp7PH2lpWBHl+j0pShNrK1PM3nV8+a84N16X25lTxk6SNhJMhFGoLcNfLiuas/gkYsHOYYCNyLF0KaUEQUxkVE47AL1ldRPxxObwNxLvvSv5m5aV/kbFSleJyHmKKq7NATwIIpMmCZmJCVlmuG0URcsc4LTL9CqT8QVVhc0c9jddvf6bAq5ZLVrF59S2fcAksmU0g58TjouaglxPDo31g14FALA77vF5eJojNuMccvsoPQloMweik8kkzD+FQYuCWONYrtxtToZOo2dyIzsnpouUxNRs6DCRCx4kKoPMLEd+EfL+e7qWDQpkgCOW0PEALF77xU0L0u68dBFKeyxi2AoZCWJ5TO3qVA4c6+XpizoG8uKzfKuiY3ghTKr7n4I+F2e18ckOAktmJgYKkaZqGimFXUWo54eLHTCBNUm/xDxpNFkBva5x/yF7xeOx3NqONOI8aGpi1DPTo789a65ieZKnzSrwXymnMKWjJkgE5MqOBRgy8uYh6i9PINzH2K5EFCrujNj+2HnE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(376002)(396003)(366004)(39860400002)(6916009)(33656002)(966005)(71200400001)(5660300002)(122000001)(38100700002)(2906002)(83380400001)(52536014)(66556008)(64756008)(66446008)(55016002)(76116006)(26005)(7696005)(6506007)(8676002)(86362001)(8936002)(478600001)(316002)(186003)(9686003)(16799955002)(66946007)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QZ5hcWbW24ctU+4pz7JhtUabs00eyG8T+6yWYN1fCeGneZJ+dZ4gCayC9d2h?= =?us-ascii?Q?/sTRAI3yRA3tZcpD39fSx6JnxbMMX0sRJ3FFcMCFlzeCCGTk6qX321gclKo3?= =?us-ascii?Q?bViXMShOKbooaJwpiyZr191kz8MLbprGOHJ5LcjHKbsK1pgNn1RYehJnA/4n?= =?us-ascii?Q?VLSZlxEmgpzCuIIasSC47kKXe7ZBkdb2KNrUQXWvsFRrwy2w50OtJtgGDdom?= =?us-ascii?Q?nsqNFl1bImTueuVROmL/10NxaRwsY60Id3HpWz8CR5V3bIRhesgA3VXEZD6U?= =?us-ascii?Q?VzDPzUcSl9kVEVWx1DFUZmwg/nKcpDyLl+YGqkDA6S4E2COJtyCZmiPDA6OO?= =?us-ascii?Q?2Wfz4vCjscseFXGUflQzbooYmetnp7MufaUg4SdC+e+ro2PbsuyKc2CRHgEL?= =?us-ascii?Q?R9t/MwanFGXxd6PIX8zVA33ARWEvSDyeu4suNyy9D0wUx5+3ApX7PCKzT/xo?= =?us-ascii?Q?ry5wdnjAzZmh21K9GZncawg+hL/PzlXrcBBXdbc5VQyBigjoNKWX9hB+Loqz?= =?us-ascii?Q?CnOKbfO2l26XizvE4gf0nBDch3WAb/zxzOvNqrb+tSqZqzoTa5RQ/QJ+2j8g?= =?us-ascii?Q?cciCzqxxmGWNciNqgYhfvQp6yWNNX4+pwJbVLNUTwEwGqXvBWFtSxd70aJeZ?= =?us-ascii?Q?qnVDWY+cKzl0Ybfyz0ONtPoQdOyv2usQupvSfDuTaLPVZy9VUs/1Nj8/eJaW?= =?us-ascii?Q?dB/8z+lTsD3ZAEfyBXXOcCorQMaRisM3VIxOGnb7LzA7jGaCrcY+3AC2p6Ev?= =?us-ascii?Q?UiK2Evq0+uBCPuCHD61Ikzd2jtAEqESdYPWBEGi3PAkP8TusoCALof8LIn5y?= =?us-ascii?Q?+EBxxQcoKgIsaz5VJrQKMnbEOD3vR5G0KQWIGCn9GrH4662sITpg3P/F7Fwa?= =?us-ascii?Q?ZJeCwqR5QCfy23BM9TTLk08pX2YLET+6vFAQZY/w5r4I9WT83CYRh2PbGKrv?= =?us-ascii?Q?kq1CxIrX6qZ8yGoteSVTEfNEHw0Zx1mp2DSuZ/80lXwGGwtAaNHysPGsB0fn?= =?us-ascii?Q?Wdir45CC3iEGGriVi6kMitKAuP9fDmY21Kojuqy9cJ2RNroaGngX11F7AHvr?= =?us-ascii?Q?sLLetxCqyVsvfz9YvbLsy9sSW//V2uRf5ldJJmUJIKIFERA0uLaU//TAdJsW?= =?us-ascii?Q?EEtLIUKoxpvw4Wg/4D2VL9m+2h62FGASwmG1uADC/8ZDuOzdKV1zxnMNlzJt?= =?us-ascii?Q?PGzZf2VpunaCKWXz2JiBEHE0Aac7V9bRubg5peVFfp2LZO68iSuwQdqzVMFB?= =?us-ascii?Q?MVJbOF0+2BJd91bBCRZXvU1GXln0SV91VYqs7iOR7rIhytcnjrGLtv6OXDEg?= =?us-ascii?Q?E4QGYgi6fa3WNBHqAZxnuAMn?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084A5D7EB996ABBC6E91C389B099DM6PR08MB5084namp_" 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: af925268-7198-49a5-9ad1-08d93593b85c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2021 15:38:01.7737 (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: AwNiM7zsh7FmxnOTTGsJB71ojbF5bkrcafLZe+hzJw24woiFwx/+oTX1d3T5MlfBGapvFZisu/a218phKYgt2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR08MB6880 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-22 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, 22 Jun 2021 15:38:10 -0000 --_000_DM6PR08MB5084A5D7EB996ABBC6E91C389B099DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-06-22 Activity from the past week: - Rob's grammar fixes (already merged) - use of module/submodule (sitting as pull request) - *include* by revision label (leaving it out) - NBC rules for 'default' statements (leave this as per 7950, no clarificat= ion. This is because without a default a client must treat it as ambiguous= and when adding a default that old client can continue treating it as ambi= guous. Removing a default would change from known to ambiguous and is NBC.= ) - err on the safe side with NBC tag (guidelines) - Rob's comments on Module Versioning draft Left off just before RW7b in Rob's comments. Action: look through Rob's comments on Module Versioning Reshad to merge module/submodule pull request /Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB5084A5D7EB996ABBC6E91C389B099DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-06-22

 

Activity from the past week:

- Rob's grammar fixes (already merged)

- use of module/submodule (sitting as pull request)<= o:p>

- *include* by revision label (leaving it out)<= /o:p>

- NBC rules for 'default' statements (leave this as = per 7950, no clarification.  This is because without a default a clien= t must treat it as ambiguous and when adding a default that old client can = continue treating it as ambiguous.  Removing a default would change from known to ambiguous and is NBC.)

- err on the safe side with NBC tag (guidelines)

- Rob's comments on Module Versioning draft

 

Left off just before RW7b in Rob's comments.

 

Action: look through Rob's comments on Module Versio= ning

 

Reshad to merge module/submodule pull request

 

/Jason

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

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

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

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

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

Tap to join from a mobile device (attendees only)

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

--_000_DM6PR08MB5084A5D7EB996ABBC6E91C389B099DM6PR08MB5084namp_-- From nobody Thu Jun 24 12:13: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 683F83A27F7; Thu, 24 Jun 2021 12:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, 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 uq-zLzdY4chj; Thu, 24 Jun 2021 12:13:15 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2116.outbound.protection.outlook.com [40.107.243.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7E53A27F5; Thu, 24 Jun 2021 12:13:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OkZj4KAC9+UUVb5Y30qTAUqf/ukTbbCGg/KdRw1LjPzl7vaW8WiSJTbGDsPvPVlEZmK+XTRdAoDskXLCJ2HMfKmaPMNUBJneuRJqHnjeENbeTr6TH+dENpw2gJu+YurkB+RcBRd8hpRs0DP1vBE/OhSRnMh886YBF2bzm6ykVANJplv+P1p+QYlxfYurqd8m7Z2ICjOFyM8O0mG32L+D6anP6B2PPOfKQ0VMT3DcApYpcIJjt9G87+EADPX1GnUKKYOsgD0rN92HGQeLbprb+wt2IWOeBmiuycDT+Q5cWWV4QI4Va675FHLR9nD7CfMn2iwMC7i+HgfdyPa7i8u1JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=31DggCn6ETyCYEPgdecxBvieAVwKUUKe2c2xwxyTajA=; b=DimHHQLwb50U2WW+YDLzIt3EvIrjk3TFWt3hzvYsYu0HJKszZKQKyfPn/XUhGaTYa9XAxGiR6sY6SS2W9YsaziI6yPQ0wNi8TEE1/tIukT1KL3KB8G0vxsa7PSSmyk51fMO3NGJF1V0z9k6nsA0pLgfkyK71czLBjRPt7V5nDf9rkeUi0TI2A4zJiEwpBqjr9vjbeNcvSYBCws6D9Dgmvyr2PIfiP1kCumdfjz8np3jg0TDp4VIzxxQko8Jtb/KNZh8Bo+hopi0uZkELhsjwjlLNBGXN2/0r2D5IzM4BAC7YcJGqS1CNZc4kZDfjSQiFmAHnveYa2dC1g7U/sSLZNA== 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=31DggCn6ETyCYEPgdecxBvieAVwKUUKe2c2xwxyTajA=; b=Qwin73jaSX0hCWArRYlrU907lUhe9csVUcNL9VPILGlkMlZT7eMyoDkVkms8vUqeZhtHTE2V0rQ5GQury9NeURaQKEkJ4HEWtIyUtkTD/3ALpFbmZr6/jmIeQF0hOSMVFji7JZTr+WGtwx9xHbh3Eq4IuNwe/ZJkrbysyESz5E8= Received: from SA2PR08MB6524.namprd08.prod.outlook.com (2603:10b6:806:117::10) by SN2PR0801MB2174.namprd08.prod.outlook.com (2603:10b6:804:11::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.20; Thu, 24 Jun 2021 19:13:12 +0000 Received: from SA2PR08MB6524.namprd08.prod.outlook.com ([fe80::70b4:9e01:8385:1400]) by SA2PR08MB6524.namprd08.prod.outlook.com ([fe80::70b4:9e01:8385:1400%7]) with mapi id 15.20.4264.020; Thu, 24 Jun 2021 19:13:12 +0000 From: "Cumming, James (Nokia - US)" To: "andy@yumaworks.com" , "last-call@ietf.org" CC: "netmod-chairs@ietf.org" , "joelja@gmail.com" , "netmod@ietf.org" , "draft-ietf-netmod-nmda-diff@ietf.org" Thread-Topic: [netmod] Last Call: (Comparison of NMDA datastores) to Proposed Standard Thread-Index: AQHXaSygDwHnUle4b0ikjU+qLddlHw== Date: Thu, 24 Jun 2021 19:13:12 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.20.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e8ad39e-8009-489b-f5bb-08d937441c98 x-ms-traffictypediagnostic: SN2PR0801MB2174: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GO4/DJ1Qa7hunFGAY8ef+sM7ogCxfauMjrYknJ3KXeZQw3jJiQND8fiDaFkORNHnQPebRzAzjjO2ok6gkKCztQkqTdvxr3FDfDky6mjfhdSlGTbx6NGKFBUgIuWVE+Ucy1EsjI3AMcp1rzdw2fEQBeKnh0LCb0tVZ1rewXNHRkDWLXADzgEcSAUu4rViazQh1P4XMdysHa+92ns1hL60aMLnAyQ6lBhbuzwlT2qS+TmLdgEdwvNiGI4f0th8ywQUpFKw/PDusKo6E5Q1Jll5CgGiGUk1oWX4OylA7FKz820o5H1SQMpTxL/o4vi8qPRl+CD2l9F/94ngF8MEVJzVLLK5Ke/RCxP4C1dxv8dWoo4lX3z3xdZIOYsyVYzz/by6VRd3+k0qKi9GO+XIsXiUr+6Xq8T7KcZ++977Jqc39znv7MgMLKyRmSYEDn3vS+JjyR0i7cmrOAjOHkMsql4zke85pXqfCEDXRjTgRC7j5FLwWZoWldDkHZX5nyyDXtS/teaJkx8rQyLr8iy+KELY/gv2+IdXl/ki/ViEpqM2Z1mY8hYax8L+0l3KbmrhFrdNBpJq++FhQ2zZvPd8MXqI1SSQjTiiq37qbMINyJHUVq3WQDd8fNgerhDXIrOpHTYYLtlWuzK+crDzuApyNdS9q+zTPHv+VdaoF0N6FPOEHZ4yKQnKn7uwJxyEqob370hZHUybs8V+7gklJxtuNCo8FZvFKY+InV3mPHSQSF+VMbVZJpimUmNnQD94nSC61wGF x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR08MB6524.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(9686003)(66446008)(9326002)(76116006)(91956017)(5660300002)(66556008)(6506007)(64756008)(53546011)(66946007)(186003)(52536014)(966005)(26005)(66476007)(4326008)(110136005)(2906002)(54906003)(86362001)(478600001)(71200400001)(7696005)(122000001)(316002)(38100700002)(33656002)(83380400001)(166002)(8936002)(8676002)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?KlEaQBuJGlvcuVpCVAAP61RTYFbphfh0/LnPGa36I8wwLOliBUMDB9Vluy+G?= =?us-ascii?Q?1XKY3lW3UnSYDgtHBybO72EwTqVha++YwqLB0PFAJm3+BWAmsmXIrMjpf68P?= =?us-ascii?Q?U5pcAscBlRtkvWEUJhQzEDgjtmT6dOfNsOZoe6ePvoTEoOXLM6gkB9P5HA+D?= =?us-ascii?Q?Ti1MdD1Vk9agdOhqhgXa4YrFxXoiyMLc4R3Fij3Kf0rzRIOV8OadFSt8GKDI?= =?us-ascii?Q?ftePaoWevu5pjozNheYejjH6uYkrYEpggiwjZkvmhS92VfGoAP5ln7tRpe+y?= =?us-ascii?Q?YkdC7eiHtv7OwUgOSaXceiPhHNIbBFqOYSTq1vZMlIpCfYUnfCr0MeX9fIPj?= =?us-ascii?Q?+B6zvqGgJd6Uyzj04xNn0CmMm4901gX7HoiHSVrJroS4Xen+qJc2E3uuvQXr?= =?us-ascii?Q?j6DsjOIjGOpoHQGZmWc5HY6Ty4Z9Ir+qy7qYiolwv9nN4sJnJLd6lukKI4IR?= =?us-ascii?Q?SZPYRhtqcSQVnAuZWy7xrhLjBcZe6GuYjluErRG6ZlA5urPI12WVkuan7Jc5?= =?us-ascii?Q?tbkPlSPb+6HaflQHka526z0DI1CGFLXbG3zgHPbDC+HFC20zz3G8H/nporUZ?= =?us-ascii?Q?Hj2wLjOKj9hetrAB1s/41G9NP+NTFJNuUIBJZbEfLqtvjqB/inrJdaQGcdmH?= =?us-ascii?Q?BGYnIgQsbe8NfFIiYoXogceIpzvkjrJbk2T1gGs66GXwEVt75YsoX2j4muAO?= =?us-ascii?Q?v+5qj6CVFBXg2lv05R9Pz5rJ1KX5rD2t6GSgyxurqpGWjidPxZ7nQIgfVNBY?= =?us-ascii?Q?AjLZmyhDhtV4RMg8BE2MYvvNRcoKghaJO8LzIR98NFTD6ZUJvisnm46yhEkt?= =?us-ascii?Q?LSS28KRZwYdO7e3BnIyrNVkPWsNInRUB8xuD9YoSpvOaydb776ogts4nUmPY?= =?us-ascii?Q?uaXlzNgK8fdp7Lz4/sTgxG++n45H+LB1/1/kfh+NAHLCE107FyNdj1EIdYWb?= =?us-ascii?Q?UV6AxV3/d4ZFksav1WRliLixqLF3GdDm4tGS+OsfFhJk+5hwMscPoEzMUdwE?= =?us-ascii?Q?anj2pMZs6SsquFIvOYFI/4a3wLbBpJqNgN13szeLz5AJvr8sTS9zGlC+B1p5?= =?us-ascii?Q?6LqdHMJ2OnnRW4gTFrn6BbLuuAQeSGb737skNxjzSUcbUSXWd5KOSdTUXg+J?= =?us-ascii?Q?ZAAblCVplrnZ01/z3OPD2szDAcPE1EZ8OHxjCOHNli/m3AbogtnBhtAV8O8y?= =?us-ascii?Q?zItQ4gq6265hkMW5xT9nYeetybD6sjcWuOgnh4I2Gv4gYsowGwhdQYBw8uHT?= =?us-ascii?Q?+TvI5AWrWq3FGFogs2RmxC+QVC/DB/sTU90coHSTc2992kiYTF/QEr76g2O6?= =?us-ascii?Q?PYEV/jiftIYk+Wsa1RWqrmAbgww6XI5PHZDMzVQF9AdEyA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA2PR08MB6524B8A1B37E997C395C2914FF079SA2PR08MB6524namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR08MB6524.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e8ad39e-8009-489b-f5bb-08d937441c98 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2021 19:13:12.5332 (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: LFwUb9cqRSC6+0Fncr2FWIVlDNQC2RW8tonmKLxCSmVFeOgguXD/HOLIq0445D5NJjL+JwupIK/1Vz1C4T2kzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0801MB2174 Archived-At: Subject: Re: [netmod] Last Call: (Comparison of NMDA datastores) to Proposed Standard 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, 24 Jun 2021 19:13:21 -0000 --_000_SA2PR08MB6524B8A1B37E997C395C2914FF079SA2PR08MB6524namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have the same feedback as Andy on this one. Thanks James From: netmod on behalf of Andy Bierman Date: Friday, June 18, 2021 at 16:48 To: Last Call Cc: NetMod WG Chairs , Joel Jaeggli , NetMod WG , draft-ietf-netmod-nmda-diff@ietf.org Subject: Re: [netmod] Last Call: (Comp= arison of NMDA datastores) to Proposed Standard Hi, I tried to get a couple companies interested in this draft but it did not r= eally work for them. There is low demand for an NMDA diff but high demand for a more general "YA= NG data compare" operation. The main issues raised were: 1) can only compare 2 datastores Want to compare a datastore to a backup (or more generally a URI, ala c= opy-config) 2) The output is only YANG Patch Want a "config" container that can be used with the "edit-config" opera= tion. NETCONF clients cannot use the YANG patch format to edit a datastore wi= th the differences 3) Not interested in the complex filtering and "origin" attributes Not applicable to the use-case. The main use-case: 1) make a backup of a server (or already have a common baseline shared ac= ross servers) 2) make config changes to the server and test them out 3) get a diff that can be used as a "patch" to the backup 4) apply the patch to different servers (that are running a compatible co= nfig as the backup or baseline) I realize there are no standard "backup" and "restore" operations so I am n= ot suggesting that the draft be redone to support this use-case. Andy On Fri, Jun 18, 2021 at 6:36 AM The IESG > wrote: The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'Comparison of NMDA datastores' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-07-02. = Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, ple= ase retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3084/ --_000_SA2PR08MB6524B8A1B37E997C395C2914FF079SA2PR08MB6524namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

&nbs= p;

I have th= e same feedback as Andy on this one. 

&nbs= p;

Thanks

&nbs= p;

James

&nbs= p;

&nbs= p;

From: netmod <netmod-b= ounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com> Date: Friday, June 18, 2021 at 16:48
To: Last Call <last-call@ietf.org>
Cc: NetMod WG Chairs <netmod-chairs@ietf.org>, Joel Jaeggli &l= t;joelja@gmail.com>, NetMod WG <netmod@ietf.org>, draft-ietf-netmo= d-nmda-diff@ietf.org <draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-nmda-diff-09.= txt> (Comparison of NMDA datastores) to Proposed Standard

Hi,

 

I tried to get a couple companies interested in= this draft but it did not really work for them.

There is low demand for an NMDA diff but high demand= for a more general "YANG data compare" operation.

 

The main issues raised were:

 

1) can only compare 2 datastores

    Want to compare a datastore to a backu= p (or more generally a URI, ala copy-config)

 

2) The output is only YANG Patch

    Want a "config" container th= at can be used with the "edit-config" operation.

    NETCONF clients cannot use the YANG pa= tch format to edit a datastore with the differences

 

3) Not interested in the complex filtering and "= ;origin" attributes

    Not applicable to the use-case.

 

The main use-case:

 

  1) make a backup of a server (or already have= a common baseline shared across servers)

  2) make config changes to the server and test= them out

  3) get a diff that can be used as a "pat= ch" to the backup

  4) apply the patch to different servers (that= are running a compatible config as the backup or baseline)

 

I realize there are no standard "backup" a= nd "restore" operations so I am not suggesting

that the draft be redone to support this use-case.

 

 

Andy

 

 

On Fri, Jun 18, 2021 at 6:36 AM The IESG <iesg-secretary@ietf.org> wrote:<= o:p>


The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'Comparison of NMDA datastores'
  <draft-ietf-netmod-nmda-diff-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final=
comments on this action. Please send substantive comments to the
last-call@ietf.org<= /a> mailing lists by 2021-07-02. Exceptionally, comments may
be sent to iesg@ietf.org= instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document defines an RPC operation to compare management    datastores that comply with the NMDA architecture.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-di= ff/


The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3084/





&nbs= p;

--_000_SA2PR08MB6524B8A1B37E997C395C2914FF079SA2PR08MB6524namp_-- From nobody Fri Jun 25 13:41: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 01E9C3A0E29; Fri, 25 Jun 2021 13:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZTZ-wi3x6vt; Fri, 25 Jun 2021 13:41:13 -0700 (PDT) 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 10D8D3A0E28; Fri, 25 Jun 2021 13:41:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8652838BF2; Fri, 25 Jun 2021 16:42:59 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C1NSYj2BMalh; Fri, 25 Jun 2021 16:42:57 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 44CB138B9F; Fri, 25 Jun 2021 16:42:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B8B40553; Fri, 25 Jun 2021 16:41:08 -0400 (EDT) From: Michael Richardson To: Toerless Eckert , "Fries\, Steffen" , "anima\@ietf.org" , netmod@ietf.org, Kent Watsen , rwilton@cisco.com In-Reply-To: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> 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] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 25 Jun 2021 20:41:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: tte> https://trac.ietf.org/trac/netmod/wiki/YANG_FAQ#when-use-empty tte> Is this the solution we are looking for ? here it the relevant text: } The second situation is when you want to define an extensible enumeration, } as an alternative to the type "enumeration", which is not extensible by o= ther } modules. For example if an enumeration is used: } leaf protocol { } type enumeration { } enum smtp; } enum pop3; } } } } } and we want to add a new protocol 'imap4', it must be done by adding a new } enum in the module. But if we use a choice of type empty instead: } container protocol { } choice p { } case smtp { leaf smtp { type empty; } } } case pop3 { leaf pop3 { type empty; } } } } } } } then another module can augment the first: } } augment /foo:protocol/p { } case imap4 { leaf imap4 { type empty; } } } } Well, this seems to be exactly what we want. Do we get to put a description in there? can we put a value in so that our SID process works? (I imagine we'll have to hack pyang to make it cope, but...) proceedural options: 1) write this up as errata against 8366. That seems a bit much for errata, but how much whisky does it cost to bribe an AD? 2) write a formal "Updates" RFC8366 that just does the NEW/OLD version of updates, and that's it. 3) do an entire RFC8366bis. =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+93Q3WUFAmDWP2QACgkQgItw+93Q 3WX+HQf/cq+4cZ5epJqMxF/QVRnNhgvCZSkJGRH+9ajLQyVgvk2FYOgMPnPuaU5t 9CV6WJ8Ylk4ZOQS1qZ6XIz8jk40S38Q0NTS/M6gsoxee5kMyc+TsF7b5twBUspVw oFlzxie2qFXxmKNUsDkhyH3kzpXjZYNSw+UiJlfC12Rk168rKW6zFntiyDctjAbM a/v7004upqgcKsr9JzuWsRHZ2M3KmZIoBlAyGDazLAjrgTLocMUtibkBPzHGst/J mBQrMRQRQDixMgwgqAipjUREOaHb+7G625wzDTJd++jREUJmN6pgQBbWNmX8OKHY GWfwO7bO47Mn2+qfrT25nc+Oul9YQw== =QjeG -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 25 15:48: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 A1DD53A1019; Fri, 25 Jun 2021 15:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 FpLz4cuihQp2; Fri, 25 Jun 2021 15:48:18 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64C93A101F; Fri, 25 Jun 2021 15:48:17 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 830C254804D; Sat, 26 Jun 2021 00:48:10 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 77BE64E787C; Sat, 26 Jun 2021 00:48:10 +0200 (CEST) Date: Sat, 26 Jun 2021 00:48:10 +0200 From: Toerless Eckert To: Michael Richardson Cc: "Fries, Steffen" , "anima@ietf.org" , netmod@ietf.org, Kent Watsen , rwilton@cisco.com Message-ID: <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5025.1624653668@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 25 Jun 2021 22:48:23 -0000 I was first asking about the encoding ;-) Would be good to understand if this "empty" encoding would result in a - same of different degree of "backward compatibility" as an extended enum - same or different size of ascii and binary encoding ? I am also not quite clear what difference it really makes to use empty instead of just creating a new revision of the voucher, as shown for module b in https://datatracker.ietf.org/doc/html/rfc7950#section-5.6.5 Need to learn more YANG ;-) Wrt errata: I would bet that none of this will go through as errata to RFC8366. In all the instances i remember erratas being accepted as such, they where all about what i'd call real textual bugs where it was obvious that what was desired by the RFC is not what the text of the RFC says. I think choosing a better/different extensible encoding is purely a feature. Which is fine, it just means we need to find a different place to track this, maybe the trac wiki. Errata are just a very limited editorial tool, not really a generic help for an RFCbis ;-( Lets hear from yang doctors or yang friends. Right now i bet that if the only change for yang vouchers is this enum, then its probably easiest to do b), e.g.: make AE be a formal update. I think c) is appropriate if we have a larger critical mass of changes for rfc8366. Cheers Toerless On Fri, Jun 25, 2021 at 04:41:08PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > tte> https://trac.ietf.org/trac/netmod/wiki/YANG_FAQ#when-use-empty > tte> Is this the solution we are looking for ? > > > here it the relevant text: > > } The second situation is when you want to define an extensible enumeration, > } as an alternative to the type "enumeration", which is not extensible by other > } modules. For example if an enumeration is used: > > } leaf protocol { > } type enumeration { > } enum smtp; > } enum pop3; > } } > } } > } and we want to add a new protocol 'imap4', it must be done by adding a new > } enum in the module. But if we use a choice of type empty instead: > > } container protocol { > } choice p { > } case smtp { leaf smtp { type empty; } } > } case pop3 { leaf pop3 { type empty; } } > } } > } } > } then another module can augment the first: > } > } augment /foo:protocol/p { > } case imap4 { leaf imap4 { type empty; } } > } } > > Well, this seems to be exactly what we want. > Do we get to put a description in there? > can we put a value in so that our SID process works? > (I imagine we'll have to hack pyang to make it cope, but...) > > proceedural options: > > 1) write this up as errata against 8366. That seems a bit much for errata, > but how much whisky does it cost to bribe an AD? > > 2) write a formal "Updates" RFC8366 that just does the NEW/OLD version of > updates, and that's it. > > 3) do an entire RFC8366bis. > > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > -- --- tte@cs.fau.de From nobody Sun Jun 27 06:29: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 DE3883A0BAD; Sun, 27 Jun 2021 06:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvNVr1ABsVLQ; Sun, 27 Jun 2021 06:29:50 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2121.outbound.protection.outlook.com [40.107.223.121]) (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 72C943A0B9F; Sun, 27 Jun 2021 06:29:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QcOdhi7OlswMXT5p5av0M8Fwp4rkPfq73lVI7gvOgDY5YYsuG0KU63QRj9nZVMBCBo1Mjo85q1isktXwCGvnGcc/I3lflhhk3iDXTXKx06JC7ddomUvEJSCuSvjXAk4Pv+TO6hBIA1jPPZcltedElJ0GM/py/gHPeesfgK9FgHMX9OFOIkjYP8cRu5jAJjfCP5SWypB9gxglXi9/Rvss5oKY4ga/npH6k2blJIMB8RpkXv7aHOCyp4kebjU48BAQWbvmqINHxKW2AvJzt+aFgUVW/3fnQx6KgfwUEXMw2VLIvD5tEK0tpGmkJvbgBBANPKQGuQ3EqYwnVbz2+D4OTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SI+c3Nl/jXUDi1yltl6JqpY9Nxiq23/5cgR2CiBxE3A=; b=lOkQle5OGleeaeQmwu04hQXIwzDddbuF2Dmxs8Qvd/Kjlz+nUnU2AB6ltbSSI1BxXRaqa0+9fro0P33QT43fpeSs2fPQN0X66+NGCdocJBZqmIGlUr4FClMaDCVOWVg4jp3SmqKy2QRx8CTRsLipX79EVGZzX6IGK3I9aqw3vKxiRg1bxDc2a0s8gc/h60fM9iB3/ZuHzbqgT8VjGkp75Ya2y7B7SqGwdgIYKcCWc2pXXjN+wCid1hVys4t0A8X57A21LPE7Zgni1wJOl/LKu/tEFuTdlzB7wYZqTbnPTUMRwU/uiyoQXUzMFxpmda+okF+JHaJgn5UqhhrE9C8moQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SI+c3Nl/jXUDi1yltl6JqpY9Nxiq23/5cgR2CiBxE3A=; b=aka7IS2ItMchvqXNJq+TbB3fwR0HW9+wiwI3571bKBc4LDtCQV/He7X4WCqUWWo2HtWtSQv6+EsL0Pi/USQoUetPTFKjND5pF0w/DehlMaZYT53S6EH1XMf+MlbPwnu8Ma1vYw21PgcpLdw/Wj8rgkezIUEE3utopD2/HMzACyA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=labn.net; Received: from SJ0PR14MB4792.namprd14.prod.outlook.com (2603:10b6:a03:379::24) by BY5PR14MB3624.namprd14.prod.outlook.com (2603:10b6:a03:1c4::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.19; Sun, 27 Jun 2021 13:29:49 +0000 Received: from SJ0PR14MB4792.namprd14.prod.outlook.com ([fe80::44ba:9615:94a2:dd5b]) by SJ0PR14MB4792.namprd14.prod.outlook.com ([fe80::44ba:9615:94a2:dd5b%5]) with mapi id 15.20.4264.026; Sun, 27 Jun 2021 13:29:49 +0000 From: Lou Berger To: NetMod WG Cc: NetMod WG Chairs References: <159373570027.29538.11387984048129033777@ietfa.amsl.com> Message-ID: <35561628-b862-f688-4fa2-52aa0e3b07cc@labn.net> Date: Sun, 27 Jun 2021 09:29:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <159373570027.29538.11387984048129033777@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [100.15.108.238] X-ClientProxiedBy: BL1PR13CA0013.namprd13.prod.outlook.com (2603:10b6:208:256::18) To SJ0PR14MB4792.namprd14.prod.outlook.com (2603:10b6:a03:379::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [127.0.0.1] (100.15.108.238) by BL1PR13CA0013.namprd13.prod.outlook.com (2603:10b6:208:256::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.17 via Frontend Transport; Sun, 27 Jun 2021 13:29:48 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9bfb0cc6-04c8-4a77-71cd-08d9396fa33b X-MS-TrafficTypeDiagnostic: BY5PR14MB3624: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9yB1AyG/VsdMdr9fiWmMmtIJgAsv1NJjOXYr1F3Pm080T8J7T+SNiuCDISvhHQkpt5Au1pKD8/eOX17HcRzafGFrXR54nXjhV4IUYC+1sex1xElq/SfDHKC0sd+ExMwPpOpOvBJqSo5Q8p4gthq8eBeYHSddAxhTDrmr+1GFer0yoPewJU2+a+Ki3mOoHa5/DoJ7Ws6IuMDwlta95JiNednMrHQ5DkQDfNbGtdZmZwrSLRAg8hBhfrEE5sAaX3muFoBykf4oputGtobtGhfzR5CRC7ZS3sQz+XiCAAyiGgrCp2ruUogyYlBCXeGU3Uw/y9t0+STCANm17ZqtckV4G8d4BK59LJsSJT9zcpLxq1V5d1ZVdLtqmH/zArlQ+LsKO8sbejEsAa8Y26qjf/WwrRn79xlcciiVK09cCBwxBPoaIGfbBxi8Vif2WLpRhcO9MGRXBUFMmi0llGuDBXhxFw3KXS6i2Xmxx2RzpzBhPXGlI8FY0YMndr2zRnQ26VKBTnBROHCln3DxCS0lnMxlg7U92WBGobR8OuFMKMVTwudyqrlflaw6wFh50hqkttUNGhf3F/YAa2RI0YVjH/UTYM3+8vXJcCi8/oMzgJ9/jI2pP9o6Vh+A2K14Er7YCIQvQy43rX4dtUPbjWaIsSGx1jmDC2jeLKYcYgHYcuP4rjTHJxk4u32QM3bMPiVIyMwlZwgFwIUk2sC/ZOqGJmb5BohVE7otrNiM/r6vM9rzefl+99UZtPdsQU+V4WnHd+LZJFlfVWyKadiuCNWNMRG5P1zVsv8e6at/+tN/wCe1WoqImbGFM6975jmOvVqACXQ1e2ZmOgUTVt4sS4c1cSVIOu/u648aInagErNimr24qVX7bGa9HgrsCNNqh+K5+cXdrRV84kvtPvKzJh1mTP9sl06ILP5/u3COXuvEYCanjoE= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR14MB4792.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39830400003)(366004)(346002)(396003)(376002)(316002)(16576012)(86362001)(450100002)(186003)(478600001)(16526019)(31696002)(7126003)(31686004)(966005)(36756003)(2906002)(38100700002)(26005)(38350700002)(4326008)(2616005)(52116002)(956004)(6486002)(7116003)(6916009)(66946007)(7246003)(5660300002)(66574015)(45640500001)(83380400001)(8936002)(8676002)(66556008)(66476007)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dHhXakt5QWVVd2ZkYk5UMDdxYWtLRFNSaXBjaGxES2VrelV0aWRNeTZhRnU2?= =?utf-8?B?aVNYUkRjV0syTThYMGM5THlwVmpVTTd4YnBPWlpBRDQ5aWRNci9GWUFZUGRD?= =?utf-8?B?YUo2OXpkRllMOUh0R2JORzA4YVpKRHdyUDV4aWQwMUxDelJJWHkzMEtmRXJm?= =?utf-8?B?aWE0elZBV2RQRFNUUmxGY1NPV0M3Unc2VWFiRGErYVVoZDIxTGdWbi9MUzBM?= =?utf-8?B?dHJKTEhveXRrb09UK3JPK0p2TVFRdmlpMG8xY3o1ei83WU1RS2lUYWlRejBD?= =?utf-8?B?bGxRU2RFaG1RWTA0VDBuMGxIanBRcGpaNkt6T2NEQUtZaE95bkFZbEtNMy9m?= =?utf-8?B?WjFESVozZ2ZBWkRtZWtBcWRaOGtmcWRFMWRhVDFiVThIKytHWU0rRjg0a2ZO?= =?utf-8?B?SzlqZXcvbDZHaWdMOHNvZCt4QzVCQzlydUJPV0d0TlBNQkpUNHo1ZmJwcVpm?= =?utf-8?B?N1FKVG14UHFDQzNkOGNnWXRmMW93TDVTK3V1K09IN2d2aitwVkIwTWw1RlZ5?= =?utf-8?B?K0pIM2F6b29FRTVyWW1aQlFrMWpwSllXV3psUHpwZU9nN1BNclQvU2ZaVWFp?= =?utf-8?B?Y2tMNXVaOXFvdHQ4VHNmR21XL1RVR3duNllDai82dmZPUC9mRXNOMzM0MVRN?= =?utf-8?B?c2hVUVFLdnRMOHplcUlnMjRJVzMwMkpMSWx6emszSFJpc3lwTDAvOS90bUcr?= =?utf-8?B?bGFIclE1YnFZTGdKM2tTa3pTSkpzQ3ByOWxRYUs3dFNPMmdaVFYvL1MwRHhT?= =?utf-8?B?WEVCWFc5YkJLM21WNGNrM0JkQXdNRHJ4YlMydnQzb3ZqRkdyaUFGNHRQVUN1?= =?utf-8?B?MW5KSTd3QUdiazdtb3JzaFJNTkpvTHI5cXRtVUNSZGU1TFVubWR2Z0QvM1Rv?= =?utf-8?B?SllxaHJTM1cwL1VCN0l2OFdWa09TV0E0YUJ6OHBDUzNtK3ZUejFTOGhWTXdo?= =?utf-8?B?TThCOTdWNjkwa3YyZnJ1ek92cGVJNnBsUE4za2c2eXlLZWdwUVZhdzFBd094?= =?utf-8?B?NWl3STJHb2YzdzIrTlQ3VWlHYzZGRUl3cWhOelg4bXpyckJ3bVZDUjJlQmpa?= =?utf-8?B?TCtqS2VINm5RZ21HT3ExVkhZTUoxaElObkJ1bmF3aGRIQnJ0UHhPNW15R3BD?= =?utf-8?B?aVVEZGs0QWZpOHV3L3ZwS1BGQUdvSFFPa3R5OW9Gc0xjRVFNNXlCNjQ5OEkv?= =?utf-8?B?QnFCcmZmUDdUQnRzbDFkTFdBY096WDI1U3VDMnlzVUNrTHV6d2t0TzU3Qm4z?= =?utf-8?B?TlNrUWdaZlFKMFN0bkVOYndlUSt4dkxiVnhlNHI2alh5Uk9PcHhJU2dHbEJN?= =?utf-8?B?Rzk5azZZdFdRQmpsL0d4Ty9Qam1ybUNoNU9OazJsNGZJdS8vYXJ5SzVsSzU4?= =?utf-8?B?LzdOcjMzTUtqOWNRM0RVSVJ0dVUvRTVTQVdIK1ZjSmJhYzZyd1ZuQkRJaDh6?= =?utf-8?B?bHgzVXdtU255NEVQSXlnWm8rOFVvUUQvMVgxZDFIQTlzOVRaMEQvQ0RhQmt0?= =?utf-8?B?Vklucjl1QmVzNjliODVHSnZqZGpWWFduR3NnRXdBcUh6MjlHYXZ5d2krY0xR?= =?utf-8?B?UzJ6RGd3UG9OaUhuN3k3OHVhMk1VY1R2NkpZb1BZMks5TWQ3NWVoMUN4T3RJ?= =?utf-8?B?MjRFVnRqRDNqTGJiT2kyNVNBNlZnN3lOYzVSMlNGd1FlZXNVTEJLOG0wQ0lS?= =?utf-8?B?SWtvMS9jenVtS0xqME5nVGlWaXBaU0pRWWJmM0J3Tm1vdHNUYm8yak1kVjcz?= =?utf-8?Q?jOKyGDLanGK2VGXDznemHqrPd2lF7RLVw+Zdpgf?= X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-Network-Message-Id: 9bfb0cc6-04c8-4a77-71cd-08d9396fa33b X-MS-Exchange-CrossTenant-AuthSource: SJ0PR14MB4792.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2021 13:29:49.3177 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5qOFVCRYNYuRcBYB7w0CD0zOjNTPQKJZgYBqDIO+j/TewW7sXdfnZEVEU9/GoKkVfoXtODZJ6ZkMLTEX+i1UOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR14MB3624 Archived-At: Subject: [netmod] IETF 111 Slot Requests 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, 27 Jun 2021 13:29:56 -0000 WG, The *draft* agenda for IETF111 has been posted - https://datatracker.ietf.org/meeting/111/agenda     TUESDAY, July 27, 2021 -- 1430-1530  Session II (UTC) iCalendar: https://datatracker.ietf.org/meeting/111/sessions/nemod.ics This will be fully remote meeting.  Our plan to cover updates, open issues, and new topics. Please send slot requests to netmod-chairs@ietf.org before the end of the day Sunday, July 11 (any TZ).  Please include draft names(s), presenter, desired slot length.  Also, please let us know if you think the topic would be better covered in a Virtual Interim to be held at a future date. Please keep in mind that priority for agenda time is given to WG drafts and other drafts/topics discussed on the mailing list. Thank you ! Lou, (Kent and Joel) Important dates: IETF 111: 2021-07-24, Online, US 2021-06-30 (Wednesday): Cut-off date for requests to reschedule Working Group or BOF meetings UTC 23:59. 2021-07-02 (Friday): Final agenda to be published. 2021-07-12 (Monday): Standard rate registration and payment cut-off at UTC 23:59.. 2021-07-12 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59. Upload using the ID Submission Tool. 2021-07-14 (Wednesday): Draft Working Group agendas due by UTC 23:59. Upload using the Meeting Materials Management Tool. 2021-07-19 (Monday): Revised Working Group agendas due by UTC 23:59. Upload using the Meeting Materials Management Tool. 2021-07-19 (Monday): Registration cancellation cut-off at UTC 23:59. From nobody Sun Jun 27 14:03: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 DCDD23A1A60; Sun, 27 Jun 2021 14:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 z6Ssx5FUvw9l; Sun, 27 Jun 2021 14:02:58 -0700 (PDT) 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 152853A1A64; Sun, 27 Jun 2021 14:02:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 08E283899D; Sun, 27 Jun 2021 17:04:52 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eHVGN419Jclh; Sun, 27 Jun 2021 17:04:50 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 12C4A3899A; Sun, 27 Jun 2021 17:04:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 254E2997; Sun, 27 Jun 2021 17:02:54 -0400 (EDT) From: Michael Richardson To: Toerless Eckert , "Fries\, Steffen" , "anima\@ietf.org" , netmod@ietf.org, Kent Watsen , rwilton@cisco.com In-Reply-To: <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> 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] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 27 Jun 2021 21:03:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > Lets hear from yang doctors or yang friends. Right now i bet that if > the only change for yang vouchers is this enum, then its probably > easiest to do b), e.g.: make AE be a formal update. I think c) is > appropriate if we have a larger critical mass of changes for rfc8366. I wasn't think that brski-async-enroll would be the RFC8366 Update document, but I guess it could be. I thought that it would be a new document. I will prepare an RFC8366bis ID so that we have some complete YANG, and I'll attempt to point constrained-voucher at it to see what happens to SID value= s, etc. But, not before the hackathon, maybe during. =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+93Q3WUFAmDY530ACgkQgItw+93Q 3WWKcggAnolcUiJdAdZQzXmVQ/KAIe+RgtlJUMkhEzKwv40XKQUG7G7+tEhHy/4r jMK4Lxwl1ynf8mhngKCYND6nxfWYRs6wPnFnQMMvXAdEN0plyozi/hjM5/+579K0 KK/pzA01hfd6zvqbqN3j2UqHDk5e8X3KoQO24YuAA9pVVo6gB3QnhxPDjpmI71Ih IT0JXruYzAJNLX01TfHhe3l09iwXoDooHgczNNWNpZEpHH+jcQp4WQuVzoJrn7jZ voNpuTbLhA/zV0Ar5DUYquP8+qr29sAeVSZHo7EE2/++rmmqZ6vRkB4OBK/41pgC mUfdWONlhSsVTHfl7KntwKtIDMMOxA== =p5wC -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 28 04:54: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 B752C3A369B; Mon, 28 Jun 2021 04:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxdB_VbIbgAx; Mon, 28 Jun 2021 04:54:07 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20108.outbound.protection.outlook.com [40.107.2.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF213A369A; Mon, 28 Jun 2021 04:54:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IcpPxv9yskq+YKXXCYtVvcjqIrCvFj7zm27V1zQLPXIwj28WUQJq/1jThPw/AqVL3Ggp8FXztzrUReH073b8VejF1ERlkzKOhUzw4QMN+Q4eXvj1TL4ump91b4nR50XoFU2CeHFMwlTg+53i6VQRh5z6RxhAIFWOP6Sn+fnsAfEUwp7aOL6EpFzblQTCH03wvb3WH3CWH2yscp6XalSvBqllfffad5MTz/JeP6bF7OQnD5a61FCFK3kkjigvt/0u+vyJLAdfduDR+ZozgZQv2RTnpeOUgU8Y4+T8aWCupUnxlKg50vLi4ReJYOvpVrxKfyBPwE5OjDSq0bwhVxXVng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R0V4fnvE/bew+zFBCiCv3gsmYjzDnIVsfF0yhITXxPA=; b=OK8OphiTHzs1kv/PW8tjoFVxlGZdnd7DJg+vNxggL7nFbISTktIEevX7pe+LOdT3JvvzfIKvmN+Hf0/avvEa8pC9REpZglyuSYmfC7VFgKd5BiuuuY+bjOR8vZ3ActHdf7K94MANMxkEhVVw2CmQVxrR1VfOvzdo2uoCVO52V4SiBrrN8edr64FbzxaD70CW0l/C1VTqSR0ODgwSLsET9VoyEvu0blw/tmU3J1v+k/M4LYUPZfUtbm7DfBDNGMgIG26weKeHdcHlvKdFwygpwEg+Zo9Oij5SawbmCjTM64LvhNXHNnSYJ04s51XVKirOJ503apYOQrH6TZhomwd1LA== 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=R0V4fnvE/bew+zFBCiCv3gsmYjzDnIVsfF0yhITXxPA=; b=xdFwpg4l/fOO2pEvoDQ8JghF2kXIMkYfBDEAb7HOLqLJLtgq00VeVY15FRE/wcwmmKkOEQK0gmY50JGN2cXEeIHXWrFFuqHNMxSR87m4w7ukSxj1dskV7mifOUphBmovwgFZ8oh6PzctVhNRq0vWbiUScClzkyrBKa1HHJ5aDRY= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB5829.eurprd07.prod.outlook.com (2603:10a6:20b:2a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.16; Mon, 28 Jun 2021 11:54:04 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d%7]) with mapi id 15.20.4287.021; Mon, 28 Jun 2021 11:54:04 +0000 From: tom petch To: Toerless Eckert , Michael Richardson CC: "netmod@ietf.org" , "anima@ietf.org" , "Fries, Steffen" Thread-Topic: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? Thread-Index: AQHXagJ4SmLy7OhzB0KCTs+uGzc5c6slVFIAgAP9gGU= Date: Mon, 28 Jun 2021 11:54:04 +0000 Message-ID: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost>, <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> In-Reply-To: <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e66cabcf-d38e-4d42-e993-08d93a2b6da6 x-ms-traffictypediagnostic: AM6PR07MB5829: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tP9v5vSowOd/JTNsnLPKer4zQ3g2l6NNJ1tz67WobDlwRgmSO52Zmfyf0gZXNE4TyLfwIzOnpt8Qgy0ZxWRF7ZO6bR8aS0YX+LyUpY3k/ovTs9VU7kbNhAU+mK86C91G5Aliwfw2gHvnkTW6nwJYAtiXgo6mYQdAFoNOHuELpV4gKVAFhSZO7U1j4D08YvIFP+5AcIQe2V6bncsxZiEoGA7VmvMkZjr5kVMMrsJn3Ascil11cPHg9m9KkzCIzFp0d+fesLrB/d7yclm/l6z4X5lR2f9YtCvmyypME1iwGnWgWG7jEDZxr7XTzqfbZEZrRsmHLm0WbOTI/mn5nwfFasGjuUk5HA/vnP+KZBYFlVN3gUBFvBestsZuAFmJSgt3OMQpsQplUiTrlNnHuhujXJeMzhlt2iLTt0xYIUeVYq5vApb5T9uN6wxGW3cSVjvWM2Q4jUQQ7dL8FS0yijsUDfRa8pimhzYx16NFAhozDvhf/t+1KcMz9dd0nXBA38kAuP7u2RH7UzyXAt87L5ZiGfkmE+67mkWzdN77oeT3S9YHzM9NF3OdZ1udk+YpqyEOCk4YmyexQ+ktFGbHQXOuk6QN10dCDs2V2lrB/Ttdv+jamvpGiqSed1CscrdqIclFzc/9oqNYDYwpPp/yHn54QzNmF4bwIDPdNuabZjAm2nulXptQNFQWoOdj8424Wrvx2bPwUK1CNVaeRgEm/K2htQQUEmI64CocMwcA3p6fstNKlgmY+Y98LwBAUbf+rTAsr9rkfiD/zTi83x3M+2c4/XLHpD8rQY72m2mq6pP7UiEEo6W7AgNTxn9x7MHXnS5W 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:(136003)(346002)(376002)(396003)(366004)(39860400002)(5660300002)(38100700002)(71200400001)(316002)(4326008)(52536014)(54906003)(91956017)(110136005)(66446008)(26005)(76116006)(64756008)(66476007)(66946007)(66556008)(478600001)(186003)(66574015)(7696005)(966005)(8676002)(33656002)(83380400001)(55016002)(9686003)(2906002)(122000001)(6506007)(8936002)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?t5o7nXRl1k7ctWRqz82tC5ea0RfKCuzdQvQHZbAXjBpUYCY+53jY1Flloo?= =?iso-8859-1?Q?iIqrlknmN+rHcJm5l2cDy7lZ0w8SwcQ1exPouAr1fJjf3L35nro4Ds+82O?= =?iso-8859-1?Q?jRY62suslBGa8B6pDkNvPEwX4CrTUY5s4zV1sBDoN6/wgZ2FcH3cDp4gcr?= =?iso-8859-1?Q?KBVwm0XVzZgXVtAQdQ1db4y/3po3uEp+ATsbC3fG8CDxiBHnBz4Dsq1AQI?= =?iso-8859-1?Q?+gXxG1371+lzHsHhEuD9aZy2PCxuhINwK/pTPdpWJdWKUKz1TPi5sQIHzk?= =?iso-8859-1?Q?ozgUSX0T1DT+V+LCggEao7QE2nqZVbcXyfwTiCGTKmccdRkkW1jj720NQ2?= =?iso-8859-1?Q?MoCOEBSZ1kgbKOKORYImN2lJtGnlvK0ehL8nKfZh8vRJpX+pZYDZDCQNor?= =?iso-8859-1?Q?StISPFsgiY/iQ2jo79AgkzJE1RiJX3VsVWbeBBENtU0Q8NZcI811SspEsb?= =?iso-8859-1?Q?eq/+HxsavhKhd38gr+UxbxAVbGuhsFMst117YK1Kg96x8CVfXIEXgdu+dm?= =?iso-8859-1?Q?Z7hQ9yAb9py98JWPal8v1+Xq+fFY5FTEbJZIqKcQ4svOf2gG4cq5S7Z0RF?= =?iso-8859-1?Q?StkAkwbZ0JH3eP5fF7Qq+SDbIV5LcLq7aNLj36mQ7UNWLJRIJMI73NA3fl?= =?iso-8859-1?Q?h4D1KUnvagzPPnp+6ZL9iLhOJRRHamNBMnUkpiKTfC/pqp9DEClxNnUAsi?= =?iso-8859-1?Q?3a31WfMpTjsAsXTEQ2/gYo8O19JAnAlm+Esz8eZ+jds/umawXKUue32Dfl?= =?iso-8859-1?Q?wHatn5uPwtGe1IdhYbfoHU3bR3XxbQU/7Y9DBw/LIfcLzPhWT2100JtFf0?= =?iso-8859-1?Q?3rGVMeII29SLDX6cHwjMZD1ewO2FiqDMLZ7wV3vRgSKMx/GyRD9Akiznwk?= =?iso-8859-1?Q?GKSYh7TjHjGl/ilSt6AY7CmK2U2wvb3yJ0IhfrcHAtbRDf253mh8Fz4PFK?= =?iso-8859-1?Q?8QGbjobkjvuA0R09hHg8g8TQLVNacSnTcIkBazStrcvUYaZSPRJWpnLv0k?= =?iso-8859-1?Q?nIg/qmhPPyDalLpxPso7ZaSvOPe8KoFzLVK2KgO06pxZCTUzpkPtgOVqcB?= =?iso-8859-1?Q?e6sA6nGo7J/sBJbGrC9QHEYEOu8My4wbBCG1h9BCK5XHRkV8mvaBSxyylP?= =?iso-8859-1?Q?5R712lSyQHVWli0ehJbTRDhuHUqg5OLYE/BSa74/W7AKLuU3XiovYxWV7S?= =?iso-8859-1?Q?HiH5bCBVmf7RZ3iM0ywl7AL+M8Pzd+pm5+ppChpwWS2F2l3o52unmfF/t0?= =?iso-8859-1?Q?Yr+N4nl27QCtlWnidlJM0xzKoFZ5Q8tZ8yWZE9qhVQqRpQPXdrvVz6J+m4?= =?iso-8859-1?Q?6VFdNR91H7QrnhuErjJsYWlaX9/gsOpfBV87Tfgrow3Jv8TjYi2WynxHj8?= =?iso-8859-1?Q?qUQ9Xks80g?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e66cabcf-d38e-4d42-e993-08d93a2b6da6 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2021 11:54:04.6449 (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: UogHbLcG+Nc2LdqtYuzhMDWRX2k+Qgd5NTpSfiP0liNO6+AGhSnb9TX+oid6ojH95F2jKb904fuOnptHfDLC3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5829 Archived-At: Subject: Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 28 Jun 2021 11:54:13 -0000 From: netmod on behalf of Toerless Eckert =0A= Sent: 25 June 2021 23:48=0A= =0A= I was first asking about the encoding ;-)=0A= =0A= Would be good to understand if this "empty" encoding would result in a=0A= - same of different degree of "backward compatibility" as an extended enum= =0A= - same or different size of ascii and binary encoding ?=0A= =0A= I am also not quite clear what difference it really makes to use empty inst= ead=0A= of just creating a new revision of the voucher, as shown for module b in=0A= =0A= https://datatracker.ietf.org/doc/html/rfc7950#section-5.6.5=0A= =0A= Need to learn more YANG ;-)=0A= =0A= Wrt errata: I would bet that none of this will go through as errata to=0A= RFC8366. In all the instances i remember erratas being accepted as such,=0A= they where all about what i'd call real textual bugs where it was obvious= =0A= that what was desired by the RFC is not what the text of the RFC says.=0A= I think choosing a better/different extensible encoding is purely a feature= .=0A= Which is fine, it just means we need to find a different place to track=0A= this, maybe the trac wiki. Errata are just a very limited editorial tool,= =0A= not really a generic help for an RFCbis ;-(=0A= =0A= Lets hear from yang doctors or yang friends. Right now i bet that if=0A= the only change for yang vouchers is this enum, then its probably easiest= =0A= to do b), e.g.: make AE be a formal update. I think c) is appropriate if=0A= we have a larger critical mass of changes for rfc8366.=0A= =0A= =0A= As you say, this is never going to be an Erratum.=0A= =0A= A leaf of type empty is encoded as, well, empty.=0A= =0A= as per RFC 7950.=0A= =0A= When this concept was first mentioned, my sense was that while it was techn= ically possible, it would still add complexity for little gain. As I see Y= ANG Doctors for ever saying, identity can be augmented, enumeration can not= so enumeration are used when you positively want to stop people augmenting= , when the concept does not make sense so a revised enum may make sense or = a change to something like identity which I see as as big a change as the u= se of 'empty' but the latter is not in current use and so may cause some un= certainty, some confusion.=0A= =0A= Tom Petch=0A= =0A= Cheers=0A= Toerless=0A= =0A= On Fri, Jun 25, 2021 at 04:41:08PM -0400, Michael Richardson wrote:=0A= >=0A= > Toerless Eckert wrote:=0A= > tte> https://trac.ietf.org/trac/netmod/wiki/YANG_FAQ#when-use-empty= =0A= > tte> Is this the solution we are looking for ?=0A= >=0A= >=0A= > here it the relevant text:=0A= >=0A= > } The second situation is when you want to define an extensible enumerati= on,=0A= > } as an alternative to the type "enumeration", which is not extensible by= other=0A= > } modules. For example if an enumeration is used:=0A= >=0A= > } leaf protocol {=0A= > } type enumeration {=0A= > } enum smtp;=0A= > } enum pop3;=0A= > } }=0A= > } }=0A= > } and we want to add a new protocol 'imap4', it must be done by adding a = new=0A= > } enum in the module. But if we use a choice of type empty instead:=0A= >=0A= > } container protocol {=0A= > } choice p {=0A= > } case smtp { leaf smtp { type empty; } }=0A= > } case pop3 { leaf pop3 { type empty; } }=0A= > } }=0A= > } }=0A= > } then another module can augment the first:=0A= > }=0A= > } augment /foo:protocol/p {=0A= > } case imap4 { leaf imap4 { type empty; } }=0A= > } }=0A= >=0A= > Well, this seems to be exactly what we want.=0A= > Do we get to put a description in there?=0A= > can we put a value in so that our SID process works?=0A= > (I imagine we'll have to hack pyang to make it cope, but...)=0A= >=0A= > proceedural options:=0A= >=0A= > 1) write this up as errata against 8366. That seems a bit much for errat= a,=0A= > but how much whisky does it cost to bribe an AD?=0A= >=0A= > 2) write a formal "Updates" RFC8366 that just does the NEW/OLD version of= =0A= > updates, and that's it.=0A= >=0A= > 3) do an entire RFC8366bis.=0A= >=0A= > --=0A= > Michael Richardson . o O ( IPv6 I=F8T consultin= g )=0A= > Sandelman Software Works Inc, Ottawa and Worldwide=0A= >=0A= >=0A= >=0A= >=0A= =0A= =0A= =0A= --=0A= ---=0A= tte@cs.fau.de=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Mon Jun 28 05:09:40 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99FE3A3707; Mon, 28 Jun 2021 05:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdN6C8QUb2Hj; Mon, 28 Jun 2021 05:09:28 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20055.outbound.protection.outlook.com [40.107.2.55]) (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 989BB3A3703; Mon, 28 Jun 2021 05:09:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CJPi7B+hZdPf5Fu2W0eKJSSSR/MOts4vTRWt7HRbOPL6f5W2AdQIdsLlbIsuRCRs/rmJktA/CTSQ3Ee+GYhfY5q0+X7258GW3AqlR5zLueb7XK42wMaY4MKXwQ5c5ShgsOT0MzNBZFunyQ7qeB+eFfNnCDPlFuvV9EhkTYelrlcjwl3OKcRaRHIEHufXmITmitMIYoaO+febx4tv1zblkCU+XMyJmsbvVlTG8ONHZ9FiWCF31JTcY8XWXpgke33YiLBkmQ18pSEsxYWzM/8ZXo6a5EWJkHMp0s1+QPsRN1W0g4SDEn7/Xmn6pyjpEQ35AbpIDwkmwRep6TGBkAvzsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vS8JWLY2b72qyWU7vJC+kbv0YMRipFiGGGYU4/RNyGE=; b=laHx34CgdJjeqJFpWYdHjw+3GFSHrDZBEtoAkvPN3c0S0zwc59Ud7MceueMPycdS04g5yWro+GwI4sTYySyzVjtT1um27AZKmxFvSCZFGaldyfL5JQWe8f+qOt+IDFjsUUFziC+ycrlpCu/E5Bd7gR7ZD8DxbnQTdauom2ZxAPWAg71+4prgu5eDM9WomOuwp2T1O2VhRgKPqm5u0lcBvvNbO3ThvbALXELTkZLAv3uYJKnVawuG8co6FGeFR0ECGYDUhWGLZLW22plOeRL2sOUuNAxGlIcoiu7WxDA4Eq7nca0LxDG9EMpVSASqxjWCTvD1Pv+/AvLQrQgttp2/ZA== 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=vS8JWLY2b72qyWU7vJC+kbv0YMRipFiGGGYU4/RNyGE=; b=l3U2eicx5B4BI3jgJK8NbKk957eL0jOFA7I4dHWsGUbzISUnIz1RpCPFKWXSOgNjbZ4nHdEEAwEFDpAjhH221u+RUY+zfY3kNqmMwD0/CslF5JcIjxij+qpCPhmLFw/Af+OidI5a0oTpYLIKkMzVZjtj0M4FKxZ7+sWv0/egBhs= Authentication-Results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM8P190MB0802.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1c7::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.20; Mon, 28 Jun 2021 12:09:25 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4264.026; Mon, 28 Jun 2021 12:09:25 +0000 Date: Mon, 28 Jun 2021 14:09:24 +0200 From: Juergen Schoenwaelder To: tom petch Cc: Toerless Eckert , Michael Richardson , "Fries, Steffen" , "anima@ietf.org" , "netmod@ietf.org" Message-ID: <20210628120924.xuuwnhnvz4jid7sp@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: tom petch , Toerless Eckert , Michael Richardson , "Fries, Steffen" , "anima@ietf.org" , "netmod@ietf.org" References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: FR2P281CA0033.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::20) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by FR2P281CA0033.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.12 via Frontend Transport; Mon, 28 Jun 2021 12:09:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8727ec82-3d13-48bd-fe8a-08d93a2d9242 X-MS-TrafficTypeDiagnostic: AM8P190MB0802: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nya1xBi1D5BVQthC07TTlwp2fzxsUGR4frUdRFh1C3ptPCup13scmNXpgXZ2GNxFZNjXBjf7/rBnLEYh4JuvdApji4RSsJWAJYZCQ0YyO0On36s5OFm1Wu8oR7j4NUpASdLaWdL/cFe/FYxlNoyH7FLRBjtC3Ow297twlRwgV/S+5nyA6zAXjSKhJMMFLMgC0PyZ+b1izNnv2XWZ8kVQ7aACMjw3LkkbR9OryLDGp2HWuEJG4lnf3JNt/p2+8kQZsf0vgxe1rhBHOB8+0kLBhZbLI+ne60TVSR2LeyStkHMXfr4ios69vryNjhaxuno115C70KY9BR6sPiyNXrUC6oJoKE3UJEIT6A6tT1dPgKC6L7nIPKyPZuDNvZw+CxZco8bi4TISfMySjPm4dQ3kq0p5f0VMfY4NTIBr5o2J0xKZbg7Q6wUHrGORGIwXL2SqOBhyjKv+2sperAVOAYBnkVQXCeMw9Ra5flaVUbGaanw3ZlquE2Pmh4/2DQzfhoEioAX60/f0T/jL5Sy0A2pcr9iRIpea954W/2Y2bbQWcDrKKgSFqwyXpRX/ok4nyi+mXZPrguCa8HVPfOf2ij4rGAfso9MVbS871kqbofxs4M20KSdEqZPqYL/ASMf+W+Qn/rZSV5OT8fay4QaR13jNO/rFrEwu0fA8ah4FKW0/JnEKusmMGofX/97EqqCVSSmFu7lhIcLw99e6wHFOB4UuZXyNW2G0qSNnoYw7rXrvTYe/ZpfLiKvJPTzpFB9khf5h+UTXgGiMXPMTeWm1o+9uh4nTK2mQ0PUxwTcodjGDoQt/+4MO1VutSrgwGwEH3lfOh7n4+O8xG57BOhfxxSdMJQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(39850400004)(376002)(366004)(86362001)(16526019)(3450700001)(26005)(6916009)(52116002)(8676002)(2906002)(786003)(4326008)(6496006)(296002)(186003)(5660300002)(38100700002)(1076003)(956004)(316002)(478600001)(8936002)(6486002)(66556008)(38350700002)(54906003)(66946007)(66476007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?6L5DYHrSW2WRMFrB4IP2+OeuaTrMgjZglZND4G9SHH4dnjHSs6IkS2TBUYGJ?= =?us-ascii?Q?fIJWrTkl3JI8MyRtls4aJbJFJBO5WiCi4b6IJa2QHcMbDRbtSC1JGi+FAMDy?= =?us-ascii?Q?O/1XCQfjsedNtd976JRpLpQX8hZU1puUwRzI10LGjNToWbXO/sPYlsbnLA7d?= =?us-ascii?Q?OkSHWjmq50DIKUECXxNKma3UvcDPN14FEKH8jlU9nruYU0dKHBRdJApbrNY5?= =?us-ascii?Q?4uIXRDhXjcA11ty16d+C84LCyojhlIXLTHyMo2xV8vfLg5UDHWO4zzuHiQRO?= =?us-ascii?Q?dlUr9xhEyhRo/fhi8l5cY+bc2Ll4za9ffVKoYT5rJ1TFW1JWNYcVF8omP1IJ?= =?us-ascii?Q?Uh+Ho+BgfjqYaF4QhNh8otLYKxmgmXVA4S6TCOPAGUqifow4WGhd/yjopAGK?= =?us-ascii?Q?GDoAUE1Yxz3/tmaFGsKV7YvaKLI9w64IwPNH539HWxXunlDS2C7c8rR/UOw5?= =?us-ascii?Q?eVEGQzREYhjogucNVIc76La6HGEmLmK7wTAuOw6lKOjXE87cYfGbQuahduW1?= =?us-ascii?Q?qsoEk1iky7Dl9DhBQjmPZtHeL5c+5/NxpEWNl4stUW8f2g2hiUQfyOsdNNWa?= =?us-ascii?Q?Urazy8Fm9Z1frv4ZK+n1niMTUkmDY9FMlbDjhz4cC+Aa2rkCaNieAeiBvctN?= =?us-ascii?Q?h5f7swU9IMVulJHGZg9abVG9aEwPAiiuR4xO2PipynSStcVet8Vn5DGFGEb6?= =?us-ascii?Q?sFuaP36RX4qELh7z99qEJY9utm7HhOza0u+/NfUePfT43rMx+RZLN1aJMOJj?= =?us-ascii?Q?AhgvpHk/0kfmyCP+B7/zaHD6q05urXX/7eCAydREsE40R1waC8PjUK5TP/mg?= =?us-ascii?Q?Y2CJF5H796PDz39jpXF1ebLV1vW9jOhIz5ousjdwd/j/9pQyspap16pSrUyh?= =?us-ascii?Q?/ge/BVKaKVOYLaDS3gjqJkvdTOGX6I0pJ6uIvsIha2J52t5pAdft7fYryW/2?= =?us-ascii?Q?xTUj8nLfnD1zYsV9fFuTiV8Khwkc9ERHna4OCnkfQv/O4bVtPHxFhufMnRRq?= =?us-ascii?Q?oRQllRd1++nkkxF06ZPTfVkCGXNOWFgu7uk/L+tEFHxX2WrbSgeGGXl7wXK+?= =?us-ascii?Q?3nxX53lp8fGyHzKDs5PPKqu+sHN8BR46mXXC8dZDalVlcjBUR5b+XbHBzX/E?= =?us-ascii?Q?ELIXPbnZTwutPvFI0/mTSnfTJ0QQfLymn+1IKPg+XIh1RLalfU63H1cfBpmW?= =?us-ascii?Q?otSpUPHDffGy5a8zcYWZDGfmiH2x/GYbk3wL/gD0ibaspmHaZQqc/0jEPIpw?= =?us-ascii?Q?o7kTRNGYOf0g8POQDeO5pruTJlqkaVvgUYfmvr5v3dbVmMZo2ntPg2tWBzSq?= =?us-ascii?Q?Vx/6SFqHmidNSFuht4cYDbF0?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 8727ec82-3d13-48bd-fe8a-08d93a2d9242 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2021 12:09:25.3191 (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: J9LQJIJz3IgDjmvgzhg/OYdEfS1wMlDX0MZxoBOgBTpDdBrTzO2Xgyy9McQv+HpLf5LYwbaJP8CGDC7tn5EjoWp31exw5BsQxVf2Km266Kk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0802 Archived-At: Subject: Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 28 Jun 2021 12:09:34 -0000 On Mon, Jun 28, 2021 at 11:54:04AM +0000, tom petch wrote: [...] > As you say, this is never going to be an Erratum. Yep. > A leaf of type empty is encoded as, well, empty. > > as per RFC 7950. > > When this concept was first mentioned, my sense was that while it was technically possible, it would still add complexity for little gain. As I see YANG Doctors for ever saying, identity can be augmented, enumeration can not so enumeration are used when you positively want to stop people augmenting, when the concept does not make sense so a revised enum may make sense or a change to something like identity which I see as as big a change as the use of 'empty' but the latter is not in current use and so may cause some uncertainty, some confusion. > Enumerations are centrally managed. Section 11 of RFC 7950 does allow additions to enums but only where the enum itself is defined, i.e., you need to create a new revision of the YANG module to add an enum value. An identity is more flexible as the value space is not centrally managed. Using leafs of type as a way to define a non-centrally managed enumerated set of values really is a hack. It may work if people follow certain rules, but it is unlikely that tools will understand the rules (i.e., which places of a data model were designed to be used as a 'leafs of type enumeration'). Hence, there is nothing that will prevents people from augmenting in a leaf that is not using the type empty or even an entire subtree of YANG definitions. I do not know exactly what the issue with RFC 8366 is but it seems you will have to revise the YANG module defined in RFC 8366 anyway. Note that there is also a middle ground, namely an enumeration type factored out into an IANA maintained module that is process wise easier to extend - should extensions be needed more regularly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 28 09:05: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 CE35F3A0A40; Mon, 28 Jun 2021 09:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 WZ4ESmENzY96; Mon, 28 Jun 2021 09:04:51 -0700 (PDT) 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 D1BC43A0A3E; Mon, 28 Jun 2021 09:04:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AFCB338A74; Mon, 28 Jun 2021 12:06:47 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CE_CWgFO-dYa; Mon, 28 Jun 2021 12:06:45 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B01838A71; Mon, 28 Jun 2021 12:06:45 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A7240885; Mon, 28 Jun 2021 12:04:46 -0400 (EDT) From: Michael Richardson To: j.schoenwaelder@jacobs-university.de, "anima\@ietf.org" , "netmod\@ietf.org" In-Reply-To: <20210628120924.xuuwnhnvz4jid7sp@anna.jacobs.jacobs-university.de> References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> <20210628120924.xuuwnhnvz4jid7sp@anna.jacobs.jacobs-university.de> 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] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 28 Jun 2021 16:04:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Juergen Schoenwaelder wrote: > Note that there is also a middle ground, namely an enumeration type > factored out into an IANA maintained module that is process wise easi= er > to extend - should extensions be needed more regularly. That would suit me. How do we do that? =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+93Q3WUFAmDZ8x4ACgkQgItw+93Q 3WUpZAf+K1OHIPch8LO0zVwqrYztIvW7of7HJ9MG/Bljtzz/YyC+K0DKD+WFAQNY VPesDBc+l+02Iurml0ElzbI1iSgqJX+lbqjq1s38sl2yD9uQlnl6Jh9VA0WKBS2x PhM5CYr6SwmF+6neSb5pWPB2s07wXQO731NjE6qYz9y4knc1Vom4hEtlA93chJFV m3m956P9s4RFwZz9BCDecsejJYsdgvijoysrhGI9AaF6GcIHHFlP8lEHiU/q+E8O 7Qo3RRDsQMitYUx5sflctDaqjy+JOXGCs7yHuYKeWj5cWCsW2ts8VJlLopZatckY pFacjsXcd5e1yGU6oskF4sf5M0oi6A== =1eEU -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 28 09:15: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 5CA7C3A0AE8; Mon, 28 Jun 2021 09:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adfgIH1-L96L; Mon, 28 Jun 2021 09:14:53 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80083.outbound.protection.outlook.com [40.107.8.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 02A3B3A0AF1; Mon, 28 Jun 2021 09:14:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZKoTCs3muZHpBDsuD1BYHIL36U3FVoet0CCaAtV+kpeVHw+VzOYQ49Ly/zYP6qFiJfb16hSOYmWZxUNUJYrFS4btqAh4Lxpy42hy7xap7W8bNBHdOrnHxHfM83lISFCw8vSqOX8M/eKFAn9qkKtvhqJqlpPD6A/EEERchyhXwQCMCIELxa7zXMstGJMuIWUOFgdPpGjoHo+FOXjsBAwR0zKku1zdZLO/uqQRlCoaFNcXwbAimXIa5/rQXopNFia+AOCdcG2yWiMEx5fZJM0jGmLI8f+p+iL5kq2Ey1SU040OYvrsH/+kkf7qddQk12huDDK8tInzPjrJNf5NtSrPTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4QD8f9JOXq4o4jjMxAyqtGkj8lv+EiUxP0NNTrdg18Q=; b=kkDiWA/yiLcjoyx0qlKZqShRDntNTxkxgdmf4QOctwSR3UoeGfI40T3qquJ20Ms0JPyTrgM0T6I6CMtJKkT89nd3+DV9NpuVlo+ep+HvC0ZkvAre1ta34rWfpCJRp6TYv8FFibes9A0F0D1j4G4Ag6c6yFKLJT1qKKWzZuPJ+MzY5ZPnqVQ3VyJU2uYANunu9Lf8LGz7SEqK7ScLmb5K1kTJoFTptJviL1gprbZ8oVqcjXHOoIM3r6yHR1D/LDgCjCG1tcMwzUZSTIthfLECerUozj6btuN/lc/DUy72AZFbpCRg22JvM2CXeCsO/PcAIZm8AtmzZXj81NuXrkYB4w== 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=4QD8f9JOXq4o4jjMxAyqtGkj8lv+EiUxP0NNTrdg18Q=; b=FoF8EAVZne5npPoVYYfjMpjd3Ru3F2BeIhp2FBj8MOBSUlrWW8bxSYVbum5hE7YnJSR5czowAYWjkHOKsbuYHnIbAAcLGbUf7qbGoqpxeUJtrkOL2ymPpDHfp+0PCx9a5AXRpBPc8x+C14Q4Udly8HdsZR6y7gqTpWF3Y6SNP1c= Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1636.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3ee::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Mon, 28 Jun 2021 16:14:49 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4264.026; Mon, 28 Jun 2021 16:14:49 +0000 Date: Mon, 28 Jun 2021 18:14:48 +0200 From: Juergen Schoenwaelder To: Michael Richardson Cc: "anima@ietf.org" , "netmod@ietf.org" Message-ID: <20210628161448.23zzsb2iazxgakmd@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michael Richardson , "anima@ietf.org" , "netmod@ietf.org" References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> <20210628120924.xuuwnhnvz4jid7sp@anna.jacobs.jacobs-university.de> <26783.1624896286@localhost> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26783.1624896286@localhost> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR0P264CA0149.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1b::17) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR0P264CA0149.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Mon, 28 Jun 2021 16:14:49 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 700a1508-83b0-47bd-9c30-08d93a4fdaa1 X-MS-TrafficTypeDiagnostic: AM9P190MB1636: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ur3kXNtHy3Ia2RmvdkcWP0lhVNf4hEe1/jad5YGDXJ1mFOcov/3SASiRknG0xMIrgJaNqW3SVWJfo/Ir+JzunJIBBCdX61m96M1DPpJcfW2UFm/2a2RevGQYEXZ+f4iP1GA7fWzlXdorUSReuo45u+wCcv0v1+04CNd/mqb11f+V9Cub8QxW1vJPwrCQlYOg0mqgrq8dj8CZ96ggbFItynHchrmxAYSfQcgCxBStG8dj7Zj22ukZ/j/a70+xJrMBgmMO9+TfVr2xTbvph68rQFalnvvKmRR+0RiA67oHzTVLGHarxyLE876m7AWDX1al1PXJ133w+Lw2n6cTc/8fkjeDUcmH/ebmNLfv0fmk+8baW7VgGVdoi3/rjfR6AqS4lZCn+P0Iix533U0OrlCyoHwioW7FkzEud/gabwvaFpgjbwreeLkeWAKvZx3xDBZH1eN68ejIuhJ2fKF2zOIjD8oN7BtT7ifvcEY6WU1XRE85KZ1sNEgftwzC+gcxEM0ORvX0LM9w6vCnwZc9ncY0Jqwchwdvl+/4xrl/onqAbVLb54ahqAgWmwlFOss9B4zls1yjPLXuIPf5yuWZeExjoTaHhx4VDqwLUH7kXEhdkmBfQ0FTIBV3gWLNPgjRrHfIuiQM7jRoof5CDwQjEtT3NyiZ6HgxCdooNbY8NM4KtMxM2TYDJ+5W8t4MgFH5ls9aryvayFS0TRwMiO9mPjzfyVjEZ4gleSQ8m64Ic3nu4MxwzwuLb0v/siu9Hxju+27ngAkont+dumyhihC+PEocwg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39850400004)(396003)(366004)(136003)(346002)(376002)(26005)(4326008)(186003)(16526019)(6496006)(66476007)(478600001)(66946007)(52116002)(86362001)(66556008)(5660300002)(6486002)(54906003)(956004)(316002)(786003)(1076003)(38100700002)(38350700002)(2906002)(3450700001)(8676002)(8936002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ojAzCs3X+nSNHouIh+g1DUcKGSUCUnvCfpGiP/4uQ7vONt+5eULV9HTWtt8m?= =?us-ascii?Q?evzJhfMtgtWIKztByy2xMwYfG5K8yOuS0MO898CGCgjAJvnOJQevnx58vjVH?= =?us-ascii?Q?dO+qwk0N81UGRIoSm1WH8rKI3raF6HOIDIj1KE5+WS0eSfZZyfviyMWpUbiT?= =?us-ascii?Q?aJdGPqMd/4VO6EXN8OL/Vw1MqyHMoSpew6C8nmVp0Gxnt76GPlZa+qnATnjJ?= =?us-ascii?Q?msB0siBNV4ziSEGobSg9yvRTBQnqqHVLdMKzDqKSWkTbvFc3NwHr0S/G1QhD?= =?us-ascii?Q?s313ZN/rklrv2OR/ZHg6wqJA/NX0JaaPA8r8sazdE2iHZKhWkAIeN9ojC9D3?= =?us-ascii?Q?CHy2IdSOPGgcFlvG6vQeY1QmHZQpv3XhV0qklHcKkvgn5looGrsRI+rUdSmw?= =?us-ascii?Q?aeqMHH8ewARaThaTBkKRCdWvk4QLA1FvP9AYGRGo97NdALeebl9YOAIks9Jy?= =?us-ascii?Q?y6nvQBCruk60AfyeoCbVE7lZV2eSokrFGHN9PYyye5nSIB4iasWG/QYtR+np?= =?us-ascii?Q?kDv9rDsaH7NEUjFY9FFVb+TJFokfdxw8KEVgkbkldbqi6u6+dvy8AWoM9wvn?= =?us-ascii?Q?zzJ5jDnKUbVChrvzppLr4joLeAmayAZX3CHGooZRQXyJuaGv02dIdlwQX1wJ?= =?us-ascii?Q?R/n3/qcEKZgECbgrxY/kWGOwlL2wthMAPRNB2y6IV1sW2pWlyd8qDJgdnvNU?= =?us-ascii?Q?8ClGTWH8JE7nrqexjcMrMhPh+GXnICK9tVgYOGICrp4SooPAbSH9pfzf26uD?= =?us-ascii?Q?dBBNzt3u0js+uXQVB5m8v8KAesXxDsXQ41MgiP1vO3Asf8PE5YDa6biAN68u?= =?us-ascii?Q?Esu7DJk/iIShixlNwswI8b2TeOCbcTqbaHf2fv3x7CDWbHI8RdJVxtvdD818?= =?us-ascii?Q?TI8iXiMPK4KnBUxGqYZT9LSRS9Bmsy4m72Mqv/tZrvkuMjpC2EOAbqlTAE8U?= =?us-ascii?Q?pbwiLil2i0JPtLnrYDXT7/EtpHp3hCGRBSu3vP1+SFtlN8lbXada7TxbtYmf?= =?us-ascii?Q?FvYnXqsCVpk1seDLqYy8y3lJL94ctQnAk0+/kmGR6cNT3vnf+Zpw0G+DySll?= =?us-ascii?Q?rxUwYUuqu2g+jTFNn0ioMJgkiOS35QbTT4Hyj6Kr6p3l65nTVZ4/pUlLR/A3?= =?us-ascii?Q?LJMZaqNTOtkB8AGaQmAtfZXLs0cXYI2lATtML+447qsRXA6gSRUWDP6yflCL?= =?us-ascii?Q?0WrNLHMfWekh+cLSvLRUwf2eSgvqez5sdGMp2l5pmgSpcK9JCI9bCfU82/Xi?= =?us-ascii?Q?opTmwqOVuidtH+ay7MNJhYv5S3yh3D68AP6mB/YZ/LsQf6vINLLCkGJCJMyR?= =?us-ascii?Q?3IX+Sr0H3Zr8S0PcT2Q4Ro8j?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 700a1508-83b0-47bd-9c30-08d93a4fdaa1 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2021 16:14:49.5742 (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: GMtgaDxkZ901um/AKCaxDhJ9FtcxXNEhOkTJNtpP9C9hhs70ZMouG55yccoFIrFZO3mnioM4mV6Nlh7VTgt9M3EH0poN4T3uIElXiGEnyA4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1636 Archived-At: Subject: Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 28 Jun 2021 16:15:00 -0000 On Mon, Jun 28, 2021 at 12:04:46PM -0400, Michael Richardson wrote: > > Juergen Schoenwaelder wrote: > > Note that there is also a middle ground, namely an enumeration type > > factored out into an IANA maintained module that is process wise easier > > to extend - should extensions be needed more regularly. > > That would suit me. How do we do that? > You revise RFC 8366 and do the following: - You define an IANA maintained module defining the enumeration type. - You write IANA considerations for the new module. - You modify the existing module to import and use the enumeration type. - You do not make any modifications to the existing enumerations. - You republish the revised version of RFC 8366. A couple of month later (and after surviving all the reviews), you declare success. I fear there is nothing "cheaper". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 28 09:39: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 5AEE93A0E08; Mon, 28 Jun 2021 09:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 5EPH6BbFXTYC; Mon, 28 Jun 2021 09:39:42 -0700 (PDT) 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 550E63A0E03; Mon, 28 Jun 2021 09:39:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AFD4D38A74; Mon, 28 Jun 2021 12:41:39 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GMReJfF9xs-C; Mon, 28 Jun 2021 12:41:37 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8D0EF38A6C; Mon, 28 Jun 2021 12:41:37 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 96184885; Mon, 28 Jun 2021 12:39:38 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" , "netmod\@ietf.org" In-Reply-To: <20210628161448.23zzsb2iazxgakmd@anna.jacobs.jacobs-university.de> References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> <20210628120924.xuuwnhnvz4jid7sp@anna.jacobs.jacobs-university.de> <26783.1624896286@localhost> <20210628161448.23zzsb2iazxgakmd@anna.jacobs.jacobs-university.de> 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] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 28 Jun 2021 16:39:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Juergen Schoenwaelder wrote: >> Juergen Schoenwaelder wrote: >> > Note that there is also a middle ground, namely an enumeration type >> > factored out into an IANA maintained module that is process wise e= asier >> > to extend - should extensions be needed more regularly. >> >> That would suit me. How do we do that? >> > You revise RFC 8366 and do the following: > - You define an IANA maintained module defining the enumeration type. This is the part that I don't know to do. https://www.rfc-editor.org/rfc/rfc7950.html#section-9.6 says nothing about IANA. Is RFC7224 the model for this? What document am I missing here? > - You write IANA considerations for the new module. > - You modify the existing module to import and use the enumeration ty= pe. > - You do not make any modifications to the existing enumerations. > - You republish the revised version of RFC 8366. > A couple of month later (and after surviving all the reviews), you > declare success. I fear there is nothing "cheaper". =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+93Q3WUFAmDZ+0oACgkQgItw+93Q 3WUMPAgAjBz7Z8ObBGSgsJIzUb8YiPKbrz/v7nfBYkko5hqSu+sCpaDio+efvlSE 4ekFKNv6t3vtz8Gpy3gr0DHj2xZ4gilK5kRXytgWp60V8gjKO68V4bUoAXorncql ajgoUID+R4Xo0o9eh0xy6TEwQ0Z/JuJR/O7vXp0atlUe7vJcnEsSJ/MLUmK989Vy IZf7Z6M6xCtJX0nqqiLuhpNPIp/xKbmbxqsLlqvftnIQmE+BZUQGkWcYX7EBNUry +mIOx6eHEFZZsoy5AMPzlLKJ8V5EFmeIDWU0kPtYu1z6sruzxmqbH4VN+IbdE51h ZmJuqxyyYYtDh2LssR2QPn853sz/rg== =EkZM -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 28 11:21:06 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE79D3A1447; Mon, 28 Jun 2021 11:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vmpD4muUqcn; Mon, 28 Jun 2021 11:20:53 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2049.outbound.protection.outlook.com [40.107.22.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 8E2123A1446; Mon, 28 Jun 2021 11:20:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZSWbbGdz8AOAolcx6Gc0w1pcAWfD09eZI5c4Es6si/sypE4/LMdEtwHbwJprJMwsUIzflUUS0WtuC6Zmvnzr9d8ZX8G73PfPuBOJ5DfYXmS+em9knU7tO0qysXYEqdmi+8NHyrZpoo+Wjmd36O5STtTbOuYeffKG+BO6a+qNcJ+/ih5bCcBN7sXXrjp9nQd2POU1BsrvJtG4L/qnyGwYRfvVydk0IQrrpUTy7tUVRlHDhbg/7YQXeEQoX4QQzP4F7JWMyVKpxPjS85TyVDcBW54sWYuxikY2SV5RXmQODuesaRV6hDN8iozVO2cCwvjLGLBgSx/MwIop/2Gjq2Dwhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LsTNWMWBnqsqnmzjZ+6dGUMJZ0+Gfg1bUMHP58s9Uvk=; b=RQkM/UIhK4vmersjDnNNT7gscCUwlGQFm2doz/X5kjcnUInjQZi9ibNsOO3P8lHVclNeoIrs6kfZKb4DOf/iRJmnfK/KziWP1efq9r4Fhs3EPaj0k0qHHu6FxvUBJbR1W6OvgaeUcLTrES62wr6lvEC/Vh+ivjguBp8S44uqRDPDgpFFrzMPX5c1/w9wZoiH5NJ6SpNoHIh8tFNKkm672ijbQhK09kZWTonYp4EfNRV0TPUVZ5BPV9mRIYm5D3PvLvj05SiuAN8q2n8mfV5tsU4WY5imvgLr/O7pQ4xaJD/0kggsGyzt+eZY2mxa0fJ9IvjgfkbMWguZuS3At+wIpQ== 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=LsTNWMWBnqsqnmzjZ+6dGUMJZ0+Gfg1bUMHP58s9Uvk=; b=eNSVYl2U3duXDejEiRVEF/F5JIRa/AlQ6jcqbSfGhPvEh8CkrbrwhTVahvO9YXP4WmTLSsWl00+dn0Z2kPKUjzEotI3OgsQl8BaDtREQS9jNm/fgMRgUyEDFijKq/bybBVDCOYEEK7AFav80znCh1Qdt3JNyCBV3tpPlIzdPExQ= Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1378.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:267::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Mon, 28 Jun 2021 18:20:51 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4264.026; Mon, 28 Jun 2021 18:20:44 +0000 Date: Mon, 28 Jun 2021 20:20:43 +0200 From: Juergen Schoenwaelder To: Michael Richardson Cc: "anima@ietf.org" , "netmod@ietf.org" Message-ID: <20210628182043.krqzcflymazra52d@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michael Richardson , "anima@ietf.org" , "netmod@ietf.org" References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> <20210628120924.xuuwnhnvz4jid7sp@anna.jacobs.jacobs-university.de> <26783.1624896286@localhost> <20210628161448.23zzsb2iazxgakmd@anna.jacobs.jacobs-university.de> <5322.1624898378@localhost> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5322.1624898378@localhost> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR06CA0082.eurprd06.prod.outlook.com (2603:10a6:208:fa::23) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR06CA0082.eurprd06.prod.outlook.com (2603:10a6:208:fa::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Mon, 28 Jun 2021 18:20:44 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5c2415c0-da2e-4416-16a3-08d93a6171e1 X-MS-TrafficTypeDiagnostic: AM9P190MB1378: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3HT6rlQjhShlPuij+TQB0TtwaQBFc1EqeeH5gM2olqQRftIKGyZinH9wnkITjfvgcO8EIDs97GV1Dvyv085+rjVLUOA2l9JhbUEjOI6n5jLd5gb57JdXWORvgqJt2XokVSotPihgKcoicGMmZbln/r+MMQcbLlH4tiC6eyOZIP/9j/Rxa0/g7wRkQxLC/W1a702+WjlrwALyuujPUe9MQI1QzcCu8qWwcQTUaJi8cYTZM2K5EnxXIzBXfuEoOXOZ0AUjTQEYf5HXhnb657aI78CU2sistDKD5PC+OVlC673+axbaMRXM+HLt1+6QicA9elBDzhsYpK1c5obnXyEHaYveN8LL+/06XTESIc5eeshcp9iecQZCz8GdV7qKWHic2Z+y5TOQWFUrrMx1qYCRtLt8bkHrIfTh4dKegYy1LWMqLs5OBISCaF4jA2Cs/nuKlIUSCkDi2e03t2+1VKX05YEA6Zsw8f+ft/JGdLCQiFUP0spn39s9Sm25/cWfdXCq6OkDQ0ed+MBUvPlf2ol+HrGjrPiYZ4lbxvIfCfFznK4XJnwT8tXdPR5ot1f1f/fPUCHxJkLpV1kShGfeElCwjeL8VjmezRqZ4ETzfl6HP3Uq/Ce5TSTEI3Sd/2BCaYFLj4In1SxgzDrSUx2P1K/ItwRDq4jIEJo3AqS+3OceTcpnKHfmbMtlgPuyEp1rLqryK99+lY4S84SVpFYz1FKZ34YQHKLh6xvjnGEBNr5xFvhY7nRoIDC5LcyYoT7Bpfv8Y8S3vmO1Yot4Ajk4AJNort/MPvItkIXabDqo+cUH/JHBBGFDWUremgj1TPi4ojmG X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39850400004)(366004)(346002)(396003)(376002)(136003)(26005)(4326008)(966005)(66556008)(186003)(16526019)(6496006)(478600001)(66946007)(66476007)(52116002)(86362001)(5660300002)(6486002)(956004)(316002)(786003)(1076003)(38100700002)(38350700002)(2906002)(3450700001)(8676002)(8936002)(54906003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Lc84bnE3Z21JcuSyb2u1ShaELhTra25HWFQT0TQ7C9EJoKmkjtL+abQWJUk/?= =?us-ascii?Q?2S8cOY277IA20Km9vnZKQx6kqVqB6/PqCYQYqhkUqL13z3oeOHMKsuEp8lrX?= =?us-ascii?Q?PJSkmNKKidOhxzb1cESY4xW2qbW9sE2OA3DsEWNjd53xbrb91AJh/OBXgGmu?= =?us-ascii?Q?KQTdI+gF6ZBUtJbLqBHCTQ5r+6bW3hOczojIQ6EK8GRUz1ohviaiUD11cV8n?= =?us-ascii?Q?O4wysaZGwD57JsNJKqqkzyq3x6ZwX6ivCCC1HNNrlZnHHF/7PYTVc1YYZ+Hr?= =?us-ascii?Q?f04+dylBIsgekccb+Kt+rsph9icv9cA1anDpXCv7xJefql+YCyFzQMZuVytV?= =?us-ascii?Q?j2J1Sin9LYNCKu3l25yjKhxpBKh8/MGMqwxprMrzehyI6xfZv5RFJgMZHoBI?= =?us-ascii?Q?lwjsUHMzWJ2vCUePGhW9MJLPl0Gs6hs96XoiicLZ5mVXfNcW5gT53OFKYr/1?= =?us-ascii?Q?I9x8swQJXAyGWcPKY80R8jyl4nE12SD9WOm7k62xXqfCP0ZvLQqTWJxwHp/S?= =?us-ascii?Q?lqICmVb2mzb1wxruFI2bm2vnPcHd5p3VWSuhWUPZbSR+n46LiAus7ScZY74i?= =?us-ascii?Q?GHTem/OMAcswTvWOpqWoF8ESimVT6cYkh9XY2rjbBKCUyLazX0lRIeg6aSIg?= =?us-ascii?Q?I3xJ9VzhCO2OAwPs+EI4L7nl3b+kdhqFzysRcsNfgOhZsjSTSM99hhzWZeY5?= =?us-ascii?Q?TzCSBBRgYIt+kwCBKiOaUASIqF+6GRexGU8hxpkpfWvUMvhCgpXAfW1wuSn9?= =?us-ascii?Q?GtPltjRSoE9Y6WTjG5fAN2EgAtLxQMIzA26+GzyK5Mb0zxujXGogYL97N4Dc?= =?us-ascii?Q?rPy6K4NH1/N7FJvBuJQydZ4YxsAB9ds/bGLESQs/N80QR66lmgkh/1WYd+pj?= =?us-ascii?Q?PaooqiUlRF/bNGkkJTd6V8IsoHf9LfrDNsEbwkqf+Yl14dHplDgL/RMP3LSv?= =?us-ascii?Q?dBjhfi+SXQh77K/AUoNBRfyNVFM6Gi6GPdXWxED65wskCGMqXfJihL2nJ5zS?= =?us-ascii?Q?VRKeOqOFhk8z6bBnxjZZ/ieCJpuEY5mmbnFruEJ1Fm4effppkTQCqa3sCkvY?= =?us-ascii?Q?zFPuvv3UEsAlVh7isjjYwiYG4XSjTgKTxMvZ8JcoWBT0as2SKyGLJwnaUeRK?= =?us-ascii?Q?4W/lHrzinM8aAa3egJWjz8eM6BQF5UEfU2KMZY03nnZWbxxgq62Tz1VZDC6T?= =?us-ascii?Q?kvidtihkFTglQiUdA9JyL4IdrytByfd7HkmRFKLyEO8fBWsat6dCgaU0jriw?= =?us-ascii?Q?1jVrxKmFWowcO8e4TcZyut7u6b8chYyxm7zwbVDwWMbHSx365CffwPydfDeR?= =?us-ascii?Q?/vAj7P/alh1y0Oe2W20wya56?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 5c2415c0-da2e-4416-16a3-08d93a6171e1 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2021 18:20:44.8980 (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: b0vIF3CiPv7Utr1Q7mEVfyQwJYy3yIcNi1fZcfRZIOlRhPTtxzAMYp8anPpdSNbXzlyvs0GVSiGhPzZY5LkqvpN9EitSZ4vo24LP+P1DIA8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1378 Archived-At: Subject: Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 28 Jun 2021 18:20:59 -0000 On Mon, Jun 28, 2021 at 12:39:38PM -0400, Michael Richardson wrote: > > Juergen Schoenwaelder wrote: > >> Juergen Schoenwaelder wrote: > >> > Note that there is also a middle ground, namely an enumeration type > >> > factored out into an IANA maintained module that is process wise easier > >> > to extend - should extensions be needed more regularly. > >> > >> That would suit me. How do we do that? > >> > > > You revise RFC 8366 and do the following: > > > - You define an IANA maintained module defining the enumeration type. > > This is the part that I don't know to do. > https://www.rfc-editor.org/rfc/rfc7950.html#section-9.6 > says nothing about IANA. Is RFC7224 the model for this? > > What document am I missing here? Yes, RFC 7224 defining the iana-if-type module may serve as a template. There are a couple of IANA maintained YANG modules, I am not sure whether we have a good place listing them all. Well, you can filter out the iana- modules from this list: https://www.iana.org/assignments/yang-parameters/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 28 13:04: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 97E133A0D9B; Mon, 28 Jun 2021 13:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.896 X-Spam-Level: X-Spam-Status: No, score=-11.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NizJOQ1h; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pMTJ2XoV 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 leJrHse7i49i; Mon, 28 Jun 2021 13:04:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64BAF3A0D98; Mon, 28 Jun 2021 13:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3342; q=dns/txt; s=iport; t=1624910650; x=1626120250; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=eWphDnupZamTNmvk7cfZ+LeD/4heWF9xkvDKL/Fsl/s=; b=NizJOQ1h/YwHyK4FIHeWfv1aEY5lL1aLDRFvwpAw1wwll+7C5eupcFct LLBmE6L7oQnTJiCQDquS0+zun3eoZz8co3BTT9F81p3dKDkCFysHJ4jMs BOvKjW3MlQ4vAzaH+cSjFp9jg6bgINjD5Ui5Xbvye1cSNtyKIgg+aGRpx A=; IronPort-PHdr: =?us-ascii?q?A9a23=3AEzKiVBa7SmaRIie98MO1TmD/LTDNhN3EVzX9o?= =?us-ascii?q?rI8grRCf6Cm9pKkN0WMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAF?= =?us-ascii?q?npnwcUblgAtGoiJXEv8KvO5dCU8EMlGUVZjuXqyYgBZHc/kbAjUpXu/pTcZB?= =?us-ascii?q?hT4M19zIeL4Uo7fhsi6zaa84ZrWNg5JnzG6J7h1KUbekA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AIRKjO68d/rsjb4r5Nn1uk+Fddb1zdoMgy1?= =?us-ascii?q?knxilNoENuE/BwxvrBoB1E73DJYW4qKQ0dcKO7Sda9qBTnhN9ICOgqTPmftW?= =?us-ascii?q?zd2FdAQ7sSlbcKrweQfhEWs9QtqJuIEJIOSOEYb2IK9voSiTPQe71LrbX3k9?= =?us-ascii?q?HLuQ6d9QYWcegAUdAG0+4NMHfjLqQAfnghOXNWLuv52uN34x6bPVgHZMWyAX?= =?us-ascii?q?cIG8LZocfQqZ7gaRkaQzY69Qinl1qTmf3HOind+i1bfyJEwL8k/2SAuRf+/L?= =?us-ascii?q?+fv/ayzQKZ/3PP7q5RhMDqxrJ4dY6xY4kuW3DRYzSTFcNcso65zXYISSaUmQ?= =?us-ascii?q?8Xeez30lMd1gJImivsly+O0EDQMkLboUgTAjfZuC6laD3Y0JbErPZQMbscuW?= =?us-ascii?q?qfGSGptnbI9esMoJ5jziaXsYFaAgjHmzm479/UVwtynk7xunY6l/UP5kYvG7?= =?us-ascii?q?f2RYUh5bD3xnklW6vo3RiKn7wPAa1rFoXR9fxWeVSVYzTQuXRu2sWlWjA2Eg?= =?us-ascii?q?2dSkYPt8SJ23wO9UoJg3cw1YgahDMN5Zg9Q55L66DNNblpjqhHSosTYbhmDO?= =?us-ascii?q?kMTMOrAijGQA7KMmiVPVP7fZt3dk4la6SHqYndwdvaN6Dg4KFC7agpYWkow1?= =?us-ascii?q?LaIXiee/Fm9Kc7hiwlbl/NLgjQ9g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcCgC/Ktpg/4cNJK1aHgEBCxIMQIM?= =?us-ascii?q?qUQd3WjcxC4Q9g0gDhTmIa5ogglMDVAsBAQENAQE1CgIEAQGBXoJ0AheCWQI?= =?us-ascii?q?lOBMCBAEBARIBAQUBAQECAQYEcROFaA2GRQEBAQECARIRBA0MAQE4CwQCAQg?= =?us-ascii?q?RBAEBAQICJgICAjAVCAgCBAESCBMHglCCVQMOIQEDC51lAYE6Aoofen8zgQG?= =?us-ascii?q?CBwEBBgQEhUQYgjIDBoEQKoJ7hA6CZ4N4AiccgUlEgRVDgmA+gQR7YwICgWC?= =?us-ascii?q?DFTaCLoMagUEgeDSBK5RSpi+BFQqDIIoYlBQSpgiGZ48BjCOYOAIEAgQFAg4?= =?us-ascii?q?BAQaBaySBWXAVgyRQFwIOjh8MFhWDOYUUhUpzOAIGAQkBAQMJfIoyAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.83,306,1616457600"; d="scan'208";a="636718455" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jun 2021 20:04:09 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 15SK48iW032669 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Jun 2021 20:04:08 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 28 Jun 2021 15:04:08 -0500 Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 28 Jun 2021 15:04:08 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 28 Jun 2021 15:04:07 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KINLwiLmQPKPPM8rqoCaVeNxntUfWcl6qzaeqbwfffmq9bDr66278HPNNjslYjiFNZy7MgbiExr/PdxVOmLtWgLpoKVL88QydqeBdLOUIG+ZSoMFZmqAgai6s766eNWheqbt2UBcON2kpW/reyhZO9ur0vGsgdPXIaAsMqOWuK3w0M5kmp9atNpQPU5axynY6FtYtvSWTkaCthZp0jRBZG2l+J3HLhs0U4WqeA6DBeYFo8yOX6d76c5v4BYflxUzbW0+mGZi/Br5erwSClIks8Nhj7gsxYvruw0sVw0g81Uw98jETC6i6GYre1phLilzcHfuAE0dgut32FY+6a3Ubg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eWphDnupZamTNmvk7cfZ+LeD/4heWF9xkvDKL/Fsl/s=; b=DCe8MFlTrPwYcmqYvwUWlSb26Ho4htrbft9p+crQeuQT4KR3AOWazAZIkT04Y64YyvHXbTubwxsI/OlWj3F3UV5LKGXn1p1pym7hZUoHn8ssl/wK7dznm0wZp/HbT/AFAkjnaE1uyecopSgHSqPoAC9Z+HPzit0MzrCZcCk4bqiwj8xTiLtf3T01mmIzKgij32JMnCQo7IudgMxJ3RGqOywLgQ0dEUP++gC1thqaXl19LEPHOSDhy104fwL/r1Cr9J5pxz1HQ9j06kQHOXBv70MhVZlpfwHoVjb88gaddhKar52R7+cw3KB0RLCjQR7oW20NPN2IlU38ZELsVuvu9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eWphDnupZamTNmvk7cfZ+LeD/4heWF9xkvDKL/Fsl/s=; b=pMTJ2XoV3yTvwugDt4Tge7HqVOjtDyjXlOPDN5uxebNoe8Nq2RNBdnFJxKdaCNZDwVuQdm25FzYnN26xUOqTVvRIk60uuI+ZZcmC33ov3DB6HQ3wzGVP0CPOzA3mP6cAvtb8rApa6sUWCR+hrlCSDx3jZNETClzwZ6jRIpSKJYU= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM5PR1101MB2331.namprd11.prod.outlook.com (2603:10b6:3:a2::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Mon, 28 Jun 2021 20:04:07 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c%7]) with mapi id 15.20.4264.026; Mon, 28 Jun 2021 20:04:07 +0000 From: "Rob Wilton (rwilton)" To: Michael Richardson , Toerless Eckert , "Fries, Steffen" , "anima@ietf.org" , "netmod@ietf.org" , "Kent Watsen" Thread-Topic: [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? Thread-Index: AQHXagKBMUPXQfFzDkG5oxc/ZPlW46sp2/9w Date: Mon, 28 Jun 2021 20:04:06 +0000 Message-ID: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> In-Reply-To: <5025.1624653668@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dc69316f-1da7-4996-2273-08d93a6fe2d0 x-ms-traffictypediagnostic: DM5PR1101MB2331: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W4DQF1Thrv4sKys3WmR3xmVCpdVwrY/Qjgs9WkqjMdtdnJSFKb1u8l9q+xSULVOgqG3bm7uahaLmB+0RhpQ12SSw40ES/6wJI318OZqs4tcA7qA3dxz5bZubLQ/X9D6DyjiH+7sqqc5TC5L7tsDohOamQ6R/CJ4tyDaqP3dEGLDe8su0VOed8TA/9T/R56VSGVUH/wzXUYJ0tcq4JolWIwvc55SLXHj3dtTw5M+b+nEW2u0xkXjRXRV4Yx3vbPohazFbetXbeTvHUoTZk9+ebG5CAFh4f1Tf+6FSM1XFu1Tu6vVU1y8nyo7mgosAn+VvcGdaSvcs+krcsGH8mx+lzcE1b5cDnQVEnhvc4RUJiM2QmMv4Rqpg5LrQOWgX6NgbIrUxPLyq4jGPvkgx53eVphJZYBJzXgQh4QjXAOubPuuor4IEKVs5QrX/NxGa80lO6FHoBIx7i1OaFU8PFmSv/uNTQQN3G9//eNJPRVar7wa/YxIt2p049KkIFoc8b56RSQuvSM4CW7dbGFjFDlEwiYF//IUL7zMwyVig4Tq0B1Ye/uERFzGjCFkUHvjebMMMYG6yiHzZKsChqLD+mNxIpNlUAa4dZVDMKxKwFu0QN6BEh7OwIffoouK4qPR1jYKTWHvhl7lVc6SJfNE3NuxmiJWZlCrjkMMYXRcVB2ZjEcVeCHbzUAkeCkQVFbSE9rcVoocxO1S80juHQPZ0jtdtStMl+HYvcrUSax8e425tqYQKUFc3sFWlvBzjK1jVhWWilisxr3BYmXTmHAm+YQBrKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(396003)(136003)(376002)(366004)(2906002)(110136005)(8676002)(33656002)(83380400001)(66476007)(71200400001)(7696005)(5660300002)(64756008)(66556008)(478600001)(66446008)(38100700002)(122000001)(53546011)(6506007)(966005)(76116006)(9686003)(55016002)(186003)(8936002)(86362001)(316002)(52536014)(26005)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dVNmS252OHFOeEJodUt0VXNsZFRZUXVJYmJRbmo0VlZFWUladE9QeVVzM1lJ?= =?utf-8?B?VHpFZDRrNkI5MHptUU5abmdNTU56TlQxWG5jVjNVdU9zL3FNQU16U2ZacUx2?= =?utf-8?B?NUhydmdobXZoRlpUbVNUM01UZmhNVUVuSWNqMDhoY29IaFE1Mm5VYlVEeU1s?= =?utf-8?B?MFgxYU1DbXo4OUdxdHlWVFM5N3E2d1NRUkVDSmhXMWdBMmFrd3NhcFA1SldP?= =?utf-8?B?WWhHYStOSDdKOVlkYnkyTnJSZ1d5UjliME03VDFpRmR4SlJQSm1hVDBMWktk?= =?utf-8?B?NGlCTHVQRHlaeW9wbXNpTW1ydmlYeEpmOStHMVh5d0dKNi9CUnhJSkRQdytO?= =?utf-8?B?MnRUZEl2S2toU2ZKZGZIN29CL0IyaS82MzJXTEI3RWI5WUJQcGVVZFJRT25D?= =?utf-8?B?SmtpVEs1S2xzQUFDUTNLS0twcVBuUXNKTFU4M21YeXQybVlzUklMa2J5aFdq?= =?utf-8?B?QWlHY05HK3gvU0J2aFJBc050V2hQRGxQZXE0c1JYNjFMbkl5SUdTZExoZkxI?= =?utf-8?B?MmNMNUw0Wm5aeVFVdUdXYXRINlRGQTJkV3B0WGQ5T2p0c1RoV21HaWlnQ29h?= =?utf-8?B?OFRDQ1dNVHVYYXo3bDE2a2t4Rm1ZZGFYTkF6MTc5OWE2QUgrenZpR2FXMWpG?= =?utf-8?B?TVBEZCt4eERZWW1yaVE5MlNOeXJpblpUNzYvODRsc2VkUnpNcm9iMTRheTZm?= =?utf-8?B?aC9uK0ZVRjNPQUNGRUpXOGFVQzRvaHVLaERvWGUvOFRxMXJxTmFEWjYwYTAv?= =?utf-8?B?TGVtYkZQdml2bFRiWmRkbHJiaHp4SjEzWko1bWlhZjhwK3FtS3lmdFluclk3?= =?utf-8?B?SzZwaFNqUC93YUNMUFc1OEJYc1VFRnVjOHJ4VFkzMEhkcXpsRnlCZ1FRaHJx?= =?utf-8?B?eEE1N3lQYk5RQmoxK2JXS2JvM1BOcWNPb2k2VEZpSUtzaVdrYklpWE5CaVZt?= =?utf-8?B?YjRvMFI4UmhzUXkybFVtSDNhODBNVVBXMkVuN1I1YW15WVBRSjZOTi9jUGZ5?= =?utf-8?B?OUNha2F5MFduQjBqRWNoc282d2RvYVRGS1BpN0lXTkxiVTdsVEZYaFJhSkJl?= =?utf-8?B?ZjJQaldqWHBsRTRVT2xtaFZ0MUhQZnM0OThoWFgvUFFKTk9zaTNvOTQwQ0pS?= =?utf-8?B?dnM5emJMUm9BSEUveTFyakFOVmhIWEwwRjR6R3RPVm5WYUdrRzd1T3JIem0v?= =?utf-8?B?RENhMEl2SnRpSmZxTElVbEJ3UytZeDF3ZWJqd0pTSzdaaEpTOVhsZVVkZnlC?= =?utf-8?B?V0V5cG9yaW5IdGN3UHFUdDhzRlN6YVlqd0hETnZyUkVlMGhmSVRaSHlJQ1M1?= =?utf-8?B?VW9sK0RXbWVUWTZnOEpRTlV2bmcwQTVWRVJ5ZmExZi9MQy85NTRKbmJxV1NI?= =?utf-8?B?ayt0aktINVkvRmlpZk5laFozUmJOcGY3ajNGWmlDNzRzNEFIV0xFWUJoWFBl?= =?utf-8?B?VTQrdm5pNzV4TkpQYjVNcENXc3JMSFlSZ0lRYWcwbjhaQjJzVVROMTVQRXZM?= =?utf-8?B?UC91ZEhOTTVSZ0dDZityNVh4SG5ZNk9BRW80T0E1NkxpNUVTNDVoRTFxZ2Qx?= =?utf-8?B?YytWdzhML2c1UUluektGN2JuUC9tbWxKa2NuZ002TTRKaFlFVWt0RFAyczFY?= =?utf-8?B?U0NkeExMRjhFUU9MUHJ2eE1CTUpSYXBGYnFoMXgvVzRLYWpmL2xZRm9pVGR3?= =?utf-8?B?NFNBTXZxZkNEY1IyTHZ3RXNyK2JaYWVyZXhSK3BQbE5IVHhmbHRLa0hKc0JX?= =?utf-8?Q?H5Oex6b/KY1qKbaaijfX2Y7IGkfZdQBiB/3h8TQ?= x-ms-exchange-transport-forked: True 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: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dc69316f-1da7-4996-2273-08d93a6fe2d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2021 20:04:07.0210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tiVGkZIWHCzpafrczAxcMvT6DP4AEJlrzKd0+0qW1JY9Jb54YWHJXGGmbXHJHBEY0pd8yVDUa3CVIMQSxi+m4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2331 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 28 Jun 2021 20:04:16 -0000 SGkgTWljaGFlbCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmlt YSA8YW5pbWEtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1pY2hhZWwgUmljaGFyZHNv bg0KPiBTZW50OiAyNSBKdW5lIDIwMjEgMjE6NDENCj4gVG86IFRvZXJsZXNzIEVja2VydCA8dHRl QGNzLmZhdS5kZT47IEZyaWVzLCBTdGVmZmVuDQo+IDxzdGVmZmVuLmZyaWVzQHNpZW1lbnMuY29t PjsgYW5pbWFAaWV0Zi5vcmc7IG5ldG1vZEBpZXRmLm9yZzsgS2VudA0KPiBXYXRzZW4gPGtlbnQr aWV0ZkB3YXRzZW4ubmV0PjsgUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29t Pg0KPiBTdWJqZWN0OiBbQW5pbWFdIHJldmlzaW5nIFJGQzgzNjYgLS0gUmU6IEJSU0tJLUFFIGVu dW0gaXNzdWUgLT4gZW1wdHksIGJ1dA0KPiB3aGF0J3MgaGUgZW5jb2RpbmcgPw0KPiANCj4gDQo+ IFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZT4gd3JvdGU6DQo+ICAgICB0dGU+IGh0dHBz Oi8vdHJhYy5pZXRmLm9yZy90cmFjL25ldG1vZC93aWtpL1lBTkdfRkFRI3doZW4tdXNlLWVtcHR5 DQo+ICAgICB0dGU+IElzIHRoaXMgdGhlIHNvbHV0aW9uIHdlIGFyZSBsb29raW5nIGZvciA/DQo+ IA0KPiANCj4gaGVyZSBpdCB0aGUgcmVsZXZhbnQgdGV4dDoNCj4gDQo+IH0gVGhlIHNlY29uZCBz aXR1YXRpb24gaXMgd2hlbiB5b3Ugd2FudCB0byBkZWZpbmUgYW4gZXh0ZW5zaWJsZQ0KPiBlbnVt ZXJhdGlvbiwNCj4gfSBhcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgdHlwZSAiZW51bWVyYXRpb24i LCB3aGljaCBpcyBub3QgZXh0ZW5zaWJsZSBieQ0KPiBvdGhlcg0KPiB9IG1vZHVsZXMuIEZvciBl eGFtcGxlIGlmIGFuIGVudW1lcmF0aW9uIGlzIHVzZWQ6DQo+IA0KPiB9IGxlYWYgcHJvdG9jb2wg ew0KPiB9ICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+IH0gICAgIGVudW0gc210cDsNCj4gfSAgICAg ZW51bSBwb3AzOw0KPiB9ICAgfQ0KPiB9IH0NCj4gfSBhbmQgd2Ugd2FudCB0byBhZGQgYSBuZXcg cHJvdG9jb2wgJ2ltYXA0JywgaXQgbXVzdCBiZSBkb25lIGJ5IGFkZGluZyBhDQo+IG5ldw0KPiB9 IGVudW0gaW4gdGhlIG1vZHVsZS4gQnV0IGlmIHdlIHVzZSBhIGNob2ljZSBvZiB0eXBlIGVtcHR5 IGluc3RlYWQ6DQo+IA0KPiB9IGNvbnRhaW5lciBwcm90b2NvbCB7DQo+IH0gICBjaG9pY2UgcCB7 DQo+IH0gICAgIGNhc2Ugc210cCB7IGxlYWYgc210cCB7IHR5cGUgZW1wdHk7IH0gfQ0KPiB9ICAg ICBjYXNlIHBvcDMgeyBsZWFmIHBvcDMgeyB0eXBlIGVtcHR5OyB9IH0NCj4gfSAgIH0NCj4gfSB9 DQo+IH0gdGhlbiBhbm90aGVyIG1vZHVsZSBjYW4gYXVnbWVudCB0aGUgZmlyc3Q6DQo+IH0NCj4g fSBhdWdtZW50IC9mb286cHJvdG9jb2wvcCB7DQo+IH0gICAgY2FzZSBpbWFwNCB7IGxlYWYgaW1h cDQgeyB0eXBlIGVtcHR5OyB9IH0NCj4gfSB9DQo+IA0KPiBXZWxsLCB0aGlzIHNlZW1zIHRvIGJl IGV4YWN0bHkgd2hhdCB3ZSB3YW50Lg0KPiBEbyB3ZSBnZXQgdG8gcHV0IGEgZGVzY3JpcHRpb24g aW4gdGhlcmU/DQo+IGNhbiB3ZSBwdXQgYSB2YWx1ZSBpbiBzbyB0aGF0IG91ciBTSUQgcHJvY2Vz cyB3b3Jrcz8NCj4gKEkgaW1hZ2luZSB3ZSdsbCBoYXZlIHRvIGhhY2sgcHlhbmcgdG8gbWFrZSBp dCBjb3BlLCBidXQuLi4pDQo+IA0KPiBwcm9jZWVkdXJhbCBvcHRpb25zOg0KPiANCj4gMSkgd3Jp dGUgdGhpcyB1cCBhcyBlcnJhdGEgYWdhaW5zdCA4MzY2LiAgVGhhdCBzZWVtcyBhIGJpdCBtdWNo IGZvciBlcnJhdGEsDQo+ICAgIGJ1dCBob3cgbXVjaCB3aGlza3kgZG9lcyBpdCBjb3N0IHRvIGJy aWJlIGFuIEFEPw0KDQpEZXBlbmRzIGhvdyBleHBlbnNpdmUgdGhlIHdoaXNreSBpcyA7LSkNCg0K TW9yZSBzZXJpb3VzbHkgdGhvdWdoLCB0aGlzIGNhbid0IGJlIGRvbmUgYXMgYW4gZXJyYXRhLg0K DQpBbiBSRkM4MzY2YmlzIGlzIHRoZSByaWdodCBvcHRpb24uICBJZiB0aGUgY2hhbmdlcyBhcmUg bWlub3IgdGhlbiBJIG1heSBiZSBhYmxlIHRvIGVhc2UgdGhlIHBhc3NhZ2UgdGhyb3VnaCB0aGUg SUVTRywgYnV0IEkgY2FuJ3QgZG8gbXVjaCB0byBhZmZlY3QgdGhlIGVsYXBzZWQgdGltZS4NCg0K UmVnYXJkcywNClJvYg0KDQoNCj4gDQo+IDIpIHdyaXRlIGEgZm9ybWFsICJVcGRhdGVzIiBSRkM4 MzY2IHRoYXQganVzdCBkb2VzIHRoZSBORVcvT0xEIHZlcnNpb24gb2YNCj4gICAgdXBkYXRlcywg YW5kIHRoYXQncyBpdC4NCj4gDQo+IDMpIGRvIGFuIGVudGlyZSBSRkM4MzY2YmlzLg0KPiANCj4g LS0NCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8g KCBJUHY2IEnDuFQgY29uc3VsdGluZyApDQo+ICAgICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzIEluYywgT3R0YXdhIGFuZCBXb3JsZHdpZGUNCj4gDQo+IA0KPiANCg0K From nobody Tue Jun 29 01:48: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 7AD0C3A2B96; Tue, 29 Jun 2021 01:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNwTZbsPxB6j; Tue, 29 Jun 2021 01:48:14 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00136.outbound.protection.outlook.com [40.107.0.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 026E73A2B94; Tue, 29 Jun 2021 01:48:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F7HwdIqvmHu1v3wOInBpHW59ksDUpJN53szrwF9fn97T8Zmwwo+k9XhcEusJuSzMFzr1S5LMUVV9MW+sUqOPs1n1pbZ347StL2Um/xsvZYCAAS79hsX4Au7eTR0LFGl5Rj5fHZvjBxRgLVVgywQ9HlUUgb1yvNA6KbtqVKF9Hk97adQrQQBingUSEp2Fjc2vklWYyzUGgrF6AXCbXCabY0HHB/EM5mxeiCCeeRy5f/E96Q+lBoe8Vh1x++1O2sF6lpbz4LhfQctmeC4iU3LE4joxwXw33nRxV5WvqlYYeXmjHLkE9YgzOoHM5CfnM3iOtzGedjP8gyIhGj6Ru3nM/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-SenderADCheck; bh=A2IpFD8Npy8Loq17NuCN3GW8YA2SDY4PHxWrh+RghYE=; b=LIOLMXJgESc5VdwAhfaCxj32BQyV4/lp47BQWutKMCArQvncvt1eNl+yG5E5nd4iBlg7isgVrGMm2dl5CzAwVCJrbINOQ/g/NDhG5BU8A7sP8wWP9w0p7jX2tbgd4F5fW4zoQtq26r/3/bUmVtAnQU++M57FCS+SaKEpEX4ARollnWwzrGHRur8t5AFm6cDDflxXgm7Qqb2A5LWvH3fW94i7Y8hFmrRviJFtfSxssEkUpHWfkUxHQ3UIPZUmxMbc9Kpuabrtfa30c8SKI63q650ncdyG8+BEh/KuT3QG+05oZmP8cfZ7BZZEBxm2/Pbmmr3z4z/9qz/jn06YKAO5fQ== 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=A2IpFD8Npy8Loq17NuCN3GW8YA2SDY4PHxWrh+RghYE=; b=ERRrmyMorja83EOEJKV61Yckg0jOrI7wF+2nwTsPDQfi8zTMo3Peh644uy6HF0OyNP0PC1nkA579SLQP9bhJ5MGZn65xh6zBI1eA4mD4niIi2aMbOJPl2ESTgZSU6CXuislrRhfreHmJDWTBwtjKe2/23RQUVocVfhhSx3C44cA= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB3974.eurprd07.prod.outlook.com (2603:10a6:209:2f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.8; Tue, 29 Jun 2021 08:48:11 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d%7]) with mapi id 15.20.4287.021; Tue, 29 Jun 2021 08:48:11 +0000 From: tom petch To: Michael Richardson , Juergen Schoenwaelder CC: "netmod@ietf.org" , "anima@ietf.org" Thread-Topic: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? Thread-Index: AQHXagJ4SmLy7OhzB0KCTs+uGzc5c6slVFIAgAP9gGWAAAcHAIAAQcMAgAACzQCAAAbwAIAAHD6AgADv118= Date: Tue, 29 Jun 2021 08:48:10 +0000 Message-ID: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> <20210628120924.xuuwnhnvz4jid7sp@anna.jacobs.jacobs-university.de> <26783.1624896286@localhost> <20210628161448.23zzsb2iazxgakmd@anna.jacobs.jacobs-university.de> <5322.1624898378@localhost>, <20210628182043.krqzcflymazra52d@anna.jacobs.jacobs-university.de> In-Reply-To: <20210628182043.krqzcflymazra52d@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cdd4319c-053e-4c7a-a80e-08d93ada9fee x-ms-traffictypediagnostic: AM6PR07MB3974: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8A/18orJuGazQsj2BwNBzJm/Db4/Omvf5pGcAp2p6K3ad1RS2AVPMQFJM7X/OVJaz3H9EHeE+Fnka+jc8q9x8tphlWryERgD5cV4dcD/aGiQHsmg/U1pqj/oQXqDzxVTFV6PFuyQT5dbMEsHqeM3Rzlc9GmlubJF5w28h0TtTUBHsvYdN6OD58/R5pHc22I6jz0fnVkyqjNV30Cjlmg1awZWeVoHk7RtqhD0tR+ja8FxMRH/bgF+XgM8385fMv0rNsVBTlEz3duatPk523nSb2lrPtJ3BGT0IM+30Hrc7NHJLnVMEAhYpygJDK5KYeOyXMWr9aOWFhh9ar9awo1K96hkWC2c3CzZvC4WcexU7yY786aDiItBLqP2jId59Oqp4gi6Pt/TAUz0Q5JUTz/C5Bb7p/g/4uRSxdZjA+xYON3LcqrRoMmfHi2CfYgI8xx1jVsJqOkaJDdRBbEz4HBnpgZFamBf38WuvIxPcxtKDfiehYgm5tK/5VjyeI7FU44lohXPPAfcZjU0jbRoHVmDT+KO8bBUk1ywAnlmHMffiBhHwouCCzEgUsA9CY67wXE5DRspbM7ogM4suRM7yalsEu12Q5+gpwEvTSWv4MEnJiIf0cNaglb7Fj3vbOOZck2c2IJCBxU5ycL04Zcb5j9zPJ0Y27v1ZfUcJ6Em+w5dRPQhbopDxFpklGngB15hLjBvGlE+TfBR3l8u0VFH/2qDd5O+rNyknUerzpdoZ4xoH0SCUFxU5DN0ZBZPa5hqZm/ehTCk/Mz6xzAwpoWBM+Fe2KkOx95Mw2gdA80eTwKvM0c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(39860400002)(346002)(136003)(376002)(71200400001)(186003)(26005)(66446008)(64756008)(66476007)(91956017)(66946007)(76116006)(66556008)(86362001)(478600001)(966005)(9686003)(52536014)(55016002)(6506007)(5660300002)(7696005)(316002)(33656002)(8936002)(110136005)(122000001)(54906003)(8676002)(38100700002)(4326008)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?YW6GY5AnSdScguzSsvzEpnOKCRra3ccLVRgB7AXvoJ+OeYmwjdPzzX/FwR?= =?iso-8859-1?Q?IJYgxrBNvA3IcIOH3D5uSjT3uQ4tWMvgTHdKwfJX6HeMmmEPeFhC4W4BL7?= =?iso-8859-1?Q?QHwohpbLhhdSX4VHqexpPBaYvi/4R0fAyTV+co3XQSJ9M4vmN1FZYGTsSg?= =?iso-8859-1?Q?0RT3cwg4iQCEY+APQBgabVJgLPYeuoQigiGhSdZYLzVGb9ss3IHjp0QLiB?= =?iso-8859-1?Q?OwqZdj0fW4AMBLJyepL+AiKjQvbdOJD0NncN9g/GZRjD0nFxza9qZB2uD5?= =?iso-8859-1?Q?QgBrAPjLRXwvvovLfmFjXbJ6ozujL02h/WhuedlsC/C8J4fa3A0ljEs29e?= =?iso-8859-1?Q?af5hdPkb5NIdV+MMlNaLV/lV0iqNV4Mk2ZbDfIHqwuBGk5Tbn/msGQrvNQ?= =?iso-8859-1?Q?rg9MBrrm+QnahFNz9LdBFaJiLjdIKvBiQcOrxoyEYCFhgrTy6PGp5RW/vn?= =?iso-8859-1?Q?YuM6egsavWXA30XRTy4ILWRRTrlcyrzkNlLvYKVkMC+tYQG6QjwHaLpvpq?= =?iso-8859-1?Q?PIf9qO2uncrnAClD7T0xWVi3NDyyC1Uz4EWfS9ZUzT7KOmg3eYsodN6NJR?= =?iso-8859-1?Q?XhaJ5SoHC1eDDJ+4wqUBXV6p+rY9qENKlrPzusF1PfHQ2SPOPSZwyz1nga?= =?iso-8859-1?Q?WDGQcpFCSkrOKV7KVe3Eu0viWU4v5Wpu9fO6Z/uSv155Uhk8norBVZoEJj?= =?iso-8859-1?Q?U/hYIcTlr4Z5HOhnaR41B9z+WhrIzUVXu2F82inyPiVuvUSrRzPr+riUX9?= =?iso-8859-1?Q?8eGZyqFJPREHAea+GEg1HR5xF/Rpz/rKGNvwOy/Amfdwr5vOkk/UYj3rqH?= =?iso-8859-1?Q?WvcXbDXGCQeqt82u+KuOt72C3GB3EkeVnLGfjW51Ws5AMofI3Ovvez3YHq?= =?iso-8859-1?Q?R3mIxhq6bdOvrbC9ERfulceXAmKpOdjCDn9qI0Cp/SKFcdzYycmcJyt0tx?= =?iso-8859-1?Q?IKwWLwawUebhkzg5HntAagm8wQ5ilELbnbxktRlzP8Etr5jLQGuctA3Auf?= =?iso-8859-1?Q?V9KdDQlExGOyI9vFtXcmjOJVwPYqJV6BV3huRlHsG6HqO/nb6XLw4iNbBp?= =?iso-8859-1?Q?r6yd6dqc5IF7ouS9VJMu97gDpumlk/RVcwNCBZYV5HEC3wguaXvHGG+qO8?= =?iso-8859-1?Q?OgKcWcMmYjGlTGVy78MOcOK6a9RNtFcXj+Jej1MTk8Xb56RHPyJyGf1KEu?= =?iso-8859-1?Q?dNq5ral2CLsX9TJrXZdHHvPq2o59SCyu4ytSyiY1gUXtDaxOSbuujxTaNZ?= =?iso-8859-1?Q?Cb96y+G9u70vvosabInoGUW+Panv5jPjIE1inI3NrYEqmFOAMMBT+QmotL?= =?iso-8859-1?Q?OHOwmYa65eMURzF8kuAPZ2PSUjBjNFW9yuq2eFUOajh6Hl8=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdd4319c-053e-4c7a-a80e-08d93ada9fee X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2021 08:48:10.9597 (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: Bcuduez7/SbZJYdlNR1GLPcm5hIuI50psVyWP00J/yEkmfhLloja/UIYoV/Vz8y3Claev0yNKopBz9LDEeDJqA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3974 Archived-At: Subject: Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 29 Jun 2021 08:48:20 -0000 From: netmod on behalf of Juergen Schoenwaelder <= j.schoenwaelder@jacobs-university.de>=0A= Sent: 28 June 2021 19:20=0A= =0A= On Mon, Jun 28, 2021 at 12:39:38PM -0400, Michael Richardson wrote:=0A= >=0A= > Juergen Schoenwaelder wrote:=0A= > >> Juergen Schoenwaelder wrote= :=0A= =0A= > > You revise RFC 8366 and do the following:=0A= >=0A= > > - You define an IANA maintained module defining the enumeration typ= e.=0A= >=0A= > This is the part that I don't know to do.=0A= > https://www.rfc-editor.org/rfc/rfc7950.html#section-9.6=0A= > says nothing about IANA. Is RFC7224 the model for this?=0A= >=0A= > What document am I missing here?=0A= =0A= Yes, RFC 7224 defining the iana-if-type module may serve as a=0A= template. There are a couple of IANA maintained YANG modules, I am not=0A= sure whether we have a good place listing them all. Well, you can=0A= filter out the iana- modules from this list:=0A= =0A= https://www.iana.org/assignments/yang-parameters/=0A= =0A= =0A= =0A= There is what would be a good place but it is on the IANA website and that = is never a good place:-( AFAICT there is no URI for it but if you go to IA= NA Parameters, click on the letter 'Y', it takes me to =0A= YANG Module Tags (no URI)=0A= below which is =0A= YANG Modules (no URI)=0A= which is not YANG Modules in any expected sense but IANA-Maintained YANG Mo= dules. (But if the title was sensible, then it would collate under the let= ter 'I' and I would never find it again:-(.=0A= =0A= Anyhow, cynicism aside, there is a list of eight IANA-maintained modules to= use as exemplars.=0A= =0A= Tom Petch=0A= =0A= /js=0A= =0A= --=0A= Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany=0A= Fax: +49 421 200 3103 =0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Tue Jun 29 12:49:50 2021 Return-Path: <0100017a5951f6a0-a7ee6ced-8c27-41f2-ad21-9d8b1524f541-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 13E1B3A3EFF; Tue, 29 Jun 2021 12:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB-TYJhl3N-U; Tue, 29 Jun 2021 12:49:44 -0700 (PDT) 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 C14393A3EFD; Tue, 29 Jun 2021 12:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1624996182; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=nh1L9Bx8gdZqxOYGvJvcPufUC91hVV+RXqsG83Hr9+I=; b=Jizy90pl4TdExsbkjx+4M2+gfkZvPC62QcZ1B0Gw32BNf6gU79xVwKBLkq0bBUhz IPQvcFmODw8eGNnO+SVTpcEn7CCPxRxX0JOCj7NKbCyNda5WSay7OYO7H5hzqtSKOsf DXZN4X8ztIuc3WTFkjXIDLcFbLR0i8AfXekEzxD4= From: Kent Watsen Message-ID: <0100017a5951f6a0-a7ee6ced-8c27-41f2-ad21-9d8b1524f541-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C940736B-9B85-4E8A-8B6B-322A36A8C28D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 29 Jun 2021 19:49:41 +0000 In-Reply-To: Cc: Michael Richardson , Juergen Schoenwaelder , "anima@ietf.org" , "netmod@ietf.org" To: tom petch References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> <20210628120924.xuuwnhnvz4jid7sp@anna.jacobs.jacobs-university.de> <26783.1624896286@localhost> <20210628161448.23zzsb2iazxgakmd@anna.jacobs.jacobs-university.de> <5322.1624898378@localhost> <20210628182043.krqzcflymazra52d@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.29-54.240.8.83 Archived-At: Subject: Re: [netmod] revising RFC8366 -- Re: [Anima] BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 29 Jun 2021 19:49:49 -0000 --Apple-Mail=_C940736B-9B85-4E8A-8B6B-322A36A8C28D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Anyhow, cynicism aside, there is a list of eight IANA-maintained = modules to use as exemplars. >=20 > Tom Petch And five more IANA-maintained modules to-be with = "draft-ietf-netconf-ssh-client-server" and = "draft-ietf-netconf-ssh-client-server". K. --Apple-Mail=_C940736B-9B85-4E8A-8B6B-322A36A8C28D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Anyhow, = cynicism aside, there is a list of eight IANA-maintained modules to use = as exemplars.

Tom = Petch

And five more IANA-maintained modules to-be with = "draft-ietf-netconf-ssh-client-server" and = "draft-ietf-netconf-ssh-client-server".

K.

= --Apple-Mail=_C940736B-9B85-4E8A-8B6B-322A36A8C28D-- From nobody Tue Jun 29 15:36: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 4107F3A157B; Tue, 29 Jun 2021 15:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 111XHBetnbR4; Tue, 29 Jun 2021 15:36:26 -0700 (PDT) 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 CDB363A15A0; Tue, 29 Jun 2021 15:36:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1756038A2D; Tue, 29 Jun 2021 18:38:26 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4MhHBs6o1hGG; Tue, 29 Jun 2021 18:38:24 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ECBBD38A2C; Tue, 29 Jun 2021 18:38:23 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7A2DF1801; Tue, 29 Jun 2021 18:36:20 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" , "netmod\@ietf.org" In-Reply-To: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <20210625224810.GC30200@faui48e.informatik.uni-erlangen.de> <20210628120924.xuuwnhnvz4jid7sp@anna.jacobs.jacobs-university.de> <26783.1624896286@localhost> <20210628161448.23zzsb2iazxgakmd@anna.jacobs.jacobs-university.de> <5322.1624898378@localhost>, <20210628182043.krqzcflymazra52d@anna.jacobs.jacobs-university.de> 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] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 29 Jun 2021 22:36:31 -0000 <#secure method=3Dpgpmime mode=3Dsign> > On Mon, Jun 28, 2021 at 12:39:38PM -0400, Michael Richardson wrote: >> >> Juergen Schoenwaelder wrote: >> >> Juergen Schoenwaelder wrot= e: > >> > You revise RFC 8366 and do the following: >> >> > - You define an IANA maintained module defining the enumeration ty= pe. >> >> This is the part that I don't know to do. >> https://www.rfc-editor.org/rfc/rfc7950.html#section-9.6 >> says nothing about IANA. Is RFC7224 the model for this? >> >> What document am I missing here? > Yes, RFC 7224 defining the iana-if-type module may serve as a > template. There are a couple of IANA maintained YANG modules, I am not > sure whether we have a good place listing them all. Well, you can > filter out the iana- modules from this list: Okay, I understand now. RFC7224 is an *IANA* maintained YANG module. When new allocations are made, then IANA rewrites the YANG module to include the new items. It's not a YANG module that imports from a IANA registry, which I think we have no YANG way to do that. RFC7224 seems to use identity to create new subclasses. RFC7217 seems to use typedef and feature. Based upon my understanding, perhaps we don't need to revise RFC8366 comple= tely, it might be that we can just update it to include IANA Considerations and turn the ietf-voucher YANG module into an IANA maintained YANG module? That just avoids opportunity for more text churn. -- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide From nobody Tue Jun 29 15:51:23 2021 Return-Path: <0100017a59f81d52-dd739c93-2634-487f-a4c9-403f9d350c19-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 1EC3F3A1824; Tue, 29 Jun 2021 15:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 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_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=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 w2GdDQALhPFl; Tue, 29 Jun 2021 15:51:12 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB2A3A1826; Tue, 29 Jun 2021 15:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1625007070; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=/mCPKk6fLtn/ITvjdgcHxEomBqnZHEpk23Yvh7ldt4s=; b=Turyn4oSpaoWAUfhc9sQAe6zqI9eJGP5ChvQ3li4AD+EaA8KMylxzdZQryVupsy3 TJKWUZXA26l64tRwP3ekn9EgyCC9+lrVPUUdLebF767ZjmVB6G2WNAcUBX5/iiukIFn h5DnYyGl3opwt5hx+qW5F1mKAxS7hK/sLCa2qL8c= From: Kent Watsen Message-ID: <0100017a59f81d52-dd739c93-2634-487f-a4c9-403f9d350c19-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7C5CEEC4-DD69-4E5A-99BB-1CCFD3EF2F06" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 29 Jun 2021 22:51:10 +0000 In-Reply-To: <765757acb49741f7a64013b5525cdbb4@huawei.com> Cc: "netconf@ietf.org" , "netmod@ietf.org" To: "maqiufang (A)" References: <38c3aa805f1846d0ad0e5ac67a82cfa1@huawei.com> <0100017a5501b507-02588bdb-c4c4-430f-9b53-39eefdfffe8b-000000@email.amazonses.com> <765757acb49741f7a64013b5525cdbb4@huawei.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.29-54.240.8.31 Archived-At: Subject: Re: [netmod] system configuration sync mechanism 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, 29 Jun 2021 22:51:17 -0000 --Apple-Mail=_7C5CEEC4-DD69-4E5A-99BB-1CCFD3EF2F06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [CC-ing NETMOD, as I think this discussion belongs on that list...please = consider removing NETCONF in your reply] Hi Qiufang, > Hi, Kent: > Thanks for kicking off some discussion around this draft. Please see = my reply inline. I'm interested in this work, as it seems as if the datastore = was left out of the NMDA work. > 1) I wish there were more examples, especially for = "resource-independent=E2=80=9D configuration. I understand well enough = "resource-dependent" (dynamic) configuration, but am unclear about what = all "resource-independent=E2=80=9D entails. By example, JUNOS has a = concept called =E2=80=9CJUNOS defaults=E2=80=9D, which is effectively = read-only and hidden-by-default configuration that, most times, must be = referenced in order to take effect. For instance, check the examples = halfway down this page: = https://nextheader.net/2016/06/10/junos-defaults-group = . Is this = similar to what you have in mind? > [Qiufang Ma] Yes. Physical-resource-independent system configuration = is generated when the device is powered on and has nothing to do with = the physical resource. Loopback interface may be the most common = physical-resource-independent system configuration. To my knowledge, = many vendors ((e.g., Huawei NE40E and Cisco IOS XR) will provide several = predefined user groups and/or task groups which are used for = authentication, authorization and accounting (AAA) services. Since these = configurations are provided by the device/system, they could be treated = as system configuration. I think your information about the predefined = hidden configuration group which contains preconfigured values should = also be treated the same.=20 > More examples about system configurations would be worked on and added = in the next version of the draft.:) Right, the loopback interface is a common example but, more generally, I = think "resource-independent=E2=80=9D configuration might fall into = exactly two categories: 1) config that is =E2=80=9Capplied=E2=80=9D immediately - ex: interfaces/lo0/unit 0/family [ inet inet6 ] - ex: system/login/password/minimum-length=3D6 - ex: system/ports/console-type=3Dvt100 - ex: system/syslog/archive-size=3D256k; - ex: = chassis/cluster/fabric-monitoring/heartbeat-interval=3D1000; - ex: security/zones/security-zone/junos-host; - ex: security/alg/sip/inactive-media-timeout=3D120; 2) config that is =E2=80=9Capplied=E2=80=9D only after being = referenced by other config (e.g., ACLs) - ex: applications/ftp/=E2=80=A6 - ex: applications/tftp/... - ex: applications/smtp/=E2=80=A6 - ex: utm/custom-objects/Adult_Material/... - ex: utm/custom-objects/Religion/... - ex: utm/custom-objects/Gambling/=E2=80=A6 It would be good if we could determine if there are any other = "resource-independent=E2=80=9D configuration categories here. As for "resource-dependent=E2=80=9D configuration, I wonder how this is = supposed to work=E2=80=A6more specifically, I wonder to what extent the = IETF needs to care how if works (perhaps the same could be said for = "resource-independent=E2=80=9D configuration too). For instance, in = JUNOS, there exists a config-template that is automatically applied to = any user-defined interface, such as: junos-default-profile { interfaces { "$junos-interface-ifd-name" { unit "$junos-underlying-interface-unit" { family inet; family inet6; } } } } Notably, RFC 8342 mentions templates as something that might be expanded = when converting to . Actually, knowing that it is = that is subject to validation, it seems that much (if not = all) of should be consumed when converting to = - agreed?=20 > 2) Please treat NETCONF and RESTCONF equally. Currently the draft = speaks only to how it impacts NETCONF, but it should equally show how = RESTCONF in impacted. > [Qiufang Ma] Thanks for bringing it to my attention, I would take = RESTCONF into consideration and see how the proposal works on RESTCONF. It will work nearly transparently, if not completely so. =20 What you need to do, mostly, is search/replace =E2=80=9CNETCONF=E2=80=9D = =E2=80=94> =E2=80=9CYANG-driven management protocols such as NETCONF and = RESTCONF=E2=80=9D =E2=80=A6and also =E2=80=9C=E2=80=A6The following example is provided = using NETCONF, but could just as easily be provided using RESTCONF, in = XML or JSON.=E2=80=9D Alternately, and perhaps better, have a mix of = both kinds of examples throughout your document. > 3) The =E2=80=9Cbasic mode=E2=80=9D term sounds too close to the = =E2=80=9Cwith-defaults=E2=80=9D basic modes...can we please pick another = name (e.g., system-datastore-operating-mode)? =20 > [Qiufang Ma] Yes, agree. Actually we don=E2=80=99t really want to = cause any confusion or misunderstandings. This term controls whether the = device will update with system configuration change or not.=20 > Your proposal looks good to me, other suggestions are also welcome = here. Ack. > Regarding your question below I don=E2=80=99t feel ready to comment = on it yet. I do understand the JUNOS model and, if it is compatible, = would recommend considering, as it is implemented and seems to be = working well enough. That said, it might be the case that every vendor = has defined their own way and each needs to be documented in turn... > [Qiufang Ma] The issue we try to resolve here is that in order for = system configurations being referenced or to make sure a successful = validation when the system configuration is in the when/must statement, = the system configuration must be retrieved from firstly = and then copied into manually, which is cumbersome. In this = case, we would like to define some kind of mechanism to synchronize = system configuration into . Currently two system configuration = data handling modes are specified. One will update with any = system configuration change automatically, and the other will not, so = that the implementer may choose the mode more suitable for them. = Hopefully this clarifies what we try to do. Please feel free to comment = or suggest. I=E2=80=99m beginning to think that: auto-copying into is likely never a good idea, because it = violates the definition of having in doesn=E2=80=99t make sense, since the tweaks = wouldn=E2=80=99t go thru --> validation. I=E2=80=99m wondering if a model like below would work for everyone - = thoughts? +-------------+ +-----------+ | | | | | (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) | +---------------+ > Best Regards, > Qiufang Ma K. // contributor --Apple-Mail=_7C5CEEC4-DD69-4E5A-99BB-1CCFD3EF2F06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [CC-ing NETMOD, as I think this discussion belongs on that = list...please consider removing NETCONF in your reply]


Hi Qiufang,


Hi, = Kent:
Thanks for kicking off = some discussion around this draft. Please see my reply = inline.

I'm interested in this work, as it seems as if the = <system> datastore was left out of the NMDA work.


1)= I wish there were more examples, especially for = "resource-independent=E2=80=9D configuration.  I understand = well enough "resource-dependent" (dynamic) configuration, but am unclear = about what all "resource-independent=E2=80=9D entails. =  By example, JUNOS has a concept called =E2=80=9CJUNOS = defaults=E2=80=9D, which is effectively read-only and = hidden-by-default configuration that, most times, must be referenced in = order to take effect.   For instance, check the examples halfway = down this page: https://nextheader.net/2016/06/10/junos-defaults-group. =  Is this similar to what you have in mind?
[Qiufang Ma]  Yes. Physical-resource-independent system = configuration is generated when the device is powered on and has nothing = to do with the physical resource. Loopback interface may be the most = common physical-resource-independent system configuration. To my = knowledge, many vendors ((e.g., Huawei NE40E and Cisco IOS XR) will = provide several predefined user groups and/or task groups which are used = for authentication, authorization and accounting (AAA) services. Since = these configurations are provided by the device/system, they could =  be treated as system configuration. I think your  information = about the predefined hidden configuration group which contains = preconfigured values should also be treated the same. 
More examples about system configurations would be worked on = and added in  the next version of the = draft.:)

Right, the loopback interface is a common example = but, more generally, I think "resource-independent=E2=80=9D = configuration might fall into exactly two categories:

1) config that is =E2=80=9Capplied=E2= =80=9D immediately
- ex: interfaces/lo0/unit = 0/family [ inet inet6 ]
- ex: system/login/password/minimum-length=3D6
- = ex: system/ports/console-type=3Dvt100
= - ex: system/syslog/archive-size=3D256k;
- = ex: = chassis/cluster/fabric-monitoring/heartbeat-interval=3D1000;
= - ex: security/zones/security-zone/junos-host;
- ex: = security/alg/sip/inactive-media-timeout=3D120;

2) config that is =E2=80=9Capplied=E2= =80=9D only after being referenced by other config (e.g., = ACLs)
= - ex: applications/ftp/=E2=80=A6
- = ex: applications/tftp/...
- ex: = applications/smtp/=E2=80=A6
- ex: = utm/custom-objects/Adult_Material/...
- = ex: utm/custom-objects/Religion/...
- = ex: utm/custom-objects/Gambling/=E2=80=A6

It would be good if we could determine = if there are any other "resource-independent=E2=80=9D configuration = categories here.

As for "resource-dependent=E2=80=9D configuration, I = wonder how this is supposed to work=E2=80=A6more specifically, I wonder = to what extent the IETF needs to care how if works (perhaps the same = could be said for "resource-independent=E2=80=9D configuration = too).  For instance, in JUNOS, there exists a config-template that = is automatically applied to any user-defined interface, such = as:

  =   junos-default-profile {
      =   interfaces {
        =     "$junos-interface-ifd-name" {
  =               unit = "$junos-underlying-interface-unit" {
      =               family inet;
                =     family inet6;
      =           }
    =         }
      =   }
    }

Notably, RFC 8342 mentions templates as something = that might be expanded when converting <running> to = <intended>.  Actually, knowing that it is <intended> = that is subject to validation, it seems that much (if not all) of = <system> should be consumed when converting = <running> to <intended> - agreed? 


2) Please treat = NETCONF and RESTCONF equally.  Currently the draft speaks only = to how it impacts NETCONF, but it should equally show how RESTCONF = in impacted.
[Qiufang Ma] Thanks for bringing it to my attention, I would = take RESTCONF into consideration and see how the proposal works on = RESTCONF.

It will work nearly transparently, if not = completely so.   

What you = need to do, mostly, is search/replace =E2=80=9CNETCONF=E2=80=9D =E2=80=94&= gt; =E2=80=9CYANG-driven management protocols such as NETCONF and = RESTCONF=E2=80=9D

=E2=80=A6and also = =E2=80=9C=E2=80=A6The following example is provided using NETCONF, but = could just as easily be provided using RESTCONF, in XML or JSON.=E2=80=9D =   Alternately, and perhaps better, have a mix of both kinds of = examples throughout your document.


3) The =E2=80=9Cbasic = mode=E2=80=9D term sounds too close to the =E2=80=9Cwith-default= s=E2=80=9D basic modes...can we please pick another name (e.g., = system-datastore-operating-mode)?  
[Qiufang Ma] Yes, agree. Actually we don=E2=80=99t really = want to cause any confusion or misunderstandings. This term controls = whether the device will update <running> with system configuration = change or not. 
Your proposal looks good to me, other suggestions are also = welcome = here.

Ack.


 Regarding your question below I don=E2=80=99t feel ready to = comment on it yet.  I do understand the JUNOS model and, if it = is compatible, would recommend considering, as it is = implemented and seems to be working well enough.  That said, it = might be the case that every vendor has defined their own way and = each needs to be documented in turn...
[Qiufang Ma] = The issue we try to resolve here is that in order for system = configurations being referenced or to make sure a successful validation = when the system configuration is in the when/must statement, the system = configuration must be retrieved from <operational> firstly and = then copied into <running> manually, which is cumbersome. In this = case, we would like to define some kind of mechanism to synchronize = system configuration into <running>. Currently two system = configuration data handling modes are specified. One will update = <running> with any system configuration change automatically, and = the other will not, so that the implementer may choose the mode more = suitable for them. Hopefully this clarifies what we try to do. Please = feel free to comment or = suggest.


I=E2=80=99m beginning to = think that:
  • auto-copying into = <running> is likely never a good idea, because it violates the = definition of <running>
  • having in = <operational> doesn=E2=80=99t make sense, since the tweaks = wouldn=E2=80=99t go thru <running> --> <intended> = validation.

I=E2=80=99m = wondering if a model like below would work for everyone - = thoughts?

     +-------------+   =               = +-----------+
     | <candidate> |     =             | <startup> = |
  =    |  (ct, rw)   |<---+       = +--->| (ct, rw)  |
     +-------------+   =  |       |   =  +-----------+
            |     =       |       |       =     |
            |     =     +-----------+         = |
  =           +-------->| <running> = |<--------+
                =       | (ct, rw)  |
            =           +-----------+
        =                     = |
 +----------+             =   |        // configuration = transformations,
 | <system> |-------------->|     =    // e.g., removal of nodes marked as
 | (ct, ro) | // = underlay   |        // "inactive", expansion = of
 +----------+ =              |       =  // templates
                =             v
        =               = +------------+
                =       | <intended> | // 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
            =         +---------------+
        =             | <operational> | <-- = system state
                =     | (ct + cf, ro) |
            =         +---------------+






Best Regards,
Qiufang = Ma

K. // contributor





= --Apple-Mail=_7C5CEEC4-DD69-4E5A-99BB-1CCFD3EF2F06-- From nobody Tue Jun 29 17:37: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 756193A0E08; Tue, 29 Jun 2021 17:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 Qymk5fm58CB6; Tue, 29 Jun 2021 17:36:56 -0700 (PDT) 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 3A3283A0DFE; Tue, 29 Jun 2021 17:36:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 094CB389DB; Tue, 29 Jun 2021 20:38:57 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RIS-7ua_PNQT; Tue, 29 Jun 2021 20:38:55 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EEB7A389DA; Tue, 29 Jun 2021 20:38:54 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 231371801; Tue, 29 Jun 2021 20:36:51 -0400 (EDT) From: Michael Richardson To: "Rob Wilton \(rwilton\)" , "anima\@ietf.org" , "netmod\@ietf.org" cc: Toerless Eckert , "Fries\, Steffen" , "Kent Watsen" In-Reply-To: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@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] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 30 Jun 2021 00:37:02 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Rob Wilton (rwilton) wrote: > An RFC8366bis is the right option. If the changes are minor then I m= ay > be able to ease the passage through the IESG, but I can't do much to > affect the elapsed time. I will prepare a draft for this week. I thought I wrote a really nice ASCII art version of what documents inherit from RFC8366. I can't find it in my outbox... I wonder if I nuked the draft by mistake. The short of it: RFC8366 -> RFC8995 (voucher-request) -> constrained-voucher (voucher-request, voucher) -> brski-async-enroll (voucher-request) -> jose-voucher (voucher, voucher-request) and my question was a bit about how we manage all their things inherited. It's really the classic CS multiple inheritance problem. {A Cat is an Mammal A Cat is an Four-legged creature A Cat is Nocturnal.} --=-=-= 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+93Q3WUFAmDbvKIACgkQgItw+93Q 3WXqSQf/bMzu0EHB0loF/7mUMefqGz4EdSqMYevVKbrqCFVDBOdKw7b4msO0lHc6 gtDzW/Vjhowy2TpQl9llby5qDZQaBdah0i1vIjjITvWeXsIV/CmrH6/RiySoS00z 4ojp5J9ewi6Uc7tsyzWYeLq4/as4gMZBZHvromLPqz1MVz2u7fDDFX0O1QLVbOtG mcoqKoZ0IEpzUH+UskGxioEUo0mSnE0SkZCIh5dG/jlVnklxWOQYgWUdrThWgYb9 09MjP07mhe5qQ7V1xX0AuY0DIDieL97AVSWmjKV6SnYUI+swzX2NYrWc4N48YTG/ KU/3KJQUFuY4XC1Jz7Wtz/KYIEbNPQ== =o5gy -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Jun 29 17:56:37 2021 Return-Path: <0100017a5a6ac423-889b9d5b-51cb-4f86-8977-c5bac1e021ec-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 D7DEA3A0F4D; Tue, 29 Jun 2021 17:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=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 vMs_u5zLK8Gz; Tue, 29 Jun 2021 17:56:26 -0700 (PDT) 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 E1D573A0F4A; Tue, 29 Jun 2021 17:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1625014584; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=5o7AundQLPCa5GgKBTNBBgRhcgqoPo8U69O+tcSLsMc=; b=GJENVq/evMMhUSkmGMMtZLnIiQu5U5eHVSCtCGhJfBYivuKYjOlKEzUttTiyzSZc WxcL2Bh/PHOX/TLQ4UJEUAcOosu1f5K1psRHvXgRyRGUw8pFLGbDNwcUjObdSLApqca ysplwhDr6R2pGULnnkPAfKVCRJzaSKomZEJVULsM= From: Kent Watsen Message-ID: <0100017a5a6ac423-889b9d5b-51cb-4f86-8977-c5bac1e021ec-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C8690CC8-008F-4449-8584-4E2ACDD872F1" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 30 Jun 2021 00:56:24 +0000 In-Reply-To: <27560.1625013411@localhost> Cc: "Rob Wilton (rwilton)" , "anima@ietf.org" , "netmod@ietf.org" , Toerless Eckert , "Fries, Steffen" , "netconf@ietf.org" To: Michael Richardson References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <27560.1625013411@localhost> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.06.30-54.240.48.94 Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 30 Jun 2021 00:56:32 -0000 --Apple-Mail=_C8690CC8-008F-4449-8584-4E2ACDD872F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 29, 2021, at 8:36 PM, Michael Richardson = wrote: >=20 >=20 > Rob Wilton (rwilton) wrote: >> An RFC8366bis is the right option. If the changes are minor then I = may >> be able to ease the passage through the IESG, but I can't do much to >> affect the elapsed time. If considering a bis, can we consider changing the = "pinned-domain-cert=E2=80=9D node from a X.509v3 cert to a =E2=80=9Cchoice= =E2=80=9D between that and a chain of certs? =20 In particular, from: +---- pinned-domain-cert binary To: +---- (domain-cert-format) +---- pinned-domain-cert binary +---- pinned-domain-certs binary Or, better, using ietf-crypto-types: +---- (domain-cert-format) +---- pinned-domain-cert ct:end-entity-cert-x509 +---- pinned-domain-certs ct:end-entity-cert-cms > I will prepare a draft for this week. >=20 > I thought I wrote a really nice ASCII art version of what documents = inherit > from RFC8366. I can't find it in my outbox... I wonder if I nuked the = draft > by mistake. Check this: = https://yangcatalog.org/yang-search/impact_analysis/?modtags=3Dietf-vouche= r%402017-10-25.yang&orgtags=3D&recursion=3D0&show_rfcs=3D1&show_subm=3D1&s= how_dir=3Ddependents = K. --Apple-Mail=_C8690CC8-008F-4449-8584-4E2ACDD872F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 29, 2021, at 8:36 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
An RFC8366bis is the right option.  If the = changes are minor then I may
be able to ease the passage = through the IESG, but I can't do much to
affect the = elapsed time.

If considering a bis, can we consider changing the = "pinned-domain-cert=E2=80=9D node from a X.509v3 cert to a =E2=80=9Cchoice= =E2=80=9D between that and a chain of certs?   

In particular, from:

   +---- pinned-domain-cert               binary

To:

   +---- (domain-cert-format)
      +---- pinned-domain-cert               binary

      +---- pinned-domain-certs         =
     binary



Or, better, using =
ietf-crypto-types:

   +---- (domain-cert-format)
      +---- pinned-domain-cert          =
     ct:end-entity-cert-x509

      +---- pinned-domain-certs         =
     ct:end-entity-cert-cms





I will prepare a draft for = this week.

I thought I wrote a really nice = ASCII art version of what documents inherit
from RFC8366. =  I can't find it in my outbox... I wonder if I nuked the draft
by mistake.

Check this:

https://yangcatalog.org/yang-search/impact_analysis/?modtags=3D= ietf-voucher%402017-10-25.yang&orgtags=3D&recursion=3D0&show_r= fcs=3D1&show_subm=3D1&show_dir=3Ddependents


K.


= --Apple-Mail=_C8690CC8-008F-4449-8584-4E2ACDD872F1-- From nobody Tue Jun 29 18:23: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 1E0DB3A1147; Tue, 29 Jun 2021 18:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 ZLz0fhXTMvcn; Tue, 29 Jun 2021 18:23:21 -0700 (PDT) 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 1113B3A10E7; Tue, 29 Jun 2021 18:23:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 14A6C389DC; Tue, 29 Jun 2021 21:25:11 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5GFoYZ_2JBNt; Tue, 29 Jun 2021 21:25:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 77F15389DA; Tue, 29 Jun 2021 21:25:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 91B9222B; Tue, 29 Jun 2021 21:23:04 -0400 (EDT) From: Michael Richardson To: Kent Watsen , "Rob Wilton \(rwilton\)" , "anima\@ietf.org" , "netmod\@ietf.org" , Toerless Eckert , "Fries\, Steffen" , "netconf\@ietf.org" In-Reply-To: <0100017a5a6ac423-889b9d5b-51cb-4f86-8977-c5bac1e021ec-000000@email.amazonses.com> References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <27560.1625013411@localhost> <0100017a5a6ac423-889b9d5b-51cb-4f86-8977-c5bac1e021ec-000000@email.amazonses.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] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 30 Jun 2021 01:23:35 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kent Watsen wrote: >> Rob Wilton (rwilton) wrote: >>> An RFC8366bis is the right option. If the changes are minor then I= may >>> be able to ease the passage through the IESG, but I can't do much to >>> affect the elapsed time. > If considering a bis, can we consider changing the "pinned-domain-cer= t=E2=80=9D > node from a X.509v3 cert to a =E2=80=9Cchoice=E2=80=9D between that a= nd a chain of > certs? Yeah, I think it's a good idea. Could we also have the choice be a RPK? > Or, better, using ietf-crypto-types: :-) > Check this: > https://yangcatalog.org/yang-search/impact_analysis/?modtags=3Dietf-v= oucher%402017-10-25.yang&orgtags=3D&recursion=3D0&show_rfcs=3D1&show_subm= =3D1&show_dir=3Ddependents > Yeah, I knew about that, but others might not. I was basically trying to distill it down into a few words. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDbx3gACgkQgItw+93Q 3WX38wgAuOrFmWzGEw6pq4Rkl39TSRyswF2IgWJgSytBKxZsm0JBKBPLjCkwyPhy +TUyP2WEJgLO1FAHPOB26rBjbTp3C3JKuloZMUdZZ9MTKi34aBdhQL/5Gdkf9H71 NlKJx3fNHr5AeJTMDWirpBjNa0Tt50Ut6BrksLiaj3zxrV1YG0BuqESKii8iD/yz 59UkXSkJvZJVSjYOdP+Z0CdL/bQncTUz1xi2K/pLye+hzjCpuRVOTDQVmRq2pC/p 1ziu7XHk+0BF090Kca06cWV0SHXDNSS9/zHBOT6rU9GepWmrlCo6DM+aeS6tjN+H LtOhzLpO2w9ykG0zhQxP8ZzigTmELQ== =EN3e -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 30 05:38: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 12C973A1B12; Wed, 30 Jun 2021 05:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_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 6DXXMWn9Ry_Q; Wed, 30 Jun 2021 05:38:31 -0700 (PDT) Received: from gw-eagle1.siemens.com (gw-eagle1.siemens.com [194.138.20.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0413A1B10; Wed, 30 Jun 2021 05:38:31 -0700 (PDT) Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle1.siemens.com (Postfix) with ESMTPS id 669264F032D; Wed, 30 Jun 2021 14:38:23 +0200 (CEST) Received: from DEMCHDC8A2A.ad011.siemens.net (demchdc8a2a.ad011.siemens.net [139.25.226.108]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id 74BEA1A4AF14F; Wed, 30 Jun 2021 14:38:21 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC8A2A.ad011.siemens.net (139.25.226.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Wed, 30 Jun 2021 14:38:20 +0200 Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2176.014; Wed, 30 Jun 2021 14:38:20 +0200 From: "Fries, Steffen" To: Michael Richardson , "Rob Wilton (rwilton)" , "anima@ietf.org" , "netmod@ietf.org" CC: Toerless Eckert , Kent Watsen Thread-Topic: [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? Thread-Index: AQHXbUgLTh6qzCTiOUi87TrW2ebB4KssfkVA Date: Wed, 30 Jun 2021 12:38:20 +0000 Message-ID: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <27560.1625013411@localhost> In-Reply-To: <27560.1625013411@localhost> Accept-Language: en-US, de-DE 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-06-30T12:38:19Z; 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=96855855-ca3d-4f28-901b-68576cfadb6f; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [144.145.220.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? 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, 30 Jun 2021 12:38:36 -0000 SGkgTWljaGFlbCwgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWlj aGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+DQo+IFNlbnQ6IE1pdHR3b2No LCAzMC4gSnVuaSAyMDIxIDAyOjM3DQoNCg0KPiBJIHRob3VnaHQgSSB3cm90ZSBhIHJlYWxseSBu aWNlIEFTQ0lJIGFydCB2ZXJzaW9uIG9mIHdoYXQgZG9jdW1lbnRzIGluaGVyaXQgZnJvbQ0KPiBS RkM4MzY2LiAgSSBjYW4ndCBmaW5kIGl0IGluIG15IG91dGJveC4uLiBJIHdvbmRlciBpZiBJIG51 a2VkIHRoZSBkcmFmdCBieSBtaXN0YWtlLg0KPiANCj4gVGhlIHNob3J0IG9mIGl0Og0KPiBSRkM4 MzY2IC0+IFJGQzg5OTUgKHZvdWNoZXItcmVxdWVzdCkNCj4gICAgICAgICAtPiBjb25zdHJhaW5l ZC12b3VjaGVyICh2b3VjaGVyLXJlcXVlc3QsIHZvdWNoZXIpDQo+ICAgICAgICAgLT4gYnJza2kt YXN5bmMtZW5yb2xsICh2b3VjaGVyLXJlcXVlc3QpDQpXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIGFs c28gc3RhdGUgdGhlIHZvdWNoZXIgZm9yIEJSU0tJLUFFIGFzIGl0IGFsc28gdXNlcyB0aGUgdm91 Y2hlciBhbmQgdHJpZXMgdG8gYXJndWUgZm9yIGEgbmV3IGFzc2VydGlvbiB0eXBlIChhZ2VudC1w cm94aW1pdHkpPw0KDQo+ICAgICAgICAgLT4gam9zZS12b3VjaGVyICh2b3VjaGVyLCB2b3VjaGVy LXJlcXVlc3QpDQoNClJlZ2FyZHMNClN0ZWZmZW4NCg0KDQoNCj4gDQo+IGFuZCBteSBxdWVzdGlv biB3YXMgYSBiaXQgYWJvdXQgaG93IHdlIG1hbmFnZSBhbGwgdGhlaXIgdGhpbmdzIGluaGVyaXRl ZC4NCj4gSXQncyByZWFsbHkgdGhlIGNsYXNzaWMgQ1MgbXVsdGlwbGUgaW5oZXJpdGFuY2UgcHJv YmxlbS4NCj4gDQo+IHtBIENhdCBpcyBhbiBNYW1tYWwNCj4gIEEgQ2F0IGlzIGFuIEZvdXItbGVn Z2VkIGNyZWF0dXJlDQo+ICBBIENhdCBpcyBOb2N0dXJuYWwufQ0KDQo= From nobody Wed Jun 30 14:58: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 5A3E43A2CB8 for ; Wed, 30 Jun 2021 14:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy3sz2oTt_8G for ; Wed, 30 Jun 2021 14:58:00 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 818FA3A2C82 for ; Wed, 30 Jun 2021 14:58:00 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id c11so5382389ljd.6 for ; Wed, 30 Jun 2021 14:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=E8SHwWVVronOEQ7INm/HJcnOPfvxoJatEnBaIsY3ka0=; b=zFXy37Q8JAWnSl5YfXOj7zmbYpX0PdEVORc3aVlsQn47dUc2eETxdGRM3ijx6j1E0S 4lp/MaOY5th3/oK6XNqxRGoxy7CuxED9hRB93DPEL3nSqp5v/MHaPB8iiqv+om8ng94I Anaywm5ytf3vTbORWkZSbSgAXCE3jARzu7bQgFVattjMucvb1tYMgWaPdKnYGePuh+gh 79P9bu0QpsEsoLe8koZcTeZUk5vnwHbZwzP3grWfyc4KuzYcCieiwbLF+ENFAWYxL8Ci 79HyUAH/irGlmTEGGSIGL4kDfc19D3lLAXSUJ4XM2wwLTVqH9YaARctpiTQj28j1D6kM LYBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E8SHwWVVronOEQ7INm/HJcnOPfvxoJatEnBaIsY3ka0=; b=NfFYaRy1ckSYJr7kHHA7VrdmB2bHQh93jQ61JB8liKr725GLxjHDaMogibTbWybqd6 F3D2BZCVKxFGYiQDtiQWpzgujuf5ya1mbA5mUD2PfRiYnECSCcKQxc3spkrvuhmA4Dsk pWRXR8IOZqh1fdi/mhR3hdZj3CP6RKI3TFCt+zzJQY5rRV5hZl9rq1ItfUNJJrWQgtWm Y4uOUhKeuCiDsAaUjMK5s7DBBfl309dq3W41M7sxxgMSkbhWDZ8QLFijuNg5ZbLB8lbs 6W62DOucC0YoYW052emE5+a7WEhPyYszp++ROs9AoRq0MkparVwODWu2oSeXEYUlx3JY 63/g== X-Gm-Message-State: AOAM530XLPyJFWtPlC9wlw72vWXQhlQTSJHRkFsN6+1Sit5JfVW68Kqf 0F94EZvO+redzcHwKYMuz00Beup4dEa1+XcsEFJGMBI9QwNwRw== X-Google-Smtp-Source: ABdhPJyBjwddi1D6n9j3Ddgx+usQ+Ip1CrqUPvO0Ji3frrdNE0awHtneVWJQgVwzR2CtxsuWx1kYGp1nHt0LfS2nRKU= X-Received: by 2002:a05:651c:178b:: with SMTP id bn11mr9237213ljb.43.1625090277001; Wed, 30 Jun 2021 14:57:57 -0700 (PDT) MIME-Version: 1.0 From: Andy Bierman Date: Wed, 30 Jun 2021 14:57:46 -0700 Message-ID: To: NetMod WG Content-Type: multipart/alternative; boundary="000000000000b062d405c602d0ac" Archived-At: Subject: [netmod] comments on draft-ietf-netmod-yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 21:58:02 -0000 --000000000000b062d405c602d0ac Content-Type: text/plain; charset="UTF-8" Hi, I have many concerns about the actual deployment of this draft. It is well-written and very careful and complete in its coverage of the issues. The problem is increased complexity and confusion. The extension procedures will greatly increase the busy work that YANG authors are expected to perform. There are a lot of maintenance tasks for humans to read and write. It is not that clear that automation tools will rely too much on all this extra metadata added to YANG modules. The changes to YANG that this draft would impose need to be clearly identified to YANG readers, writers, and tools, This should be done by incremented the yang-version field, as designed into the YANG language. Otherwise it will not be clear what tools actually support. The only extension that is really useful is "revision-or-derived". But I agree with all the concerns originally raised by Martin wrt/ this should be a real-statement instead of an extension. This is the way import-by-revision should have worked from the start. The draft contains some reasonable updates to YANG and YANG Guidelines wrt/ updating a module.. They would be appropriate for a new YANG language version. Andy --000000000000b062d405c602d0ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have many concerns about the actu= al deployment of this draft.
It is well-written and very careful = and complete in its coverage of the
issues.

<= div>The problem is increased complexity and confusion.
The extens= ion procedures will greatly increase the busy work that YANG authors
<= div>are expected to perform. There are a lot of maintenance tasks for
=
humans to read and write. It is not that clear that automation tools w= ill
rely too much on all this extra metadata added to YANG module= s.

The changes to YANG that this draft would impos= e need to be
clearly identified to YANG readers, writers, and too= ls,
This should be done by incremented the yang-version field,
as designed into the YANG language. Otherwise it will not
be clear what tools actually support.

The only ex= tension that is really useful is "revision-or-derived".
But I agree with all the concerns originally raised by Martin wrt/=C2=A0
this should be a real-statement instead of an extension.
This is the way import-by-revision should have worked from the start.

The draft contains some reasonable updates to YANG and= YANG Guidelines
wrt/ updating a module.. They would be appropria= te for a new YANG language
version.

= Andy

--000000000000b062d405c602d0ac-- From nobody Wed Jun 30 23:07: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 1708F3A14FE for ; Wed, 30 Jun 2021 23:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7BNyzN4mDl0 for ; Wed, 30 Jun 2021 23:07:26 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2067.outbound.protection.outlook.com [40.107.21.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 931F23A14FC for ; Wed, 30 Jun 2021 23:07:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X9j/CO+XE56Zp1l2Z+2oc45Sp2IZetrqTRs1PnDiASiwzxm3/psAfGL9VVCphBPEOduxDIWUFgdqVuIYFpwrYegLaas9GmDyMmQSTUyw2XpN27uqXElNEztjIwQM1KEJJhyPHuucEwBNrtsBU+6vI4HMsMFhS2ZPZWugjFh627S1GKi8cZyvAWBvGSoDtBMlGpGtep0mOktCBeWcJwQ5fI/vfJiDyl74aSeVqU65WtVpC8+PJsY025qfkf3QaP6dQkeZboqUWFXxeK/fibVJzNkxDU+BQRDO9+o3U4V8L6xWsykaP18BjhUBAz4AhQGGcJNlBkoQyWKV8/4F4qAzaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2Gep96x86AQIrCmB02AWcKkBAtEP2v92sH6ZOMN1ekw=; b=K/qsf+Qz3P4UFjEHEIPW8eA1p0JcB+5mLSrr57G3AbYwXff90sw+Dparw2Fav3Cxtd+L32E1RXRC9UIhe7kwirGNSBOwedeP5VEma+WZvZGJb1l39c1CYL30zuLSYqotDdkIhnILt7DlI20Ha83Qfhv0rB8srEp23sQFBqOaWXAtHUb2M5dfOc7WAqfeE7Cb2KrmNjnpYfnGY5XXYhOwB+1BwQ+QLmcybrXxBkKHEYwUNXlbPdSqLnI21ke8FjRPqgSpDwkmRQUPmGI0gFdKW+Ukq93QiLc3boTwdIyMUoE3/+9jxTXXIt7/NT2VdhN+cmeiUquxD9kkHe64U+fBTA== 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=2Gep96x86AQIrCmB02AWcKkBAtEP2v92sH6ZOMN1ekw=; b=PXgpAh/luFz0xJjJx+Ue4tvsJh5FZSOslqGsAtRsmGTxwN6XvHu7sIWN/yUlJJI2UW8fTH6R+ASUZSCrGuBZwwFMbVFTR6U+nnr+zWZaZmYcHq9+IkC6gqM14VfuXZsxWoHqQeMxW+P25MYvJZ7ygIJ2CEJyCUgaoQjLI4KFW8o= Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0708.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:198::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.23; Thu, 1 Jul 2021 06:07:23 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4264.027; Thu, 1 Jul 2021 06:07:23 +0000 Date: Thu, 1 Jul 2021 08:07:22 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: NetMod WG Message-ID: <20210701060721.bolg6d6koc4ic6ev@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , NetMod WG References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: FR3P281CA0021.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1c::11) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by FR3P281CA0021.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.8 via Frontend Transport; Thu, 1 Jul 2021 06:07:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b6081290-f285-485d-5586-08d93c567df9 X-MS-TrafficTypeDiagnostic: AM0P190MB0708: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pNPXwm5ABXtuAFjZqrwf7zBAVDfVL53l2ZFOw2uII86i+FTtox8jrvINuqJoQUeeK2N3jCcFYlrJ7vNYqvcZJ/Bzo5kbfSqqdMjJMIOB1rwGPeHxVHDWZmmk5IhHmu/UtXn1Sv3rpq0Myz8w2LX+aOmoWEicM/v14gADWfoJsnpumN/E4HVWddM/5FlpPJg3hJBKypBrFxOPrSj+pzEUTIIt+7VhfMsirlxrpZmpucUkVwRH7uaehOHm25+MMJHmHdJ2nCRYQYkrKBoF6XKiS13snkzPODwrh22vyYbZ4cAOS+aR+cWztl2/du8eVf1PCgJn2UUvu7k+MCJTJppYPh8gpqhk72DUpCMuMysVpIwN/QtKl16Cz8D3FTtDkflIaBfapZQF4dkuHEEMRsmQEM+6dtchm7bFiCcbH/GNR1fLr6ZdwtIXQPopcN4Xmo8Pc1rIgkxaMMBHiwgXG5PL2Bc+eE8Cm6JFAn6zInOsNxDY9Cays1ie9klAF0HjdDkoP2xSEZn17p6e8huFKgkVnjJwaUb3PLu2wMuP05D6SLCISaIsabG/IXOhRD0Ppa20HEHBavGDzeHp3cJCMaT/UYX+II2JvemhPJWuDuuadlHyb25kJk1T+qdhtWerMi41wT0eV9CcAZZORcxR5dL/791gSja2ccdR0DrJ6oPW1XD7muWrpHD0dl7vxqvXJmHf/k0ymWK8L7cqk4gzE/BEVILc7NZCuBLHQlRUPZ82CHDMf0FlMwQCAkU8klXZJe6TnA0jeHDmtHP5+g2O+pu6S1YWYZtRHxmRCbV6HXa2FNA1eymOUP/M1SXUN97HZO9b+vf+TwwrZoHVMi6pLkTS0w== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(346002)(136003)(366004)(376002)(39850400004)(3450700001)(956004)(6496006)(2906002)(83380400001)(4326008)(4744005)(52116002)(26005)(16526019)(186003)(6486002)(66476007)(66556008)(38100700002)(478600001)(66946007)(5660300002)(8676002)(38350700002)(8936002)(6916009)(786003)(1076003)(86362001)(316002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?TRJupAPtqZNML5RSNLajSAcVR9pkKFw60d7t+FMqPVP8PTjEPU7GBvEuQcWZ?= =?us-ascii?Q?V7n2AK4jDA4iI2MbtkFNUyQvRhrXeh4L1iG/d4Nc/8BgWwenP9zSql4mpz/Z?= =?us-ascii?Q?QrQB2+AkTYtD826po8mFzAxnpIEVrwSDH1AUCIVw8+Sqmm7TPWd6z/w2rwnK?= =?us-ascii?Q?+naQCYqtnhxYF3YOmgcZLk4X0grLZdq24bHe5TcrAOwCCkjRf4iKzA6/fClA?= =?us-ascii?Q?2MhpgxealxeIrtzy8CGe/KoTHQ6RS0p+xoErnGPXFH4RxwUk9KQslCzdnKfO?= =?us-ascii?Q?t/tYKHzfpKjcsD7VnVO+t1+BCOwiH5EIZUsoWPd6p+ICpjsXg5IE1x+B503L?= =?us-ascii?Q?641C/Q1r2Uumbd+KNP3vxMWNarmwGNC9rsDVeR5D+vLNlyXHCio7UKUGUHEo?= =?us-ascii?Q?f7d0kMjphzFoHB6TMNCu1h0NfQIO8vFPf+hM6RkLCApmw43iiXT2DFlRv3b9?= =?us-ascii?Q?/Xmv3dFkX8qzGzVDm9vBwBJm6XMShPpUKvheCoK4h64xyhJKjDJlH9oaCQoX?= =?us-ascii?Q?UFnAEUeeIlFukjB1TsF0oC2iAv7Sc8OkKYzVbdzFAAaJwYaOZMRWH/H5iHrA?= =?us-ascii?Q?zcdEvT54T8gEJxO2qdI930lTX5nIg+V0RRzS2uETcubzy+iakbnAYzl189YH?= =?us-ascii?Q?7+OtEJE2nzQ+SRXPKoAuWybo0mJuouX2KkyVZlbUIRoT/vyZRXqCAjqoGuCZ?= =?us-ascii?Q?ubYl8lDN0ccbBjuBkuRWoxVsryTWHK8vTYXqaK++AD3WREFtgFWcDjo7rr5W?= =?us-ascii?Q?ClpsSM+NKy+tUgroQZudup5qHlevWsaKuPCPr+ZjunZfO1EvBNHJhPEzgaS/?= =?us-ascii?Q?iGwZ7EymbB1i8nIbKJ0A2DFHySpbVue3fre5Yb5W0Ibfhy3/u0V91I2wD7wj?= =?us-ascii?Q?wTfnxJM4xD/cA7snx3gfDeLKVWM4475+ELDT3X4CsqhL5gFYUc1WaDNjXykY?= =?us-ascii?Q?wI8VDFwwxK0CrMNoAvEZ2Be6a9C6fAlXQZUIQCcLKM/95l7SD2UdOUdmh0cw?= =?us-ascii?Q?Q8oZPlA/gxmLRS8YJgZ4yv36Uf6278Zgh7KgFUH4elurnRR13hWamJ/oEljt?= =?us-ascii?Q?BzPXDDhU+3W9Qos8ETOC2dDKbO+a+b8sRx2pFtf0mZPZWECp18em63Infv+W?= =?us-ascii?Q?TtlWS+4x8yhvP/tdcNatsjWlde5jrXrDycj76nwVkkV3k3Q45iqs0j+t1jQw?= =?us-ascii?Q?3xjLbLopf0QBGjDktw2ic9s/yhMRyjH6DzVL1nTSL7dMHeNRtgHOuYZVMzMC?= =?us-ascii?Q?ko4wiCJBAdTuJxrHFW18aGfHNo0sSVph4hEo7Ha04OW9q/7t2XdLwACzv6tI?= =?us-ascii?Q?pg7wYtxoDRnfyUuI+ly3bVuN?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: b6081290-f285-485d-5586-08d93c567df9 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2021 06:07:22.9435 (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: BCp3wWUPQIOKVmcShOJB79lRd15q4+zG2ojZx2ATgRVaJeN+qMHDAtYh7J/TkH05CIC3aAHdvwLH+S2L8cOKxmXL4g6xACFKYCUC20QYF7c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0708 Archived-At: Subject: Re: [netmod] comments on draft-ietf-netmod-yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 06:07:33 -0000 On Wed, Jun 30, 2021 at 02:57:46PM -0700, Andy Bierman wrote: > > The only extension that is really useful is "revision-or-derived". > But I agree with all the concerns originally raised by Martin wrt/ > this should be a real-statement instead of an extension. > This is the way import-by-revision should have worked from the start. > > The draft contains some reasonable updates to YANG and YANG Guidelines > wrt/ updating a module.. They would be appropriate for a new YANG language > version. > +1 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103