[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
- [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-… Rob Wilton (rwilton)
- [OPSAWG] 答复: AD review of draft-ietf-opsawg-yang-… Wubo (lana)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Rob Wilton (rwilton)
- [OPSAWG] 答复: AD review of draft-ietf-opsawg-yang-… Wubo (lana)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Wubo (lana)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Wubo (lana)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… tom petch
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Adrian Farrel
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Wubo (lana)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Wubo (lana)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Wubo (lana)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… tom petch
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… Rob Wilton (rwilton)
- Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-… tom petch