[OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 09 September 2022 10:42 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47466C157B59; Fri, 9 Sep 2022 03:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.605
X-Spam-Level:
X-Spam-Status: No, score=-9.605 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=nJbedhHV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ttx+Ydbf
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU8MJ2PMOugJ; Fri, 9 Sep 2022 03:42:54 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F2BC157B45; Fri, 9 Sep 2022 03:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15467; q=dns/txt; s=iport; t=1662720174; x=1663929774; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=S/eSAFn7iqf2wfODQJAPD3ySHCL9MyYghoGQHUs7GXI=; b=nJbedhHV9EYdwpovkNzFvZVXdsnKGsX+OeBNRwch8FGrLaRuHYuWdN7q hRdn1mlAfv/cXbbEvlDHPlLMAtPnkuYVtomN6ALyIC6QUqhos7RQ7Ro9K J1LhKkql/Qe/5PeIhPK73NRMjZ5DrfsupRdEfZAk4+z/N+8v0M3GTKcaU c=;
IronPort-PHdr: A9a23:IKr+QRKR1Rv4d80QG9mcuWEyDhhOgF28FgIW659yjbVIf+zj+pn5J0XQ6L1ri0OBRoTU7f9Iyo+0+6DtUGAN+9CN5XYFdpEfWxoMk85DmQsmDYaMAlH6K/i/aSs8EYxCWVZp8mv9P1JSHZP1ZkbZpTu56jtBcig=
IronPort-Data: A9a23:P0J646JCbuVnLPWvFE+RGJclxSXFcZb7ZxGr2PjKsXjdYENS0zVUnDQYC2qCa63cNjH8cttwOYiz80JSscOBzYdmG1Qd+CA2RRqmiyZq6fd1j6vI0qj7wvTrFCqL1O1DLIiZRCwIZiWE/E31b+G/9SAUOZygH9IQNsaVYkideic8IMsRoUoLd98R2uaEs/Dga+++kYuaT/nkBbOQ82Uc3lT4RE60gEgHUPza4Fv0t7GlDBxBlAe2e3I9VPrzKUwtRkYUTLW4HsbiLwrC5Li9+mWc9BA3B5b/1L36aUYNBLXVOGBiiFIPBPPk2UYE/3d0i/1mXBYfQR8/ZzGhhc9wzMlKs7S7SBwiOevHn+F1vxxwSnkhYPMdoe6YeRBTtuTWlSUqaUDExO11BV45FYwV5ugxBntBndQUMjkDclWCiv64hbWjUeBziYEyJc/keZ0HvDR7wCvHDP0rBIjGBazO4fdZ0Ss+wMdUEp7ji2AxAdZ0RB3EZxsKMVANBddk2uypnXL4NTZfrTqoSWMMyzC75GRMPHLFa7I5ouC3ePg=
IronPort-HdrOrdr: A9a23:loiaha682MwUnYkmPAPXwXCBI+orL9Y04lQ7vn2ZFiY6TiXIra+TdaoguSMc0AxhIk3Jmbi7Sc29qADnhONICO4qTP2ftWjdySCVxeRZjLcKrAeQYxEWmtQtt5uIEJIOReEYb2IK9voSiTPQe71Lrbn3k5xA7t2uqEuFODsaEp2ImD0JbDpzfHcGITVuNN4cLt6x98BHrz2vdTA8dcKgHEQIWODFupniiI/mSQRuPW9q1CC+yReTrJLqGRmR2RkTFxlVx605zGTDmwvloo2+rvCAzAPG3WO71eUYpDKh8KoMOCW/sLlUFtzesHfqWG2nYczBgNkBmpDv1L/tqqiIn/5vBbU215qbRBDInfKk4Xie7N9p0Q6k9bdd6kGT+PAQg1kBeox8bMtiA2Xkwltls9dm3K1R2WWF85JREBPbhSz4o8PFThdwiyOP0AwfeMMo/ghiuLElGchshJ1a+FkQHIYLHSr85oxiGO5yDNvE7PITdV+BdXjWsmRm3dTpBx0Ib1+7a1lHvtbQ3yldnXh/wUddzMsDnm0Y/JZ4T5Vf/ezLPqlhibkLRM4LaqB2AvsHXKKMeyXwaAOJNHjXLUXsFakBNX6Io5nr4K8t7OXvY5AMxItaouW1bLqZjx9BR6vDM7z84HQQyGG9fIyUZ0Wc9v1j
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DCBwB2bIJi/4cNJK1aHgEBCxIMQIFEC4FSUgd1WjlDiBoDhTGFCYMCgRaPNIpxgSyBJQNUCwEBAQ0BAUIEAQGFAgKFPgIlNQgOAQIEAQEBEgEBBQEBAQIBBwSBCROFaAEMhkUWFRMGAQEwBwERARoSARFCFw8BBA4NGoU/AzEBn3UBgT4Cih94gQEygQGCCAEBBgQEhQ0YgjgJgTyDFItzHIFJRIEURIIwhTuEC4IukHCCR4IwOwNUgQUSgSFxAQgGBgcKBTIGAgwYFAQCExJTHgITDAocDlQZDA8DEgMRAQcCCxIIFSwIAwIDCAMCAyMLAgMYCQcKAx0IChwSEBQCBBMfCwgDGh8tCQIEDgNDCAsKAxEEAxMYCxYIEAQGAwkvDSgLAxQPAQYDBgIFBQEDIAMUAwUnBwMhBwsmDQ0EIx0DAwUmAwICGwcCAgMCBhcGAgJxCigNCAQIBBweJRMFAgcxBQQvAh4EBQYRCQIWAgYEBQIEBBYCAhIIAggnGwcPBzYZAQVdBgsJIxwsEQUGFgMmUgUEmB0XJxwDBwQYAygKHTkHBgMbBwNVDxQBBg8ZCzGRfDGOCJ8QgTAKg0ygJhWDdYw+mCSWZiCCKp53PgQYCoRZAgQCBAUCDgEBBoFiATorgS5wFYMjURkPjiAMBRGDUIpedTsCBgsBAQMJjlIGgWVdAQE
X-IronPort-AV: E=Sophos;i="5.91,230,1647302400"; d="scan'208";a="1075631970"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Sep 2022 10:42:52 +0000
Received: from mail.cisco.com (xfe-rcd-005.cisco.com [173.37.227.253]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 289Agqtl007711 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2022 10:42:52 GMT
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Fri, 9 Sep 2022 05:42:52 -0500
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Fri, 9 Sep 2022 05:42:51 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LUpoIuMS/s+/3kFAgPdAL1VSzUMNCBTTvVI8WVWamXlMlovTqZ1X1X22moZnj4UlR1RbMsVAfV7PMru2gLbS4DJaU3K1yxPqWjsEosG8s4q9C+g5OhsxwZJyFv5Oo5fbQxkK/18Ezw6UERYvPWW91mIna1OT4Ews0GPqzTcLpSVYsRTsYmtP4FdsAheGMtonuJkiIgpWhcWAAfThHdjBeO6KtuV6lYpmbqtzqMzqCYNHtDey/IqpYzR0XsxrnlVY2khvQxrTvtoxRyiXOr+YU/3NGA4dYJGD/BMbU5gaBBYQ67M17L/H9zKjq9hMnYp+x5nvlPE3WNoidQidMOeXMg==
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=W8/ZzKl81f0UZvqUTjId5IynAvnt1w1PQSPu95Il8Mo=; b=ieIGlUDy6lJd+kAyUR214dJCuQ5J0tfXJ78iZaEPClCKlNPgct3xTn7p7T98Kck9KQImqALXQ9sxkk4Cs1oOG40apaM1YvIZJQ9Mjqd4xInGcmkv0kC2/1lJQrE9SjNnd7X5Hxu3a16rSTLUkaZiER6Cfqd1gFMYcKgJAzjGxqb8i4VI8nCOpXlDHGESlJE1c2PUsFYaa4LqJs9m7ArxdYzg18lzfcJhqkQRd9A3ig2Rj6wDrx2jNYWcf/55ZHt0xNQfNCYcIVawKKTfahJe3EyFzhL7XEtxUfHpaSMh1Yy6ZesE3lvD1pJF+NilIlboSSG5EGWXq5lEynXmRZtYUw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W8/ZzKl81f0UZvqUTjId5IynAvnt1w1PQSPu95Il8Mo=; b=Ttx+Ydbfsh7ifkbp4KEOl6K7sBzUy2Xn1J5EpkEZ0bBkI6ZRVZnhKgCPG74JCD55oMQozQgr+D96oQ+7r0tOxTEZcF8ptIfLRZbLCwGWP1LCqDrRLpa+2euwSebbuh7CzjyxfLM6HtYf5pKB4d3pQ3ChsAbMZMOZWJu+WCFo4oI=
Received: from BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) by SA0PR11MB4557.namprd11.prod.outlook.com (2603:10b6:806:96::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.19; Fri, 9 Sep 2022 10:42:49 +0000
Received: from BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::9dd8:a726:9a08:ecf1]) by BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::9dd8:a726:9a08:ecf1%5]) with mapi id 15.20.5612.019; Fri, 9 Sep 2022 10:42:49 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org" <draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org>
CC: "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09
Thread-Index: AdjDgY74oamysRH/SPqEo+WFhVCtXA==
Date: Fri, 09 Sep 2022 10:42:49 +0000
Message-ID: <BY5PR11MB4196E8A452961895B97B284CB5439@BY5PR11MB4196.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY5PR11MB4196:EE_|SA0PR11MB4557:EE_
x-ms-office365-filtering-correlation-id: 44383db6-b1ac-4a75-4680-08da92500a58
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BY5ppudNjvOoduVDyw2NGeOFFf0JMIJXcPJoFC2eeTlYGiDC30QRgoLu3K5/0xQs0eMCZPW/7i+8FAeNPLMutwnTVri5C8pkIk5ZabENpjuVHpDiHfWdmcMIRhdo1W9ilS3CiiGV/s+BzpCUt6aoBMg4iGDt4yAvGlZQ8dW8AgupLpEeLbAhr19btZQO+0wOcTAR90+pWRcrDl2DfQ98NYxKN7kzM7cgXN0tTfvXAQbTvqhDtoeadnnrNFk9ZcVMuyLBD0nENtbKJHan7TOhPNu/ABiwF2qYVJzob+lwdvj8Rq3yJv+/XRAKcT6C5Fj3CZYo19wiTU5rHRuFZvCwiMHHX3ElO/H5OlZVx5v4G0HGmkvqt/OSWxJREDUN2eiFO3dVK62atorkYWZ0qBOOA9G4lgkiiAFqyzsuoQHBmENWQzo1s7lr3lzcThH+Ji8OCSdafdVKGyV1XRr7xvZMxZCHLmGuF7eP9esPCCwQe09ArDmJyA4r0GnWtaGl7AMh8ce7yszf3tE1nDVAL2SVRxZzdC7xMvX8laC7V7i0UHxZF3Jk/JHYELLxsDVZTpImwWvnzHYZWKYFqifK15NviRZDdD1L8iv8hFoMkIo13vYb0zQ5Hx1floQG4oxJJj2c+TsOFQWchqBqmN34SCJuioLpHjjO/Q1udhH08UxV7AZz5TT5sRtPWMbWEHYj+nwARpzZuz4qzYcgzbiJqZx01Hb17aM9wVQwnDPpjulZsKsoYa4bo5xJ1+3CKbv0mOZaiYwogzN5Rv8IdLus4kePWA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4196.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(136003)(366004)(376002)(346002)(396003)(39860400002)(66446008)(30864003)(2906002)(8936002)(6506007)(86362001)(52536014)(5660300002)(33656002)(9686003)(26005)(83380400001)(186003)(38100700002)(122000001)(38070700005)(55016003)(8676002)(66556008)(41300700001)(71200400001)(7696005)(478600001)(76116006)(66476007)(66946007)(64756008)(316002)(4326008)(6916009)(450100002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: +oUzz2Bf6VC16tos4mRD3bwRQyKGZTUHFMm2h2lAKs+kgdD0MHYtb3JNnQrKVLYqoh2trz2mjECucbN/aNH9gBrpo6WxOauvCCXVFv5k1vPSLDOYf3Y7DAeRawLUecCHKlsSpxoWI5Z9XQKUPww4Y2OqV6Oz8tOQ5iL3Re3IM0k8YUNGPoM8pdKTn2i+w0fU8iPdNAkR+WWZEc4or0J61nKWHzquW4T2vu/fXyayQwdxryo/3wbH/0JKOpb+nl9UHf5FUUZuTI+w/h+ei0B16Xy6pkp96d1D0hlHUtpycjie+ddWHwwDLSC1/AfK43h4BstZL/lqU0Yokj6bc6A6rt0IDz7ISm6UEIPMz70atjn0YQZne3RpI4qfmxni4piXne0K1ZXRazdWtJktWNpWJ/6KjQ9MQAPj8xdb1M7zNUcveW6lyCvv8QocS8pvIcayho5nwKVqaQx5FAfigWCaUxMdUiIV0TldolWDXFRax7l3Mmvpjo2Nwkcua/k7pKFvpZBHt1E5bwjFItQlG5V/jM8fDcfG8VwcJmOX2+XXCqOweUVAaXI6gWUPvgzO+WQkZZ11+JWL+CyttmW2+dv449KeoZuH84zvXdftoO83NCPG81IqHQpEBP7zgmZxCG2go3c5nt9AlaNgdAE8w2qKD5y3iwkNxUkbYfJk7O/6+lpdSMvW5B4fIN7G1eMJo3tJ8/4CgL3dmlIDJXCFTW761ABiXQMGJx09XixfWlNgYPCJz2lnSJl7ljuWgV3TRVP7vJGkojBSTPUBjVyF0h0og/qAUEMVV5VdSLaRGKHFIOWWv8AaOK2v/0V40IqGjWs5GGCBDzzm9cojr9vBK4UHpEuMtzW9A0sv18GDvfXr/otkkGI/vH8MimxrrjJDNosTcNv1ZHCnaj6Ak1WzyFXXvF0+gIVAyhwHOtxb6FNU25cYrqRN0KZr7ISOdUKWC57Miw/96Ee26jfIXLTX1gYyJWTz5By+oYWEJIX3NzYIIFRuT3TQof8zvqA8bym99C1NtHnpX7bRqDHY/Pe2rWAWE8KKZwJ/aXAef90xVjCOgyiP039XXZQEYUR4fHEYknmiSzbSZiucU9MFCpX/aomu0lzf4tIVAZcOYcsVSzqJxtBXXYotSe37xz2iuD+w1hwkyuapKqQrTh3PPqraJ7epPXCEuSPbUIJlKilypUme9fNCdu9bsy6l8B8H6iHDmFEPhBgY5VTAKvbcS9w/HFhKmQ86v/H4LQGP1y/PEO3PJlMIGpuZ9Zgwfc+eNRhsU9EfwrHatST9tu0dOaji/rkoNqoq7WFwJK3zTghL6horuXbVU9EaXQYgauvzkEczdxDCitYyvfSPcxFgVAutOzGOFZ20Tr9ZVvGowARZEYIQCSzMklK7pJ2pIypMNvYfqv6Ci8h04eoreyFmnehV7j+Wjov1T9QzdOh1DaORfbOv0ueVdZICTDgLD01yhSpdxZBJwlXZJDVF3XjGbmjiENldab+3JF1YLKbHE0MPNYYx965tkCpmPB/fOXIxUnMsgidhPHgyLL4+h6NCm0i9I3AZenEO2pswJSp8pEvkCKr+r/k=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4196.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 44383db6-b1ac-4a75-4680-08da92500a58
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2022 10:42:49.4630 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hvMFt6OVydL2h248tJilhnF5OfveEnNcTLvM4X4bEqJVwrxqDTiMEuUNt6aide2MWHDoV4PL+YeQj21GajXg/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4557
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.227.253, xfe-rcd-005.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/kbmmRK_VZ-cgqas3Os7F7dSdU4A>
Subject: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm-09
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2022 10:42:58 -0000

Hi,

Here are my AD review comments for draft-ietf-opsawg-yang-vpn-service-pm-09, apologies for the delay.

I think that this document is in good shape and hence most of my comments are only minor or nits.


Minor level comments:

(1) p 0, sec 

   The data model for network topologies defined in RFC 8345 introduces
   vertical layering relationships between networks that can be
   augmented to cover network and service topologies.  This document
   defines a YANG module for performance monitoring (PM) of both
   networks and VPN services that can be used to monitor and manage
   network performance on the topology at higher layer or the service
   topology between VPN sites.

"the topology at higher layer" doesn't scan particularly well to me, please can you tweak it.


(2) p 1, sec 1.  Introduction

   [RFC8969] describes a framework for automating service and network
   management with YANG [RFC6020] models.

Please update reference to RFC 7950 for YANG.


(3) p 4, sec 3.  Network and VPN Service Performance Monitoring Model Usage

   As shown in Figure 1, in the context of the layering model
   architecture described in [RFC8309], the network and VPN service
   performance monitoring (PM) model can be used to expose a set of
   performance information to the above layer.  Such information can be
   used by an orchestrator to subscribe to performance data.

Perhaps rephase?  I.e., is it the performance data that is being used to create a subscription based on the performance data, or is it just that the model makes the performance data readily available, which can then be subscribed do?


(4) p 4, sec 3.  Network and VPN Service Performance Monitoring Model Usage

   In addition, the amount of performance data collected from the
   devices can be huge.  To avoid receiving a large amount of
   operational data of VPN instances, VPN interfaces, or tunnels, the
   network controller can specifically subscribe to metric-specific data
   using the tagging methods defined in [I-D.ietf-netmod-node-tags].

At the moment, my reading of the ietf-netmod-node-tags draft is that it doesn't currently allow you do this.  I.e., you can't just make a subscription to all datanodes that have been tagged in a particular way.  Hence, I would suggest removing this paragraph, since it doesn't seem to be directly related to what is described in this model.


(5) p 5, sec 3.1.  Collecting Data via Pub/Sub Mechanism

   Some applications such as service-assurance applications, which must
   maintain a continuous view of operational data and state, can use the
   subscription model specified in [RFC8641] to subscribe to the
   specific network performance data or VPN service performance data
   they are interested in, at the data source.  For example, network or
   VPN topology updates may be obtained through on-change notifications
   [RFC8641].  For dynamic PM data, various notifications can be
   specified to obtain more complete data.

Can you elaborate a bit on what is meant by dynamic PM data please.


(6) p 5, sec 3.1.  Collecting Data via Pub/Sub Mechanism

  A periodic notification
   [RFC8641] can be specified to obtain real-time performance data, a
   replay notification defined in [RFC5277] or [RFC8639] can be
   specified to obtain historical data

If this data is coming from a device then ideally it would not hold on to much historical data.


(7) p 6, sec 4.1.  Layering Relationship between Multiple Layers of Topology

      Figure 3: Example of Topology Mapping Between VPN Service
                   Topology and Underlying Network

Note, I don't find this diagram brilliantly clear, it is hard to see when the dotted lines go
but the explanatory text is clear (and probably sufficient).


(8) p 7, sec 4.1.  Layering Relationship between Multiple Layers of Topology

   Apart from the association between the VPN topology and the underlay
   topology, VPN Network PM can also provide the performance status of
   the underlay network and VPN services.  For example, network PM can
   provide link PM statistics and port statistics.  VPN PM can provide
   statistics on VPN access interfaces, the number of current VRF routes
   or L2VPN MAC entry of VPN nodes, and performance statistics on the
   logical point-to-point link between source and destination VPN nodes
   or between source and destination VPN access interfaces.  Figure 4
   illustrates an example of VPN PM and the difference between two VPN
   PM measurement methods.  One is the VPN tunnel PM and the other is
   inter-VPN-access interface PM.

By "VPN Network PM", do you mean the "VPN Network PM YANG module", or is this just referring to performance monitoring in general?


(9) p 7, sec 4.1.  Layering Relationship between Multiple Layers of Topology

   Apart from the association between the VPN topology and the underlay
   topology, VPN Network PM can also provide the performance status of
   the underlay network and VPN services.  For example, network PM can
   provide link PM statistics and port statistics.  VPN PM can provide
   statistics on VPN access interfaces, the number of current VRF routes
   or L2VPN MAC entry of VPN nodes, and performance statistics on the
   logical point-to-point link between source and destination VPN nodes
   or between source and destination VPN access interfaces.  Figure 4
   illustrates an example of VPN PM and the difference between two VPN
   PM measurement methods.  One is the VPN tunnel PM and the other is
   inter-VPN-access interface PM.

I wonder if it would be better to move, and perhaps expand, the "Figure 4" explanation text to below the diagram?  If so, then I would add a joining sentence here, something like:
"VPN PM can be further split into PM for the VPN tunnel and PM at the VPN PE access node, as illustrated in the following diagram:"


(10) p 8, sec 4.2.  Network Level

Network Level -> Network Level PM?  If so, please also change the titles for 4.3 and 4.4.


(11) p 8, sec 4.2.  Network Level

   For network performance monitoring, the container of "networks" in
   [RFC8345] is not extended.

I'm confused by what this sentence is meant to convey - did you mean augmented?  In particular, it isn't clear to me how you express PM for the physical (or underlay networks).  Is what you are trying to express that the "service-type" container is present for VPN service performance monitoring and absence otherwise?  Probably more words required here, and in the YANG module.


(12) p 8, sec 4.2.  Network Level

   module: ietf-network-vpn-pm
     augment /nw:networks/nw:network/nw:network-types:
       +--rw service-type!
          +--rw service-type?   identityref
     augment /nw:networks/nw:network:
       +--rw vpn-pm-attributes
          +--rw vpn-id?                 vpn-common:vpn-id
          +--rw vpn-service-topology?   identityref

These two leaves are added under vpn-pm-attributes, but I was wondering if they are actually PM specific (particularly vpn-id), or would be better directly added to the network?


(13) p 8, sec 4.2.  Network Level

   module: ietf-network-vpn-pm
     augment /nw:networks/nw:network/nw:network-types:
       +--rw service-type!
          +--rw service-type?   identityref
     augment /nw:networks/nw:network:
       +--rw vpn-pm-attributes
          +--rw vpn-id?                 vpn-common:vpn-id
          +--rw vpn-service-topology?   identityref

I'm not sure that you need "attributes" in the name, isn't that implicit?  The same comment applies for "pm-attributes", and whether just "pm" would be sufficient, or perfhaps "perf-mon" would be more descriptive in the various container names rather than "pm"?


(14) p 8, sec 4.3.  Node Level

   "node-type":  Indicates the device type of Provider Edge (PE),

As per above, is "node-type" actually PM specific?


(15) p 10, sec 4.4.  Link and Termination Point Level

   The performance data of a link is a collection of counters and gauges
   that report the performance status.
  augment /nw:networks/nw:network/nt:link:
    +--rw pm-attributes
       +--rw low-percentile?            percentile
       +--rw intermediate-percentile?   percentile
       +--rw high-percentile?           percentile
       +--rw measurement-interval?      uint32
       +--ro pm* [pm-type]
       |  +--ro pm-type          identityref
       |  +--ro pm-attributes
       |     +--ro start-time?                        yang:date-and-time
       |     +--ro end-time?                          yang:date-and-time
       |     +--ro pm-source?                         identityref
       |     +--ro one-way-pm-statistics
       |     |  +--ro loss-statistics
       |     |  |  +--ro packet-loss-count?   yang:counter64
       |     |  |  +--ro loss-ratio?          percentage
       |     |  +--ro delay-statistics
       |     |  |  +--ro unit-value?                      identityref
       |     |  |  +--ro min-delay-value?                 yang:gauge64
       |     |  |  +--ro max-delay-value?                 yang:gauge64
       |     |  |  +--ro low-delay-percentile?            yang:gauge64
       |     |  |  +--ro intermediate-delay-percentile?   yang:gauge64
       |     |  |  +--ro high-delay-percentile?           yang:gauge64
       |     |  +--ro jitter-statistics
       |     |     +--ro unit-value?                       identityref
       |     |     +--ro min-jitter-value?                 yang:gauge64
       |     |     +--ro max-jitter-value?                 yang:gauge64
       |     |     +--ro low-jitter-percentile?            yang:gauge64
       |     |     +--ro intermediate-jitter-percentile?   yang:gauge64
       |     |     +--ro high-jitter-percentile?           yang:gauge64

I presume that it is intentional delay and jitter statistics can have different units, rather than always being aligned to the same units?


(16) p 18, sec 5.  Network and VPN Service Performance Monitoring YANG Module

     typedef percentage {
       type decimal64 {
         fraction-digits 5;
         range "0..100";
       }
       description
         "Percentage.";

Perhaps "Percentage to 5 decimal places?"


(17) p 18, sec 5.  Network and VPN Service Performance Monitoring YANG Module

     typedef percentile {
       type decimal64 {
         fraction-digits 2;
         range "0..100";
       }
       description
         "The percentile is a value between 0 and 100,

Perhaps value between 0 and 100 to 2 decimal places?


(18) p 24, sec 5.  Network and VPN Service Performance Monitoring YANG Module

     augment "/nw:networks/nw:network/nw:network-types" {
       description
         "Defines the service topologies types.";
       container service-type {
         presence "Indicates network service topology.";

Perhaps expand either in the presence statement, or the documentation what it means if this container isn't present.  I.e., does this mean that the topology represents the underlying network?


(19) p 24, sec 5.  Network and VPN Service Performance Monitoring YANG Module

         leaf service-type {
           type identityref {
             base vpn-common:service-type;
           }

Should this leaf be marked as mandatory?  I.e., is it okay to mark it as a service topology without identifying the srevice type?


(20) p 26, sec 5.  Network and VPN Service Performance Monitoring YANG Module

     augment "/nw:networks/nw:network/nt:link" {
       description
         "Augments the network topology link with performance
          monitoring attributes.";
       container pm-attributes {
         description
           "Container for PM attributes.";
         leaf low-percentile {
           type percentile;
           default "10.00";
           description
             "Low percentile to report. Setting low-percentile
              into 0.00 indicates the client is not interested
              in receiving low percentile.";
         }
         leaf intermediate-percentile {
           type percentile;
           default "50.00";
           description
             "Intermediate percentile to report. Setting
              intermediate-percentile into 0.00 indicates the client
              is not interested in receiving intermediate percentile.";
         }
         leaf high-percentile {
           type percentile;
           default "95.00";
           description
             "High percentile to report. Setting high-percentile
              into 0.00 indicates the client is not interested in
              receiving high percentile.";
         }
         leaf measurement-interval {
           type uint32 {
             range "1..max";
           }
           units "seconds";
           default "60";
           description
             "Indicates the time interval to perform PM measurement.";

Perhaps "The time interval to perform PM measurements over"?


(21) p 30, sec 6.  Security Considerations

   *  "/nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm-
      statistics": Unauthorized access to this subtree can disclose the
      operational state information of network termination points or VPN
      network accesses.

Perhaps add a sentence to state that the model does not define any RPC or Actions.


(22) p 38, sec Appendix A.  Illustrative Examples

   The following shows an example of a percentile measurement for a VPN
   link.

Please can you expand the description a bit.  I.e., that this is an example of data that could be returned for for link foo:vpn1-link1 between vpn-node1 and vpn-node3.



Nit level comments:

(23) p 3, sec 3.  Network and VPN Service Performance Monitoring Model Usage

   As shown in Figure 1, in the context of the layering model
   architecture described in [RFC8309], the network and VPN service
   performance monitoring (PM) model can be used to expose a set of

layering/layered


Grammar Warnings (generated by tooling):
Section: 4.4, draft text:
The statistics of the VPN abstract links can be collected based upon VPN OAM mechanisms, e.g.,OAM mechanisms referenced in [RFC9182], or Ethernet service OAM [ITU-T-Y-1731] referenced in [I-D.ietf-opsawg-l2nm]. 
Warning:  Put a space after the comma.
Suggested change:  ", OAM"

Section: 6, draft text:
Unauthorized access to this subtree may disable the the VPN PM or render the VPN service topology invalid. 
Warning:  Maybe you need to remove one determiner so that only the or the is left.
Suggested change:  "the"

Section: 6, draft text:
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. 
Warning:  If the text is a generality, 'of the' is not necessary.
Suggested change:  "Some"

Section: 6, draft text:
- /nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm-statistics": Unauthorized access to this subtree can disclose the operational state information of network termination points or VPN network accesses. 
Warning:  Unpaired symbol: '"' seems to be missing

Regards,
Rob