----- Original Message -----
From: "Mr. Jaehoon Paul Jeong" <[email protected]>
Sent: Tuesday, August 24, 2021 3:27 PM
Hi Tom,
Patrick and I have addressed your comments below with -09 version:
I attach the revision letter to explain how to address them.
Please let us know where this revision satisfies you or not.
Paul
Getting there.
You have added some references to the YANG module - good - but you must
also add them to the I-D References
I see
RFC854, RFC913, RFC1081, RFC4340, RFC4960, RFC5321, RFC7230, RFC7231.
RFC1081 is obsoleted by RFC1225 so that would likely be a better
reference. In other I-D you have cited RFC793bis - I do not know if
that is appropriate here.
You import
ietf-i2nsf-policy-rule-for-nsf {
with prefix nsfi but in nsf-facing the prefix is nsfintf
Needs to be consistent
In identity, derived from application-protocol (a base which I like), I
note that 'imap' is present elsewhere but not here. I do not know if
that is relevant to this module or not.
In the data module:
/http:/https:/
leaf src-zone {
I was thrown by this thinking of IPv6 address zones but the description
makes in clear that this is nothing of the sort. Probably not worth
changing but if you do I would suggest src-location as is used in the
description clause.
leaf-list user-agent {
I think that the description violates (!) the limit on line length for
an RFC
container i2nsf-counters {
description
"This is probably better covered by an import as this
This seems unfinished
leaf alarm-type {
elsewhere you have switched to lower case (which I think right) but this
needs bringing in line (I do like consistency).
10. I2NSF Event Stream
you are using the NETMOD convention for line breaks; would benefit from
a reference
"line breaks as per [RFC8792]
The I-D is big and I hope to find time this month to go through it again
in more detail. Meanwhile, on to capability.
In passing, I get a bounce for skku-iotlab-members every time.
Tom Petch
Thanks.
Best Regards,
Paul
On Wed, May 5, 2021 at 7:44 PM t petch
<[email protected]<mailto:[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]<mailto:[email protected]>>
To: <tom petch>
Cc: <Last Call>; <[email protected]<mailto:[email protected]>>; <Andy
Bierman>; <Yoav Nir>;
<[email protected]<mailto:draft-ie
[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<https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-m
onitoring-data-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]><mailto:daedulus@b
tconnect.com<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
Attachments:
Revision-Letter-for-NSF-Monitoring-YANG-Data-Model-version-09-20210824.d
ocx 103 kB
Revision-Letter-for-NSF-Monitoring-YANG-Data-Model-version-09-20210824.p
df 420 kB
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
