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]>]

Thinking some more ...

On 22/09/2022 12:24, tom petch wrote:
> 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

The problem starts with the title.  Does it meane

A YANG Model for Network Monitoring and VPN Service Performance Monitoring'
or perhaps
A YANG Model for Network Performance Monitoring and VPN Service 
Performance Monitoring
or perhaps
A  YANG Model for Network Service Performance Monitoring and VPN Service 
Performance Monitoring'
while if it was
A  YANG Model for Monitoring the Perfomance of a Network and a VPN Service
I would be in no doubt and it would be even clearer if it used the 
terminology of the Abstract, to whit
A YANG Model for Monitoring the Perfomance of an Overlay VPN Service and 
its Underlay Network


Tom Petch


> 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
>> .
>>