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
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
