[mpls] Re: [Last-Call] Re: [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07
mohamed.boucadair@orange.com Thu, 06 June 2024 10:05 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3009AC180B6E; Thu, 6 Jun 2024 03:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlU7k24Knt5X; Thu, 6 Jun 2024 03:05:33 -0700 (PDT)
Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.236]) (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 81ABCC1D5C7C; Thu, 6 Jun 2024 03:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1717668331; x=1749204331; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=WdwMjAEBQklwepW7c9le1KtBdsd3HOEDeWouDVSy50E=; b=NkUI4t5C7ydd+bAiMICrP2GuLEC+4TwlryARa6dA1YD1IYrmUb+z/ZjQ uzNTelaCaKGhtuk7DV44p6UbaHf/GTtZWeROe+KhDpxxDPyCBa1XHxCdh tielh8/UkcbkjfCM5W3KKq+WTBIHR8WRRioZ+OUrdXOFeU1Pcjt6rIl73 QhwUbHbxQQO7mW8oxBoY56xG+FCc7yc40WwY1ibX/CU+OQ1KeVvvirK64 aa5mqwV9waWPEXJ79CNZaS8M2citlqfyAXkkfXICiriSnN1pt0boumi3a 8AtMH2CYHKTu3zWJCuaVP1TUi8zQ9fQ4UfJB9CXPk4PYIxGx6Anmpqxsd g==;
Received: from unknown (HELO opfedv1rlp0d.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jun 2024 12:05:28 +0200
Received: from unknown (HELO opzinddimail1.si.francetelecom.fr) ([x.x.x.x]) by opfedv1rlp0d.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jun 2024 12:05:28 +0200
Received: from opzinddimail1.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with SMTP id 1C620DE85E3E; Thu, 6 Jun 2024 12:05:28 +0200 (CEST)
Received: from opzinddimail1.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id C3440DE87F9E; Thu, 6 Jun 2024 11:49:17 +0200 (CEST)
Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail1.si.francetelecom.fr (Postfix) with ESMTPS; Thu, 6 Jun 2024 11:49:17 +0200 (CEST)
Received: from mail-am6eur05lp2110.outbound.protection.outlook.com (HELO EUR05-AM6-obe.outbound.protection.outlook.com) ([104.47.18.110]) by smtp-out365.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jun 2024 11:49:16 +0200
Received: from DU2PR02MB10160.eurprd02.prod.outlook.com (2603:10a6:10:49b::6) by AM0PR02MB5826.eurprd02.prod.outlook.com (2603:10a6:208:189::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.33; Thu, 6 Jun 2024 09:49:13 +0000
Received: from DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::c9a1:d43c:e7c6:dce1]) by DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::c9a1:d43c:e7c6:dce1%6]) with mapi id 15.20.7633.021; Thu, 6 Jun 2024 09:49:13 +0000
From: mohamed.boucadair@orange.com
X-TM-AS-ERS: 10.218.35.126-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ==
X-DDEI-TLS-USAGE: Used
Authentication-Results: smtp-out365.orange.com; dkim=none (message not signed) header.i=none; spf=Fail smtp.mailfrom=mohamed.boucadair@orange.com; spf=Pass smtp.helo=postmaster@EUR05-AM6-obe.outbound.protection.outlook.com
Received-SPF: Fail (smtp-in365b.orange.com: domain of mohamed.boucadair@orange.com does not designate 104.47.18.110 as permitted sender) identity=mailfrom; client-ip=104.47.18.110; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="mohamed.boucadair@orange.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 include:spfa.orange.com include:spfb.orange.com include:spfc.orange.com include:spfd.orange.com include:spfe.orange.com include:spff.orange.com include:spf6a.orange.com include:spffed-ip.orange.com include:spffed-mm.orange.com -all"
Received-SPF: Pass (smtp-in365b.orange.com: domain of postmaster@EUR05-AM6-obe.outbound.protection.outlook.com designates 104.47.18.110 as permitted sender) identity=helo; client-ip=104.47.18.110; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="postmaster@EUR05-AM6-obe.outbound.protection.outlook.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all"
IronPort-Data: A9a23:fujIYayJ01h+mRHWahN6t+fjwSrEfRIJ4+MujC+fZmUNrF6WrkVVm jYZD2HUPfuJa2v2fth+aoS1oRxS78XSzoVhHVRqqS00HyNBpPSeCIXCJC8cHc8zwu4v7q5Dx 59DAjUVBJlsFhcwnj/0bv676yAUOZigHtLUEPTDNj16WThqQSIgjQMLs+Mii+aEu/Dha++2k Y20+5231GONgWYubjpKs/za8nuDgdyp0N8mlg1nDRx0lA+G/5UlJMp3Db28KXL+Xr5VEoaSL woU5Ojklo9x105F5uKNyt4XQGVTKlLhFVHmZk5tZkSXqkMqShrecEoMHKF0hU9/011llj3qo TlHncTYpQwBZsUglAmBOvVVO3kWAEFIxFPICVXmmOHM02PpTya2yuRpFkcTD6c73s8iVAmi9 dRAQNwMRj2+vbrrhZueFKxrjMllK9T3NoQCvH0m1SveEfstXZHERePN+MNc2zAzwMtJGJ4yZ eJAMWYpMEuGOk0JYw5PYH49tL/Aan3XdjpYoVeYqew95HXYxQB40aLFN8DcfNOHA85Smy50o 0qapz6jWEpLb7RzzxKpyF6wo6z3pxjRc7hRPpaI5vtmrEOckzl75Bo+DgDh/abRZlSFc95TA 0AU4Dcwoag1+F3tRd74NzWpoXiLrB4RXZxRHvE0wA6Iw6vQpQ2eAwAsRzVMZZonudM4bTMv3 16N2djuAFRHqqGaDH6c7J+VoC+8fy8PIgcqaTUNQxdA4tT/rsQ2lhbUC9N4HOukh9v6Xzj0x xiLoTQwwbIJgqYj06yg4RXMijaojpnEUgBz4R/YNkqg9gdiTI+oe4Lu7kLUhcusN66cR1iF+ XEBxcWD9rhTCYnXzXXVBuIQALuu+vCJdiXGhkJiFIUg8DLr/GO/eYdX43d1I0IB3ts4lSHBT Rb6lFxNyrBvYSGjfKhtZaeDIecO5P21fTj6bcz8Yt1La5l3UQaI+iByeEKdt1wBdmB8wMnT3 r/LIK6R4WYmNEhx8Nahb8E5uYLHKwg7zGLXAJn+kRm6y+LDYGbPEO5ddlyTcuo+8aWI5h3P9 MpSPNeLzBMZV/DiZi7Q8sgYKlViwZkH6XLe+5w/mg2re1EO9IQd5xn5nOxJl2tNw/s9qwsw1 ivhMnK0MXKm7ZE9FS2Ea2p4dJTkVotloHQwMEQEZAnxhCZ6O9zxsP5GLvPbmIXLEsQylZaYq NFVKq297ghnFmqeoFzxkLGh8tM+L0Tz1WpiwQL8P2ZjLscIq/P1Fi/MJVC1qHZm4tufsMo1u bq70Q3HCZEEXRwKMSolQKPH8r9FhlBEwLgadxKQfLF7IRywmKA0cXCZpqFseakkd06crgZ2I i7NXH/0U8GW/9RqmDQI7IjYx7qU/xxWRBQBRjKLtevuaEE3PAOLmOd9bQpBRhiFPEucxUloT b89Iy3UWBHGoLpLj2a4O5tW9/pjovLK+fpdxAkiG2jXZVO2DL8mOmOBwcREqqxKwPlepBeyX UWMvNJdPN1l/ev7RUUJKlNNgvurjJkpdvv6tZzZ43kWIAdw5rOBXkgUNB6J4MCYBKUgK5srm I/Np+ZKgzGCZsIWD+u7
IronPort-HdrOrdr: A9a23:FjjVD6/1kUXFTk/mIkJuk+D2I+orL9Y04lQ7vn2ZOiYlCPBw9v re5cjzsCWftN9/YgBFpTgfUJPwPE80maQFgrX5Xo3SOjUO2lHYS72KhLGKq1aBJ8SXzI9gPM xbAs1D4ajLfCNHZKjBkWuF+hUbrOVvMprEuQ4T9RhQpHlRGtldBs5CZDqmLg==
X-Talos-CUID: 9a23:lWJJJ26iWVkv1CBkx9ss2Rc9N585XFLhkS3ZMkiiD0NbYp6xYArF
X-Talos-MUID: 9a23:xBRNYQvpMI2PZLlmt82nqAtOKOIr256VIms30r8ti9mBOQBuNGLI
X-IronPort-AV: E=Sophos;i="6.08,218,1712613600"; d="scan'208,217";a="40222393"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SkpylKvvcfhC1/0smdXo35Kn/s8ZadcncU8Yz1m+GAwz42XVnmIMfsu4zCPD2AjC1krpa4FNk9kIDSFL4Tf7tR6UyRjV02o0XmwpgTwuCVO7V5rS8L7OskTnVwievDNMD+NJMa7MAErzHMne2PYNe1y2o9nbKbkU7BKLUBWN7svB8C9cIiGWttPOhrTJVSnZ/hCnf3pn+MsNVK5tYQXNaE0OElOYMYm4C6g00J8XLGqVkMorTdUYlz5UTjf3s0lpsMQyEtUq8bsEQtPlKn88c0qfnjO5VW3kKh2MYqV+trUJhGVJA70hWbtFF1klNfxdjChgWQXeTaNq94vqYRophQ==
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=ZlmzotSpQbeKlgMKTblJTmWyzkiiodV4xci1FL0D1NY=; b=HkIzlfvxDQQU/r2HHv+KEcdaeBhHKqrA63QlMMKDu9UTy8780zI0B/eDd71k38d/5uFJp3j9QT2tR+a2PDbGGF05HKBYAGEcFyhqimIKxyhxpq2P7GmR3cVgHdVv47aSYuTzNzoX+d+PlAyutvWpAEyi+a//XCUf/SSM6DFv7ZO8wGSRY8gHK3YuoyVazkNAvfAB6OAoEBd3odbaLCN5y2waxd4eJEQc7OI2hZvwNNpq6Dp2/w1Wl+zWsWBJ51u3KFGWPF9+KdGvlJkICIGm190wYrdGzb8l1mPI+5Sn1Xgasi1uV0ZeSQBdSZtpD5oxcqbr2nNer1pGUtUcYjKISA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=orange.com; dmarc=pass action=none header.from=orange.com; dkim=pass header.d=orange.com; arc=none
To: Dhruv Dhody <dd@dhruvdhody.com>
Thread-Topic: [Last-Call] Re: [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07
Thread-Index: AQHat/MmN4angApY5k6/neO0Mnhd97G6e93Q
Date: Thu, 06 Jun 2024 09:49:12 +0000
Message-ID: <DU2PR02MB1016069DAE5EBDBD02DAD3C0688FA2@DU2PR02MB10160.eurprd02.prod.outlook.com>
References: <171743797081.42914.4518891340142384843@ietfa.amsl.com> <DU2PR02MB1016077CA409CD39DB09F04E988F82@DU2PR02MB10160.eurprd02.prod.outlook.com> <CABY-gOOhPR=3nixD2qwW99i9DArYNiY3Xk-w258B2Pa4vqz2bg@mail.gmail.com> <DU2PR02MB101603134893C129D606A271288F92@DU2PR02MB10160.eurprd02.prod.outlook.com> <92571ED1-FD5F-47C6-A158-2E3BE2B2B0CB@gmail.com> <DU2PR02MB101608D94311BD0B28776344788F92@DU2PR02MB10160.eurprd02.prod.outlook.com> <CABY-gOPB=HKpTVX-nzy9HNabv0bXNU6Fz5AK4KA-8V9kfJjVvg@mail.gmail.com> <DU2PR02MB101605909EAA0561B18194E1A88F92@DU2PR02MB10160.eurprd02.prod.outlook.com> <CABY-gOOxwwAm+SmxqLZKkyDOre1rW4UT=vTO_YWFkshs3DyAyQ@mail.gmail.com> <DU2PR02MB101607B0BC82F9128AD02C35688FA2@DU2PR02MB10160.eurprd02.prod.outlook.com> <CAP7zK5aKn4N+hUYNk45He+MPROThcBSv=8ypLYKtRW3hc500XA@mail.gmail.com> <DU2PR02MB10160C927F47A9063CA4BBC0C88FA2@DU2PR02MB10160.eurprd02.prod.outlook.com> <CAP7zK5acAj4hcLkKv+TN661bVvW64Hfh8R-9uxbGMoqjzG-ozQ@mail.gmail.com>
In-Reply-To: <CAP7zK5acAj4hcLkKv+TN661bVvW64Hfh8R-9uxbGMoqjzG-ozQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU2PR02MB10160:EE_|AM0PR02MB5826:EE_
x-ms-office365-filtering-correlation-id: 4b286b80-af60-47a7-0535-08dc860debe3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230031|366007|1800799015|376005|38070700009;
x-microsoft-antispam-message-info: 9na0rutOjR/SLAzQPWmeQg+ekP9MflmWP4vYJ5MfQVR6QFyAgR4cvPPkQynMdlUalztkNpMJm/Lcno8o3SZ5UgU148f9PoPPzVC/lvr6Z2OcHsF6LvX+yef9ThoFyQmZpdiB9A7XyKR9E4gizYkEhe9FRQpkuOdFQBKFYHfr1wtwVOfWzt03A9pNABCMhE75aqHqgnAZEYFQlV49LkmXn1rEmge4FIsFvMMWBdazznZMnKhY1pF3q8zjl+MQzhQgMvvvgjkxHvJwdWZl2OIm7RcQ6vXKx/zh6BAzm80HzXO0UeXr8Uocqo80KKMTUY2UaxZNigAo6cUwXrDYryY9JalARiNJjQ4UPpFswPanuixhtY/zbHbASeS9fke1KU3sqaKGvvJW7EGLw9akIx2vxYeL2dvTJsjoZTuE9DBEXHLjAu2uBsFcrVNyd6VAIddCIp/+O3jqwjHaJ2YV5tdfYRsXjwwQoSTRpfCI1vigICctclJDvjfdzHz85knFFiekj7ujJLxQCzxHD2ASal9ifOao60+s/ZzsWgZEZLouvme5Mn++VFwIxIxSnHV/Yi0OjnhxZ5E7y/UVM4f4z3YG7MUjHGCi/xUnr/o94Ckw2Ya+7G6Ua5HBnfZxHpU3IH/y4WERBUn6lmuGI4jTXzNtbvls/6IaQHuvM70gxTdLNOpCfrEIis9ljuFpj7MFKZIEGQY4Fz3bWyN/Ptb/GhgAItnTHFX7w9baHqpA6+iF0dRQfzqypj+7VWOsrXpk/oCF7UjT0aIuay1eiC0elf3pwf5N3XGszZ4X3mjZvXC+6ze3Z0BkZR2bDaApKTPY7kTMfdNlXpB53/qncKN/UNHhzVrvPGmR6HNMqwKD2Ul5s9rFzqswAhNOUMMwQOYwOGy2iSEnPfLinLLo8EfAgEC1GEqKrbrbJ4crlszd+TWL+3g7ogbCv2fa7jPblUiph6EAfQsfnRMfdaLFV9rpT4FvN/goThJ3jtWqRk2W5g1Y2hjnojXW/IMJmfjKYedyjQBMpx5NakrH/6ZiGWzaZ9Ng54LGFSTDk3D4C7+AZj+ADm4SV9phy8jImwjXYD49009jgSkVgLelyYp/s2HuO8fBonpzwbR5cGKH0ipQbFz5B9NaWtUcFqq9KL4f7TUQzj0IdoQuRRSCCB3oIstCpYPhppefbB0NfNYl0UuL711YqPEjvcmixL58LKCj5qqVYDTgCIx+5fRHBQf/lFoOCIOrx0DGz2vR9n4E6/5LubFgGEgWvrkixm7or8cnnx2+gjs+ZGu7GpSZNn94Imo0BeZ9qPKa1yOXxLexIqWWgaRvboiTo4wNgKEtgk/h5G5TG/IT
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR02MB10160.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(376005)(38070700009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: WYB3XUS6Vp/Ksun0tm7UhVKBxxV8o92QMEO4n+4fdTtivw1C5Bn1KunVOXdoVrG/qf4JujObqgA64IO0tL3kf4bzZMRr/I+/u8TBrOfDMypRIb4ia6V7iuKzoaSEjCZ2voA4SvKONTBZNCY4MM8xjk6/HEwohGrplgZvDSYYN7DxNi03YPBLYwZJWp+5pxC/hW74YlmJu2dQPUNZBlByTg823OzGUBX/Ba5WHM3ob06p1ihzyh+K/2zA0DWHp2OLq+ymlugmxUWw8qEEao/SgBYL7vXTr04MutQls4+wz5O9PlA6fGjl/slFT3EFyhmavpa/48M78wb4jlMBDIkkgWx2ukASc1Q2k9tyHRxn7APkH85YWh1koV12mLsdkgDCyMQ4UA48dLjMQqZOpgxZfnsLBp8b1wOrI75rF9Jc8n2X79kj0xqVw6uhm/g/Zy39smIOlNLkJeR6wO+XJikCGnVpZrudd7ZUafTusoWitYTvBmaXqOtrj89d/Xv5ILSKtz6H2i6jElZVp+uZmvbwMp8J7wDTopK/75duqLkd7B1V/Mo/tJjEctssAbqSRH3MmQRGkJG/70Mif0Ub+9FIQzEDxkGHm5Vbo31+C8E3gKRWgDhT/vQSjc9jjj68GH/79DbDN4vaciqjzr2a2WXSSBtun6N/Stegc4eyOS81Lr2YpvmSqChn2Yq2mh02iAvJao2g+vRyemiCkaR8GBGzX1zlK9kYY19B0gEgrCAB2RbCqxO0TY44DnErNWCaHOghcc6vKootpqaTuKp3xHLv2KPRS4hiT8hTqlall2ald9/Mn9tAW6XkAcPfRBR0HaK1uvbLy02LavDWzK4lXpVNNn+vYhWa3aLI/7xNC3Vruk4HJi9+SgiQ0o8ls3f7auYd3FWnuCBSH/S2mnmOu3mfqzULaI43ky2AmfN7yT8+kQtiYtq6nOk29LYq8czFnGwJbtV3aop/kmgL3EWcQH9m5+rbgOyh43MNE5wkKCznmCWIoo4pDDmNAsTVYLzGUTzxN/HaOZ9czLlHcgGrJGausXtf3/KfLYDCvomOGdm+u6RQNdGqnCRy7Yv+tMvCN6KjmYt+3tUHukkp2kHnoQzcuSJI1+COcbXVV2LYYJhtRjm7H6KMhP8es5q+QXH9qFn3cyrHxraJCXnpYcRwf1WhHBHdAHtLJypKrczhPqphG9L4zRgS5CFk8Aoo23aauQQsfYkc4sERFbsE5DK6lGWZfxKMg2dXCoSTlwS3crHvDkmmhmwVc25GPwtcx/OjK/YvYD2JFDR4/fzEOhGceTcpKM+F4sfS1C0FbVTVkdUivv/wFJUg7BQ9Iy4luxjskPu2HQARO6KBYgyyfMMrRyYaZouB4jnooguH8bhhKq8A15DkG16YJd3In59haogG9W5x/mRCuu6wd9E0GaoUUslS/2FhXnIjK1LM50wmHO9SzpvI+aVw2bDZC/t4YXi7PAU+7lOmF5tPIuZFBQfxbfFyEXFsgOHefBY67XtrIquh+dSiup9PoVrV0c7kCJVisD2XWmVKXzGk0/LU3gN8SrYGvU5oA8B6d/3ZKCdJsFGzUGidLqadrZQR41H8jJwyvpOSjQvS31iTo1ZX/Plzaui8CA==
Content-Type: multipart/alternative; boundary="_000_DU2PR02MB1016069DAE5EBDBD02DAD3C0688FA2DU2PR02MB10160eu_"
MIME-Version: 1.0
X-OriginatorOrg: orange.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10160.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b286b80-af60-47a7-0535-08dc860debe3
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2024 09:49:12.9724 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: v6mIoaTc2z2hIcBQozagNYGf0kvQJk4o4HQ7cwSQ8EZvVngAlC8xh9MlJ0d+PqXJnveXtQtxaaxt0Z2/LPBlz2JzF9XWo5zddKeKffovueI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR02MB5826
X-TM-AS-ERS: 10.218.35.126-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ==
X-TMASE-Version: DDEI-5.1-9.1.1004-28434.006
X-TMASE-Result: 10--39.693500-10.000000
X-TMASE-MatchedRID: 1uttSxkBlaXuYusHgJkgytzL7yAK8QE8TQ9U6s/MYLOU62zvc1Dlo8Ln qBU8vRHqWuH0weZ3C8SCy6QpqEIA/StPpXoicS5XmPUGZJexJ/TUvu3emVFqKbd2BlHAIizFOOT wTQfLsm1Ng/bb0SR6/uyAhvqcOmZGLGQFtelDl4ulY4F8r0vXP8wZ89GbiUlnwisnIbO8h0OI88 GxbVkKXz2FT75yDfBleiHIOANtUnLN1j27XOUH5k0s9CXRACW092rTO5zZsj44oMVCbn1gag7ly eiNjnjeCLsa6HeVb+fImkQtxlGoyuJMNIftzCCTaXmdXF2Ym8czXf7KKCv6ES1+4nCRr2jQp3Z/ y3zTL9+ZI8OviNkMUUC8jypqzPK24t2mucDkRBH4qCLIu0mtIEukIs3g1HjePhs5AaW7bFEZvOx VdVQz5DpjKkcQso9FZap8N+M9om985pjA/x1xfvNkoMDX+kiuQ6Cj3EXWBE2JYV793zfRm3sOIm 6CNpYEDrjViyer3il4CGd3XYenF6ZVv5lkk9Y92FA7wK9mP9f/z5X0KzxdulxUx6Nc3kkv9YpAL QXNCHbY37WE4vg/45mRr1k6e+lg7+etKcKRtq7jLrHqvAiSy2XewsbqSeZ1krgewt7GC7h3+zLy ScOv3I1u/JNKOSTaUMJNi8DXwsnuW/BrYJGl/TzVyTxTzRaWAwUPlwYeGCU7ETvuQ225Cat6q7f 2KLhOC/g/vgkoKiVH6+lhuE4fWi/PpqUXWtWDdU2gXPGZpucXR19nmRX2X0bVC+F4n057vygxRi BC65e/5RDtQSaOpzwPzSdgh1vGfUkgDiuGxn8NsuQOB7UFW0GGpJy/q0pao8WMkQWv6iUojzu/j hRWTQKLL4Z+HVHJdR/G8OvKIg/SBVVc2BozSlkMvWAuahr8RTPcgmZKtSDHcBriiJvLGV+j8bvT Mal+IG4YlbCDECtruV6hT84yE/IxdJB3PGL0
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
X-TMASE-INERTIA: 0-0;;;;
X-TMASE-XGENCLOUD: 34bfffba-fe7a-4796-88f2-51b0124775b6-0-0-200-0
Message-ID-Hash: 5TDPEDWL4NG4YODCWYP5MLNQG7GTFQH5
X-Message-ID-Hash: 5TDPEDWL4NG4YODCWYP5MLNQG7GTFQH5
X-MailFrom: mohamed.boucadair@orange.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-msd-yang.all@ietf.org" <draft-ietf-mpls-msd-yang.all@ietf.org>, Last Call <last-call@ietf.org>, mpls <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: [Last-Call] Re: [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/liUGpkNpb-Im9lyQ5in138UgboM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>
Re-, Please see inline. Cheers, Med De : Dhruv Dhody <dd@dhruvdhody.com> Envoyé : jeudi 6 juin 2024 11:22 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com> Cc : Yingzhen Qu <yingzhen.ietf@gmail.com>; Acee Lindem <acee.ietf@gmail.com>; rtg-dir@ietf.org; draft-ietf-mpls-msd-yang.all@ietf.org; Last Call <last-call@ietf.org>; mpls <mpls@ietf.org> Objet : [Last-Call] Re: [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07 Hi Med, On Thu, Jun 6, 2024 at 8:24 AM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote: Hi Dhruv, Yes, that would work assuming that we will have a new column to record explicitly the data plane name for each type. Dhruv: What you are asking is not wrong "technically" but at the same time I can't envision someone defining a MSD without being explicit on the data plane it applies to. [Med] These two are not conflicting :-) If the information is explicit, then record it in the registry, not infer it from the narrative text or the MSD name. Can this be a guideline for designated experts to verify without adding a new column? [Med] The concern is beyond the DE review. Once a change is made to the registry: how to mirror that automatically in the IANA-maintained module using the current instructions in the spec? Which information in the registry will be used to trigger whether the base identity is to be used, existing child ones, or creating new child ones, etc. We need to make the maintenance task implementable, but easy. Some checks are worth though: Do we foresee cases where the same type can be used by multiple “data planes”? Dhruv: Unlikely IMHO. [Med] ACK. Thanks. Thanks, Dhruv Cheers, Med De : Dhruv Dhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>> Envoyé : jeudi 6 juin 2024 08:59 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Cc : Yingzhen Qu <yingzhen.ietf@gmail.com<mailto:yingzhen.ietf@gmail.com>>; Acee Lindem <acee.ietf@gmail.com<mailto:acee.ietf@gmail.com>>; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-mpls-msd-yang.all@ietf.org<mailto:draft-ietf-mpls-msd-yang.all@ietf.org>; Last Call <last-call@ietf.org<mailto:last-call@ietf.org>>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>> Objet : [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07 Hi Med, How about this I-D adds some suitable guidance for designated experts (as the IANA registry is under 'Expert Review')? We can also make this I-D update RFC8491. Could that be a way forward? Thanks! Dhruv On Thu, Jun 6, 2024 at 6:05 AM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote: Hi Yingzhen, Thank you for addressing the sec comment. I trust that you have also fixed the content mismatch between the module and the parent registry points. Thank you also for confirming that there are no such IANA considerations. The narrative text in 9352 does not change the rules set in 8491. I consider that the last comment is still valid and not addressed. Thank you. Cheers, Med De : Yingzhen Qu <yingzhen.ietf@gmail.com<mailto:yingzhen.ietf@gmail.com>> Envoyé : jeudi 6 juin 2024 01:05 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Cc : Acee Lindem <acee.ietf@gmail.com<mailto:acee.ietf@gmail.com>>; Dhruv Dhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-mpls-msd-yang.all@ietf.org<mailto:draft-ietf-mpls-msd-yang.all@ietf.org>; Last Call <last-call@ietf.org<mailto:last-call@ietf.org>>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>> Objet : Re: [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07 Hi Med, You're right, it is not explicitly stated in the IANA consideration section. However you can find "This document only defines one type of MSD: Base MPLS Imposition. " in the abstract of RFC 8491. And the following text is at the beginning of section 4 in RFC 9352 that defines the SRH MSDs: " [RFC8491<https://www.rfc-editor.org/rfc/rfc9352.html#RFC8491>] defines the means to advertise node-/link-specific values for MSDs of various types. Node MSDs are advertised in a sub-TLV of the Router Capability TLV [RFC7981<https://www.rfc-editor.org/rfc/rfc9352.html#RFC7981>] Link MSDs are advertised in a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223.¶<https://www.rfc-editor.org/rfc/rfc9352.html#section-4-1> This document defines the relevant SRv6 MSDs and requests MSD type assignments in the "IGP MSD-Types" registry created by [RFC8491<https://www.rfc-editor.org/rfc/rfc9352.html#RFC8491>] " I've updated the security consideration in version -09. Please let us know whether this addressed your comments. Thanks, Yingzhen On Wed, Jun 5, 2024 at 9:27 AM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote: Re-, I actually checked that before making the comment. There is no such requirement for new requests in https://www.rfc-editor.org/rfc/rfc8491.html#section-6. May be I’m not looking in the right place?! I would appreciate if you can point me to where I can find this requirement: “the document that defines the new entry should state what the MSD is for” Cheers, Med De : Yingzhen Qu <yingzhen.ietf@gmail.com<mailto:yingzhen.ietf@gmail.com>> Envoyé : mercredi 5 juin 2024 18:02 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Cc : Acee Lindem <acee.ietf@gmail.com<mailto:acee.ietf@gmail.com>>; Dhruv Dhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-mpls-msd-yang.all@ietf.org<mailto:draft-ietf-mpls-msd-yang.all@ietf.org>; Last Call <last-call@ietf.org<mailto:last-call@ietf.org>>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>> Objet : [RTG-DIR]Re: Rtgdir last call review of draft-ietf-mpls-msd-yang-07 Hi Med, When a new entry is added to the "IGP MSD-Type" registry, the document that defines the new entry should state what the MSD is for. I'll update the security consideration. Thanks, Yingzhen On Wed, Jun 5, 2024 at 7:06 AM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote: Hi Acee, Please see inline. Cheers, Med Orange Restricted De : Acee Lindem <acee.ietf@gmail.com<mailto:acee.ietf@gmail.com>> Envoyé : mercredi 5 juin 2024 15:35 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Cc : Yingzhen Qu <yingzhen.ietf@gmail.com<mailto:yingzhen.ietf@gmail.com>>; Dhruv Dhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-mpls-msd-yang.all@ietf.org<mailto:draft-ietf-mpls-msd-yang.all@ietf.org>; Last Call <last-call@ietf.org<mailto:last-call@ietf.org>>; mpls <mpls@ietf.org<mailto:mpls@ietf.org>> Objet : Re: [RTG-DIR]Rtgdir last call review of draft-ietf-mpls-msd-yang-07 Hi Med, See inline. On Jun 5, 2024, at 04:16, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote: Hi Yingzhen, Thanks for taking care of this. The new version looks better. Still, I don’t see how the hierarchical identity structure can be automatically inferred from the current flat registry structure. I’m afraid that the instructions in the 3rd para of 6.2 are not sufficient as I don’t think that we can trust the presence of SRH or some magic words in the description to decide which identity to use, and more generally if “a new data plane” is used. Both the description and references listed in the IANA module diverge from the actual content of the registry. I would avoid that. Please refer to this clarification in the 8407bis (see the last sentence, in particular): The content of these registries are usually available using various formats (e.g., plain text, XML). However, there were some confusion in the past about whether the content of some registries is dependent on a specific representation format. For example, Section 5 of [RFC8892] was published to clarify that MIB and YANG modules are merely additional formats in which the "Interface Types (ifType)" and "Tunnel Types (tunnelType)" registries are available. The MIB [RFC2863] and YANG modules [RFC7224][RFC8675] are not separate registries, and the same values are always present in all formats of the same registry. I disagree. The fact that we have a hierarchy of identities wouldn’t confuse anyone. They are all part of the iana-msd-types.yang model and all have “msd-base” as the root identity. We are rejecting this rather subjective comment. [Med] Hmm…this is not subjective :-) Let’s consider that I registered a new entry in Interior Gateway Protocol (IGP) Parameters (iana.org)<https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml> 115 My own type [MyREF<https://www.iana.org/go/rfc8491>] How IANA will follow the following guidance? How IANA will know this is about an existing “data plane” or a new one? How it will decide to mirror it using existing one msd-base or msd-base-srh? How to infer a data plane from a registration? Etc. The identities defined in the iana-msd-types YANG module are organized hierarchically based on the data plane. In this initial version, only MPLS and SRv6 data planes are supported, hence "msd- base-mpls" and "msd-base-srh" are defined. When a new data plane is added to the "IGP MSD-Types" registry, a new "identity" statement should be added to the "iana-msd-types" YANG module. The name of the "identity" is the prefix "msd-base-" plus a lower-case version of the data plane name . The identity statement should have the following sub-statements defined: If you want to suggest further text to explain this, we’ll consider inclusion. Some other misc. comments: (1) “lower-case version of the data plane name”: you may also indicate that the space is replaced with “-“, not trimmed. (2) "description": Replicates the description from the registry. I guess you meant replicate the “name” from the registry. There is no description in the IGP MSD Type reg. (3) OLD: name: iana-msd-types namespace: urn:ietf:params:xml:ns:yang:iana-msd-types prefix: iana-msd-types reference: RFC XXXX name: ietf-mpls-msd namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-msd prefix: mpls-msd reference: RFC XXXX NEW: name: iana-msd-types namespace: urn:ietf:params:xml:ns:yang:iana-msd-types prefix: iana-msd-types maintained by IANA? Y reference: RFC XXXX name: ietf-mpls-msd namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-msd prefix: mpls-msd maintained by IANA? N reference: RFC XXXX (4) the security section does not follow the template + does not cover the IANA module. Please refer tohttps://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-security-considerations-sect. The iana-msd-types.yang modules doesn’t include any data leafs so there are no associated security considerations. We could state this. We’ll check the latest template in the draft. [Med] There is a para in the template for that as well. Thanks, Acee Cheers, Med De : Yingzhen Qu <yingzhen.ietf@gmail.com<mailto:yingzhen.ietf@gmail.com>> Envoyé : mercredi 5 juin 2024 07:55 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Cc : Dhruv Dhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>; rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; draft-ietf-mpls-msd-yang.all@ietf.org<mailto:draft-ietf-mpls-msd-yang.all@ietf.org>; last-call@ietf.org<mailto:last-call@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org> Objet : Re: [RTG-DIR]Rtgdir last call review of draft-ietf-mpls-msd-yang-07 Hi Mohamed, Thanks for the review and pointer. I've uploaded version -08 to address your comments, please review and let me know your comments, especially about the hierarchical identities. Thanks, Yingzhen On Tue, Jun 4, 2024 at 12:18 AM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote: Hi all, In addition to the comments raised by Dhruv, the authors may look at the guidance athttps://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-iana-maintained-modules for the required details for IANA-maintained modules. ## Lack of the details to maintain the module There is currently no guidance in draft-ietf-mpls-msd-yang about how the module will be maintained. For example, given that there is no label but only a description field in the authoritative IANA registry, the doc should explain how names will be echoed in the module. ## Mirror the content of the authoritative registry The content of the IANA module does not mirror the details in the registry. For example, there are many refs that are listed in draft-ietf-mpls-msd-yang, but those are not present in the parent registry. ## Hierarchy The IANA module defines this hierarchy, while there is no such hierarchy in the IANA registry. I understand that the authors want to structure the types, but is this really required here? Absent guidance about how new entries will be echoed from the registry, I don't think this structure is easily maintainable. Please keep in mind that registrants of new types are not even aware that an IANA-maintained module exists. So, they cannot be involved in the process of maintaining the module. == identity msd-base-srh { base msd-base; description "Identity for MSD types for Segment Routing Header (SRH)."; } identity msd-srh-max-sl { base msd-base-srh; description "The Maximum Segment Left MSD type."; reference "RFC 9352: IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane"; } identity msd-srh-max-end-pop { base msd-base-srh; description "The Maximum End Pop MSD Type."; reference "RFC 9352: IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane"; } == Hope this helps. Cheers, Med > -----Message d'origine----- > De : Dhruv Dhody via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> > Envoyé : lundi 3 juin 2024 20:06 > À : rtg-dir@ietf.org<mailto:rtg-dir@ietf.org> > Cc : draft-ietf-mpls-msd-yang.all@ietf.org<mailto:draft-ietf-mpls-msd-yang.all@ietf.org>; last-call@ietf.org<mailto:last-call@ietf.org>; > mpls@ietf.org<mailto:mpls@ietf.org> > Objet : [RTG-DIR]Rtgdir last call review of draft-ietf-mpls-msd- > yang-07 > > > Reviewer: Dhruv Dhody > Review result: Has Issues > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through the IETF last call > and IESG review, and sometimes on special request. The purpose of > the review is to assist the Routing ADs. For more information > about the Routing Directorate, please see > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252> > Fwiki.ietf.org<http://fwiki.ietf.org/>%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C02%7Cmohamed > .boucadair%40orange.com<http://40orange.com/>%7C6ecf264db0bb43052c3b08dc83f8121b%7C90c7 > a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638530348673738183%7CUnkno > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h > aWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vfo%2F%2BxP9zc3YIrI1b9RjmRl > XL3MicMrirSECkDHfM3c%3D&reserved=0 > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with > any other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-mpls-msd-yang-07 > Reviewer: Dhruv Dhody > Review Date: 2024-06-03 > IETF LC End Date: 2024-06-04 > Intended Status: Proposed Standard > > ## Summary: > > * I have some minor concerns about this document that I think > should be resolved before publication. > > ## Comment: > > * This draft defines 2 YANG models one is IANA-maintained to > mirror the msd-type registry and the other is augmenting base > MPLS to include MSD values. > > ### Major Issues: > > - Please remove the BCP14 boilerplate (Section 1.1) as you are > not using any of those keywords. Also, remove from the ietf-mpls- > msd YANG model. > > - You should explicitly state that this is an initial version of > "iana-msd-types" YANG model - "This document defines the initial > version of the IANA-maintained 'iana-msd-types' YANG module." > > ### Minor Issues: > > - Title: Please change to "A YANG Data Model for MPLS Maximum > Segment Identifier (SID) Depth (MSD)". Also, update the reference > in the YANG model around RFC XXXX. > > - The abstract suggests that only one YANG model is defined in > this I-D. > Consider rephrasing or adding some hints about the IANA model as > well. > > - Section 1, "YANG [RFC7950] is a data definition language.."; I > suggest changing it to data modeling as that is the term used in > the referenced RFC. > > - Section 1, I am unsure about the text "The augmentation defined > in this document requires support..."; isn't it obvious that one > needs to support the model one is augmenting... > > - Section 4, please add this text in the description inside the > YANG module - "This YANG module is maintained by IANA and > reflects the 'IGP MSD-Types' > registry." > > - identity msd-erld, should also have a reference to RFC9088. > > - In "ietf-mpls-msd", please remove the reference "RFC XXXX: A > YANG Data Model for MPLS MSD." immediately after the module > description. The revision statement is the correct place to have > this reference. > > - leaf msd-value should also include text for "0 represents the > lack of ability to support a SID stack of any depth". > > - I can not parse "A type of Node MSD is the smallest same type > link MSD supported by the node.";" > > - RFC8340 should be normatively referenced. > > ### Nits: > > - s/(MSD) Types as the IANA the IGP MSD-Types registry/(MSD) > Types as per the IANA IGP MSD-Types registry/ > > - s/which itself augments [RFC8349]/which itself augments routing > RIB data model [RFC8349]/ > > - s/IANA maintained module/IANA-maintained module/ > > - s/This module will be maintained by IANA if more MSD types are > added to the registry./This module will be maintained by IANA and > updated if and when there is any change in the registry./ > > - s/and it is to provide support of different types of MSDs in > MPLS data plane./and it provides support for different types of > MSDs in the MPLS data plane./ > > - s/read-only data decided by/read-only data as per/ > > - Section 4, expand SID on first use in the YANG model. > > Thanks, > Dhruv > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- [mpls] Rtgdir last call review of draft-ietf-mpls… Dhruv Dhody via Datatracker
- [mpls] Re: [RTG-DIR]Rtgdir last call review of dr… mohamed.boucadair
- [mpls] Re: [RTG-DIR]Rtgdir last call review of dr… Yingzhen Qu
- [mpls] Re: [RTG-DIR]Rtgdir last call review of dr… mohamed.boucadair
- [mpls] Re: [RTG-DIR]Rtgdir last call review of dr… Acee Lindem
- [mpls] Re: [RTG-DIR]Rtgdir last call review of dr… mohamed.boucadair
- [mpls] Re: [RTG-DIR]Rtgdir last call review of dr… Yingzhen Qu
- [mpls] Re: [RTG-DIR]Re: Rtgdir last call review o… mohamed.boucadair
- [mpls] Re: [RTG-DIR]Re: Rtgdir last call review o… Yingzhen Qu
- [mpls] Re: [RTG-DIR]Re: Rtgdir last call review o… mohamed.boucadair
- [mpls] Re: [RTG-DIR]Re: Rtgdir last call review o… Dhruv Dhody
- [mpls] Re: [RTG-DIR]Re: Rtgdir last call review o… mohamed.boucadair
- [mpls] Re: [RTG-DIR]Re: Rtgdir last call review o… Dhruv Dhody
- [mpls] Re: [Last-Call] Re: [RTG-DIR]Re: Rtgdir la… mohamed.boucadair
- [mpls] Re: [Last-Call] [RTG-DIR]Re: Rtgdir last c… Acee Lindem
- [mpls] Re: [Last-Call] [RTG-DIR]Re: Rtgdir last c… mohamed.boucadair
- [mpls] Re: [Ext] [Last-Call] Re: [RTG-DIR]Re: Rtg… Amanda Baber
- [mpls] Re: [Last-Call] [RTG-DIR]Re: Rtgdir last c… Yingzhen Qu
- [mpls] Re: [Last-Call] [RTG-DIR]Re: Rtgdir last c… mohamed.boucadair
- [mpls] Re: [RTG-DIR]Re: Rtgdir last call review o… Mahesh Jethanandani
- [mpls] Re: Rtgdir last call review of draft-ietf-… Yingzhen Qu
- [mpls] Re: [Last-Call] Re: Rtgdir last call revie… Dhruv Dhody