Subject: Re: [I2nsf] review of draft-ietf-i2nsf-nsf-monitoring-data-model-10

From: tom petch <[email-masked]>
Date: Mon, 4 Oct 2021 09:57:44 +0000

From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: 30 September 2021 15:25

Hi Tom,
I will address your comments below.

<tp>
Paul

Returning to capability-data-model, I note that it and the other I-D measure traffic rates in byte per second whereas this uses bit per second.  If there is a good reason for the divergence, then I think that a comment on why should be added to this I-D lest users misunderstand 'bps'.  If there is no good reason, well, then I would suggest a change to this I-D.

Tom Petch 

Thanks.

Best Regards,
Paul

2021년 9월 30일 (목) 오후 8:52, t petch <[email-masked]<mailto:[email-masked]>>님이 작성:
----- Original Message -----
From: "Mr. Jaehoon Paul Jeong" <[email-masked]<mailto:[email-masked]>>
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.

RFC5321 needs adding to the I-D References

identity ssh
references RFC959 FTP; RFC6242 would be better - you already have that
reference in Security Considerations

nsf-name
I commented on for another I-D; I think that the description lacks
scope.  'unique' yes but within what namespace?  'management domain'
might be a suitable scope

identity access-violation
mentions read and write.  When I think of permissions, I also include
create, delete, execute as part of the set; should this do so?

        leaf attack-speed {
          type uint32;
          units "bps";
Is 32 bit bps enough for modern networks?  This applies in several places.

      grouping i2nsf-system-counter-type-content{
here and elswhere counters can wrap and so RFC6991 recommends that they
be accompanied by a discontinuity-time; you can see an example of this
RFC8343

              leaf interface-name {
in other models, such as routing ones, references to interface are by
leafref to an object in the interface YANG module of RFC8343; is it
worth it here?  I do not know what is best here.

              leaf login-ip {
assumes that login is over an IP network.  Probably a reasonable
assumption even if I sometimes use otherwise!

              leaf-list attack-dst-ip {
                type inet:ip-prefix;
The Revision Letter said that this would be
type inet:ip-address;
which I think that it should

            leaf alarm-type {
this lists three types whereas the identity has five.  Is the difference
significant?  Would an identityref do?

Tom Petch

--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 15 Oct 2021 23:05:47 +0900

Hi Tom,
Patrick and I have reflected your comments in the revision:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-11

I attach the revision letter.

Please let me know whether you are fine with this revision.

Thanks.

Best Regards,
Paul

On Thu, Sep 30, 2021 at 8:52 PM t petch <[email-masked]> wrote:

> From: "Mr. Jaehoon Paul Jeong" <[email-masked]>