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

From: t petch <[email-masked]>
Date: Wed, 5 May 2021 11:44:11 +0100

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" <[email-masked]>
To: <tom petch>
Cc: <Last Call>; <[email-masked]>; <Andy Bierman>; <Yoav Nir>;
<[email-masked]>; <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
<[email-masked]<mailto:[email-masked]>> 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

---

From: Martin Björklund <[email-masked]>
Date: Wed, 05 May 2021 17:48:02 +0200 (CEST)

Hi,

Just one comment.  I notice that this draft defines alarms, but it
doesn't use the definition of an alarm in RFC 8632, it doesn't mention
how it relates to RFC 8632, and it doesn't even provide its own
definiton of what an alarm is.  There is one reference to RFC 8632:

  typedef severity {
    ...
    reference
      "RFC 8632: A YANG Data Model for Alarm Management -
       The severity levels are defined.";
  }

But this is a very strange reference, since this draft defines
*different* severities.

/martin

t petch <[email-masked]> wrote:
> close compared to some others.  I would expect at least the root of
> the identifier to be the same if not the whole identifier.
> 
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 6 May 2021 11:44:14 +0900

Hi Tom,
I will use your comments to synchronize all the five I2NSF YANG data model
drafts.

Thanks.

Best Regards,
Paul

On Wed, May 5, 2021 at 7:44 PM t petch <[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-08>
> >

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 6 May 2021 11:46:36 +0900

Hi Martin,
Thanks for your comments.

I will address your good comments on the revision.

Thanks.

Best Regards,
Paul