Subject: [Gen-art] Genart last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-17

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Tue, 25 Jan 2022 02:26:06 -0800

Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-i2nsf-nsf-facing-interface-dm-17
Reviewer: Dan Romascanu
Review Date: 2022-01-25
IETF LC End Date: 2021-11-23
IESG Telechat date: Not scheduled for a telechat

Summary:

This document defines a YANG data model for configuring security policy rules
on Network Security Functions (NSF) in the Interface to the Network Security
Functions (I2NSF) framework. It's a solid, well-written and complete document.
It needs to be read in the context and together with several other documents
belonging to the I2NSF deliveries. The document is Ready from the perspective
of Gen-ART with a couple of minor non-blocking issues and a few editorial
problems that could be easily clarified and fixed if needed.

Major issues:

Minor issues:

1. How can RFC 8329 be only an Informative Reference. The Introduction dully
states that the YANG module is based upon the framework / architecture defined
in RFC 8329, and Section 4 uses RFC 8329 in several reference clauses.

2. Section 4.

>         leaf frequency {
               type enumeration

Is this enumeration sufficient (once, daily, weekly, monthly, yearly)? Are not
more cases  needed?  more flexibility?

Nits/editorial comments:

1. Section 3.3:

>  A condition clause of generic network security functions is defined as IPv4
condition, IPv6 condition, TCP condition, UDP condition, SCTP condition, DCCP
condition, and ICMP (ICMPv4 and ICMPv6) condition.

Should not be rather 'or' instead of 'and'?

2. Section 4:

description of identity acces-violation

>       "Identity for access-violation. Access-violation system
          event is an event when a user tries to access (read, write,
          create, or delete) any information or execute commands above
          their privilege."

'above their privilege' is vague - probably meaning not-conformant with the
access profile

3. Section 4

identity memory-alarm

description
         "Identity for memory alarm. Memory is the hardware to store
          information temporarily or for a short period, i.e., Random
          Access Memory (RAM). A memory-alarm is emitted when the RAM
          usage exceeds the threshold.";

memory-alarm is emitted when the memory usage is exceeding the threshold - RAM
example does not really help, the alarm applies to all types of memory

4. Section 4

    identity ot {
       base device-type;
       description
         "Identity for Operational Technology devices";
     }

     identity vehicle {
       base device-type;
       description
         "Identity for vehicle that connects to and shares
          data through the Internet";
     }

reference clauses would help - what is an OT and a 'vehicle' (in this context)?

5. Section 4

>     identity forwarding {
       base egress-action;
       description
         "Identity for forwarding. This action forwards the packet to
          another node in the network.";
     }

'This action forwards ... ' sounds odd. The action consists of forwarding, but
does not perform it. I suggest re-wording. There are a few more such instances
of 'This action [does] ...

---

From: tom petch <[email-masked]>
Date: Wed, 26 Jan 2022 13:09:58 +0000

Picking on this e-mail as it is the most recent of those relating to 
nsf-facing -17 and not because this has anything to do with Genart

-17 has introduced a number of errors as a result of changes (which is 
why I was unenthusiastic about the comments made on -16).

It will take me quite a while to go through all the i2nsf I-D in detail 
(again) but meanwhile, the sort of thing that leaps out at me ..

A number of references have been added to this YANG module - these now 
need adding to the I-D References; I see ten at first glance.

The added action 'reject' needs adding to the YANG description in 
several places.

The terminology is drifting out of line with RFC8329 - I do not know if 
this is just something to live with or whether these I-D should contain 
notes along the lines of 'Where RFC8329 says xxxx, we now say AVFRT 
...'.  And the right answer may depend on whether or not this RFC is 
made Normative.

And the TLP in the YANG module is out of date

Tom Petch

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 26 Jan 2022 22:23:14 +0900

Hi Dan,
Here is the revised draft of NSF-Facing Interface according to your
comments:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-18

Patrick and I have worked on the revision.

I attach the revision letter to explain our revision for your comments.

Thanks.

Best Regards,
Paul

On Tue, Jan 25, 2022 at 7:26 PM Dan Romascanu via Datatracker <
[email-masked]> wrote:

> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 26 Jan 2022 22:25:27 +0900

Hi Tom,
As you may know, I as the editor of those I-Ds need to address the comments
from
the IETF community for preparing for the IESG review.

If you have specific comments on I2NSF YANG Data Model Drafts
to improve them, please let me know.

Thanks.

Best Regards,
Paul

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 26 Jan 2022 17:44:09 +0200

Hi Paul,

Thank you for your answer and for addressing my comments. I am fine with
all your proposed changes, with one observation.

> => [PAUL] RFC 8329 (Framework for Interface to Network Security Function)
is an
Informational RFC. If RFC 8329 is moved to Normative Reference, the ID-NITS
tool
(https://www6.ietf.org/tools/idnits) returns an error as follows:
“** Downref: Normative reference to an Informational RFC: RFC 8329”
Thus, we put RFC 8329 as an Informative Reference.

I am aware that placing  RFC 8329 as Normative creates a downref. This is
admitted provided that the issue is justified and registered as such ar LC
time. This is a non-blocking comment, anyway, so I will let you and the WG
decide.

Regards,

Dan

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 27 Jan 2022 01:34:00 +0900

Dan,
I see.

Thanks for your kind guide.

Best Regards,
Paul

2022년 1월 27일 (목) 오전 12:44, Dan Romascanu <[email-masked]>님이 작성:

> > => [PAUL] RFC 8329 (Framework for Interface to Network Security
> Function) is an
> Informational RFC. If RFC 8329 is moved to Normative Reference, the
> ID-NITS tool
>> --
===========================
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], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 26 Jan 2022 22:33:02 +0000

Hi!

From: Dan Romascanu <[email-masked]>
Sent: Wednesday, January 26, 2022 10:44 AM
To: Mr. Jaehoon Paul Jeong <[email-masked]>
Cc: General Area Review Team <[email-masked]>; [email-masked]; Last Call <[email-masked]>; [email-masked]
Subject: Re: [I2nsf] Genart last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-17

Hi Paul,

Thank you for your answer and for addressing my comments. I am fine with all your proposed changes, with one observation.

> => [PAUL] RFC 8329 (Framework for Interface to Network Security Function) is an
Informational RFC. If RFC 8329 is moved to Normative Reference, the ID-NITS tool
(https://www6.ietf.org/tools/idnits) returns an error as follows:
“** Downref: Normative reference to an Informational RFC: RFC 8329”
Thus, we put RFC 8329 as an Informative Reference.

I am aware that placing  RFC 8329 as Normative creates a downref. This is admitted provided that the issue is justified and registered as such ar LC time. This is a non-blocking comment, anyway, so I will let you and the WG decide.

[Roman] I believe that all reference to RFC8329 in the Section 4 (the YANG module) also include a reference to draft-ietf-i2nsf-capability-data-model which is a normative reference.  RFC8329 has additional background on understanding these particular fields in a larger architectural sense.

Regards,
Roman

Regards,

Dan

On Wed, Jan 26, 2022 at 3:23 PM Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dan,
Here is the revised draft of NSF-Facing Interface according to your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-18

Thanks.

Best Regards,
Paul

On Tue, Jan 25, 2022 at 7:26 PM Dan Romascanu via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Dan Romascanu
Review result: Ready with Issues

Summary:

Major issues:

Minor issues:

2. Section 4.

               type enumeration

Nits/editorial comments:

2. Section 4:

3. Section 4

identity memory-alarm

description

4. Section 4

    identity ot {
       base device-type;
       description

     identity vehicle {
       base device-type;
       description

5. Section 4

       base egress-action;
       description

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 28 Jan 2022 22:56:36 +0900

Hi Roman,
I have moved RFC 8329 from Informative References to Normative References
for
the five I2NSF YANG Data Model Drafts:

- I2NSF Capability YANG Data Model Draft
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-23

- I2NSF NSF-Facing Interface YANG Data Model Draft
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-19

- I2NSF Monitoring Interface YANG Data Model Draft
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-14

- I2NSF Consumer-Facing Interface YANG Data Model Draft
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-16

- I2NSF Registration Interface YANG Data Model Draft
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-14

Also, I have moved other RFCs and I-Ds, which are core references, from
Informative References to Normative References.

In addition, I have  moved other RFCs and I-Ds, which are relatively less
important references,
from Normative References to Informative References.

Thanks.

Best Regards,
Paul

On Thu, Jan 27, 2022 at 7:33 AM Roman Danyliw <[email-masked]> wrote:

> Hi!
>
>
>
> *From:* Dan Romascanu <[email-masked]>
> *Sent:* Wednesday, January 26, 2022 10:44 AM
> *To:* Mr. Jaehoon Paul Jeong <[email-masked]>
> *Cc:* General Area Review Team <[email-masked]>; [email-masked]; Last
> Call <[email-masked]>;
> [email-masked]
> *Subject:* Re: [I2nsf] Genart last call review of
> draft-ietf-i2nsf-nsf-facing-interface-dm-17
>
>
>
> Hi Paul,
>
>
>
> [Roman] I believe that all reference to RFC8329 in the Section 4 (the YANG
> module) also include a reference to draft-ietf-i2nsf-capability-data-model
> which is a normative reference.  RFC8329 has additional background on
> understanding these particular fields in a larger architectural sense.
>
>
>
> Regards,
>
> Roman
>
>
>
> Regards,
>
>
>
> Dan
>
>
>
>
>