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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Martin,
Patrick and I have addressed your comments below with -09 version:

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

I attach the revision letter to explain how to address them.

Our answer to your comment starts from page 3 as follows.
"We removed the reference of “RFC 8632” as this NSF Monitoring Interface
data model document defines different types of severities for alarm.
We define an alarm as a warning related to service degradation in system
hardware in Section 4.2 and Section 6."

Please let us know where this revision satisfies you or not.

Thanks.

Best Regards,
Paul

On Thu, May 6, 2021 at 12:48 AM Martin Björklund <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
> > 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]>; <Andy Bierman>; <Yoav Nir>;
> > <[e-mail]>; <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
> >
> > _______________________________________________
> > yang-doctors mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/yang-doctors
>