Re: [Last-Call] Last Call: <draft-ietf-opsawg-yang-vpn-service-pm-10.txt> (A YANG Model for Network and VPN Service Performance Monitoring) to Proposed Standard

[tom petch <[e-mail]>]

On 20/09/2022 17:24, The IESG wrote:
>
> The IESG has received a request from the Operations and Management Area
> Working Group WG (opsawg) to consider the following document: - 'A YANG Model
> for Network and VPN Service Performance Monitoring'
>    <draft-ietf-opsawg-yang-vpn-service-pm-10.txt> as Proposed Standard


I struggled to understand what this I-D offered until the AD Review
where the AD had issues similar to mine.  Even now, I am unclear if I
understand it; the problem is wording and inconsistent use thereof.

In many places, the I-D says
'This document  defines a YANG module for performance monitoring (PM) of
both underlay networks and overlay VPN services '
and it is that 'both' that I think starts to lead the reader, or at 
least me, up the garden path.

s.4.2 says
    The model can be used for performance monitoring both for the
    underlay network and the VPN services.  The two would be separate
    entries in the network list [RFC8345].

and then talks of  the effect of the  "service" presence container being
absent or present, which would doubtless twitch the nostrils of a YANG
Doctor.

What it is saying, I think, is that the YANG module
- either provides data for PM of a VPN service
- or provides data for PM for the network itself
but cannot do both, except in the sense that the YANG model in a node
may contain multiple entries in the network list one or more of which is
for a VPN service and one or more of which is for a network itself and
that Netconf, e.g., can retrieve data for both in a single 'get'.  I 
think that the use of 'both' above is a stretch for that use of the 
word, more precisely it is either VPN service or network itself.

The rest of the I-D increases my confusion.

s.4
' The performance monitoring data augments the service topology as
shown in Figure 2.'
Figure 2 has no mention of service.  Perhaps the reader must infer that
what is meant is
    The YANG module for performance monitoring data augments the YANG
module for service topology - i.e. ietf-network, ietf-network-topology -

The presence container alluded to above appears as
'      container service {
          presence
            "Presence of the container indicates a service
             topology, absence of the container indicates an
             underlay network.";  '
The use of service topology here seems at odds with that in s.4.2 but
later, in several places, there is
        when '../nw:network-types/nvp:service' {
          description
            "Augments only for VPN node attributes.";
Well no, the augments only occurs when 'service' is present and that has
just been defined as
'Presence of the container indicates a service topology';
seems contradictory here and in several places.

Also, in most places, it is 'underlay tunnel' or 'underlay-tunnel'
whereas here it is 'underlay network' as it is in the Abstract and that,
for me, again, leads the reader - me - astray.

In a similar vein, I see
              leaf start-time { type yang:date-and-time;
                config false; description
                  "The time that the current measurement started.";
The YANG type is date and time so that is 'The date and time ..'.  I
often see monitoring at the same time every day which is what the
description might mean but does not.

Likewise
          leaf unit-value {
            type identityref {  base lime:time-unit-type;      }
            default "lime:milliseconds";
            description
              "Time units, where the options are s, ms, ns, etc.";
This is taken from  RFC8532 where the options are hours minutes seconds
milliseconds microseconds nanoseconds.  I think that the reader deserves
a more accurate description.

I see it as a clever idea to have one YANG module in two different roles
determined by a presence container - perhaps too clever for me.

Tom Petch



> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2022-10-04. Exceptionally, comments may
> be sent to [e-mail] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     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
>     underlay networks and overlay VPN services that can be used to
>     monitor and manage network performance on the topology of both
>     layers.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>