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

Hi Martin,
Thanks for your comments.

I will address your good comments on the revision.

Thanks.

Best Regards,
Paul

On Thu, May 6, 2021 at 12:48 AM Martin Björklund <mbj+ietf@4668.se> 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 <ietfa@btconnect.com> 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" <jaehoon.paul@gmail.com>
> > To: <tom petch>
> > Cc: <Last Call>; <i2nsf@ietf.org>; <Andy Bierman>; <Yoav Nir>;
> > <draft-ietf-i2nsf-nsf-monitoring-data-model.all@ietf.org>; <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
> > <daedulus@btconnect.com<mailto:daedulus@btconnect.com>> 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
> > yang-doctors@ietf.org
> > https://www.ietf.org/mailman/listinfo/yang-doctors
>