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 14:54 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 F27183A0AAE; Tue, 12 Apr 2022 07:54:29 -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_H5=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=K/CfYBAm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0qMQ2oan
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmI1cvdqpegN; Tue, 12 Apr 2022 07:54:24 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1113A1839; Tue, 12 Apr 2022 07:54:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17702; q=dns/txt; s=iport; t=1649775264; x=1650984864; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WgGD6tbqDilxlJTRZFA5s43sxzPvulS6QUiW5RCsMpk=; b=K/CfYBAmEhs4C2rEmUiPeOEGYpoJ/ebfKNhzc/R6p4av392Eh/n8B6m9 6rYoILfbiHVyALG50sqgpqIuHE2gV56S/O7Rveb1CM5vTRk+CdIsBgrhy wkS781m1vYznWCsFozgj236S4PtZ7pamn4tnhKxtZIxEV6o45a2bDK54n s=;
X-IPAS-Result: A0BLAADKkVVi/4kNJK1UBhwBAQEBAQEHAQESAQEEBAEBQIFGBwEBCwGBUVYHdQJaOESEVINKA4RZYIUQgwIDgROPM4p2gS6BJQNUCwEBAQ0BASwLDAQBAYRCRQIXhF4CJTQJDgECBAEBAQEDAgMBAQEBAQEDAQEFAQEBAgEHBIEJE4VoDYZCAQEBAQMBARAREQwBASoCCwELBAIBCBEEAQEBAgIjAwICAiULFAEICAIEDgUaAQeCYgGCZQMxAQ6iawGBPgKBDokReoExgQGCCAEBBgQEglOCOBiCOAMGgRAsAYMQhCmHGyccgg2BFScMEIIwNz6CYwEBAoFGCBAXgz83gi6aKgkBJUwCPCYEIiEKBhc5CxAtawE5OJISg1mKK54MgisKg0mXVYgrBS6DdIw5mCWWXoJJnxcBhQkCBAIEBQIOAQEGgWE8gVlwFTsqAYI+URkPjiAMFoNQhRSFSnUCNgIGAQoBAQMJjGcBAQ
IronPort-PHdr: A9a23:0ZV7mR0rBDf/bAkzsmDPr1BlVkEcU/3cMg0U788hjLRDOuSm8o/5N UPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AUhYfgpAQmAotSMeOFUz8KqvsaCo3V MRPXVNo5Te1K09QTc3/fFbV5Ha16G16Jw==
IronPort-Data: A9a23:ujql0q2UoATAUjHrovbD5Uxzkn2cJEfYwER7XKvMYLTBsI5bpzQFz DBLXW2BOPqJZWf3Kt9wO4W1oUsCvpGGnN42HQts3Hw8FHgiRegpqji6wuYcGwvIc6UvmWo+t 512huHodZxyFjmGzvuUGuCJQUNUjclkfZKhTr+cUsxNbVU8En151Us5w7RRbrNA2LBVPSvc4 bsenOWHULOV82Yc3rU8sv/rRLtH5ZweiRtA1rAMTakjUGz2yxH5OKkiyZSZdBMUdGX78tmSH I4vxJnhlo/QEoxE5tmNyt4XeWVSKlLe0JTnZnd+A8CfbhZ+SiMa77g3HvMHUk5trRaGzsxe0 IlpuJu5cFJ8VkHMsLx1vxhwGiV6O+hN/6XKZCT5us2IxEqAeHzpqxlsJBhpZstDpKAuWicXr qNwxDMlNnhvg8q/y7+2YuJtnc8kasLsOevzv1kwkGGJVa52GMirr6Pi7o4B/RQvqd91O/fSe skrSWY0bD7wWkgaUrsQINdk9AuyvVH5fiFdr169pKcr7S7U1gMZ+Lz2KvLUd8CEA8JPkS6wp GfG12b+DxUaPdiHxCCDtHmrg4fycTjTUYYWEviz8eRnxQHVzW0IAxpQXly+yRWktnODtxtkA xR80kITQWIarSRHkvGVs8WEnUO5
IronPort-HdrOrdr: A9a23:Yz6Jg6pG5wk32AslLEfMp+saV5tzLNV00zEX/kB9WHVpm5Oj+f xGzc516farslossSkb6Ky90KnpewK5yXbsibNhc4tKLzOWx1dAS7sSrLcKogeQVBEWk9Q96U 4OSdkHNDSdNykZsS++2njELz9C+qjGzEnLv5ak854Fd2gDAMsMj3YbNu/YKDwNeOAsP+tfKH Po3Ls/m9PWQwVwUi3UPAhhY8Hz4/nw0L72ax8PABAqrCOUiymz1bL8Gx+Emj8DTjJm294ZgC v4uj28wp/mn+Cwyxfa2WOWxY9RgsHdxtxKA9HJotQJKw/rlh2jaO1aKv+/VXEO0aSSAWQR4Z 7xSiQbToJOArTqDziISC7Wqk3dOfAVmiffIBGj8CDeSIfCNUwH4oJ69PNkm13imhAdVBUW6t MW44pf3KAnUC8o1R6NlOQhHXtR5zqJiGtnnugJg3NFV4wCLLdXsIwE5UtQVIwNBSTg9ekcYa NT5eznlb5rmGmhHjvkV6hUsauRd2V2Gg3DTlkJu8ST3TQTlHdlz1EAzMhamnsb7poyR5RN+u yBa81T5f1zZ95Tabg4CPYKQMOxBGCISRXQMHiKKVCiEK0cIXrCp5P+/b1w7uC3f54Dyoc0hf 36IR5lnH93f1irBdyF3ZVN/ByISGKhXS71wsUb/JR9sq2UfsujDcRCciFZryKNmYRrPiSAYY fABHt/OY6WEVfT
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.90,254,1643673600"; d="scan'208";a="858800810"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2022 14:54:22 +0000
Received: from mail.cisco.com (xfe-aln-005.cisco.com [173.37.135.125]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 23CEsMGQ028077 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2022 14:54:22 GMT
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-aln-005.cisco.com (173.37.135.125) 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:54:22 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 12 Apr 2022 09:54:22 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b6E2ryaTAQzhseobF56p2D+UFxChtqHyPH3QI9ZABo00GLQFV5GCl70jq1lgPJ64zDihMNMlr9WW4GEY2cCCa9yAHnAuYKw3Wu568SvnhpPlq65ZDEUTS5mBAKUOXIOAP4RGsaPMJh6H76ztjIawHXWAtRDS2Z3f1nXleahHfs21k+JUfpEa9JNnp7zk5KJc6JwtYXX3guHqiSXFC6H0iYeycEaFyJVUiFNXEcKbNMCnqTFmLmjLvTJGLfkbZoS9zlxDN3dUEn7oWqfXbc/Vx/laxzcPc3jRA5GVm+h/bueL/JHV9xxR/fL2qvNRQlSS95S6Y6gz6z5uIfzfWshIiQ==
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=WgGD6tbqDilxlJTRZFA5s43sxzPvulS6QUiW5RCsMpk=; b=fnnJv7RvWijINlksu860HQqmMwpjuPFypxaWQMha2o9sVLO0M678ClcqmlH+BRwjBDvjpkWzdgcsRurUlUmcR+mIce6Qfg8xNiXfwGSg3vssEa5AGVhc3WTRWYqlBMBeQnpxMRDTdNmlO6KAzWqEdgpkv2VOyiY1b/yQQNaVhtvUjl73SMuDswgB5NJU5Cpy9gLyUAwAORXSgrKehOksAkmE/UsoKjasjVeH/Mvq+rtKM9q7aTYguXTSHDXqs4RVsvEyKSq1d2op6XOLvJD13VGyLi7F6S5mITuSvADbQfr3/x6DtNMl2GiFoLccFYGnrPAc9DktdJvDI3Xs52d3Ag==
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=WgGD6tbqDilxlJTRZFA5s43sxzPvulS6QUiW5RCsMpk=; b=0qMQ2oangMCDQXkWKtL9CgFf0F1LkmC3JKLJDQyM9c7CjA56f7Izn/odPwqPJ26rlViUODOdBI96r00WJWSBCPya+4BGK/DJRwbfDkQgDUSlLeHoH5bAA3mSdeaCnKoGHiNOPD8/Vzkk4PNaHa1X2HP2Z+rkPE879wH4sDZioLY=
Received: from BYAPR11MB2757.namprd11.prod.outlook.com (2603:10b6:a02:cb::16) by SA1PR11MB5946.namprd11.prod.outlook.com (2603:10b6:806:23a::9) 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 14:54:17 +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 14:54:17 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
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+Tq5QOm0iy6wQBVXVLMKzsAp6AgABaOID//77fgA==
Date: Tue, 12 Apr 2022 14:54:16 +0000
Message-ID: <2379D806-6043-4074-8A3C-0A7AA1053166@cisco.com>
References: <164662287026.10186.17661147788695088858@ietfa.amsl.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> <C5B667D3-DE44-4FEF-BA79-00E0DF7FFBF9@cisco.com> <1a5b93a9-4ffd-eb56-2b41-6ccc26b2e22d@joelhalpern.com>
In-Reply-To: <1a5b93a9-4ffd-eb56-2b41-6ccc26b2e22d@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: 282e78c4-4898-4768-476e-08da1c945191
x-ms-traffictypediagnostic: SA1PR11MB5946:EE_
x-microsoft-antispam-prvs: <SA1PR11MB5946553C51835C93049E6734C2ED9@SA1PR11MB5946.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: Rv/xM7+NAvTRgXhP0/+XuIHceYrN9WQTVdoxLyIUPFf7suy50QpSTnYYoS9oieg7SfuLMx7cBGk0XbkR4RdRnmx+tzewbnDVaGIjToh0tb07FU9pyP4OJyS8Aong+5i4ssbvX3krefQNZjNenWADGGsrzdV/EIUdVmvcvQ6AUXsgYhP5cnqPVe45QHsWw8e0aA8npTxNVGz09EUzpl6oPIPvytJMsdfYbWe6s+pfDs21PAPyFRw3ALcbVb919Nh1QzJtSCHhEwI2OPPIJkaRAonpFhZebmYtw5MDdpgvyC0i/uwBVQSCpGpxbmf6ybchoguPhQA+AEAXqLoChqKguaCEZ5KdYao0iB8lIVPYTfixzVqQMUu7S40/znk6kr2hNGf27NobWduR09ZI2FVOs5d0dF8lDjnoO+6t4qKS3KmMH004HZTlxuVG5ypvKM4h1ZSehVpBL68SL+EhNbAXIj6XT3Ff0Tiut9qAer0sT+TFUyayg5C4XoRZstg3olPQ789kA6O3g78kKJWSbdP8A/f+AXlItTGw/zSvR8rchDDMACUtsaGDY5DhocrTwILj1o060p6oDYYOPtzxB3yfk5OX7CrE1ZXJEfR+s3XDQBBNxTsscJiTqk8nvUYlxnltSbIiIqfXNeyqS4nYN2YlRSVhIKjlRPNeoO4ew2wRFqTjUeo1XoICfjxHMr7IYjBbZUuoE+Bi80WHugHXjtUOX+r77mJV/PXB14Rzmeg424drs1dOdmzxWlNIzePBS3Ihw5I+4N2oeLfXAVCuxjuilm9nDj3hUh9DzfXmUTX2VqYhrkMiRqdGbiBfJO93tUwrwxqOnmaca0Q3oUeGJgd8lcdoXpB5TtNTIjMZRxLmfVY=
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)(64756008)(8676002)(508600001)(122000001)(966005)(38100700002)(2616005)(66946007)(86362001)(33656002)(71200400001)(8936002)(76116006)(38070700005)(91956017)(54906003)(66476007)(6916009)(66556008)(316002)(66446008)(53546011)(6486002)(4326008)(6506007)(6512007)(26005)(83380400001)(186003)(5660300002)(36756003)(2906002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: KEyuYMjd8aih1ormbusUkIsZ+K5M4wEd4BWfmqfd3hPx8D95MqQa8cTjpCu9v3mafq2EOVA0vUNVGa2ETrACdRuiY1N7wGEs0xtt/d2f5ScuiGv3uU48QHdM6DC38wb5J8GNydKt43Qjk8eSWbISAnKxgmCPA6Nl1Voqt/HAEStaxgxsbbbkzDXfq+gDtf6Fo0nAAcul4MWie03d8FCTdS8s1UBe7NF+bOxSuUhdy0cBr/rRHBGDhpwYG2iqu6LbwQ6uT+4RqC1kg7m/PsWsDu1kz/PtweyD5p7RdPK+GgwJB2GKZM9/k5utzM07dhoWxhWrknElFkO48Ss7ASXvExqv8q6GgzxoCjvx2K45nbfQdahQr9XoHw/GjH92TaiJhiuIajGBAPUdqZWnJkHLxERTlKp3BH9021l1oHN4SkhYyoEB1A7RFlxSeapkyGid5BeGckHr+s0kyu3+UVhvCKvzDISlaw/Ewei1PXX2OuE+nOzFb05U66dIVsxpkzsHNE+qaxXw3ufMnxL+YQpIFMwin17SObSxm5e74B5nFNRnJkziCIDsECXn2LQYzInE7vPkLsXYPQf70/R9SC7nXQJ9+7QXjf8HJ4tGWLdQKYX5Dt4/c637joI340GCTuOdb1U1FNthEGgPz/nTOBJioZGlch6Z1sT6u8SjwmohSYtQ0QECrufQHRemtu5jOir+XEKA7mYcOfgLLVTMB8/FIml730uyceXdxcBB+tx9GowD/BYPyjdGzHJ6IqmbCqNAYAXctS8vopUXvmDBPhgoOft+LFTJug/ZfnnQjVANzJfcJQ6T87gJ9QqEuPnzUKVXyy5CEPcDNsJPCHOaKq8Q621SmMMEmINZg0E16DRiiig1PSkjxKWgEtB/VrPhKI3OKaSBb7m2P2oXVe4T7GmgmH4Gputx5u7kN7NiO5g9CA1LsCwsJNXxbPS2pGpeBRF6dK4EdrWnMqFf6iC4agAt/HINO8TkzdJ57z11oM1f5VfEkeMKXkS3y6Y3hr8kCIiSAr9F9ohm18ja9NLFwKJ1DNrCwBODPw0sC0XRw6n8wQXHkzXAg21VaSeLmf70jtVVPkjSPMZQ970atE6H79IwfloHhCWcFEdFoZHnbsxY7v+9izqH70ykARYIBcM+xDWi8vxdZW5K4hh6VOjV01NjQM1Ypl5bsqdyo9sAjk4UONrd0R4Igu4gxdXyK0marF9pQRbhb7sfrRx/wNefjrU9OeTnjGzKh9v4frZ0PHO4Ue77e6FKbsbsq0JeYa6vfpLLPpn3ojGH8ULJ+XzJLPxSBSu7nRKuMgdvkRLzfFjECDAiqnEJGCM940hAD+QYkBLnq1LTCwItQZK1dGMg4hWLgJBKmA5IB3nLMv1c8VlpQ7EdO38jRcLRmdbVwE5zGPUsalb1YJGfSUYUDbTM89dBTfmNe/8FYCTkod9cGTd7Bo0I23h8oXCPaOJv+dgdCmsN85AFwVl864l0xcxmtteG6hFntCXsRh3D9BsbL9ovOR7mjg66k2Whyn/TfS2WluVgkhUANqf1u1558tategzwaicGwERH/4Dad9L7JOo9S7jyKxGLzbSnurkc8yY9Xa5/tpm+EwLGIruYYvvSWT+YkhNiLsNc0q4rjekkfGNikrviJNOwgPmF+VtpJQfbRwWVZUMNFLTuZq8Mqbyy+sEzfs1pqGbAh6eZp1uEFfs7fXC70C6pbCBLfkl+nj0S1FbMC9DnSGbzc62o1OzIR8joiQ==
Content-Type: text/plain; charset="utf-8"
Content-ID: <6F782A4BEAB12A408B39F1A0D6F03301@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: 282e78c4-4898-4768-476e-08da1c945191
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2022 14:54:17.4622 (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: WigRfunEF/oL5ob87IqhJK/OSNwBaBPqn68j6tMwVarTcbzeK4q42aCBCF236kFf
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB5946
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.135.125, xfe-aln-005.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/aVNApTl_4x18dhOzZRb65ZgO3fc>
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 14:54:30 -0000
That was a hypothetical example based on IPv6 Link Local addresses - not one anyone has implemented or deployed. Thanks, Acee On 4/12/22, 10:47 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote: Juergen posted an example of where ip-address is used and zones are expected. Yours, Joel On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote: > 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