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 <[email protected]> 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 <[email protected]> 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" <[email protected]> > > To: <tom petch> > > Cc: <Last Call>; <[email protected]>; <Andy Bierman>; <Yoav Nir>; > > <[email protected]>; <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 protected]<mailto:[email protected]>> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/yang-doctors >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
