Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
"Acee Lindem (acee)" <acee@cisco.com> Tue, 12 April 2022 13:24 UTC
Return-Path: <acee@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41F93A1F06; Tue, 12 Apr 2022 06:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.606
X-Spam-Level:
X-Spam-Status: No, score=-9.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=ab3XdoLS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=u9SdefDc
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5kke3emiOuy; Tue, 12 Apr 2022 06:24:34 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059D93A1EFC; Tue, 12 Apr 2022 06:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15138; q=dns/txt; s=iport; t=1649769873; x=1650979473; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PXdf82+SALrz5jbwtS2Kf+nzbC5VyrOImKs5DOFZKag=; b=ab3XdoLSk1b7q92iOVluNZYS2emlN3Nxy6o6/fQsFw72xPCKaHaS5Jz4 2Qcpbw+uHzUgZjtGay0dxMvv7iEZ+Ie7DxSVhJeklEi9bmWxaneERiQnp I52rDyYjIE8KK4P0pZrNMnCa4lh2By3/gy9b1mJokuJ94NiM3PK7gpXN2 E=;
IronPort-PHdr: A9a23:NFjpkhPvdUAyMj9s4LYl6ncDWUAX0o4cdiYZ6Zsi3rRJdKnrv5HvJ1fW6vgliljVFZ7a5PRJh6uz0ejgVGUM7IzHvCUEd5pBBBMAgN8dygonBsPNAEbnLfnsOio9GskKVFJs83yhd0ZPH8OrbFzJqXr05jkXSX3C
IronPort-Data: A9a23:f8jbXqOhFm8b1OjvrR1PlcFynXyQoLVcMsEvi/4bfWQNrUon3mZWzDFMWW6BM/uKMTCnf94jYYuzpxgP7ZTWnIAyS3M5pCpnJ55oRWUpJjg4wn8dtEp+F+WbJK5cx5hYO4GowPwcFCeG/E/xa+K59BGQ6InRLlbCIL+cUsxObVcMpBcJ0XqPqsZh6mJaqYHR7zCl4bsel/bi1GqNgFaYBI67B5Wr83uDtNyq0N8RU8dXifpj5DcynFFNZH4TyD3YEpf2fmVUNrbSq+fr1rq1+CbS+A0gT4zjmbfgeUpMSbnXVeSMoiMJAO753V4T/Wprjv1T2Pk0MS+7jx2AlN184N5Mrpe3DwwuO8UgncxMAkUBSXwkYPYuFLjvZCLXXdao50vLb37rz91vAV04e4oC9Y5fBXpU3f0VND5LaQqM78qs37O/Vu5q05h7J8jwN4RZsXZl5T3cBOwtB5HOX6uM4sVXtB85gMxfNefDYsMGbiBsd1LLZBgnElUSCLo8m+qshnD7azBCrhSeoq9f3oR55GSdy5D3O9bTP9eNX8gQwQCTp3nN+CLyBRRyCTBW8hLdmlrEuwMFtXmTtFouKYCF
IronPort-HdrOrdr: A9a23:Tek0hKOrljMiDMBcT5n255DYdb4zR+YMi2TDiHoedfUFSKOlfp6V8MjzjSWE9Ar4WBkb6LS90DHpewKTyXcH2/hvAV7EZnimhILIFvAs0WKG+Vzd8kLFh5ZgPMtbAspD4ZjLfCVHZKXBkUmF+rQbsaK6GcmT7I+0pRoMPGJXguNbnn1E422gYypLrXx9dOME/e2nl6x6TlSbCBEqR/X+IkNAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEA9n8PMHyyzoggb57qKsv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+cyDpAJb4RHoFqjgpF591H22xa1uUkZC1QZvib3kmhOl1dZyGdgzUIngxesEMKgmXo/0cL6faJNQ7STfAx376wtnDimhYdVBYW6tMX44vRjeslMfuL9h6Nl+TgRlVkkFG5rmEllvNWh3tDUZEGYLsUtoAH+lhJea1wVh4SxbpXWNWGNvusr8q+sGnqGEzxry1q2pihT34zFhCJTgwLvdGUySFfmDR8w1EDzMISk38c/NZlIqM0q9jsI+BtjvVDX8UWZaVyCKMIRta2EHXERVbJPHiJKVrqGakbMzbGqoLx4r8y+Oa2EaZ4gacaidDEShdVpGQyc0XhBYmH24BK6AnERCGnUTHk2qhlltFEU33HNczW2AG4OSUTepGb0oci6+XgKoKOBK4=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BLAAATfVVi/49dJa1UBhwBAQEBAQEHAQESAQEEBAEBQIFGBwEBCwGBUVYHdQJaOESEVINKA4RZYIUQgwIDgROPM4p2gS6BJQNUCwEBAQ0BASwLDAQBAYRCRQIXhF4CJTQJDgECBAEBARIBAQUBAQECAQcEgQkThWgNhkIBAQEBAgEBARAREQwBASoCCwEEBwQCAQgRBAEBAQICIwMCAgIlCxQBCAgCBAENBRoBB4JiAYJlAw0kAQ6ieQGBPgKBDokReoExgQGCCAEBBgQEhQsYgjgDBoEQLAGDEIQphxsnHIINgRUnHIIwNz6CYwEBAoFGCBAXgz83gi6aKAkBJUwCPCYEIiEKBhdEEC1rATk4khKDWYorngyCKwqDSaAABS6DdIw5mCWWXiCCKZ8XAYUJAgQCBAUCDgEBBoFhPIFZcBU7KgGCPlEZD44gDBaDUIUUhUp1AjYCBgEKAQEDCYxnAQE
X-IronPort-AV: E=Sophos;i="5.90,253,1643673600"; d="scan'208";a="994125253"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2022 13:24:32 +0000
Received: from mail.cisco.com (xfe-rtp-001.cisco.com [64.101.210.231]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 23CDOVQk029857 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2022 13:24:32 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 12 Apr 2022 09:24:31 -0400
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 12 Apr 2022 08:24:30 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WNjMGxmi4uIRxwBPSxdJeutYfuQH85VllKJomhCcJxSEMN9rT9ehPsgJ6TzRCh56COxsHKdINJk4STMdZSUMkesj69ex7q9wPoszNGx0NwAFsp3cEpScmi9+VBVmnLi7j7osOQh+aOJXBjjUrV0rCKsKUuP5GGHS5LkoBFqbpOIL6ArXiQR+Kkc/gPY5s1PvE+ic/qfyFJ/njZGphwOXMSdc6m56skhGwbO1LzEOHCtPcNR3REZAjYhDIdmBp+tor+wXzDLOPtQBreOM4V1CsPd/a+1pSE8igvWI/OoSv1ptwYYoPvVisJ8r7mDMo7N9CgkbTLggRIpfmUZJ+6X80A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PXdf82+SALrz5jbwtS2Kf+nzbC5VyrOImKs5DOFZKag=; b=XcJNcF2/d+6KjnidXnx5CeechwFKwRFX5lc3dY7WzkCw91/dHznVdWC9AjS3sc4OFlheG5CeAIjGxeLPdf9qAjdHxRDro3dX+WU/qc3RoeJ/WFGOAsWlaTXFPTyENJFumsWPmoAMjCJQIxP9jaPyUD6h4x6WSIDWMgcKtjTo+Vdv8k+S//SUG8xamzxIR3OHa9kEJp7UUUnzfUftJORh7mhBPRSleYqikB5A+TJNtUQ47E8s/bOPlsGyhUmii+jO0PJT9Z5p3HErOWX6V20YP8kfuJ+4q5wyV+imuGsxF8C4On1zh1V4JONC/+Ym8ppDopKtv1J72f3ohDJ7ozoCgQ==
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=PXdf82+SALrz5jbwtS2Kf+nzbC5VyrOImKs5DOFZKag=; b=u9SdefDcFv96lS4i73h73XjZ+LRfCnuSEBWWdZk19/ImeBpfz1PwXIKlrfMQvXS8CetRGNzogITjMeHFzgP2OvQilbCbbrbIYapZjYrRD2EVcpSFOaAkF7lGXSXeVh1dY0U6jEFU8oTZPABQC4toIRxUOCjxZNOr45XSgWIdLYE=
Received: from BYAPR11MB2757.namprd11.prod.outlook.com (2603:10b6:a02:cb::16) by DM6PR11MB3164.namprd11.prod.outlook.com (2603:10b6:5:58::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Tue, 12 Apr 2022 13:24:29 +0000
Received: from BYAPR11MB2757.namprd11.prod.outlook.com ([fe80::b46e:544c:a2a6:caad]) by BYAPR11MB2757.namprd11.prod.outlook.com ([fe80::b46e:544c:a2a6:caad%6]) with mapi id 15.20.5144.029; Tue, 12 Apr 2022 13:24:29 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Andy Bierman <andy@yumaworks.com>, "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
CC: "lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
Thread-Index: AQHYTcvNbn+Tq5QOm0iy6wQBVXVLMKzsAp6A
Date: Tue, 12 Apr 2022 13:24:29 +0000
Message-ID: <C5B667D3-DE44-4FEF-BA79-00E0DF7FFBF9@cisco.com>
References: <164662287026.10186.17661147788695088858@ietfa.amsl.com> <AM7PR07MB62483353E387A0538EDA44C6A0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <AM7PR07MB6248D0B4D19EF3168DEC4864A0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <978D3500-5A9C-49FA-A259-B4E234CC9332@cisco.com> <AM7PR07MB6248CE4BDC0B27008D4F04BCA0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <2C00E058-F836-415E-A357-797E01FE77AD@cisco.com> <DB7E3112-3C2F-4040-81E1-F4625689DA62@chopps.org> <645FCC0B-8279-4070-B052-A553317B8474@cisco.com> <3F7DDA02-DEFA-4680-B048-1AB0A54C2FA1@chopps.org> <BB1D53D0-0D36-40DF-8B9D-4BD4EB6A35C1@cisco.com> <5b05a34d-41b6-7b65-ebe7-9dcaca80eeb2@alumni.stanford.edu> <m2wnfzydgz.fsf@ja.int.chopps.org> <530e30e1-9436-2123-7d03-eb4f876a9f90@alumni.stanford.edu> <BY5PR11MB4196F5F342BA12E79FF29B08B5EA9@BY5PR11MB4196.namprd11.prod.outlook.com> <CABCOCHS+uLjK5GcpCrmegCWBHoK=1-ySZhqO+D-TEnyGUki5kQ@mail.gmail.com> <de50de1e-7f8c-5cdd-6809-b8fdf0b5df9d@joelhalpern.com>
In-Reply-To: <de50de1e-7f8c-5cdd-6809-b8fdf0b5df9d@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.59.22031300
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9ff7e511-65ab-41df-9b3e-08da1c87c5f8
x-ms-traffictypediagnostic: DM6PR11MB3164:EE_
x-microsoft-antispam-prvs: <DM6PR11MB3164746D0B992E32C004957DC2ED9@DM6PR11MB3164.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6NH5UaOEZMGDl0h1gVqMrS3f81B2PY7Y52dfijVXoFxEALnvyFPCnglV2aYgZ5bpLRSMTXH3u+bPJNDEFqH0nIxddfMZQ41gMZ4Mj1UoYTaK8YsSR6Oh3d3Vcp4xImzVHmfrCtP8UzldvdGtsnS2+4EeuDjb1Hx5FBGg67lIAR+htdE8KecTZvap832x6qE+Eb5j1R/BOqu28tfS+kNSq2GTq9kRmkWiJpM+MfsavqIoL/dAQqmdoE/1BlsU/D0obdbx9qDWCRSO7FvD3O73T/ud1vkUGIvvmfu4RthPd1cI53MkTTyo2Ko7OoQfbtACZceAaUDzCAtJv81UAfTy1ZSEzjJLaCLdYKayCTBrY1qgO24v4vTSt7NxXmcdEosOhQAwqCEH829tjEDqbrgm+gz1xFwsXmBbxnx50koHeprQS4uZgXNBXH+X7M8YcrjJm2ra9M3tylzLDQ4m/9sRnFCwgQ4XklTyPB38i6uJmRpjD++nzQaUgOcKDXPW6P8fKgZNM3KkRce5v2jPaZBN1V6WiVfQJP/YXXpQhgceoJ3nkoH+5wNdlZzYxD2RC+Mtydk8AcrgAEnMQHT5P4xDfv5+z70bbO1SvAffji/rr2+RTxgOSf0hpTSGk/l7k2bcK7H2oQD6H8fbboc91yasV7IOHvyKRt3uTcMdOXq6osNyb+6KJp0CfXgrksWhz9Vi24FZd1FvkcuIvbnoPIW8OojmT4aHBn5I6msaEdl5APPWeuw6nIs/ILrk0+ysqPXOYHMGyNuYuqihWfs9bAc/3E6ezDi8fiXAGdmuUk/Kxw2s3PVqkPzgkBA4DYAqD9T44Ay3mVQQITA1/Fifn5cHPTfcnBGa264rquVP/DC6hW8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2757.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(5660300002)(71200400001)(8936002)(33656002)(76116006)(66446008)(66476007)(66556008)(66946007)(38100700002)(91956017)(38070700005)(86362001)(64756008)(2906002)(8676002)(4326008)(6512007)(122000001)(6506007)(508600001)(53546011)(316002)(966005)(186003)(54906003)(2616005)(83380400001)(26005)(36756003)(6486002)(110136005)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 4qWbq8r8Dhk3dQ4mIALid8j1811py1Aso8u9JhIkXap5Q0JFxu1lejF0vtg5t+eXb0upduo4gyjisQ0WV6Sr9q9TjdpvymKGW0GXXgo/DyKiCmqkXCu0Gka3Fuzf4wXS6OmW5yQVMm8AMu+cpAVI+CYsMBd0GaBuSwYeSg8MF/OgUNVEjtr965H/zq9GYfzlDHUHGHrf/pUbZXjHx31bOxts1MpzRXz4B06Cr1fkE6wDdkdqm7dEH4B9ERhbTHIA9ztaQrF6nq7a9fsRCCkBO354Odeos7rc9NP2pJRt2bTw6DaztGRtMozDfC20ME3ZG1AHpaWybOinZVJESmxjHiHpXpkKeWnLif3m72KWd590VCNxNhznWppR/2xbkwtHBVmB8xkfs6/xGR5fd3PQe9rFfvJzzR9VcUEOxFVt4lppee1KhBWPxlDmOCT9BudjJ17QeH8ilvczgEyIqjAm1cThHpL0gqhaIRwABzKG4magvU4br3ddHGMoItcHFltt2/xeIxLHK2wtD7Oj+CtLyQjWDsX0uDEu1n/XUmAdwS/gjOGdB6nVQq5GQCsjVULcumQIby00dQoOO0oEeC5GWHmLImFT20AwselEZUojTtxi7BFNHbBTmvBQY6QI6CM61ADrfHpSN6QMG4lZNf9U/uk1xl3sZfoHXyrHFDuB8VscKQhb7nl8gQLxqWMNn9iZO/c5emCbW4yOVzq92UjKmIX33vZ3zMWKyqkwTHe7RqTjN3KX+/pZoLv2Axt5kEZ6NIga55WHv67ST69DNBnZKLQdtfEfl6yNhu3eLJFoALkKplsv7hGGX3g1xhfce2bsqMFCgROuqXIOxJktxhv+GKOUAPRu+eJVRpLIzTiWVO6AD2LbdAWzBqpO5pjFxeg8zjV9E70Pda8kevAva3l5idRBXFy4vMYnE5vRK9v3u4enJte8CKP7DVuhRO6R9Dc46q/urZHfMPIegMFuWLiz4BfnGZpKIzMRwTdzg4m0qanXg2nkhwP9byCMnmL1XTzEiDICMYxYdpJKzeT6ETLJLhmRvuYEgxCJbx7CwZe7J7nbNTAPDlfd1YHF8O65/KpsKMmPawGlgWlDsrVJNV6YiPBCgvZ55fo2PCzcpR4R47Ykuf+tOA/HdPNumEIVmEs9fKtfWvgq9ImTMce4lKwvE40P7JFAVGvpf/SFED4JanvwzCrtvIOsbJbMkdj/O3MnLHZenTftBaypTq04mgrYv7HsczzgoLyq0D1vQcLpV08jY6LFk+tWuYqNvPPjh57ysXtGeHX7QSYiHwBgcqxKLHSDQuIxxgIaNn7vorgfWi7InZH2a2rlk1TguDQ0HPY6ItZ/odgRFr97oJTd+hW13AOhPZu7judtXiAnhQtiXA+TLJ3b/DFoQ4P8fz6GleG4rQUJA6IthxbIQWxo3Ej15Mc4vheU7mhOzo6upCxecABXMbFfOiFxYJzcXxHoctSg5zVZoOLx6VESXIg9+vkIY80dwmbOZd14Rb6etfiqgJT3sGNZXtArmLGkj3kZqkpgqOV70JoX7FxbBo52u8Lp2S8ERpaTFbs1DSJU+JPpYpPTbE3a1AG1kS/6IDVtraSteuaFvsmJoS3Lv7ooEG8oO5CAK60J4d4eQBTlFL2NUFZwPjAEU7yq7ceh/qqLIxISvAhy9PyH8xLZxaR04e9uF6gvMivn4TnqtNArNy1XSFevyCNRn+j33FsMFth0gBinb3cB333I06UsmXiRhptaCQ==
Content-Type: text/plain; charset="utf-8"
Content-ID: <14525669167E3244BA89D614749C3F72@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2757.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9ff7e511-65ab-41df-9b3e-08da1c87c5f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2022 13:24:29.3288 (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: vcdRLQ1R25FmA2nJFiNdfEhW4RBgvr35/i/xPdL7oon0PsDX9PMmcSnkGkys2zpa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3164
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 64.101.210.231, xfe-rtp-001.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/21fNbZW0Yub9JeYzmLfSX1l_9D0>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2022 13:24:39 -0000
Joel, There are plenty of examples of where the ip-address types are used and a zone is not accepted. Show me the examples where it is expected? I do have reason to believe there aren't any significant usages of the ip-address types where zone is accepted. Show me the models!!!! Acee On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern" <lsr-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote: Do we have reason to believe that no one outside the IETF has used ip-address as we published in ways that need a zone? It seems to me that the first step in the plan below is reasonable. But changing ip-address itself seems a bad idea. If one means no-zone, use the -no-zone typedef. Yours, Joel On 4/11/2022 1:28 PM, Andy Bierman wrote: > > > On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) > <rwilton=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>> > wrote: > > Hi all, > > Thanks for the comments on this thread so far. It would be nice if > we are able to come to some sort of rough consensus to a solution. > > I think that there is consensus that the YANG type ip-address (and > the v4/v6 versions) are badly named as the prominent default type > name has been given to the unusual variant of including zone > information. > > Based on the comments on this thread, it also seems likely to me > that most of the usages of ip-address in YANG RFCs is likely to be > wrong, and the intention was that IP addresses without zones was > intended. At a rough count, of the published RFC YANG models at > github YangModels/standard/ietf/RFC/ to be: > 86 uses of ip-address > 68 uses of ipv4-address > 66 uses of ipv6-address > > 1 use of ip-address-no-zone > 4 uses of ipv4-address-no-zone > 4 uses of ipv6-address-no-zone > > These types appear in 49 out of the 141 YANG modules published in > RFCs. At a quick guess/check it looks like these 49 YANG modules > may appear in 40-50 RFCs. > > As mentioned previously, it is also worth comparing this to the > OpenConfig YANG modules: > They have redefined ip-address (and v4/v6 variants) to exclude zone > information and have defined separate types include zone information. > There are no explicit uses of the "-zoned" variants of OpenConfig IP > addresses in the latest OpenConfig github repository. However, > approximately a third of the IP address types are still to the > ietf-inet-types.yang rather than openconfig-inet-types.yang, so in > theory some of those 58 entries could still intentionally be > supporting zoned IP addresses, but I would expect that the vast > majority would not. > I do see some strong benefit if this basic type being defined in the > same way in both IETF and OC YANG, and I believe that the OC folks > have got the definition right. > > I see that some are arguing that the zone in the ip-address > definition is effectively optional, and implementations are not > really obliged to implement it. I don't find that argument > compelling, at least not with the current definition of ip-address > in RFC 6991. I see a clear difference between a type defined with > an incomplete regex that may allow some invalid values and a type > that is explicitly defined to included additional values in the > allowable value space. Further, I believe that a client just > looking at the YANG module could reasonably expect a server that > implements a data node using ip-address would be expected to support > IP zones, where they are meaningful, or otherwise they should > deviate that data node to indicate that they don't conform to the model. > > We also need to be realistic as to what implementations will do. > They are not going to start writing code to support zones just > because they are in the model. They will mostly reject IP addresses > with zone information. Perhaps some will deviate the type to > ip-address-no-zone, but probably most won't. > > The option of respinning approx. 40-50 RFCs to fix this doesn't feel > at all appealing. This would take a significant amount of > time/effort and I think that we will struggle to find folks who are > willing to do this. Although errata could be used to point out the > bug, then can't be used to fix it, all the errata would be "hold for > document update" at best. Further, during the time that it would > take us to fix it, it is plausible that more incorrect usages of > ip-address will likely occur (but perhaps could be policed via > scripted checks/warnings). > > > I still feel the right long-term solution here is to get to a state > where the "ip-address" type means what 99% of people expect it to > mean, i.e., excluding zone information. > > Given the pushback on making a single non-backwards compatible > change to the new definition, I want to ask whether the following > might be a possible path that gains wider consensus: > > (1) In RFC 6991 bis, I propose that we: > (i) define new ip-address-with-zone types (and v4 and v6 versions) > and keep the -no-zone versions. > (ii) we change the description of "ip-address" to indicate: > - Although the type allows for zone information, many > implementations are unlikely to accept zone information in most > scenarios (i.e., so the description of the type more accurately > reflects reality). > - A new ip-address-with-zone type has been introduced to use where > zoned IP addresses are required/useful, and models that use > ip-address with the intention of supporting zoned IP addresses MUST > migrate to ip-address-with-zone. > - In the future (at least 2 years after RFC 6991 bis is published), > the expectation is that the definition of ip-address will change to > match that of ip-address-no-zone. > > (2) Then in 2 years time, we publish RFC 6991-bis-bis to change the > definition of ip-address to match ip-address-no-zone and deprecate > the "-no-zone" version at the same time. > > My reasoning as to why to take this path is: > (1) It is a phased migration, nothing breaks, 3rd parties have time > to migrate. > (2) It ends up with the right definition (with the added bonus that > it aligns to the OC definition). > (3) It doesn't require us republishing 40+ RFCs. > (4) it hopefully allows us to use YANG versioning to flag this as an > NBC change, along with the other standards to help mitigate this > change (import revision-or-derived, YANG packages, schema comparison). > > I would be keen to hear thoughts on whether this could be a workable > consensus solution - i.e., specifically, you would be able to live > with it. > > > > This is a very thoughtful proposal. Looks good to me. > > It does introduce a window in which some new modules might start using > 'ip-address-no-zone'. > Should they wait for the real 'ip-address' in 2 more years or just use > 'ip-address-no-zone'? > > The leaf description-stmt using 'ip-address' should specify if any zone > support is required. > The default could be 'none' so no mention is needed most of the time. > > > > > Regards, > Rob > > > > Andy > > > > -----Original Message----- > > From: netmod <netmod-bounces@ietf.org > <mailto:netmod-bounces@ietf.org>> On Behalf Of Randy Presuhn > > Sent: 08 April 2022 18:59 > > To: Christian Hopps <chopps@chopps.org <mailto:chopps@chopps.org>> > > Cc: lsr@ietf.org <mailto:lsr@ietf.org>; netmod@ietf.org > <mailto:netmod@ietf.org> > > Subject: Re: [netmod] [Lsr] I-D Action: > draft-ietf-lsr-ospfv3-extended-lsa- > > yang-10.txt > > > > Hi - > > > > On 2022-04-08 5:11 AM, Christian Hopps wrote: > > .. > > > Instead, Acee (I'm not sure I'd call him WG B :) is asserting that > > > *nobody* actually wanted the current type, and it has been misused > > > everywhere and all over. The vast majority of implementations in > > > operation probably can't even handle the actual type (Andy's > point). So, > > > Acee is just the messenger of bad news here. Please note that > the AD in > > > charge of all this agreed with Acee as well. > > > > That's not the impression one gets from modules like > > https://www.ietf.org/archive/id/draft-ietf-mpls-mldp-yang-10.txt > <https://www.ietf.org/archive/id/draft-ietf-mpls-mldp-yang-10.txt> > > which employs both types. So, regardless of whether one is willing > > to respect YANG's compatibility rules, it's no longer a matter of > > speculation whether a name change would cause actual damage - > > it clearly would. Furthermore, my recollection is that the > > WG *did* discuss whether the "zonable" property was needed, so > > any argument based on the assertion that "*nobody* actually > > wanted the current type" seems to me to based on a false premise. > > > > Randy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org <mailto:netmod@ietf.org> > > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod> > > _______________________________________________ > netmod mailing list > netmod@ietf.org <mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Kent Watsen
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Reshad Rahman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Reshad Rahman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Yingzhen Qu
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Kent Watsen
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Charles Eckel (eckelcu)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman