From nobody Fri Sep 3 15:02:42 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6239A3A308E for ; Fri, 3 Sep 2021 15:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XIDYqTmgMkl for ; Fri, 3 Sep 2021 15:02:33 -0700 (PDT) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 AA0393A3083 for ; Fri, 3 Sep 2021 15:02:33 -0700 (PDT) Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa3.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 183M2W19003656 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 3 Sep 2021 22:02:32 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.15; Fri, 3 Sep 2021 15:02:31 -0700 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0858.015; Fri, 3 Sep 2021 15:02:31 -0700 From: Michelle Cotton To: "yang-doctors@ietf.org" CC: Amanda Baber , Sabrina Tanamal Thread-Topic: Question about implementation of yang modules for recently published RFC Thread-Index: AQHXoQ9knsg+YWYWuEeGG7spH3vjwA== Date: Fri, 3 Sep 2021 22:02:31 +0000 Message-ID: <731DAF81-C9DE-415C-9DBB-E56FAB6EC4F0@iana.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3713526149_1665834288" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-03_07:2021-09-03, 2021-09-03 signatures=0 Archived-At: Subject: [yang-doctors] Question about implementation of yang modules for recently published RFC X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2021 22:02:39 -0000 --B_3713526149_1665834288 Content-type: multipart/alternative; boundary="B_3713526149_1882807048" --B_3713526149_1882807048 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hello Yang Doctors! =20 Quick question about implementation of RFC 9132. =20 For the IANA maintained Yang, iana-dots-signal-channel, the RFC-Editor sent= us a replacement yang file. =20 In this case, do we just delete the older yang file and completely replace = it with the new one? =20 At https://www.iana.org/assignments/yang-parameters we point the iana-dots-= signal-channel entry to the newer yang file. =20 Then we=E2=80=99ll update https://www.iana.org/assignments/iana-dots-signal-chann= el/iana-dots-signal-channel.xhtml so that it points to the newer yang file a= nd update the RFC. =20 Do we have that correct? =20 For the ietf-dots-signal-channel yang, an additional entry was added since = it is not IANA maintained (per previous instructions from Benoit). =20 Thanks for any confirmation you can provide! =20 --Michelle =20 Michelle Cotton Protocol Parameters Engagement Sr. Manger IANA Services =20 --B_3713526149_1882807048 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hello Yang = Doctors!

 

Quick question about implementation of RFC 9132.

=

 

For the IANA maintained = Yang, iana-dots-signal-channel, the RFC-Editor sent us a replacement yang fi= le.

<= o:p> 

In this case, do we just delete the older yang file and completely replace = it with the new one?

 

At https://www.iana.org/assignments/yang-parameters we point the iana-d= ots-signal-channel entry to the newer yang file.

 

Then we=E2=80=99ll update https://www.iana.org/assignments/iana-dots-signal-channel/iana-= dots-signal-channel.xhtml so that it points to the newer yang file and u= pdate the RFC.

 

Do we have that correct?

 

For the ietf-dots-signal-channel yang, an = additional entry was added since it is not IANA maintained (per previous ins= tructions from Benoit).

 

Thanks for any confirmation you can provide!=

 

--Michelle

&n= bsp;

Miche= lle Cotton

Protocol Parameters Engagement Sr. Manger

IANA Services

 =

--B_3713526149_1882807048-- --B_3713526149_1665834288 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIISCwYJKoZIhvcNAQcCoIIR/DCCEfgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg/AMIIFrzCCBJegAwIBAgIQAb9GfdVafWaqP8pChY6LTDANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMjAw ODA3MDAwMDAwWhcNMjIxMDI4MTIwMDAwWjCBzDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxKzApBgNVBAMTIk1pY2hl bGxlIENvdHRvbiAoU01JTUUgMTAvMjgvMjAyMikxJzAlBgkqhkiG9w0BCQEWGG1pY2hlbGxl LmNvdHRvbkBpYW5hLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAORSAuKP yQOZeDT1+C+JyDNFSLkJCkwbQcTKMHyvkFPEXy67Sv9cVLha3EaeURR20z4oolde1w/e2vZI bjXFP1fqmQMcoOOnY5gVwGxNazp+uA0ejyiiibFsp2pNGwmlsH6GS7AhGV6g49fEfxPAJxtJ o07IismVoopRT4nARs4IS/6VNRYi22edeTFEREsLZ3HFYiKSbr7VfB0Vn/JLVK1KGEAVUrIk v5U4WizFYNV63fywq9dBW1DjiS5YbaBvZJ+4jvNr2KLoOHHsliImucd169YblxWw8S6cEJmz uRHI3Mf3NYBePmLb/UEkfJ5p5/BD5yub+i7H4PVu8fmOpOsCAwEAAaOCAfEwggHtMB8GA1Ud IwQYMBaAFOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBT3VScp2vawiKA5doG9Rn/w tiEaCzAMBgNVHRMBAf8EAjAAMCMGA1UdEQQcMBqBGG1pY2hlbGxlLmNvdHRvbkBpYW5hLm9y ZzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1Ud IAQ8MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGln aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRt MGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNy dDANBgkqhkiG9w0BAQsFAAOCAQEAgLHPW+HEDV2yzgwqbG2RRSVn6gc9Ud82f57MyWDjT3AQ lro1JH641Kz4QWr53rvYQMak1wObyotqJpFTvXD/sGxNypyrVjFcQlYD4lbLO9wymtmmy2VU 2oFbIxiVgLjKOQjMRvyrWqswiQTCQlbHRD+LLHRN2UDRL09rtaiyxokwBlHpicoHerl6CTiq 5oOcq++0hw+5l9QqTLw6Ld+2FN76hu5iXOGpsIR1OnjHgDaNT+xPP4X00c+9gGV8bpr+YLZS P2JFivSZIJicVvB2FE32fAtNYP0Lp7CUX+Asqqq4d75sx9k9ITHtvfdfFWkHeRKYi3d03dAO 5Y99vHOY6zCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNl cnQgU0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 3PgRIz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoF H9pjeFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2 QRdTQDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXq NtdfauIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPh RL16CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQw EgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaG NGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmww OqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD QS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYw ggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQu Y29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQA aABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMA IABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQA IABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIA dAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUA ZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU 5wIjgABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8w DQYJKoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jK wXFRXJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4d OZC+W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5d yBn0UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtn eCweknjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhl s+DibsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUx CzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjEx MTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0 IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0O Fc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+Q rIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlr f9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhV hyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnI sdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0P AQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3z bcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IB AQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVY lzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq 6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBn t2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYICDzCCAgsCAQEw eTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cu ZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAG/ Rn3VWn1mqj/KQoWOi0wwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgYsHaM09y xDoRuEQRxt2c5ypAAuXLUSVh47C/vlTOFFswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMjEwOTAzMjIwMjI5WjANBgkqhkiG9w0BAQEFAASCAQBGY0ZSr3pP Hkrg+RF8LGWc82f6TiFjnR95dgbaXbq2kHiODyymmkoApLc4ePJs/nsgE3c6FO7bB1jrVgHS NakX5Wgtruu2Cb9BT7T1D9C762oNJIaKHSOXqh16h7jmeq9G1PSrNyJ2yiKqZl1FTxUN1Qvx lQBKWpm6GaTveuXxI7rDy1w/OwX/Y4qEXxXkbzruQGTx3jrnINx63DESjDuEaGexqkTgbiVI HUvaPUbhRlC+BbX4M8pmD4FoIYinqwbmZW/o+yG6bKG1DfCHCvLJY7PZlsr+jHvatkeDK0MZ NlOl6ejC0Mr8l0JlPERvKkSL7j0bQ0PdxqodiHVGxJ+p --B_3713526149_1665834288-- From nobody Mon Sep 6 06:52:20 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9883A0BFA for ; Mon, 6 Sep 2021 06:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=guOlgy+c; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Gm7x/U0/ 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 WaQWYxIXK-W5 for ; Mon, 6 Sep 2021 06:52:13 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7FD3A0BF3 for ; Mon, 6 Sep 2021 06:52:11 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 439C132008FC; Mon, 6 Sep 2021 09:52:09 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 06 Sep 2021 09:52:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= HvF0C3VXeAjkqhkJwEwK+RYKtzVfBhmuNPiF2clCuC4=; b=guOlgy+ctSg2eDw3 egntfxiWTHX/6P4g9O9MP3J9qiuMAeKWAeaExx4P/vaevtTK5brGwkrzUSp+iiza lKl6vS33UwJ+fXkL6wgNRCqEMn2/HFQW9zX/K/QmvZTmp/9s8e8Km8/OlNAanl4d m5BTsrT2FHJPm3eCkQwlziEEH70jwJFbPSIdPG7+k1m2d33/or5NlbF5IPZl9NWL p8T33+9twZcxVJFpRbX7BEpd5MTJoiYKKkONYXfpL23z5ASIQMKION1fuYzbL0G8 nOUpNZvF+GQRmGykcA2gPFJcWA2l0qMAd48Mfcx5HKP5TC3uk+pajwPwcE1ysBsg V4Eq6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=HvF0C3VXeAjkqhkJwEwK+RYKtzVfBhmuNPiF2clCu C4=; b=Gm7x/U0/dLW8D8z2jtV17Kr47TGkyNKRHDThrBzF45t5s+LUBsjNCF6Rn pPjop70q0yj3GyuMYTwO9mv/uHSlWuQ9/x86PVClaTTQlAI6O9RClJlyJcbCOPWM q1NX06wZsx4NlOWo0xP/ZvhxdiDB4rbMSxc7uT67Zai6lWZa6wc7PdbGfEJnhGPG vxf4WsHDKTJj8zWlrQXPTtGekNpDVNFkTHRoBXVVtLyzAZhAE8uYcpfSp8JMz6S7 qITB9AqXVm0DERJdNfoO5qs14xpPqkH7AqDBt01xuT/lcg8FgOhZW50DlM/XyYpm cOILURV/gIXLKbNx2yzXIpdAoSZdA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudeffedgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepleehkeetfeekgfekgfeiud ehteelfeevteeuffelhfevgffggefghfdtkeehffehnecuffhomhgrihhnpehirghnrgdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 6 Sep 2021 09:52:07 -0400 (EDT) Date: Mon, 06 Sep 2021 15:52:05 +0200 (CEST) Message-Id: <20210906.155205.514219278646645474.id@4668.se> To: michelle.cotton@iana.org Cc: yang-doctors@ietf.org, sabrina.tanamal@iana.org, amanda.baber@iana.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <731DAF81-C9DE-415C-9DBB-E56FAB6EC4F0@iana.org> References: <731DAF81-C9DE-415C-9DBB-E56FAB6EC4F0@iana.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [yang-doctors] Question about implementation of yang modules for recently published RFC X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 13:52:19 -0000 SGksDQoNCg0KTWljaGVsbGUgQ290dG9uIDxtaWNoZWxsZS5jb3R0b25AaWFuYS5vcmc+IHdyb3Rl Og0KPiBIZWxsbyBZYW5nIERvY3RvcnMhDQo+IA0KPiAgDQo+IA0KPiBRdWljayBxdWVzdGlvbiBh Ym91dCBpbXBsZW1lbnRhdGlvbiBvZiBSRkMgOTEzMi4NCj4gDQo+ICANCj4gDQo+IEZvciB0aGUg SUFOQSBtYWludGFpbmVkIFlhbmcsIGlhbmEtZG90cy1zaWduYWwtY2hhbm5lbCwgdGhlIFJGQy1F ZGl0b3INCj4gc2VudCB1cyBhIHJlcGxhY2VtZW50IHlhbmcgZmlsZS4NCj4gDQo+ICANCj4gDQo+ IEluIHRoaXMgY2FzZSwgZG8gd2UganVzdCBkZWxldGUgdGhlIG9sZGVyIHlhbmcgZmlsZSBhbmQg Y29tcGxldGVseQ0KPiByZXBsYWNlIGl0IHdpdGggdGhlIG5ldyBvbmU/DQoNClllcyBJIHRoaW5r IHRoYXQncyB0aGUgcmlnaHQgcHJvY2VkdXJlLiAgRm9yIGlhbmEtaWYtdHlwZS55YW5nLCB0aGF0 J3MNCndoYXQgeW91IGRvIGV2ZXJ5dGltZSBhIG5ldyBpbnRlcmZhY2UgaXMgYWRkZWQsIHNvIEkg dGhpbmsgaXQgaXMgb2sgaW4NCnRoaXMgY2FzZSBhcyB3ZWxsLg0KDQo+ICANCj4gDQo+IEF0IGh0 dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3lhbmctcGFyYW1ldGVycyB3ZSBwb2ludCB0 aGUNCj4gaWFuYS1kb3RzLXNpZ25hbC1jaGFubmVsIGVudHJ5IHRvIHRoZSBuZXdlciB5YW5nIGZp bGUuDQo+IA0KPiAgDQo+IA0KPiBUaGVuIHdl4oCZbGwgdXBkYXRlDQo+IGh0dHBzOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL2lhbmEtZG90cy1zaWduYWwtY2hhbm5lbC9pYW5hLWRvdHMtc2ln bmFsLWNoYW5uZWwueGh0bWwNCj4gc28gdGhhdCBpdCBwb2ludHMgdG8gdGhlIG5ld2VyIHlhbmcg ZmlsZSBhbmQgdXBkYXRlIHRoZSBSRkMuDQo+IA0KPiAgDQo+IA0KPiBEbyB3ZSBoYXZlIHRoYXQg Y29ycmVjdD8NCg0KWWVzLg0KDQoNCj4gDQo+IEZvciB0aGUgaWV0Zi1kb3RzLXNpZ25hbC1jaGFu bmVsIHlhbmcsIGFuIGFkZGl0aW9uYWwgZW50cnkgd2FzIGFkZGVkDQo+IHNpbmNlIGl0IGlzIG5v dCBJQU5BIG1haW50YWluZWQgKHBlciBwcmV2aW91cyBpbnN0cnVjdGlvbnMgZnJvbQ0KPiBCZW5v aXQpLg0KDQpJIGRvbid0IHVuZGVyc3RhZCBpZiB0aGlzIGNvbW1lbnQgaXMgcmVsYXRlZCB0byB0 aGUgcXVlc3Rpb24gYWJvdmUuLi4/DQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+ICANCj4gDQo+IFRo YW5rcyBmb3IgYW55IGNvbmZpcm1hdGlvbiB5b3UgY2FuIHByb3ZpZGUhDQo+IA0KPiAgDQo+IA0K PiAtLU1pY2hlbGxlDQo+IA0KPiAgDQo+IA0KPiBNaWNoZWxsZSBDb3R0b24NCj4gDQo+IFByb3Rv Y29sIFBhcmFtZXRlcnMgRW5nYWdlbWVudCBTci4gTWFuZ2VyDQo+IA0KPiBJQU5BIFNlcnZpY2Vz DQo+IA0KPiAgDQo+IA0K From nobody Thu Sep 9 02:10:30 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE8B3A2340; Thu, 9 Sep 2021 02:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehblMZ7LF0Kt; Thu, 9 Sep 2021 02:10:12 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 291503A233E; Thu, 9 Sep 2021 02:10:07 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 84B6476588A4FE92C4E3; Thu, 9 Sep 2021 17:10:02 +0800 (CST) Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl2.zte.com.cn with SMTP id 18999QwN085616; Thu, 9 Sep 2021 17:09:26 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid203; Thu, 9 Sep 2021 17:09:26 +0800 (CST) Date: Thu, 9 Sep 2021 17:09:26 +0800 (CST) X-Zmail-TransId: 2af96139cf466cb55199 X-Mailer: Zmail v1.0 Message-ID: <202109091709262207934@zte.com.cn> In-Reply-To: <162573898729.4670.7837396780950130231@ietfa.amsl.com> References: 162573898729.4670.7837396780950130231@ietfa.amsl.com Mime-Version: 1.0 From: To: Cc: , , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 18999QwN085616 Archived-At: Subject: Re: [yang-doctors] =?utf-8?q?=5BRift=5D_Yangdoctors_last_call_review?= =?utf-8?q?_of_draft-ietf-rift-yang-03?= X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2021 09:10:18 -0000 --=====_001_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Hi Michal, Thank you again for your review! We are do the updating work. But we are not sure that we got the meaning of the following comment: "algorithm-type - empty cases - redundant on their own, are expected to be augmented?" The algorithm-type leaf in the model is not empty. Could you please explain this comment more detailedly? Thank you very much! Best regards, Sandy ------------------原始邮件------------------ 发件人:MichalVaškoviaDatatracker 收件人:yang-doctors@ietf.org; 抄送人:draft-ietf-rift-yang.all@ietf.org;last-call@ietf.org;rift@ietf.org; 日 期 :2021年07月08日 18:17 主 题 :[Rift] Yangdoctors last call review of draft-ietf-rift-yang-03 Reviewer: Michal Vaško Review result: Almost Ready Generally, use references where make sense (features, nodes) and use units and/or standard types (ietf-yang-types) for leaves (such as grouping neighbor-node/bandwidth). All links are invalid, better to use references anyway because the module will be used outside the RFC. Specific problems: - description - copyright 2020 - typedef ieee802-1as-timestamp-type - reference in description, put separately - grouping address-families - list with a single key can be leaf-list - would make sense if meant to be augmented with new nodes - grouping node-flag - used only once, makes sense if meant to be reused by other modules - consider using bits type in the leaf - grouping base-node-info/pod - redundant description, use union of number and "undefined", or leave out for undefined since it is not mandatory - augment rift/rx-lie-multicast-address,tx-lie-multicast-address - default value in description - should be defined in YANG - consider using refine on "addresses" rx-flood-port - redundant default in description, is obvious in YANG algorithm-type - empty cases - redundant on their own, are expected to be augmented? HAL - use lowercase database/tie/negative_disaggregation_prefixes - use hyphen instead of underscore - consider abbreviated/shorter node names - applicable for the following nodes as well _______________________________________________ RIFT mailing list RIFT@ietf.org https://www.ietf.org/mailman/listinfo/rift --=====_003_next=====-- --=====_001_next=====-- From nobody Thu Sep 9 02:27:27 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D273A23FD; Thu, 9 Sep 2021 02:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zH88LNrIl25; Thu, 9 Sep 2021 02:26:47 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1AD73A2405; Thu, 9 Sep 2021 02:26:44 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 4CB1960068; Thu, 9 Sep 2021 11:26:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1631179597; bh=jC1qErbNEhx/qIJ3CSXnXVOkUbDyupjSKzCof3wCiZ4=; h=From:In-Reply-To:Date:Cc:To:Subject; b=ShmH+1vGZApL21UDEZPv1ckT4ihvnAdjNOp4ov2A7fH9A6NVRWhuz/Ek9i9zc/adp Qf8vSFgq6I+MxLYVA1i1DqEjwSUqxblMvCrpDF+nECRRMdA8OJblhw5jV145o2ip8z X6UDXvWDeQCfhtoscGtIrwke6E7GnAhYVLnOwedk= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <202109091709262207934@zte.com.cn> Content-Type: text/plain; charset="utf-8" X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Thu, 09 Sep 2021 11:26:37 +0200 Cc: noreply@ietf.org, draft-ietf-rift-yang.all@ietf.org, yang-doctors@ietf.org, rift@ietf.org, last-call@ietf.org To: zhang.zheng@zte.com.cn MIME-Version: 1.0 Message-ID: <137d-6139d380-3-67131e80@232159592> User-Agent: SOGoMail 5.2.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [yang-doctors] =?utf-8?q?=5BRift=5D_Yangdoctors_last_call_review?= =?utf-8?q?_of_draft-ietf-rift-yang-03?= X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2021 09:26:53 -0000 Hi Sandy, firstly, sorry for the chaotic review. I have organized it properly but= some formatting was lost, I will know next time. As for your question, I do not see any node "algorithm-type" of type le= af, only choice. This choice includes 2 empty cases "spf" and "all-path= ". This YANG construct as it is has no purpose and cannot even be insta= ntiated in YANG data, unless some YANG data nodes were added into the c= ases by augments. I suppose that is not the intention and you simply wa= nted to write a configuration node that could be set to either "spf" or= "all-path" value. In that case you want to use enumeration like this: leaf algorithm-type { type enumeration { enum spf { description "The algorithm is SPF."; } enum all-path { description "The algorithm is all-path."; } } description "The possible algorithm types."; } If you need the possible "algorithm-type" values to be dynamic - allowe= d new to be added from other YANG modules, you can even use type "ident= ityref" and define the values as identities. Regards, Michal On Thursday, September 09, 2021 11:09 CEST, wr= ote: > Hi Michal, > Thank you again for your review! > We are do the updating work. > But we are not sure that we got the meaning of the following comment:= > "algorithm-type - empty cases - redundant on their own, are expected = to > be augmented?" > The algorithm-type leaf in the model is not empty. Could you please e= xplain this comment more detailedly? > Thank you very much! > Best regards, > Sandy > > ------------------=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6---------------= --- > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AMichalVa=C5=A1koviaDatatracker > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9Ayang-doctors@ietf.org; > =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Adraft-ietf-rift-yang.all@ietf.org= ;last-call@ietf.org;rift@ietf.org; > =E6=97=A5 =E6=9C=9F =EF=BC=9A2021=E5=B9=B407=E6=9C=8808=E6=97=A5 18:1= 7 > =E4=B8=BB =E9=A2=98 =EF=BC=9A[Rift] Yangdoctors last call review of d= raft-ietf-rift-yang-03 > Reviewer: Michal Va=C5=A1ko > Review result: Almost Ready > > Generally, use references where make sense (features, nodes) and use = units > and/or standard types (ietf-yang-types) for leaves (such as grouping > neighbor-node/bandwidth). All links are invalid, better to use refere= nces > anyway because the module will be used outside the RFC. > > Specific problems: > > - description - copyright 2020 > - typedef ieee802-1as-timestamp-type - reference in description, put = separately > - grouping address-families > - list with a single key can be leaf-list > - would make sense if meant to be augmented with new nodes > - grouping node-flag > - used only once, makes sense if meant to be reused by other modules > - consider using bits type in the leaf > - grouping base-node-info/pod - redundant description, use union of n= umber and > "undefined", or leave out for undefined since it is not mandatory - a= ugment > rift/rx-lie-multicast-address,tx-lie-multicast-address > - default value in description - should be defined in YANG > - consider using > refine on > "addresses" > rx-flood-port - redundant default in description, is obvious in YANG > algorithm-type - empty cases - redundant on their own, are expected t= o > be augmented? HAL - use lowercase > database/tie/negative=5Fdisaggregation=5Fprefixes > - use hyphen instead of underscore > - consider abbreviated/shorter node names > - applicable for the following nodes as well > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift From nobody Thu Sep 9 02:41:43 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78693A24A4; Thu, 9 Sep 2021 02:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-VM-f6yq1Xe; Thu, 9 Sep 2021 02:41:02 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 CABD53A24A0; Thu, 9 Sep 2021 02:41:01 -0700 (PDT) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 6E429EBE0E1C8C1596C9; Thu, 9 Sep 2021 17:40:58 +0800 (CST) Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id 1899ecfn024899; Thu, 9 Sep 2021 17:40:38 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid203; Thu, 9 Sep 2021 17:40:38 +0800 (CST) Date: Thu, 9 Sep 2021 17:40:38 +0800 (CST) X-Zmail-TransId: 2af96139d6966d7a9151 X-Mailer: Zmail v1.0 Message-ID: <202109091740384839547@zte.com.cn> In-Reply-To: <137d-6139d380-3-67131e80@232159592> References: 137d-6139d380-3-67131e80@232159592 Mime-Version: 1.0 From: To: Cc: , , , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn 1899ecfn024899 Archived-At: Subject: Re: [yang-doctors] =?utf-8?q?=5BRift=5D_Yangdoctors_last_call_review?= =?utf-8?q?_of_draft-ietf-rift-yang-03?= X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2021 09:41:10 -0000 --=====_001_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Hi Michal, Got it. We'll change the type of the leaf to enum. Thank you very much! Best regards, Sandy ------------------原始邮件------------------ 发件人:MichalVaško 收件人:张征00007940; 抄送人:noreply@ietf.org;draft-ietf-rift-yang.all@ietf.org;yang-doctors@ietf.org;rift@ietf.org;last-call@ietf.org; 日 期 :2021年09月09日 17:27 主 题 :Re: [yang-doctors] [Rift] Yangdoctors last call review of draft-ietf-rift-yang-03 Hi Sandy, firstly, sorry for the chaotic review. I have organized it properly but some formatting was lost, I will know next time. As for your question, I do not see any node "algorithm-type" of type leaf, only choice. This choice includes 2 empty cases "spf" and "all-path". This YANG construct as it is has no purpose and cannot even be instantiated in YANG data, unless some YANG data nodes were added into the cases by augments. I suppose that is not the intention and you simply wanted to write a configuration node that could be set to either "spf" or "all-path" value. In that case you want to use enumeration like this: leaf algorithm-type { type enumeration { enum spf { description "The algorithm is SPF."; } enum all-path { description "The algorithm is all-path."; } } description "The possible algorithm types."; } If you need the possible "algorithm-type" values to be dynamic - allowed new to be added from other YANG modules, you can even use type "identityref" and define the values as identities. Regards, Michal On Thursday, September 09, 2021 11:09 CEST, wrote: > Hi Michal, > Thank you again for your review! > We are do the updating work. > But we are not sure that we got the meaning of the following comment: > "algorithm-type - empty cases - redundant on their own, are expected to > be augmented?" > The algorithm-type leaf in the model is not empty. Could you please explain this comment more detailedly? > Thank you very much! > Best regards, > Sandy > > ------------------原始邮件------------------ > 发件人:MichalVaškoviaDatatracker > 收件人:yang-doctors@ietf.org; > 抄送人:draft-ietf-rift-yang.all@ietf.org;last-call@ietf.org;rift@ietf.org; > 日 期 :2021年07月08日 18:17 > 主 题 :[Rift] Yangdoctors last call review of draft-ietf-rift-yang-03 > Reviewer: Michal Vaško > Review result: Almost Ready > > Generally, use references where make sense (features, nodes) and use units > and/or standard types (ietf-yang-types) for leaves (such as grouping > neighbor-node/bandwidth). All links are invalid, better to use references > anyway because the module will be used outside the RFC. > > Specific problems: > > - description - copyright 2020 > - typedef ieee802-1as-timestamp-type - reference in description, put separately > - grouping address-families > - list with a single key can be leaf-list > - would make sense if meant to be augmented with new nodes > - grouping node-flag > - used only once, makes sense if meant to be reused by other modules > - consider using bits type in the leaf > - grouping base-node-info/pod - redundant description, use union of number and > "undefined", or leave out for undefined since it is not mandatory - augment > rift/rx-lie-multicast-address,tx-lie-multicast-address > - default value in description - should be defined in YANG > - consider using > refine on > "addresses" > rx-flood-port - redundant default in description, is obvious in YANG > algorithm-type - empty cases - redundant on their own, are expected to > be augmented? HAL - use lowercase > database/tie/negative_disaggregation_prefixes > - use hyphen instead of underscore > - consider abbreviated/shorter node names > - applicable for the following nodes as well > > > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift --=====_003_next=====-- --=====_001_next=====-- From nobody Fri Sep 10 01:03:42 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B178E3A00E4 for ; Fri, 10 Sep 2021 01:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM25TCZSkKXK for ; Fri, 10 Sep 2021 01:03:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA943A00E2 for ; Fri, 10 Sep 2021 01:03:35 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id A7B66147DB9; Fri, 10 Sep 2021 10:03:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1631261011; bh=uQ8Nup3/I2os3tix+UntiyrYRXa8NbUhORo65Fp5/1Y=; h=From:To:Date; b=km8nSeSgZ1OkUvo839JsYpqb6jOkPh/tkHqIeK8/t+dfD7Er8+z8pVr/P7VATxPsj thzbTLtDoG3f9wcZR0T9bz/YE0pXM+teb6NqON9qszOmGtQX0wCgbWS9aago9ALND6 ucckZ1DDN/FfeuQyZvLoPnPG5ygesrJBVma3eagI= From: Ladislav Lhotka To: Michelle Cotton , "yang-doctors@ietf.org" Cc: Sabrina Tanamal , Amanda Baber In-Reply-To: <731DAF81-C9DE-415C-9DBB-E56FAB6EC4F0@iana.org> References: <731DAF81-C9DE-415C-9DBB-E56FAB6EC4F0@iana.org> Date: Fri, 10 Sep 2021 10:03:31 +0200 Message-ID: <874kasrh64.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [yang-doctors] Question about implementation of yang modules for recently published RFC X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 08:03:42 -0000 Hi, this is unrelated to Michelle's question but... It seems it is somewhat complicated for IANA to maintain YANG modules mirro= ring IANA registries. I am thinking about using the approach of RFC 9108 on= a larger scale - specifically, developing XSLT stylesheets that would take= the online XML format of an IANA registry and transform it to a YANG modul= e. This way, IANA would only maintain the registries, but YANG modellers ca= n always obtain a YANG module corresponding to the up-to-date revision of t= he registry. Moreover, there would be some hope that important IANA registries can be ma= de available to YANG before the end of the universe - it took three years t= o finish RFC 9108 in DNSOP WG. What do you think? Lada Michelle Cotton writes: > Hello Yang Doctors! > >=20=20 > > Quick question about implementation of RFC 9132. > >=20=20 > > For the IANA maintained Yang, iana-dots-signal-channel, the RFC-Editor se= nt us a replacement yang file. > >=20=20 > > In this case, do we just delete the older yang file and completely replac= e it with the new one? > >=20=20 > > At https://www.iana.org/assignments/yang-parameters we point the iana-dot= s-signal-channel entry to the newer yang file. > >=20=20 > > Then we=E2=80=99ll update https://www.iana.org/assignments/iana-dots-sign= al-channel/iana-dots-signal-channel.xhtml so that it points to the newer ya= ng file and update the RFC. > >=20=20 > > Do we have that correct? > >=20=20 > > For the ietf-dots-signal-channel yang, an additional entry was added sinc= e it is not IANA maintained (per previous instructions from Benoit). > >=20=20 > > Thanks for any confirmation you can provide! > >=20=20 > > --Michelle > >=20=20 > > Michelle Cotton > > Protocol Parameters Engagement Sr. Manger > > IANA Services > >=20=20 > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Sep 10 02:42:10 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E913A0C00 for ; Fri, 10 Sep 2021 02:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIT7ODaPs6ad for ; Fri, 10 Sep 2021 02:42:02 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40054.outbound.protection.outlook.com [40.107.4.54]) (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 997E73A0BF3 for ; Fri, 10 Sep 2021 02:42:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=REFolQnr709JlKU3w5XRNkI7BBIILctOZD92gPEwbi4R3MuhrUOx1aPrbXQNd4dC47EDWm8tj7+XtRAYvI9WAtwVDNcvEKSowWJxuGGnexoIoYOFRexqjvSvRKsCTzQK771dqHbnKlDYmQqE+Vcla1oXii2+OTAESvth/9ty9J7gPP3pmr1NJ4r5NNJcgxkmcTF5fq0NRbExHjDCT4W8Vp8arPhoZpjnmxXWOH6XvXZRZN/KIbjCjBdtiyDd1/UH8BSe5sGYbm29oxfld/TOD8pPO7BZteMcFI27R41LgTIWpNV1SZeAyaSuPDybWzEiCW2+SmMsi1mDkNr1ZsYSCg== 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; bh=/Juv84jmWaMtGu7488YTKTLKQs7qFMfO+e5uHzZMJAk=; b=LyMrKiXtbAaKE8YFTKyhAVz592lCNCV+kbGppqy0Jja5641oAC1u5RbKB1H+Q59fWjBlBsyr4MAeNZ7ktylDDzlNsaQu9ogK64ayRDkQ0fCIq77R8wQUrtKu6HvQofFH0wc/vtH3of/ZQgr70WzPhTRiZNg+6KzVHKNuyeG8Tbo8Rh0xAGDjN6/Id3Rde+HyetFv7dQ7/ZqlhZNnp1kM99eSphuI9xGzJacC+hRkGYXwiZDLBCz9GRkWvBvLo1cssBppeO3+5TuJB8uNHVWw6qEWPM4VrVNoMs6sTV6jhgT0+sLAygxFdYrbTvShqf28vS7RyOVhLdn5ILDlZWCuFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/Juv84jmWaMtGu7488YTKTLKQs7qFMfO+e5uHzZMJAk=; b=ti92Z0Qd8QSzAbUanI/P0nh6aJ/9OGVvgGiyLrPZpFpf/Mg03BR6g7LvPns6YWhrnnSne1HzYnMaNUJPh9ptne+XqysY2cfqDdGwZ5K2z88UK8FZLV0xXHx3eran+18K2xlHOED3DzgPjMXu/OtoRW5yVe9BQ2kRAFzuDOwrc1M= Authentication-Results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0065.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:62::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.16; Fri, 10 Sep 2021 09:41:58 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::6539:572:25dd:e6ab]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::6539:572:25dd:e6ab%7]) with mapi id 15.20.4500.017; Fri, 10 Sep 2021 09:41:58 +0000 Date: Fri, 10 Sep 2021 11:41:56 +0200 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Ladislav Lhotka Cc: Michelle Cotton , "yang-doctors@ietf.org" , Sabrina Tanamal , Amanda Baber Message-ID: <20210910094156.42nvmkjo2bmru3bw@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , Michelle Cotton , "yang-doctors@ietf.org" , Sabrina Tanamal , Amanda Baber References: <731DAF81-C9DE-415C-9DBB-E56FAB6EC4F0@iana.org> <874kasrh64.fsf@nic.cz> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <874kasrh64.fsf@nic.cz> X-ClientProxiedBy: PR0P264CA0282.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1::30) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR0P264CA0282.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Fri, 10 Sep 2021 09:41:57 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2fa5fbb6-d3cf-4865-5a4d-08d9743f3b62 X-MS-TrafficTypeDiagnostic: AM4P190MB0065: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zCmNd0YtYFb+kkvuPOSGlPbrT737//8aOw38fOOrF6ZXtKP3Cuq6Oi0OjVWt+WDo83Rk1AwMdg+3rv93XUA+5hOKx0maVvKO6OvQn/VL0IyENlgiTJG6hhBnijI85QijkGa2zUFL597K+aMCqli07d8KXXKhaxY/ayOzeGhY6ODGRiG5CnydhWjOSGcPX751hV5o9VY8wFksm6DAaSZ80l/zeZrjA7nKY1aiH7nMevDBGITuScHTqBXEjnYz7rsxfGoCulbmG0tQKnADlsVaYoerw3vN08jBULITfJVpWQnpXISQX8ivlODXOXXAAGdiNe+6pCKXjLbLhbjsFxVqx8HIVtCh+VUYzfB06bObfABhdU4msnUDFgjjiJu/GhA+R0GkW34vmFNonFUUX3wnfhEnxcZBl0W6hx9SzILG1Ck3gUroEdlltQ4LhUByDD7CGNZU2O9KJNb/81b56Vq9pSnrA+XBpSsTDUZt95zXixILdEAVggZKJim6j4qwCSinsa8OES0404tLZ8NWNyPu7SSL2gz1c6GVU2QVH4DEpFLEF31LxSfIY75SlMOeZdNVAafQx7w+GlBkqsG1GNMAC8RXIBvq37YsbLSEfiNMZwgrAj2rP8RoziadHJEUCEoXy26T0NWFecraDtjmPExSqaF7Noece1/vrGE/kASs6lYAFvcIX70eBKvlricpiqLC/4J5ak1Nm54bq8lWVX2LmgKw6Y7ClL3hBzXMEa2qrgpT8rLxuQT7GH+vdoAO5um2V1sz7QVtlB1vSoaLrb4dVkksF9CqfljcfHsoiYpFhHF8fwwTALNq6Lt7N15Qs+El8Ee9RF+LURGJdU72zwPOeg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(39860400002)(136003)(396003)(86362001)(478600001)(6916009)(2906002)(8676002)(956004)(52116002)(966005)(54906003)(4326008)(186003)(40140700001)(6496006)(85182001)(8936002)(83380400001)(5660300002)(6486002)(66946007)(38100700002)(85202003)(38350700002)(66556008)(1076003)(26005)(66476007)(316002)(3450700001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZjdKamwweXZEaWYxQzIzNjlxQXVCZC9Sb2djdUlvOXNMd2pJano2TmRHcnli?= =?utf-8?B?cDhJSm04K0IrOUJGSXhOVHB1c3lPR0ZrSmxwYVpZS0dBemdDejBPN21MYmJD?= =?utf-8?B?bWJ4T25YUXN6UXNGZWdVVTQwNUNXTDB1YldUYVF6SGxXV0gyM0RiMm9YcUlo?= =?utf-8?B?Yllab09MVmRGRm8yUThuc2NuVlNWL1BrMGtzNWFBdUNsRmtQT09KSXQxT3lU?= =?utf-8?B?TitnNkt3d1BDRURSRmtIMk14MnhOYXhpWXF2d0g4bEhISmM5TktndENzZHYx?= =?utf-8?B?U3A4cGVRSVBqMXl1cE9rZ1hMNHhtRWM2MVlSb3p0YlNkclFOc1hhVy9TV0pB?= =?utf-8?B?bGdoTXpSMHJTSVVaMXhIcFJkMkhUN3o5Q1JwRGo3MjVnMHVGN3ZJc0tsU1ov?= =?utf-8?B?RUdxYXpUdGU0Y0hscWQ1VC9lUWxMN21SYXN3bDVFcmRoanJid1BmaVZ2ZG1O?= =?utf-8?B?S0JmQ3ZFNHJsM01YbW50SXpvK0JRdk1iYXIvRTA5Yjd1RjZSUGJyS0NZdmlw?= =?utf-8?B?a0Z5V08weWNhUVJJOWFIRmJrUDlXUDVQV1JBaW9jTHBJN25VU3RSb3EweThW?= =?utf-8?B?NURnQkY1RFVmVVJLQklZa3VDbS9VaWNLUGtvQVI5MTJ3bGFjUi9GY0J1dC9P?= =?utf-8?B?Qi9QRHRkVVpHWTE1WENGalVXWktNM1FiYjdCT1hXeFBzcy9BQTRkRU1UTGFI?= =?utf-8?B?YldxTlpZeGxlbjRERm0zbnB5ZUZxTFdBOWJqMXN6WHpCUnJXaTM2RG5IRzd6?= =?utf-8?B?UmloZy9FcUFHTFFQRXNOVFh3UW1oY0lzN0xuUTFTdTJhRzBWTHFZdGlYRW1l?= =?utf-8?B?VXVhM3MrN0FqeTRIYmR0eUtBYW1XUkdWcE1JNm05TkQzTVJ4M1pJNk9rdVNn?= =?utf-8?B?Q2ZpZ2NkTnV6amdaUEJnaDMyRkhjOFEzSmZkdTQ5SzNSaWRPRnRLbWpKRUI3?= =?utf-8?B?bmFKT1B6Ty9iRkhaSCtUNlBieHBJQ3BFeVJBZGF0c3NKa2hvNVRaZEdEeS9z?= =?utf-8?B?bkdRMEVqaUNEdmdJKzNVNVFIbVJZVGkzTVhkbk5BSDhNVDFJYlZRTFBLYnVk?= =?utf-8?B?UDdIK05jT0Y5djNRdW82YjYxOXlIM2hKTkJLYWxtYVlNZSt3L2ZCZ2xqM2R5?= =?utf-8?B?MVVwUnlYbFNDc1ZIS1hEUHpjeGlZTlhpNllsRWZvT0ljZmVteXZBQVZ1eWhq?= =?utf-8?B?MG1CUVNrYnk0N3ExU3RRM0dmR0dma2k1NVlnckw1UkE5b1paTjZrK3hCNmpj?= =?utf-8?B?a1hJNDZGRVlXWGRoellhZGxZTHdNQ1JNdnlhaXp1bWNxNkR5MklkblVTeVdU?= =?utf-8?B?Y1NCNzZUMlVpL0VrOHRoN05HYjdKSURuc215U1p4aHpiVXg3NXZVSlkwa1hJ?= =?utf-8?B?K3pRY1o2MWJMV1JsdzVxeUZZTWRiVnM3c3NIaHhqV1pmTjhBNWIrTk5xMmxw?= =?utf-8?B?L2FwMmwvTjNSbi9wQnJLNlBscDBGbS9qd0ZTTWlDQytYbWZrWmZVeFFMdi82?= =?utf-8?B?bDJSNjVMWFZaTEIyNHN0K0VsbFBic09zSWZYcFQvaFM3NTZ3Y2NHZFpzUjBT?= =?utf-8?B?QzAxZndwRTM2Q1AvSjduOUVaTjVNWk5FQWlCUTFtV1pLVVVhOGQzKzcwRkJJ?= =?utf-8?B?Z1BkbTZWb2tRWUNod0w1SGN4REprM0hTYkdIalltbUtqY0VtRkpmQnhPOUhK?= =?utf-8?B?RzNZU05mYTJCQkxNbTRkdjJRL3haclpML01udVp0c2Y2US9QZHBpK0l4Z1ps?= =?utf-8?Q?2cQhdee/vpJ7RkVVp4DBZRMLWYbGGNth9dKreVl?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 2fa5fbb6-d3cf-4865-5a4d-08d9743f3b62 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2021 09:41:58.0128 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +JCCkwdbZt9LJyfO5HKafaNs7mpNbbGJSUIAzEW7tHLKSL9yHE8FyFCSaVF68jFPYRacK5fdp75z/1h2lZTsn/xJQquUMjuzrAsjVy4Y0co= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0065 Archived-At: Subject: Re: [yang-doctors] Question about implementation of yang modules for recently published RFC X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 09:42:08 -0000 Lada, I think it is highly desirable to have an automated workflow that avoids manual work as much as possible. Creating such a workflow, however, may not be easy and might require a couple of hackathons in order to weed out the corner cases that will show up (and I expect there to be quite a few of them if you look at the larger universe of IANA registries). So it boils down to who brings up the energy for working on this. If you have time for it, you have my ideological support but I may not be able to contribute much to it (and I am not good at xslt transforms in particular). Back in a day, I would likely have contributed to such an activity during IETF meetings, but in the modern times with meetings that tend to do not get me anymore out of my everyday life, activities like this tend to find no time anymore. /js On Fri, Sep 10, 2021 at 10:03:31AM +0200, Ladislav Lhotka wrote: > Hi, > > this is unrelated to Michelle's question but... > > It seems it is somewhat complicated for IANA to maintain YANG modules mirroring IANA registries. I am thinking about using the approach of RFC 9108 on a larger scale - specifically, developing XSLT stylesheets that would take the online XML format of an IANA registry and transform it to a YANG module. This way, IANA would only maintain the registries, but YANG modellers can always obtain a YANG module corresponding to the up-to-date revision of the registry. > > Moreover, there would be some hope that important IANA registries can be made available to YANG before the end of the universe - it took three years to finish RFC 9108 in DNSOP WG. > > What do you think? > > Lada > > Michelle Cotton writes: > > > Hello Yang Doctors! > > > > > > > > Quick question about implementation of RFC 9132. > > > > > > > > For the IANA maintained Yang, iana-dots-signal-channel, the RFC-Editor sent us a replacement yang file. > > > > > > > > In this case, do we just delete the older yang file and completely replace it with the new one? > > > > > > > > At https://www.iana.org/assignments/yang-parameters we point the iana-dots-signal-channel entry to the newer yang file. > > > > > > > > Then we’ll update https://www.iana.org/assignments/iana-dots-signal-channel/iana-dots-signal-channel.xhtml so that it points to the newer yang file and update the RFC. > > > > > > > > Do we have that correct? > > > > > > > > For the ietf-dots-signal-channel yang, an additional entry was added since it is not IANA maintained (per previous instructions from Benoit). > > > > > > > > Thanks for any confirmation you can provide! > > > > > > > > --Michelle > > > > > > > > Michelle Cotton > > > > Protocol Parameters Engagement Sr. Manger > > > > IANA Services > > > > > > > > _______________________________________________ > > yang-doctors mailing list > > yang-doctors@ietf.org > > https://www.ietf.org/mailman/listinfo/yang-doctors > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Sep 10 04:11:36 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5883A077C for ; Fri, 10 Sep 2021 04:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_gArLsbmUyy for ; Fri, 10 Sep 2021 04:11:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDE33A0774 for ; Fri, 10 Sep 2021 04:11:27 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8] (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 60E7614238C; Fri, 10 Sep 2021 13:11:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1631272283; bh=OpoccHoRVBXQ8FEXBQ1un2RlAzt1zk6VcN8w9joUQnM=; h=To:From:Date; b=kKEf/E/oQ5xsRDqFGqG8/PmU8PiupKLgW+dRq6P40iALbgJiA1dMTwuv3jHnmT3ZN FI3NZarjlJ5yMfzVdWkgGkuBpxsv9hWWjrNkMR7tvmM1U0vqDF2wV4LCOuKcB0E6r8 XVpl9H5qdTTcfxrsgp8iCtVlqwXyYNCl35KBQpok= To: Michelle Cotton , "yang-doctors@ietf.org" , Sabrina Tanamal , Amanda Baber References: <731DAF81-C9DE-415C-9DBB-E56FAB6EC4F0@iana.org> <874kasrh64.fsf@nic.cz> <20210910094156.42nvmkjo2bmru3bw@anna.jacobs.jacobs-university.de> From: Ladislav Lhotka Organization: CZ.NIC Message-ID: <8711d0d9-eb5b-f58f-b010-f74681bc1698@nic.cz> Date: Fri, 10 Sep 2021 13:11:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20210910094156.42nvmkjo2bmru3bw@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [yang-doctors] Question about implementation of yang modules for recently published RFC X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 11:11:35 -0000 On 10. 09. 21 11:41, Jürgen Schönwälder wrote: > Lada, > > I think it is highly desirable to have an automated workflow that > avoids manual work as much as possible. Creating such a workflow, > however, may not be easy and might require a couple of hackathons in > order to weed out the corner cases that will show up (and I expect > there to be quite a few of them if you look at the larger universe of > IANA registries). Technically, the biggest problem is that I haven't been able to find any schema or other definition of the XML format used, so one doesn't really know what to expect in the next registry. Somebody also told me that IANA is considering an upgrade of this XML format. If it is so, then it might be worthwhile to prepare an interface to YANG along with it. > > So it boils down to who brings up the energy for working on this. If > you have time for it, you have my ideological support but I may not be > able to contribute much to it (and I am not good at xslt transforms in > particular). Back in a day, I would likely have contributed to such an > activity during IETF meetings, but in the modern times with meetings > that tend to do not get me anymore out of my everyday life, activities > like this tend to find no time anymore. Everything needn't be done at once, and addressing one or a few registries at a time doesn't mean a terrible aount of work. In any case, after the experience with RFC 9108 I am not much motivated to continue in the same way with other registries that are necessary for DNS (or whatever). It could be a topic for an IETF hackathon, but I was thinking simply about starting a new Github repo. I also know that XSLT language is a bit obscure but, on the other hand, it is a perfect fit for this use case, and xsltproc is a ubiquitous tool across all platforms. Thanks, Lada > > /js > > On Fri, Sep 10, 2021 at 10:03:31AM +0200, Ladislav Lhotka wrote: >> Hi, >> >> this is unrelated to Michelle's question but... >> >> It seems it is somewhat complicated for IANA to maintain YANG modules mirroring IANA registries. I am thinking about using the approach of RFC 9108 on a larger scale - specifically, developing XSLT stylesheets that would take the online XML format of an IANA registry and transform it to a YANG module. This way, IANA would only maintain the registries, but YANG modellers can always obtain a YANG module corresponding to the up-to-date revision of the registry. >> >> Moreover, there would be some hope that important IANA registries can be made available to YANG before the end of the universe - it took three years to finish RFC 9108 in DNSOP WG. >> >> What do you think? >> >> Lada >> >> Michelle Cotton writes: >> >>> Hello Yang Doctors! >>> >>> >>> >>> Quick question about implementation of RFC 9132. >>> >>> >>> >>> For the IANA maintained Yang, iana-dots-signal-channel, the RFC-Editor sent us a replacement yang file. >>> >>> >>> >>> In this case, do we just delete the older yang file and completely replace it with the new one? >>> >>> >>> >>> At https://www.iana.org/assignments/yang-parameters we point the iana-dots-signal-channel entry to the newer yang file. >>> >>> >>> >>> Then we’ll update https://www.iana.org/assignments/iana-dots-signal-channel/iana-dots-signal-channel.xhtml so that it points to the newer yang file and update the RFC. >>> >>> >>> >>> Do we have that correct? >>> >>> >>> >>> For the ietf-dots-signal-channel yang, an additional entry was added since it is not IANA maintained (per previous instructions from Benoit). >>> >>> >>> >>> Thanks for any confirmation you can provide! >>> >>> >>> >>> --Michelle >>> >>> >>> >>> Michelle Cotton >>> >>> Protocol Parameters Engagement Sr. Manger >>> >>> IANA Services >>> >>> >>> >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Sep 14 16:51:45 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B463A37A6 for ; Tue, 14 Sep 2021 16:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0wbPZV1oey4 for ; Tue, 14 Sep 2021 16:51:37 -0700 (PDT) Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (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 8D97E3A379C for ; Tue, 14 Sep 2021 16:51:37 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 0AC31E2DEF for ; Tue, 14 Sep 2021 23:51:36 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id DB6FF2056B; Tue, 14 Sep 2021 23:51:35 +0000 (UTC) RT-Owner: michelle.cotton From: "Amanda Baber via RT" Reply-To: iana-issues-comment@iana.org In-Reply-To: References: <8711505C-AC4E-4DFF-B44E-7DBAAE586A9B@iana.org> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1208742 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: yang-doctors@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 14 Sep 2021 23:51:35 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [yang-doctors] [IANA #1208742] YANG modules and XML-based registries X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 23:51:43 -0000 Hi all, On Fri Sep 10 23:53:40 2021, michelle.cotton@iana.org wrote: > Sending the follow-up conversation to a ticket for tracking. > > On 9/10/21, 4:11 AM, "Ladislav Lhotka" > wrote: > > On 10. 09. 21 11:41, Jürgen Schönwälder wrote: > > Lada, > > > > I think it is highly desirable to have an automated workflow that > > avoids manual work as much as possible. Creating such a workflow, > > however, may not be easy and might require a couple of hackathons in > > order to weed out the corner cases that will show up (and I expect > > there to be quite a few of them if you look at the larger universe of > > IANA registries). > > Technically, the biggest problem is that I haven't been able to find > any > schema or other definition of the XML format used, so one doesn't > really > know what to expect in the next registry. Somebody also told me that > IANA is considering an upgrade of this XML format. If it is so, then > it > might be worthwhile to prepare an interface to YANG along with it. Our development team is currently working on a move to a database- rather than XML-based registry system, but we don't have an ETA. Once the new system is in place, we will continue to make the current XML files available. The XML and RNG files use this naming scheme: https://www.iana.org/assignments/dns-parameters/dns-parameters.xml https://www.iana.org/assignments/dns-parameters/dns-parameters.rng If you have any questions, just let us know. Best regards, Amanda Baber IANA Operations Manager > > So it boils down to who brings up the energy for working on this. If > > you have time for it, you have my ideological support but I may not > > be > > able to contribute much to it (and I am not good at xslt transforms > > in > > particular). Back in a day, I would likely have contributed to such > > an > > activity during IETF meetings, but in the modern times with meetings > > that tend to do not get me anymore out of my everyday life, > > activities > > like this tend to find no time anymore. > > Everything needn't be done at once, and addressing one or a few > registries at a time doesn't mean a terrible aount of work. In any > case, > after the experience with RFC 9108 I am not much motivated to continue > in the same way with other registries that are necessary for DNS (or > whatever). > > It could be a topic for an IETF hackathon, but I was thinking simply > about starting a new Github repo. I also know that XSLT language is a > bit obscure but, on the other hand, it is a perfect fit for this use > case, and xsltproc is a ubiquitous tool across all platforms. > > Thanks, Lada > > > > > /js > > > > On Fri, Sep 10, 2021 at 10:03:31AM +0200, Ladislav Lhotka wrote: > >> Hi, > >> > >> this is unrelated to Michelle's question but... > >> > >> It seems it is somewhat complicated for IANA to maintain YANG > >> modules mirroring IANA registries. I am thinking about using the > >> approach of RFC 9108 on a larger scale - specifically, developing > >> XSLT stylesheets that would take the online XML format of an IANA > >> registry and transform it to a YANG module. This way, IANA would > >> only maintain the registries, but YANG modellers can always obtain a > >> YANG module corresponding to the up-to-date revision of the > >> registry. > >> > >> Moreover, there would be some hope that important IANA registries > >> can be made available to YANG before the end of the universe - it > >> took three years to finish RFC 9108 in DNSOP WG. > >> > >> What do you think? > >> > >> Lada > >> > >> Michelle Cotton writes: > >> > >>> Hello Yang Doctors! > >>> > >>> > >>> > >>> Quick question about implementation of RFC 9132. > >>> > >>> > >>> > >>> For the IANA maintained Yang, iana-dots-signal-channel, the RFC- > >>> Editor sent us a replacement yang file. > >>> > >>> > >>> > >>> In this case, do we just delete the older yang file and completely > >>> replace it with the new one? > >>> > >>> > >>> > >>> At https://www.iana.org/assignments/yang-parameters we point the > >>> iana-dots-signal-channel entry to the newer yang file. > >>> > >>> > >>> > >>> Then we’ll update https://www.iana.org/assignments/iana-dots- > >>> signal-channel/iana-dots-signal-channel.xhtml so that it points to > >>> the newer yang file and update the RFC. > >>> > >>> > >>> > >>> Do we have that correct? > >>> > >>> > >>> > >>> For the ietf-dots-signal-channel yang, an additional entry was > >>> added since it is not IANA maintained (per previous instructions > >>> from Benoit). > >>> > >>> > >>> > >>> Thanks for any confirmation you can provide! > >>> > >>> > >>> > >>> --Michelle > >>> > >>> > >>> > >>> Michelle Cotton > >>> > >>> Protocol Parameters Engagement Sr. Manger > >>> > >>> IANA Services > >>> > >>> > >>> > >>> _______________________________________________ > >>> yang-doctors mailing list > >>> yang-doctors@ietf.org > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/yang- > >>> doctors__;!!PtGJab4!suPziUKOfyykv0Qhj5r9en1nZ4hyHyBETXrSXpt2j4KRdQAQwZVIDsCiraSEwF1E0lbPE0COcxY$ > >> > >> -- > >> Ladislav Lhotka > >> Head, CZ.NIC Labs > >> PGP Key ID: 0xB8F92B08A9F76C67 > >> > >> _______________________________________________ > >> yang-doctors mailing list > >> yang-doctors@ietf.org > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/yang- > >> doctors__;!!PtGJab4!suPziUKOfyykv0Qhj5r9en1nZ4hyHyBETXrSXpt2j4KRdQAQwZVIDsCiraSEwF1E0lbPE0COcxY$ > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Sep 16 00:12:46 2021 Return-Path: X-Original-To: yang-doctors@ietf.org Delivered-To: yang-doctors@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECDC3A1BF7; Thu, 16 Sep 2021 00:10:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jan Lindblad via Datatracker To: Cc: draft-ietf-nvo3-yang-cfg.all@ietf.org, last-call@ietf.org, nvo3@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163177624716.21367.10437954922414983100@ietfa.amsl.com> Reply-To: Jan Lindblad Date: Thu, 16 Sep 2021 00:10:47 -0700 Archived-At: Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-nvo3-yang-cfg-05 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 07:10:48 -0000 Reviewer: Jan Lindblad Review result: Not Ready This is the YANG Doctor review of draft-ietf-nvo3-yang-cfg. In my judgement the draft is not ready for last call. This is not to say that there isn't plenty of good work that has gone into this draft and YANG module, but since I have been unable to compile it, due to unclear dependencies, the fundamental requirements for performing a review aren't met. As soon as you import another module, you become dependent on that module and inherit any problems it may have. If the modules you depend upon are not stable enough, it may not be viable to perform a last call review. As long as the modules you depend upon are not published, I would think you cannot go through with publication of your own module either. There's always a bit of guesswork involved when a YANG module imports unpublished modules. By looking in the IETF Git repository, under "standards/ietf/RFC" as well as under "experimental/ietf-extracted-YANG-modules", i.e. the section for automatically extracted YANG modules from drafts, I was able to guess at which modules that are transitively referenced. Based on this, I believe we will need to have stable versions of the following modules before the draft-ietf-nvo3-yang-cfg can proceed. Experimental modules are marked (*). iana-bfd-types.yang (*) iana-if-type.yang ietf-bfd-types.yang (*) ietf-bgp-common-multiprotocol.yang (*) ietf-bgp-common-structure.yang (*) ietf-bgp-common.yang (*) ietf-bgp-l3vpn.yang (*) ietf-bgp-neighbor.yang (*) ietf-bgp-peer-group.yang (*) ietf-bgp-policy.yang (*) ietf-bgp-rib-attributes.yang (*) ietf-bgp-rib-tables.yang (*) ietf-bgp-rib-types.yang (*) ietf-bgp-rib.yang (*) ietf-bgp-types.yang (*) ietf-bgp.yang (*) ietf-inet-types.yang ietf-interfaces.yang ietf-ip.yang ietf-key-chain.yang ietf-l2vpn.yang (*) ietf-netconf-acm.yang ietf-network-instance.yang ietf-pseudowires.yang (*) ietf-routing-policy.yang (*) ietf-routing-types.yang ietf-routing.yang ietf-tcp-common.yang (*) ietf-tcp.yang (*) ietf-yang-schema-mount.yang ietf-yang-types.yang Since I already did a first reading and found a few things, I'll list them here for the WG's benefit rather than me holding them to myself. 1. YANG 1.1 The draft says "YANG [RFC6020] is a data definition language that was introduced to". Since you are using yang-version 1.1, it would be more appropriate with a reference to RFC 7950. 2. Identity equality tests There are a couple of places in the YANG that check that an interface is of Nve type. Currently this is done using an equality test. While that can work, a better and more future proof way is to use derived-from-or-self(). So change must "(/if:interfaces/if:interface[if:name=current()]/if:type='Nve')"; to must "derived-from-or-self(/if:interfaces/if:interface[if:name=current()]/if:type, 'Nve')"; 3. Behavioral constraints defined in English text list static-peer { key "peer-ip"; ... leaf out-vni-id { type uint32 { range "1..16777215"; } description "The ID of VNI for outbound. Do not support separate deletion."; } I'm not completely clear as to the "Do not support separate deletion" is supposed to mean. If every static-peer must have an out-vni-id, it should be marked mandatory. If this is supposed to mean that an out-vni-id may be added, but not deleted, that violates one of the basic principles in YANG. The validity of a configuration should not depend on anything else than the configuration itself. In particular, the validity of an upcoming configuration should not depend on the prior configuration. If you don't want out-vni-id to be mandatory, but also don't want people to be able to delete it without deleting the static-peer, I would recommend making out-vni-id part of the key for static-peer, and ensure it can take a value that essentially means none. For example like this: list static-peer { key "peer-ip out-vni-id"; ... leaf out-vni-id { type union { type enumeration { enum none; } type uint32 { range "1..16777215"; } } description "The ID of VNI for outbound. Do not support separate deletion."; } 4. Repetition of config false In many places within the module, there are config false statements inside elements that are already config false. While this is perfectly legal, it is superfluous. Once a container or other element is marked config false, everything below that point will always be config false. The IETF convention is to not write config false in more places than necessary. container peers { config false; <--- Everything within/below container peers is now config false description "Operational data of remote NVE address in a VNI."; list peer { key "vni-id source-ip peer-ip"; config false; <--- Superfluous 5. Weak data format leaf up-time { type string { length "1..10"; } config false; description "The continuous time as NVO3 tunnel is reachable."; } YANG strings are great when used for names that the client can choose arbitrarily. They are not so great when they encode information that is not a name, unless there is a detailed description of the encoding. Since the encoding of the up-time leaf is not specified, the contents will not be interoperable. Either remove this leaf, or better, describe the format of the contents so that it can be decoded. Changing the type from string to some time type might be a good option. 6. Identities conventionally start with lowercase letters By convention, all identities defined by IETF start with a lower case letter. Citing the principle of least surprise, I would recommend changing identity Nve { to identity nve { 7. RPC or Action In YANG 1.1, rpc:s that pertain to a certain element in the data tree can be modeled as actions instead. This often leads to a more coherent model with less text. In this module, that seems to be the case for the two rpc:s defined. Therefore I would suggest changing rpc reset-vni-peer-statistic { description "Clear traffic statistics about the VXLAN tunnel."; input { leaf vni-id { type uint32 { range "1..16777215"; } mandatory true; description "The ID of the VNI."; } leaf peer-ip { type inet:ip-address-no-zone; mandatory true; description "The address of the remote NVE."; } leaf direction{ type direction-type; mandatory true; description "Traffic statistics direction for the tunnel."; } } } to list statistic { key "vni-id peer-ip direction"; ... action reset-vni-peer-statistic { description "Clear traffic statistics about the VXLAN tunnel."; } Best Regards, /jan From nobody Thu Sep 16 00:19:56 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71A83A1C26; Thu, 16 Sep 2021 00:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQLAadtv80fR; Thu, 16 Sep 2021 00:18:17 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCC03A1C28; Thu, 16 Sep 2021 00:18:17 -0700 (PDT) Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4H97fT0l7nz67L3d; Thu, 16 Sep 2021 15:16:01 +0800 (CST) Received: from dggpeml500011.china.huawei.com (7.185.36.84) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 16 Sep 2021 09:18:14 +0200 Received: from dggpeml500011.china.huawei.com (7.185.36.84) by dggpeml500011.china.huawei.com (7.185.36.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 16 Sep 2021 15:18:12 +0800 Received: from dggpeml500011.china.huawei.com ([7.185.36.84]) by dggpeml500011.china.huawei.com ([7.185.36.84]) with mapi id 15.01.2308.008; Thu, 16 Sep 2021 15:18:12 +0800 From: "Liubing (Remy)" To: Jan Lindblad , "yang-doctors@ietf.org" CC: "draft-ietf-nvo3-yang-cfg.all@ietf.org" , "last-call@ietf.org" , "nvo3@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-nvo3-yang-cfg-05 Thread-Index: Adeqys6uzIdlNTMncUKvbpf0o39XJw== Date: Thu, 16 Sep 2021 07:18:12 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.110.113.220] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-nvo3-yang-cfg-05 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 07:18:23 -0000 SGVsbG8gSmFuLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcuIFdlIHdpbGwgbWFrZSBy ZWxhdGVkIGNoYW5nZXMgaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KQmVzdCByZWdhcmRzLA0KQmlu Zw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IEphbiBMaW5kYmxhZCB2aWEg RGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAy MeW5tDnmnIgxNuaXpSAxNToxMQ0K5pS25Lu25Lq6OiB5YW5nLWRvY3RvcnNAaWV0Zi5vcmcNCuaK hOmAgTogZHJhZnQtaWV0Zi1udm8zLXlhbmctY2ZnLmFsbEBpZXRmLm9yZzsgbGFzdC1jYWxsQGll dGYub3JnOyBudm8zQGlldGYub3JnDQrkuLvpopg6IFlhbmdkb2N0b3JzIGxhc3QgY2FsbCByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1udm8zLXlhbmctY2ZnLTA1DQoNClJldmlld2VyOiBKYW4gTGluZGJs YWQNClJldmlldyByZXN1bHQ6IE5vdCBSZWFkeQ0KDQpUaGlzIGlzIHRoZSBZQU5HIERvY3RvciBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1udm8zLXlhbmctY2ZnLiBJbiBteSBqdWRnZW1lbnQgdGhlIGRy YWZ0IGlzIG5vdCByZWFkeSBmb3IgbGFzdCBjYWxsLiBUaGlzIGlzIG5vdCB0byBzYXkgdGhhdCB0 aGVyZSBpc24ndCBwbGVudHkgb2YgZ29vZCB3b3JrIHRoYXQgaGFzIGdvbmUgaW50byB0aGlzIGRy YWZ0IGFuZCBZQU5HIG1vZHVsZSwgYnV0IHNpbmNlIEkgaGF2ZSBiZWVuIHVuYWJsZSB0byBjb21w aWxlIGl0LCBkdWUgdG8gdW5jbGVhciBkZXBlbmRlbmNpZXMsIHRoZSBmdW5kYW1lbnRhbCByZXF1 aXJlbWVudHMgZm9yIHBlcmZvcm1pbmcgYSByZXZpZXcgYXJlbid0IG1ldC4NCg0KQXMgc29vbiBh cyB5b3UgaW1wb3J0IGFub3RoZXIgbW9kdWxlLCB5b3UgYmVjb21lIGRlcGVuZGVudCBvbiB0aGF0 IG1vZHVsZSBhbmQgaW5oZXJpdCBhbnkgcHJvYmxlbXMgaXQgbWF5IGhhdmUuIElmIHRoZSBtb2R1 bGVzIHlvdSBkZXBlbmQgdXBvbiBhcmUgbm90IHN0YWJsZSBlbm91Z2gsIGl0IG1heSBub3QgYmUg dmlhYmxlIHRvIHBlcmZvcm0gYSBsYXN0IGNhbGwgcmV2aWV3LiBBcyBsb25nIGFzIHRoZSBtb2R1 bGVzIHlvdSBkZXBlbmQgdXBvbiBhcmUgbm90IHB1Ymxpc2hlZCwgSSB3b3VsZCB0aGluayB5b3Ug Y2Fubm90IGdvIHRocm91Z2ggd2l0aCBwdWJsaWNhdGlvbiBvZiB5b3VyIG93biBtb2R1bGUgZWl0 aGVyLg0KDQpUaGVyZSdzIGFsd2F5cyBhIGJpdCBvZiBndWVzc3dvcmsgaW52b2x2ZWQgd2hlbiBh IFlBTkcgbW9kdWxlIGltcG9ydHMgdW5wdWJsaXNoZWQgbW9kdWxlcy4gQnkgbG9va2luZyBpbiB0 aGUgSUVURiBHaXQgcmVwb3NpdG9yeSwgdW5kZXIgInN0YW5kYXJkcy9pZXRmL1JGQyIgYXMgd2Vs bCBhcyB1bmRlciAiZXhwZXJpbWVudGFsL2lldGYtZXh0cmFjdGVkLVlBTkctbW9kdWxlcyIsIGku ZS4gdGhlIHNlY3Rpb24gZm9yIGF1dG9tYXRpY2FsbHkgZXh0cmFjdGVkIFlBTkcgbW9kdWxlcyBm cm9tIGRyYWZ0cywgSSB3YXMgYWJsZSB0byBndWVzcyBhdCB3aGljaCBtb2R1bGVzIHRoYXQgYXJl IHRyYW5zaXRpdmVseSByZWZlcmVuY2VkLiBCYXNlZCBvbiB0aGlzLCBJIGJlbGlldmUgd2Ugd2ls bCBuZWVkIHRvIGhhdmUgc3RhYmxlIHZlcnNpb25zIG9mIHRoZSBmb2xsb3dpbmcgbW9kdWxlcyBi ZWZvcmUgdGhlIGRyYWZ0LWlldGYtbnZvMy15YW5nLWNmZyBjYW4gcHJvY2VlZC4gRXhwZXJpbWVu dGFsIG1vZHVsZXMgYXJlIG1hcmtlZCAoKikuDQoNCmlhbmEtYmZkLXR5cGVzLnlhbmcgKCopDQpp YW5hLWlmLXR5cGUueWFuZw0KaWV0Zi1iZmQtdHlwZXMueWFuZyAoKikNCmlldGYtYmdwLWNvbW1v bi1tdWx0aXByb3RvY29sLnlhbmcgKCopDQppZXRmLWJncC1jb21tb24tc3RydWN0dXJlLnlhbmcg KCopDQppZXRmLWJncC1jb21tb24ueWFuZyAoKikNCmlldGYtYmdwLWwzdnBuLnlhbmcgKCopDQpp ZXRmLWJncC1uZWlnaGJvci55YW5nICgqKQ0KaWV0Zi1iZ3AtcGVlci1ncm91cC55YW5nICgqKQ0K aWV0Zi1iZ3AtcG9saWN5LnlhbmcgKCopDQppZXRmLWJncC1yaWItYXR0cmlidXRlcy55YW5nICgq KQ0KaWV0Zi1iZ3AtcmliLXRhYmxlcy55YW5nICgqKQ0KaWV0Zi1iZ3AtcmliLXR5cGVzLnlhbmcg KCopDQppZXRmLWJncC1yaWIueWFuZyAoKikNCmlldGYtYmdwLXR5cGVzLnlhbmcgKCopDQppZXRm LWJncC55YW5nICgqKQ0KaWV0Zi1pbmV0LXR5cGVzLnlhbmcNCmlldGYtaW50ZXJmYWNlcy55YW5n DQppZXRmLWlwLnlhbmcNCmlldGYta2V5LWNoYWluLnlhbmcNCmlldGYtbDJ2cG4ueWFuZyAoKikN CmlldGYtbmV0Y29uZi1hY20ueWFuZw0KaWV0Zi1uZXR3b3JrLWluc3RhbmNlLnlhbmcNCmlldGYt cHNldWRvd2lyZXMueWFuZyAoKikNCmlldGYtcm91dGluZy1wb2xpY3kueWFuZyAoKikNCmlldGYt cm91dGluZy10eXBlcy55YW5nDQppZXRmLXJvdXRpbmcueWFuZw0KaWV0Zi10Y3AtY29tbW9uLnlh bmcgKCopDQppZXRmLXRjcC55YW5nICgqKQ0KaWV0Zi15YW5nLXNjaGVtYS1tb3VudC55YW5nDQpp ZXRmLXlhbmctdHlwZXMueWFuZw0KDQpTaW5jZSBJIGFscmVhZHkgZGlkIGEgZmlyc3QgcmVhZGlu ZyBhbmQgZm91bmQgYSBmZXcgdGhpbmdzLCBJJ2xsIGxpc3QgdGhlbSBoZXJlIGZvciB0aGUgV0cn cyBiZW5lZml0IHJhdGhlciB0aGFuIG1lIGhvbGRpbmcgdGhlbSB0byBteXNlbGYuDQoNCjEuIFlB TkcgMS4xDQoNClRoZSBkcmFmdCBzYXlzICJZQU5HIFtSRkM2MDIwXSBpcyBhIGRhdGEgZGVmaW5p dGlvbiBsYW5ndWFnZSB0aGF0IHdhcyBpbnRyb2R1Y2VkIHRvIi4gU2luY2UgeW91IGFyZSB1c2lu ZyB5YW5nLXZlcnNpb24gMS4xLCBpdCB3b3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRlIHdpdGggYSBy ZWZlcmVuY2UgdG8gUkZDIDc5NTAuDQoNCjIuIElkZW50aXR5IGVxdWFsaXR5IHRlc3RzDQoNClRo ZXJlIGFyZSBhIGNvdXBsZSBvZiBwbGFjZXMgaW4gdGhlIFlBTkcgdGhhdCBjaGVjayB0aGF0IGFu IGludGVyZmFjZSBpcyBvZiBOdmUgdHlwZS4gQ3VycmVudGx5IHRoaXMgaXMgZG9uZSB1c2luZyBh biBlcXVhbGl0eSB0ZXN0LiBXaGlsZSB0aGF0IGNhbiB3b3JrLCBhIGJldHRlciBhbmQgbW9yZSBm dXR1cmUgcHJvb2Ygd2F5IGlzIHRvIHVzZSBkZXJpdmVkLWZyb20tb3Itc2VsZigpLiBTbyBjaGFu Z2UNCg0KIG11c3QgIigvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2VbaWY6bmFtZT1jdXJyZW50 KCldL2lmOnR5cGU9J052ZScpIjsNCg0KdG8NCg0KIG11c3QNCiAiZGVyaXZlZC1mcm9tLW9yLXNl bGYoL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlW2lmOm5hbWU9Y3VycmVudCgpXS9pZjp0eXBl LA0KICdOdmUnKSI7DQoNCjMuIEJlaGF2aW9yYWwgY29uc3RyYWludHMgZGVmaW5lZCBpbiBFbmds aXNoIHRleHQNCg0KICAgICAgICAgIGxpc3Qgc3RhdGljLXBlZXIgew0KICAgICAgICAgICAga2V5 ICJwZWVyLWlwIjsNCi4uLg0KICAgICAgICAgICAgbGVhZiBvdXQtdm5pLWlkIHsNCiAgICAgICAg ICAgICAgdHlwZSB1aW50MzIgew0KICAgICAgICAgICAgICAgIHJhbmdlICIxLi4xNjc3NzIxNSI7 DQogICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAg ICAgICAiVGhlIElEIG9mIFZOSSBmb3Igb3V0Ym91bmQuIERvIG5vdCBzdXBwb3J0IHNlcGFyYXRl IGRlbGV0aW9uLiI7DQogICAgICAgICAgICB9DQoNCkknbSBub3QgY29tcGxldGVseSBjbGVhciBh cyB0byB0aGUgIkRvIG5vdCBzdXBwb3J0IHNlcGFyYXRlIGRlbGV0aW9uIiBpcyBzdXBwb3NlZCB0 byBtZWFuLiBJZiBldmVyeSBzdGF0aWMtcGVlciBtdXN0IGhhdmUgYW4gb3V0LXZuaS1pZCwgaXQg c2hvdWxkIGJlIG1hcmtlZCBtYW5kYXRvcnkuIElmIHRoaXMgaXMgc3VwcG9zZWQgdG8gbWVhbiB0 aGF0IGFuIG91dC12bmktaWQgbWF5IGJlIGFkZGVkLCBidXQgbm90IGRlbGV0ZWQsIHRoYXQgdmlv bGF0ZXMgb25lIG9mIHRoZSBiYXNpYyBwcmluY2lwbGVzIGluIFlBTkcuIFRoZSB2YWxpZGl0eSBv ZiBhIGNvbmZpZ3VyYXRpb24gc2hvdWxkIG5vdCBkZXBlbmQgb24gYW55dGhpbmcgZWxzZSB0aGFu IHRoZSBjb25maWd1cmF0aW9uIGl0c2VsZi4gSW4gcGFydGljdWxhciwgdGhlIHZhbGlkaXR5IG9m IGFuIHVwY29taW5nIGNvbmZpZ3VyYXRpb24gc2hvdWxkIG5vdCBkZXBlbmQgb24gdGhlIHByaW9y IGNvbmZpZ3VyYXRpb24uDQoNCklmIHlvdSBkb24ndCB3YW50IG91dC12bmktaWQgdG8gYmUgbWFu ZGF0b3J5LCBidXQgYWxzbyBkb24ndCB3YW50IHBlb3BsZSB0byBiZSBhYmxlIHRvIGRlbGV0ZSBp dCB3aXRob3V0IGRlbGV0aW5nIHRoZSBzdGF0aWMtcGVlciwgSSB3b3VsZCByZWNvbW1lbmQgbWFr aW5nIG91dC12bmktaWQgcGFydCBvZiB0aGUga2V5IGZvciBzdGF0aWMtcGVlciwgYW5kIGVuc3Vy ZSBpdCBjYW4gdGFrZSBhIHZhbHVlIHRoYXQgZXNzZW50aWFsbHkgbWVhbnMgbm9uZS4gRm9yIGV4 YW1wbGUgbGlrZSB0aGlzOg0KDQogICAgICAgICAgbGlzdCBzdGF0aWMtcGVlciB7DQogICAgICAg ICAgICBrZXkgInBlZXItaXAgb3V0LXZuaS1pZCI7DQouLi4NCiAgICAgICAgICAgIGxlYWYgb3V0 LXZuaS1pZCB7DQogICAgICAgICAgICAgIHR5cGUgdW5pb24gew0KICAgICAgICAgICAgICAgIHR5 cGUgZW51bWVyYXRpb24gew0KICAgICAgICAgICAgICAgICAgZW51bSBub25lOw0KICAgICAgICAg ICAgICAgIH0NCiAgICAgICAgICAgICAgICB0eXBlIHVpbnQzMiB7DQogICAgICAgICAgICAgICAg ICByYW5nZSAiMS4uMTY3NzcyMTUiOw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAg fQ0KICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICJUaGUgSUQgb2Yg Vk5JIGZvciBvdXRib3VuZC4gRG8gbm90IHN1cHBvcnQgc2VwYXJhdGUgZGVsZXRpb24uIjsNCiAg ICAgICAgICAgIH0NCg0KNC4gUmVwZXRpdGlvbiBvZiBjb25maWcgZmFsc2UNCg0KSW4gbWFueSBw bGFjZXMgd2l0aGluIHRoZSBtb2R1bGUsIHRoZXJlIGFyZSBjb25maWcgZmFsc2Ugc3RhdGVtZW50 cyBpbnNpZGUgZWxlbWVudHMgdGhhdCBhcmUgYWxyZWFkeSBjb25maWcgZmFsc2UuIFdoaWxlIHRo aXMgaXMgcGVyZmVjdGx5IGxlZ2FsLCBpdCBpcyBzdXBlcmZsdW91cy4gT25jZSBhIGNvbnRhaW5l ciBvciBvdGhlciBlbGVtZW50IGlzIG1hcmtlZCBjb25maWcgZmFsc2UsIGV2ZXJ5dGhpbmcgYmVs b3cgdGhhdCBwb2ludCB3aWxsIGFsd2F5cyBiZSBjb25maWcgZmFsc2UuIFRoZSBJRVRGIGNvbnZl bnRpb24gaXMgdG8gbm90IHdyaXRlIGNvbmZpZyBmYWxzZSBpbiBtb3JlIHBsYWNlcyB0aGFuIG5l Y2Vzc2FyeS4NCg0KICAgICAgY29udGFpbmVyIHBlZXJzIHsNCiAgICAgICAgY29uZmlnIGZhbHNl OyAgICAgPC0tLSBFdmVyeXRoaW5nIHdpdGhpbi9iZWxvdyBjb250YWluZXIgcGVlcnMgaXMgbm93 DQogICAgICAgIGNvbmZpZyBmYWxzZSBkZXNjcmlwdGlvbg0KICAgICAgICAgICJPcGVyYXRpb25h bCBkYXRhIG9mIHJlbW90ZSBOVkUgYWRkcmVzcyBpbiBhIFZOSS4iOw0KICAgICAgICBsaXN0IHBl ZXIgew0KICAgICAgICAgIGtleSAidm5pLWlkIHNvdXJjZS1pcCBwZWVyLWlwIjsNCiAgICAgICAg ICBjb25maWcgZmFsc2U7ICAgICA8LS0tIFN1cGVyZmx1b3VzDQoNCjUuIFdlYWsgZGF0YSBmb3Jt YXQNCg0KICAgICAgbGVhZiB1cC10aW1lIHsNCiAgICAgICAgdHlwZSBzdHJpbmcgew0KICAgICAg ICAgIGxlbmd0aCAiMS4uMTAiOw0KICAgICAgICB9DQogICAgICAgIGNvbmZpZyBmYWxzZTsNCiAg ICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAiVGhlIGNvbnRpbnVvdXMgdGltZSBhcyBOVk8z IHR1bm5lbCBpcyByZWFjaGFibGUuIjsNCiAgICAgIH0NCg0KWUFORyBzdHJpbmdzIGFyZSBncmVh dCB3aGVuIHVzZWQgZm9yIG5hbWVzIHRoYXQgdGhlIGNsaWVudCBjYW4gY2hvb3NlIGFyYml0cmFy aWx5LiBUaGV5IGFyZSBub3Qgc28gZ3JlYXQgd2hlbiB0aGV5IGVuY29kZSBpbmZvcm1hdGlvbiB0 aGF0IGlzIG5vdCBhIG5hbWUsIHVubGVzcyB0aGVyZSBpcyBhIGRldGFpbGVkIGRlc2NyaXB0aW9u IG9mIHRoZSBlbmNvZGluZy4gU2luY2UgdGhlIGVuY29kaW5nIG9mIHRoZSB1cC10aW1lIGxlYWYg aXMgbm90IHNwZWNpZmllZCwgdGhlIGNvbnRlbnRzIHdpbGwgbm90IGJlIGludGVyb3BlcmFibGUu IEVpdGhlciByZW1vdmUgdGhpcyBsZWFmLCBvciBiZXR0ZXIsIGRlc2NyaWJlIHRoZSBmb3JtYXQg b2YgdGhlIGNvbnRlbnRzIHNvIHRoYXQgaXQgY2FuIGJlIGRlY29kZWQuIENoYW5naW5nIHRoZSB0 eXBlIGZyb20gc3RyaW5nIHRvIHNvbWUgdGltZSB0eXBlIG1pZ2h0IGJlIGEgZ29vZCBvcHRpb24u DQoNCjYuIElkZW50aXRpZXMgY29udmVudGlvbmFsbHkgc3RhcnQgd2l0aCBsb3dlcmNhc2UgbGV0 dGVycw0KDQpCeSBjb252ZW50aW9uLCBhbGwgaWRlbnRpdGllcyBkZWZpbmVkIGJ5IElFVEYgc3Rh cnQgd2l0aCBhIGxvd2VyIGNhc2UgbGV0dGVyLg0KQ2l0aW5nIHRoZSBwcmluY2lwbGUgb2YgbGVh c3Qgc3VycHJpc2UsIEkgd291bGQgcmVjb21tZW5kIGNoYW5naW5nDQoNCiAgaWRlbnRpdHkgTnZl IHsNCg0KdG8NCg0KICBpZGVudGl0eSBudmUgew0KDQo3LiBSUEMgb3IgQWN0aW9uDQoNCkluIFlB TkcgMS4xLCBycGM6cyB0aGF0IHBlcnRhaW4gdG8gYSBjZXJ0YWluIGVsZW1lbnQgaW4gdGhlIGRh dGEgdHJlZSBjYW4gYmUgbW9kZWxlZCBhcyBhY3Rpb25zIGluc3RlYWQuIFRoaXMgb2Z0ZW4gbGVh ZHMgdG8gYSBtb3JlIGNvaGVyZW50IG1vZGVsIHdpdGggbGVzcyB0ZXh0LiBJbiB0aGlzIG1vZHVs ZSwgdGhhdCBzZWVtcyB0byBiZSB0aGUgY2FzZSBmb3IgdGhlIHR3byBycGM6cyBkZWZpbmVkLg0K VGhlcmVmb3JlIEkgd291bGQgc3VnZ2VzdCBjaGFuZ2luZw0KDQogIHJwYyByZXNldC12bmktcGVl ci1zdGF0aXN0aWMgew0KICAgIGRlc2NyaXB0aW9uDQogICAgICAiQ2xlYXIgdHJhZmZpYyBzdGF0 aXN0aWNzIGFib3V0IHRoZSBWWExBTiB0dW5uZWwuIjsNCiAgICBpbnB1dCB7DQogICAgICBsZWFm IHZuaS1pZCB7DQogICAgICAgIHR5cGUgdWludDMyIHsNCiAgICAgICAgICByYW5nZSAiMS4uMTY3 NzcyMTUiOw0KICAgICAgICB9DQogICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KICAgICAgICBkZXNj cmlwdGlvbg0KICAgICAgICAgICJUaGUgSUQgb2YgdGhlIFZOSS4iOw0KICAgICAgfQ0KICAgICAg bGVhZiBwZWVyLWlwIHsNCiAgICAgICAgdHlwZSBpbmV0OmlwLWFkZHJlc3Mtbm8tem9uZTsNCiAg ICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgIlRo ZSBhZGRyZXNzIG9mIHRoZSByZW1vdGUgTlZFLiI7DQogICAgICB9DQogICAgICBsZWFmIGRpcmVj dGlvbnsNCiAgICAgICAgdHlwZSBkaXJlY3Rpb24tdHlwZTsNCiAgICAgICAgbWFuZGF0b3J5IHRy dWU7DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgIlRyYWZmaWMgc3RhdGlzdGljcyBk aXJlY3Rpb24gZm9yIHRoZSB0dW5uZWwuIjsNCiAgICAgIH0NCiAgICB9DQogIH0NCg0KdG8NCg0K ICAgICAgICBsaXN0IHN0YXRpc3RpYyB7DQogICAgICAgICAga2V5ICJ2bmktaWQgcGVlci1pcCBk aXJlY3Rpb24iOyAuLi4NCiAgICAgICAgICBhY3Rpb24gcmVzZXQtdm5pLXBlZXItc3RhdGlzdGlj IHsNCiAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICJDbGVhciB0cmFmZmlj IHN0YXRpc3RpY3MgYWJvdXQgdGhlIFZYTEFOIHR1bm5lbC4iOw0KICAgICAgICAgIH0NCg0KQmVz dCBSZWdhcmRzLA0KL2phbg0KDQoNCg0K From nobody Thu Sep 16 04:05:05 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C801E3A24AF for ; Thu, 16 Sep 2021 04:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F1sSqg40iHi for ; Thu, 16 Sep 2021 04:04:55 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E39E3A24AD for ; Thu, 16 Sep 2021 04:04:55 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id n7-20020a05600c3b8700b002f8ca941d89so4201172wms.2 for ; Thu, 16 Sep 2021 04:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=1otvaxn27Bjnf4u4gg8foLQCs3eM9oHm4RZUgHDMxWA=; b=m0qngtoyy7SUQMt/DgmlWRJgfFI4rqgAx+ksEupl9WUOWPHHX0yzEi5s7OFC8863Jn 2g9pg2aWlkWhDr7pW+SvMVSMVyIq5UEbKjzAK4Ywr0cRYlQ8WVJ31d9qzdMNH7gVOFFB oMpybAJfg3ghNbZdRNNsl0GRjsaIMoJifMx6t8d5qCjc6gM9aVFljJ8h0Ef2j4dr2v/r 8BYlWB9emcdr/JhEszQIjzE2vJQdoNf4NkYXWdv3Qde5jQWjvSez/O2JfiPi3dYnWeZS ABTRrcMcmwewIBJ8aVUuJaP/Q8Usa1kf4kLU8e7IUGwuU1Q6E+IUEN+Qvt1BN0SRmPOX SCiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=1otvaxn27Bjnf4u4gg8foLQCs3eM9oHm4RZUgHDMxWA=; b=JZWFk1sUKW2Kzg1/5v0wdeeAcyUtTnSel05Sln9SLxUqBDaeAvMfRQBT00ilz+APC0 6XiUBMZ2pQAlEW4fP66rwniFhMAeGpNVHJVrkWERbhcGtLI/+W85BoHFy01HzOYLsHqW 2bZEGf0N+pY/V3sIj/NgCMlwJpDXWuIEcEFfMdRqFnbw7eybdt8IzHEgKPF3YjyjzR5V zKsoLuoroyhRfcJHWFDACdVcALwNbpoYSDa+Dcdvznz2hOgS4US1VhhakOwZ9G4KKe73 JNodrG0mxha5q1/eVbRXOujAGxNglOyaavVVZPGr1/69S2Xt2C91Q5uRb0s8yUwssu+i FCcg== X-Gm-Message-State: AOAM5320mie3+PLMGrvLes9NdOY38Wcaci7olWtR1vv9HVBixYV0GasA UdBLJS5dgUjXeMvGXvpzXN7LAccp0rg= X-Google-Smtp-Source: ABdhPJwZzzT0eMra1MUjMoFqF2b6OqsJ4KlsRIKnfQ6Pvn0TyT4ESPpbscWevZYDzUiuf70G8kjzzQ== X-Received: by 2002:a05:600c:3b83:: with SMTP id n3mr4624891wms.50.1631790293350; Thu, 16 Sep 2021 04:04:53 -0700 (PDT) Received: from DESKTOPFLHJVQJ ([188.119.61.189]) by smtp.gmail.com with ESMTPSA id u29sm238718wru.34.2021.09.16.04.04.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Sep 2021 04:04:52 -0700 (PDT) From: "Mehmet Ersue" To: "'Jan Lindblad'" , References: <163177624716.21367.10437954922414983100@ietfa.amsl.com> In-Reply-To: <163177624716.21367.10437954922414983100@ietfa.amsl.com> Date: Thu, 16 Sep 2021 14:04:50 +0300 Message-ID: <00d201d7aaea$ac0e0c70$042a2550$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFyp63HCT8vykxLHHnYIUX52g+qU6xwhbPA Content-Language: de Archived-At: Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-nvo3-yang-cfg-05 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 11:05:01 -0000 Many Thanks Jan! Cheers, Mehmet > -----Original Message----- > From: yang-doctors On Behalf Of Jan > Lindblad via Datatracker > Sent: Thursday, September 16, 2021 10:11 AM > To: yang-doctors@ietf.org > Cc: last-call@ietf.org; nvo3@ietf.org; draft-ietf-nvo3-yang-cfg.all@ietf.org > Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-nvo3-yang- > cfg-05 > > Reviewer: Jan Lindblad > Review result: Not Ready > > This is the YANG Doctor review of draft-ietf-nvo3-yang-cfg. In my judgement > the draft is not ready for last call. This is not to say that there isn't plenty of > good work that has gone into this draft and YANG module, but since I have > been unable to compile it, due to unclear dependencies, the fundamental > requirements for performing a review aren't met. > > As soon as you import another module, you become dependent on that > module and inherit any problems it may have. If the modules you depend > upon are not stable enough, it may not be viable to perform a last call review. > As long as the modules you depend upon are not published, I would think > you cannot go through with publication of your own module either. > > There's always a bit of guesswork involved when a YANG module imports > unpublished modules. By looking in the IETF Git repository, under > "standards/ietf/RFC" as well as under "experimental/ietf-extracted-YANG- > modules", i.e. the section for automatically extracted YANG modules from > drafts, I was able to guess at which modules that are transitively referenced. > Based on this, I believe we will need to have stable versions of the following > modules before the draft-ietf-nvo3-yang-cfg can proceed. Experimental > modules are marked (*). > > iana-bfd-types.yang (*) > iana-if-type.yang > ietf-bfd-types.yang (*) > ietf-bgp-common-multiprotocol.yang (*) > ietf-bgp-common-structure.yang (*) > ietf-bgp-common.yang (*) > ietf-bgp-l3vpn.yang (*) > ietf-bgp-neighbor.yang (*) > ietf-bgp-peer-group.yang (*) > ietf-bgp-policy.yang (*) > ietf-bgp-rib-attributes.yang (*) > ietf-bgp-rib-tables.yang (*) > ietf-bgp-rib-types.yang (*) > ietf-bgp-rib.yang (*) > ietf-bgp-types.yang (*) > ietf-bgp.yang (*) > ietf-inet-types.yang > ietf-interfaces.yang > ietf-ip.yang > ietf-key-chain.yang > ietf-l2vpn.yang (*) > ietf-netconf-acm.yang > ietf-network-instance.yang > ietf-pseudowires.yang (*) > ietf-routing-policy.yang (*) > ietf-routing-types.yang > ietf-routing.yang > ietf-tcp-common.yang (*) > ietf-tcp.yang (*) > ietf-yang-schema-mount.yang > ietf-yang-types.yang > > Since I already did a first reading and found a few things, I'll list them here for > the WG's benefit rather than me holding them to myself. > > 1. YANG 1.1 > > The draft says "YANG [RFC6020] is a data definition language that was > introduced to". Since you are using yang-version 1.1, it would be more > appropriate with a reference to RFC 7950. > > 2. Identity equality tests > > There are a couple of places in the YANG that check that an interface is of > Nve type. Currently this is done using an equality test. While that can work, a > better and more future proof way is to use derived-from-or-self(). So change > > must "(/if:interfaces/if:interface[if:name=current()]/if:type='Nve')"; > > to > > must > "derived-from-or-self(/if:interfaces/if:interface[if:name=current()]/if:type , > 'Nve')"; > > 3. Behavioral constraints defined in English text > > list static-peer { > key "peer-ip"; > ... > leaf out-vni-id { > type uint32 { > range "1..16777215"; > } > description > "The ID of VNI for outbound. Do not support separate deletion."; > } > > I'm not completely clear as to the "Do not support separate deletion" is > supposed to mean. If every static-peer must have an out-vni-id, it should be > marked mandatory. If this is supposed to mean that an out-vni-id may be > added, but not deleted, that violates one of the basic principles in YANG. The > validity of a configuration should not depend on anything else than the > configuration itself. In particular, the validity of an upcoming configuration > should not depend on the prior configuration. > > If you don't want out-vni-id to be mandatory, but also don't want people to > be able to delete it without deleting the static-peer, I would recommend > making out-vni-id part of the key for static-peer, and ensure it can take a > value that essentially means none. For example like this: > > list static-peer { > key "peer-ip out-vni-id"; > ... > leaf out-vni-id { > type union { > type enumeration { > enum none; > } > type uint32 { > range "1..16777215"; > } > } > description > "The ID of VNI for outbound. Do not support separate deletion."; > } > > 4. Repetition of config false > > In many places within the module, there are config false statements inside > elements that are already config false. While this is perfectly legal, it is > superfluous. Once a container or other element is marked config false, > everything below that point will always be config false. The IETF convention is > to not write config false in more places than necessary. > > container peers { > config false; <--- Everything within/below container peers is now > config false description > "Operational data of remote NVE address in a VNI."; > list peer { > key "vni-id source-ip peer-ip"; > config false; <--- Superfluous > > 5. Weak data format > > leaf up-time { > type string { > length "1..10"; > } > config false; > description > "The continuous time as NVO3 tunnel is reachable."; > } > > YANG strings are great when used for names that the client can choose > arbitrarily. They are not so great when they encode information that is not a > name, unless there is a detailed description of the encoding. Since the > encoding of the up-time leaf is not specified, the contents will not be > interoperable. Either remove this leaf, or better, describe the format of the > contents so that it can be decoded. Changing the type from string to some > time type might be a good option. > > 6. Identities conventionally start with lowercase letters > > By convention, all identities defined by IETF start with a lower case letter. > Citing the principle of least surprise, I would recommend changing > > identity Nve { > > to > > identity nve { > > 7. RPC or Action > > In YANG 1.1, rpc:s that pertain to a certain element in the data tree can be > modeled as actions instead. This often leads to a more coherent model with > less text. In this module, that seems to be the case for the two rpc:s defined. > Therefore I would suggest changing > > rpc reset-vni-peer-statistic { > description > "Clear traffic statistics about the VXLAN tunnel."; > input { > leaf vni-id { > type uint32 { > range "1..16777215"; > } > mandatory true; > description > "The ID of the VNI."; > } > leaf peer-ip { > type inet:ip-address-no-zone; > mandatory true; > description > "The address of the remote NVE."; > } > leaf direction{ > type direction-type; > mandatory true; > description > "Traffic statistics direction for the tunnel."; > } > } > } > > to > > list statistic { > key "vni-id peer-ip direction"; ... > action reset-vni-peer-statistic { > description > "Clear traffic statistics about the VXLAN tunnel."; > } > > Best Regards, > /jan > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Thu Sep 16 04:14:44 2021 Return-Path: X-Original-To: yang-doctors@ietf.org Delivered-To: yang-doctors@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D66E53A24F9; Thu, 16 Sep 2021 04:14:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Martin_Bj=C3=B6rklund_via_Datatracker?= To: Cc: draft-ietf-sfc-proof-of-transit.all@ietf.org, last-call@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163179088168.23735.14264777118398601057@ietfa.amsl.com> Reply-To: =?utf-8?q?Martin_Bj=C3=B6rklund?= Date: Thu, 16 Sep 2021 04:14:41 -0700 Archived-At: Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-sfc-proof-of-transit-08 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 11:14:42 -0000 Reviewer: Martin Björklund Review result: Ready with Nits Hi, This is my YANG doctor review of draft-ietf-sfc-proof-of-transit-08. The review is focused on the YANG module in the draft. In general, the draft and YANG module are well-written. o pyang --ietf complains that the module description doesn't contain the (correct) IETF Trust Copyright statement. The problem is probably due to an copy&paste error; some text is duplicated. I suggest you also keep the normal line breaks to make the text easier to read: description "This module contains a collection of YANG definitions for proof of transit configuration parameters. The model is meant for proof of transit and is targeted for communicating the POT-Profile between a controller and nodes participating in proof of transit. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; o It is not clear to me how the profile sets are supposed to be used. Perhaps the intention is one set per packet flow? If so, how is the set tied to a flow? o The list "pot-profile-list" is defined as ordered-by user. Why? How is the order relevant? o In the profile list there is a leaf "status" of type "boolean". It is not immediately clear what "status = false" means (but the meaning of the values are explained in the text). I suggest that the leaf is renamed to "active", or "enabled". But see below! o The current model allows a list where both entries have "status" true. Perhaps a simpler solution could be to remove the "status" leaf, and instead have a leaf in the profile set that refers to the active entry: leaf active-profile { type leafref { path '../pot-profile-list/pot-profile-index'; } } o It is not clear why you have the two groupings in the model. Do you expect other models to reuse these groupings? If so, you should probably add some descriptions that explain how they are to be reused. If not, perhaps remove the groupings. The model is quite simple anyway. o The choice of prefixes for some of the names seems a bit random. Some are called 'pot-profile-xxx' and some just 'xxx'. In YANG we tend to avoid repeating prefixes unless it is necessary. So perhaps, instead of: module: ietf-pot-profile +--rw pot-profiles +--rw pot-profile-set* [pot-profile-name] +--rw pot-profile-name string +--rw pot-profile-list* [pot-profile-index] +--rw pot-profile-index profile-index-range you could have: module: ietf-pot-profile +--rw pot-profiles +--rw profile-set* [name] +--rw name string +--rw profile-list* [index] +--rw index profile-index-range Also I would probably name the list 'profile-list' just 'profile', to align with other models. o Minor: I suggest you run the module through: pyang -f yang --yang-line-length 68 --yang-canonical MODULE in order to fix some inconsistensies in the formatting of the text. This will make the RFC editor's job easier. Also, I suggest you remove the comments you have; I don't think they add anything. o It would be helpful with an example of the XML or JSON data for the example in section 3.3. Perhaps add that as an appendix? /martin From nobody Thu Sep 23 09:56:28 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4A93A132B for ; Thu, 23 Sep 2021 09:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHpQ5Q666Q1S for ; Thu, 23 Sep 2021 09:56:23 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E9C3A1327 for ; Thu, 23 Sep 2021 09:56:23 -0700 (PDT) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HFh8058yMz67PN6; Fri, 24 Sep 2021 00:53:52 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 23 Sep 2021 18:56:19 +0200 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2308.008; Thu, 23 Sep 2021 18:56:19 +0200 From: Italo Busi To: "yang-doctors@ietf.org" CC: Zhenghaomian , 'Aihua Guo' Thread-Topic: Question about absolute and relative paths in YANG Thread-Index: Adewm28iyulrueZ7Rp+MN5B2Vq4mbA== Date: Thu, 23 Sep 2021 16:56:19 +0000 Message-ID: <72a905a18a334460864bfc95be778150@huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.81.55] Content-Type: multipart/alternative; boundary="_000_72a905a18a334460864bfc95be778150huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [yang-doctors] Question about absolute and relative paths in YANG X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2021 16:56:26 -0000 --_000_72a905a18a334460864bfc95be778150huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi YANG doctors, I am quite active within the IETF CCAMP and TEAS WGs on YANG models for opt= ical transport networks We are having some discussions about the use of absolute and relative paths= in some of the drafts we are developing for IETF I have been told that YANG doctors prefer absolute paths to relative paths We think it makes a lot of sense to use absolute paths whenever possible bu= t there are some cases where we are not sure whether and how we could use a= bsolute paths We would appreciate your opinions and suggestions about how to address thes= e cases One case could be one of the augment statements defined in RFC8795 (TE Topo= logy model): augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:label-restrictions/tet:label-restriction" { when "../../../../../../nw:network-types/tet:te-topology/" + "example-topology" { The intention is to say that this augmentation applies only to a specific n= etwork-types of this network instance. Using an absolute path the code coul= d become: augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:label-restrictions/tet:label-restriction" { when "/nw:networks/nw:network[nw:network-id=3Dcurrent()../../../../../../nw= :network-id]/" + "nw:network-types/tet:te-topology/" + "example-topology" { It seems that using the absolute path is moving the issue on requiring a re= lative path to get the value of the network-id of this network Is there an alternative solution to avoid using relative path in this case? Another case we have considered is the definition of a grouping with a leaf= that references another node within the same network. In this case, using = a relative path or an absolution path embedding a relative path required to= get the network-id of this network, would make quite difficult to re-use t= his grouping in multiple places within the YANG tree One work-around could be to use the refine statement, such as: grouping node-reference { leaf network-ref { type leafref { path "/nw:networks/nw:network/nw:network-id" } } leaf node-ref { type leafref { path "deref(../network-ref)/../nw:node/nw:nw:node-id" } } } augment "/nw:networks/nw:network/nw:node/tet:te/" + "tet:te-node-attributes/tet:connectivity-matrices/" + "tet:label-restrictions/tet:label-restriction" { uses node-reference { refine network-ref { default current()/../../../../../../network-id; must current() =3D current()/../../../../../../network-id; } } This work-around seems a bit weird but at least it should the need to use r= elative paths within the grouping but keep the requirement to use the relat= ive paths in the refine statements Is there a better solution to avoid using relative path within the grouping= ? Thanks in advance for your help Italo --_000_72a905a18a334460864bfc95be778150huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi YANG doctors,

 

I am quite active within the IETF CCAMP and TEAS WGs= on YANG models for optical transport networks

 

We are having some discussions about the use of abso= lute and relative paths in some of the drafts we are developing for IETF

 

I have been told that YANG doctors prefer absolute p= aths to relative paths

 

We think it makes a lot of sense to use absolute pat= hs whenever possible but there are some cases where we are not sure whether= and how we could use absolute paths

 

We would appreciate your opinions and suggestions ab= out how to address these cases

 

One case could be one of the augment statements defi= ned in RFC8795 (TE Topology model):

 

=   augment "/nw:networks/nw:network/nw:node/tet:te/"

=         + "tet:te-node-attribut= es/tet:connectivity-matrices/"

=         + "tet:label-restrictio= ns/tet:label-restriction" {

=     when "../../../../../../nw:network-types/tet:te-top= ology/"

=        + "example-topology" {

 

The intention is to say that this augmentation appli= es only to a specific network-types of this network instance. Using an abso= lute path the code could become:

 

=   augment "/nw:networks/nw:network/nw:node/tet:te/"

=         + "tet:te-node-attribut= es/tet:connectivity-matrices/"

=         + "tet:label-restrictio= ns/tet:label-restriction" {

when "/nw:networks/nw:network[nw:network-= id=3Dcurrent()../../../../../../nw:network-id]/"

   + "nw:network-types/tet:= te-topology/"

=        + "example-topology" {

 

It seems that using the absolute path is moving the = issue on requiring a relative path to get the value of the network-id of th= is network

 

Is there an alternative solution to avoid using rela= tive path in this case?

 

Another case we have considered is the definition of= a grouping with a leaf that references another node within the same networ= k. In this case, using a relative path or an absolution path embedding a re= lative path required to get the network-id of this network, would make quite difficult to re-use this grouping in mul= tiple places within the YANG tree

 

One work-around could be to use the refine statement= , such as:

 

grouping node-reference {

  leaf network-ref {

    type leafref {

      path "/nw:= networks/nw:network/nw:network-id"

    }

  }

 

  leaf node-ref {

    type leafref {

      path "dere= f(../network-ref)/../nw:node/nw:nw:node-id"

    }

  }

}

 

augment "/nw:networks/nw:network/nw:node/= tet:te/"

      + "tet= :te-node-attributes/tet:connectivity-matrices/"

      + "tet= :label-restrictions/tet:label-restriction" {

  uses node-reference {=

    refine network-ref {

      default current= ()/../../../../../../network-id;

      must current() = =3D current()/../../../../../../network-id;

   }

  }

 

This work-around seems a bit weird but at least it s= hould the need to use relative paths within the grouping but keep the requi= rement to use the relative paths in the refine statements

 

Is there a better solution to avoid using relative p= ath within the grouping?

 

Thanks in advance for your help

 

Italo

 

--_000_72a905a18a334460864bfc95be778150huaweicom_-- From nobody Wed Sep 29 20:09:24 2021 Return-Path: X-Original-To: yang-doctors@ietf.org Delivered-To: yang-doctors@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5333A0FCC; Wed, 29 Sep 2021 20:08:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Reshad Rahman via Datatracker To: Cc: draft-ietf-pim-igmp-mld-snooping-yang.all@ietf.org, last-call@ietf.org, pim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163297133399.7456.4753723321157921343@ietfa.amsl.com> Reply-To: Reshad Rahman Date: Wed, 29 Sep 2021 20:08:54 -0700 Archived-At: Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-pim-igmp-mld-snooping-yang-19 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2021 03:08:55 -0000 Reviewer: Reshad Rahman Review result: Ready with Nits This is my 3rd review of the document. While I have focused on changes done since my last review, some comments apply to parts of the YANG model which hasn't changed recently. Main comments ============= - Feature immediate-leave mentions “fast leave” in the description. RFC3376 mentions fast leave but not immediate leave. Should the feature, and the leaf node which depends on it, be renamed to fast-leave? - Leaf send-query, description says that it cooperates with parameter querier-source. I believe there should be enforcement that send-query can only be set if querier-source is also set (must statement)? Also querier-source in IGMP mentions VLAN, no such mention in MLD, is that correct? Questions ======== - Feature static-l2-multicast-group. The description mentions L2 multicast static-group. Is it a static multicast group or a multicast static group? I believe it’s the former and the description should be changed? - igmp-version and mld-version are both uint8 with a range (1..3 and 1..2). If we get a new version someday, the range will have to be changed. I don’t recall if this was brought up before. Another option is to use an identity. I realize we don’t spin out a new version frequently so this may not be an issue. And probably with a new version other changes would be needed anyway… - Last-reporter is present under the group and also under each source entry. Is the one under the group the last host from all sources? - Leaf node require-router-alert. What happens if it’s set to true and the IP hdr does not contain RA? Consider updating description and/or adding a reference. Minor ===== - Typo in bridge-router-interface: dynamicly. - No need to mention the leaf name in description, e.g. in l2-service-type - Leaf “host-address”, rename to “address” since the list is called host (no need to duplicate host). Regards, Reshad. From nobody Wed Sep 29 20:25:30 2021 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36523A101F; Wed, 29 Sep 2021 20:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwpO0DQ0B5pN; Wed, 29 Sep 2021 20:25:17 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70054.outbound.protection.outlook.com [40.107.7.54]) (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 0176D3A1019; Wed, 29 Sep 2021 20:25:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dO7ywy1E0geTGdFqwOCHewhXR+Sm5N0+rSVel+cP/YLZVq6169hAVAKH8KCTIAYo05MNa3yV12vFUhFMoA0sDhX6qjZbAUOmwDh5ZfTLVxgt8doIl9TczYK62BSduuOKqVSc+nopISEq6GnCTfyvPiXuMzKenIGT/cjBf/GMyOLFf3Gyde4ywQqyULngNEZJvVOR0Gz+Ke+au5/pYGcDdXbiYbNxMJSCW0Rje/fMyZGbh4FsKJ1++x16GUQykv68La57Q5eQ3k3e7Jj4ustD6Hb9/OzgnBuVdSAirxEYa5BOonpi1xiNeHfACSZTshmkpBRFUf1tzvr7gyyIb9IKMg== 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=MpaaYsemElZRyu8ZyOGoT22MFPmyUrkFtbz2dQvtl9Q=; b=YfXEWKLteLAyyJxTo/h0o9/0/uqyyjLa6gS+EJqvJa6SvRTN+XU1he0w+9jgfg05oorBrS2L54Kopuezg5oGYNoovjQjucUUDfwuJWVcXuTmyllPStw2Em7Lw0suVXvAzfApxjbw5BArBjlUOm/i/jk7wpdoqPo8svfuNKjSjm3IUD/kHPrOtK9e7fUb75e3oLK6nshQBKd4HAEtafV/J9VYcAcD4sDtzwGRiX4T21igpz/r3XrCNurUY1i3j5JUAMgS/4AwUsWHeaX5zhaTu7VbMCbClV59qyizYDGtgj4nVGeBgNfrGQlVA+0IfGK1X+v63JCEWXxOcChjHoYZbA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MpaaYsemElZRyu8ZyOGoT22MFPmyUrkFtbz2dQvtl9Q=; b=S3R1hzeIUSQYJ2X4AsrjZaR6Ghr/PQBAM2w8IXkA/gXP/uHn8vS2/ttbu0r3RnDiwgDrws1ivd8aTEwiOMpFd7/p60mm3q4wQxVhbyBUdkk/AbOREGBGhyKy+Franr8gBDD9opvNQbBg71XmpCzRmPfI3X28lyZtkd3MZqnIpTs= Received: from DB6PR07MB4438.eurprd07.prod.outlook.com (2603:10a6:6:52::13) by DB7PR07MB6057.eurprd07.prod.outlook.com (2603:10a6:10:8e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.9; Thu, 30 Sep 2021 03:25:09 +0000 Received: from DB6PR07MB4438.eurprd07.prod.outlook.com ([fe80::3155:841d:12bb:362f]) by DB6PR07MB4438.eurprd07.prod.outlook.com ([fe80::3155:841d:12bb:362f%5]) with mapi id 15.20.4566.014; Thu, 30 Sep 2021 03:25:09 +0000 From: Hongji Zhao To: Reshad Rahman , "yang-doctors@ietf.org" CC: "draft-ietf-pim-igmp-mld-snooping-yang.all@ietf.org" , "last-call@ietf.org" , "pim@ietf.org" Thread-Topic: Yangdoctors last call review of draft-ietf-pim-igmp-mld-snooping-yang-19 Thread-Index: AQHXtaiGPQpz2dduN0ezKWEbZwsye6u76c3g Date: Thu, 30 Sep 2021 03:25:08 +0000 Message-ID: References: <163297133399.7456.4753723321157921343@ietfa.amsl.com> In-Reply-To: <163297133399.7456.4753723321157921343@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yahoo.com; dkim=none (message not signed) header.d=none;yahoo.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d641f7c-2307-4ffd-429c-08d983c1e7d1 x-ms-traffictypediagnostic: DB7PR07MB6057: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ucmr8de525wToJwKJvOQsusSayYokb8e3CiawdCY8RaBEQboimyh9fGhbHBu5I1wQXIX1xJ1uOW6oTdZ+sXFWc26/aL5ZQhC6oW3mTepemdouOouK7Jmo6vGOys9WsM9GXmXFBxFrBOFl7nXgEU2Y/GFXg0w6mYzL35k53jkXX/H6oVNmeeAXYxgTrZyB3U02OoNNEUOlRN8SJp+eJNw5jiht2LyVqpfWwYSirwCMjsnIWMWLf8T2KTcbM0TWiJEQvqA1//liJ+zK9/ufs2G8y60UHCYO0cNyf76GUKJiCa41dYoGWP6cG+FZuhsZhLr+rPIvd6ZeYmTIMmImNVlykxJP6BsoWoB9Sl9YOpdzfpeZxmXcUe15Gl0nRG4CPzYlDQgZO88Fty1/0lUFCHUaeO/yR9iQlOrTwCnKWLvuYpGot5bDPDx5RgB71+vnxUBFsSiHyIhY1GBJAzUIwO4bTsTHEWMHn74aL5ldv1EqK7ZQw6DexYLK9Yvx926WsS/e5Oc+zsTQlcOKgyG5rvcGy+M1ZkX+eTPehJpHMftDLAinSj2j1srQK7ZDDrfC0NLmz6Mfdpmpx+gFP2ts1MBbI4kc6v1sfz5F52WJqTrm9opRHzc9JGsb2MJM33PIYOATZS+LuYoM9zq18EssC2zp5ExJWjyrYAQ35VHQI+saFEU+f5hvnsM3U/VaLx/yKYweNHGXa1vZu2j1lTD+dSjRA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR07MB4438.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(83380400001)(76116006)(66574015)(54906003)(52536014)(66476007)(66556008)(64756008)(66446008)(110136005)(4326008)(5660300002)(316002)(66946007)(26005)(38070700005)(53546011)(55016002)(71200400001)(6506007)(2906002)(8936002)(33656002)(86362001)(8676002)(186003)(38100700002)(7696005)(9686003)(508600001)(122000001)(44832011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?U2lqaG5QRGt0MjE4d1BNNWZOYUxNUmtDNXJyM3FBY090TjVkZ2ZFZ3F3eTNj?= =?utf-8?B?ZzF4VmhrV3BkRzNzY1pBbGZoaTVxTWhsMFJrS0tQYldDU1JuSTU3WjAyczkz?= =?utf-8?B?UEZUUkJweGR3RHduSzN0bnBBeWJ4NE9FYW0wdFlwN2cwNjZhWjJIMnBBL1lD?= =?utf-8?B?dWszNVpxa3Z0amNGR0VyZncrc2p4d2FkWHBVUnBuR0tSYmllRlhSenYvVlZu?= =?utf-8?B?SDNXTXA2Rm9va1ZzcThBTFgwTGR4L3BYYzRwMDZ1TlQ5Nmw1Y1VOc20zZklj?= =?utf-8?B?bGd4bTZHamJhSy9KakZHNWVxZjJKbUFwZ1hyMmVvcXZGVDZ6UUpwWWVLTUM2?= =?utf-8?B?SUc4Mms5MG96S09VTzN3V0ZOT2hpTnUxdVpRRlZvU21aSjZ5VFlFOEtCL1N5?= =?utf-8?B?ZmJIajE5SUdZMDg2ZjFXajN0NkEzRnhoM2IxeXBJTW9ISVQreHBTMm1PNUcx?= =?utf-8?B?RnRjcUdGb0dNVEp6bzVHV0lIMnBPeVJUbEVTcUFrczFPUlhqZy83VUVMVlA0?= =?utf-8?B?SFRCS2VBeVVCNjRTdTBOUVVFeTNmSk9qYVowYkdYTU9lK1BReGVZUU0yWjNQ?= =?utf-8?B?QzBWN3o2MlU0bHRDdUsyMUFneExXZjQyN3ZwUmUyTWtQM2FFemxaQ1VIMzdU?= =?utf-8?B?ZldCR2RkZmNVMStPYkh0Q25qVDFJQ2ptbExsYURWWU56aTg5R09KbThSeVpJ?= =?utf-8?B?RURaWjRXdnNwTlJjTlMvRkJpcXNyNCtpZmc0MHBCUWhxckJOZ2tmWlZqV3hY?= =?utf-8?B?cHFXVWczaUtQK21sZk5ESE5wY3U4VTNqc1hteVpNMFcwMGdQZVdSaHcxQXlQ?= =?utf-8?B?cDBVSC80ZFV6bWE0alQyZlRtQXBrTVFiTjd6ekg5VlNMMDVwQys1dUNDWDc1?= =?utf-8?B?M1ZiZTB0ZDhMejhUMlpVRGIyaVpyK3Buakppa0JMYmd4WXVSeU12VGhKVWVH?= =?utf-8?B?RGJwT2dWSmdsZHI1VThYK2llOE9hdVozb3NxQWRkQS9lV2dvQlpYRk9PWC9y?= =?utf-8?B?V1Zld3dFUzNldFlpY2FBc0ZKMEtRUXhCeS9IUmtSMnZwU1lRZ1dKalZJUktx?= =?utf-8?B?Z3R0MWFnVklUcGV6UUNQS3JnV1pwcHpRVkM1aVV4Sk9LT0RrcHBGQW43M01W?= =?utf-8?B?Rng4OUk0VmZBS01WalhtMW13SkU2SnBHK3puZW1hS1hEVmhOQUxjNnZtekF2?= =?utf-8?B?L1RMbnJzZHNoSjBHU3pmVEgwaHg0RTd0cStxY1FUb29XUnpkWlpNejRuaDQ1?= =?utf-8?B?cngwN2FUcDdUTlJFTHFWZEp5aTF6RmVoS0dSN2JVTkdFL2xid0FVT3RnNytY?= =?utf-8?B?NW83dDJUZ1JtSzlkKzV1WUJVb3YvMGFjeEhueVZBeDl1KzRwSWJVRjJCMWgv?= =?utf-8?B?aXVhQnBkcTRRY0kxSXZZYXFuU2dHTUVUZTZpamczMyszT1Q0QTV1Zm1OQ1pL?= =?utf-8?B?Um54dnpVcmNkL25ob3dtcGJ1Q0pRam5nRFdBRFRiOEFodUdyRUprYzRzdGx2?= =?utf-8?B?WGZLdDJSaFdabGR0b2tGbWpkZTdGTlRURU1LdDQ4Mjk5QUxQUkhmUlJibGRM?= =?utf-8?B?UFpDakJMVnkwVmhPSWZ6Z1RjZnNnYkVuNm1aVXJKd2RUWEExdzV5UHJuSVRp?= =?utf-8?B?eXRRNElJb3V3b1cwSG0yME8rSjFmWklMajVKYkZIMzA2R08yYkx3RjNqZFh5?= =?utf-8?B?U01SQkc3R0ZSd3VtbmNISnYzNURTd3NTZjdhZlozd3RzR2VsN05iSzJCK2Jz?= =?utf-8?Q?BO+srOlUVegJtZGEcho880gNs13nTvbbeXngAqV?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB6PR07MB4438.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d641f7c-2307-4ffd-429c-08d983c1e7d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2021 03:25:08.9044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rAuszXlG+1KWqvR3RHG/uiPC08Ied9XBQLTHe5zcyiNOMGdRCIO/5mQ99h+urKOWoez1Rr+8+Rxm/EPhOcZeCSVL3ghrhxzDuvTC4LdCNLM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6057 Archived-At: Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-pim-igmp-mld-snooping-yang-19 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2021 03:25:22 -0000 SGkgUmVzaGFkLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMuIFdlIHdpbGwgZGlz Y3VzcyBhbmQgYWRkcmVzcyB0aGVtIEFTQVAuDQoNCkJSL0hvbmdqaQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmVzaGFkIFJhaG1hbiB2aWEgRGF0YXRyYWNrZXIgPG5vcmVw bHlAaWV0Zi5vcmc+IA0KU2VudDogMjAyMeW5tDnmnIgzMOaXpSAxMTowOQ0KVG86IHlhbmctZG9j dG9yc0BpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYtcGltLWlnbXAtbWxkLXNub29waW5nLXlhbmcu YWxsQGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmc7IHBpbUBpZXRmLm9yZw0KU3ViamVjdDog WWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXBpbS1pZ21wLW1sZC1z bm9vcGluZy15YW5nLTE5DQoNClJldmlld2VyOiBSZXNoYWQgUmFobWFuDQpSZXZpZXcgcmVzdWx0 OiBSZWFkeSB3aXRoIE5pdHMNCg0KVGhpcyBpcyBteSAzcmQgcmV2aWV3IG9mIHRoZSBkb2N1bWVu dC4gV2hpbGUgSSBoYXZlIGZvY3VzZWQgb24gY2hhbmdlcyBkb25lIHNpbmNlIG15IGxhc3QgcmV2 aWV3LCBzb21lIGNvbW1lbnRzIGFwcGx5IHRvIHBhcnRzIG9mIHRoZSBZQU5HIG1vZGVsIHdoaWNo IGhhc24ndCBjaGFuZ2VkIHJlY2VudGx5Lg0KDQpNYWluIGNvbW1lbnRzDQo9PT09PT09PT09PT09 DQoNCi0gRmVhdHVyZSBpbW1lZGlhdGUtbGVhdmUgbWVudGlvbnMg4oCcZmFzdCBsZWF2ZeKAnSBp biB0aGUgZGVzY3JpcHRpb24uIFJGQzMzNzYgbWVudGlvbnMgZmFzdCBsZWF2ZSBidXQgbm90IGlt bWVkaWF0ZSBsZWF2ZS4gU2hvdWxkIHRoZSBmZWF0dXJlLCBhbmQgdGhlIGxlYWYgbm9kZSB3aGlj aCBkZXBlbmRzIG9uIGl0LCBiZSByZW5hbWVkIHRvIGZhc3QtbGVhdmU/DQoNCi0gTGVhZiBzZW5k LXF1ZXJ5LCBkZXNjcmlwdGlvbiBzYXlzIHRoYXQgaXQgY29vcGVyYXRlcyB3aXRoIHBhcmFtZXRl ciBxdWVyaWVyLXNvdXJjZS4gSSBiZWxpZXZlIHRoZXJlIHNob3VsZCBiZSBlbmZvcmNlbWVudCB0 aGF0IHNlbmQtcXVlcnkgY2FuIG9ubHkgYmUgc2V0IGlmIHF1ZXJpZXItc291cmNlIGlzIGFsc28g c2V0IChtdXN0IHN0YXRlbWVudCk/IEFsc28gcXVlcmllci1zb3VyY2UgaW4gSUdNUCBtZW50aW9u cyBWTEFOLCBubyBzdWNoIG1lbnRpb24gaW4gTUxELCBpcyB0aGF0IGNvcnJlY3Q/DQoNClF1ZXN0 aW9ucw0KPT09PT09PT0NCg0KLSBGZWF0dXJlIHN0YXRpYy1sMi1tdWx0aWNhc3QtZ3JvdXAuIFRo ZSBkZXNjcmlwdGlvbiBtZW50aW9ucyBMMiBtdWx0aWNhc3Qgc3RhdGljLWdyb3VwLiBJcyBpdCBh IHN0YXRpYyBtdWx0aWNhc3QgZ3JvdXAgb3IgYSBtdWx0aWNhc3Qgc3RhdGljIGdyb3VwPyBJIGJl bGlldmUgaXTigJlzIHRoZSBmb3JtZXIgYW5kIHRoZSBkZXNjcmlwdGlvbiBzaG91bGQgYmUgY2hh bmdlZD8NCg0KLSBpZ21wLXZlcnNpb24gYW5kIG1sZC12ZXJzaW9uIGFyZSBib3RoIHVpbnQ4IHdp dGggYSByYW5nZSAoMS4uMyBhbmQgMS4uMikuIElmIHdlIGdldCBhIG5ldyB2ZXJzaW9uIHNvbWVk YXksIHRoZSByYW5nZSB3aWxsIGhhdmUgdG8gYmUgY2hhbmdlZC4gSSBkb27igJl0IHJlY2FsbCBp ZiB0aGlzIHdhcyBicm91Z2h0IHVwIGJlZm9yZS4gQW5vdGhlciBvcHRpb24gaXMgdG8gdXNlIGFu IGlkZW50aXR5LiBJIHJlYWxpemUgd2UgZG9u4oCZdCBzcGluIG91dCBhIG5ldyB2ZXJzaW9uIGZy ZXF1ZW50bHkgc28gdGhpcyBtYXkgbm90IGJlIGFuIGlzc3VlLiBBbmQgcHJvYmFibHkgd2l0aCBh IG5ldyB2ZXJzaW9uIG90aGVyIGNoYW5nZXMgd291bGQgYmUgbmVlZGVkIGFueXdheeKApg0KDQot IExhc3QtcmVwb3J0ZXIgaXMgcHJlc2VudCB1bmRlciB0aGUgZ3JvdXAgYW5kIGFsc28gdW5kZXIg ZWFjaCBzb3VyY2UgZW50cnkuIElzIHRoZSBvbmUgdW5kZXIgdGhlIGdyb3VwIHRoZSBsYXN0IGhv c3QgZnJvbSBhbGwgc291cmNlcz8NCg0KLSBMZWFmIG5vZGUgcmVxdWlyZS1yb3V0ZXItYWxlcnQu IFdoYXQgaGFwcGVucyBpZiBpdOKAmXMgc2V0IHRvIHRydWUgYW5kIHRoZSBJUCBoZHIgZG9lcyBu b3QgY29udGFpbiBSQT8gQ29uc2lkZXIgdXBkYXRpbmcgZGVzY3JpcHRpb24gYW5kL29yIGFkZGlu ZyBhIHJlZmVyZW5jZS4NCg0KTWlub3INCj09PT09DQoNCi0gVHlwbyBpbiBicmlkZ2Utcm91dGVy LWludGVyZmFjZTogZHluYW1pY2x5Lg0KDQotIE5vIG5lZWQgdG8gbWVudGlvbiB0aGUgbGVhZiBu YW1lIGluIGRlc2NyaXB0aW9uLCBlLmcuIGluIGwyLXNlcnZpY2UtdHlwZQ0KDQotIExlYWYg4oCc aG9zdC1hZGRyZXNz4oCdLCByZW5hbWUgdG8g4oCcYWRkcmVzc+KAnSBzaW5jZSB0aGUgbGlzdCBp cyBjYWxsZWQgaG9zdCAobm8gbmVlZCB0byBkdXBsaWNhdGUgaG9zdCkuDQoNClJlZ2FyZHMsDQpS ZXNoYWQuDQoNCg==