[Last-Call] Secdir last call review of draft-ietf-opsawg-yang-vpn-service-pm-12

Daniel Migault via Datatracker <noreply@ietf.org> Fri, 07 October 2022 19:54 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D7EC1522B1; Fri, 7 Oct 2022 12:54:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Daniel Migault via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166517247062.48551.6117451096915058371@ietfa.amsl.com>
Reply-To: Daniel Migault <daniel.migault@ericsson.com>
Date: Fri, 07 Oct 2022 12:54:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/IFDi4QzxgPN3wiBfqSo22K40DkI>
Subject: [Last-Call] Secdir last call review of draft-ietf-opsawg-yang-vpn-service-pm-12
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2022 19:54:30 -0000

Reviewer: Daniel Migault
Review result: Ready

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with nits, but I am not an expert
in this area, so please take this comments as questions that came to
me while reading the document.

Introduction:

[...]

   The performance of VPN services is associated with the performance
   changes of the underlay networks that carries VPN services.  For
   example, link delay between PE and P

<mglt>
It seems to me that is the first time these acronyms are introduced - same with
CE. </mglt>

   devices and packet loss status
   on Layer 2 and Layer 3 interfaces connecting PEs and CEs directly
   impact VPN service performance.  Additionally, the integration of
   Layer 2/Layer 3 VPN performance and network performance data enables
   the orchestrator to subscribe uniformly.

<mglt>
I do not understand "subscribe uniformly".
My impression is that here the orchestrator is responsible to enforce some
network performances, and depending on the performance to meet, it will choose
one configuration or the other. Does the use of one configuration versus the
other is seen as a subscription ?  If that is correct, this sounds like a
cooperation between various actor. If so, that surprises me. </mglt>

Therefore, this document
   defines a YANG module for both network and VPN service performance
   monitoring (PM).  The module can be used to monitor and manage
   network performance on the topology level or the service topology
   between VPN sites.

   This document defines a base YANG data model for monitoring of
   network performance and VPN service performance.
<mglt>
I have the impression the text above repeats the previous paragraph.
</mglt>

[...]

3.  Network and VPN Service Performance Monitoring Model Usage

   As shown in Figure 1, in the context of the layered model
   architecture described in [RFC8309], the network and VPN service
   performance monitoring (PM) model can be used to expose operational
   performance information to the layer above, e.g., to an orchestrator
   or other client application, via standard network management APIs.

<mglt>
I am wondering if the client application is related to the Customer.
I do not think so, but I might be wrong. I am wondering if that would
make sense to have the client application being mentioned on the figure.
</mglt>