Re: [yang-doctors] [I2nsf] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-nsf-monitoring-data-model-06

[t petch <[e-mail]>]

Paul

Top posting since this is a more general response (and leaving in YANG
doctors since I note that five different YANG doctors reviewed the five
I-D and so might not see the issue that concerns me).

As you have probably realised, I have now looked at the five YANG I-D of
I2NSF and am concerned at the disparate approaches to the same topics
that I think will confuse a user and, likely, induce mistakes.  I
provided some detailed comments  in response to WG LC on
capability-data-model but really it cuts across all five.  It may be
that the inconsistenicies that I see can be justified but if so, then I
think that the I-D may need some text to say so, to relate one I-D to
another.

The treatment of YANG identity for ICMP is to me a clear example.  I
think that nsf-monitoring is good here, deriving icmpv4 and icmpv6 from
icmp (and ipv4 and ipv6)
while capability is not good having icmp (sic) and icmpv6 as two
unrelated identity, no common base.

But at a higher level it may be that capability has a better treatment
where it has
   base event; [from which is derived]
     identity system-event-capability {
     identity system-alarm-capability {

   base system-event-capability;
     identity access-violation {
     identity configuration-change {

   base system-alarm-capability;
     identity memory-alarm {
     identity cpu-alarm {
     identity disk-alarm {
     identity hardware-alarm {
     identity interface-alarm {

while nsf-monitoring has

   base alarm-type;
     identity mem-usage-alarm {
     identity cpu-usage-alarm {
     identity disk-usage-alarm {
     identity hw-failure-alarm {
     identity ifnet-state-alarm {

   base event-type;
     identity access-denied {
     identity config-change {

Different structure, different terminology, and these examples are quite
close compared to some others.  I would expect at least the root of the 
identifier to be the same if not the whole identifier.

What is missing, for me, is an underlying, high-level, information model
to provide a consistent structure and a consistent terminology for the
I2NSF YANG I-D.

Tom Petch


----- Original Message -----
From: "Mr. Jaehoon Paul Jeong" <[e-mail]>
To: <tom petch>
Cc: <Last Call>; <[e-mail]>rg>; <Andy Bierman>; <Yoav Nir>;
<[e-mail]>rg>; <Linda
Dunbar>; <Patrick Lingga>; <YANG Doctors>; <skku-iotlab-members>; <Mr.
Jaehoon Paul Jeong>
Sent: Thursday, April 29, 2021 3:49 PM
Subject: Re: [I2nsf] [Last-Call] Yangdoctors last call review of
draft-ietf-i2nsf-nsf-monitoring-data-model-06


> Hi Tom,
> Patrick and I have addressed all your comments below with the
following revision.
>
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-da
ta-model-08
>
> I attach our revision letter.
>
> Thanks.
>
> Best Regards,
> Paul
>
> On Mon, Apr 12, 2021 at 6:59 PM tom petch
<[e-mail]<mailto:[e-mail]>> wrote:
> Paul
>
> Some admin comments on -07; I think that you need to:
>
> - change the title in YANG revision reference
>
> - add to the I-D references
> RFC959
> RFC8632
>
> - shorten lines. There is a limit to line length in RFC as per the
Style
> Guide.  This is exceeded in the YANG where some of the path statements
> take it over 80 while some of the examples are over 100.
>
> - add a reference for the import of
> ietf-i2nsf-policy-rule-for-nsf
>
> HTH
>
> Tom Petcb
>
> On 01/04/2021 03:09, Mr. Jaehoon Paul Jeong wrote:
> > > Hi Andy, Linda, and Yoav,
> > > Patrick and I have addressed all the comments from Andy.
> > > Here is the revised draft -07:
> ATT00001.txt 130 bytes