Subject: [I2nsf] Robert Wilton's No Objection on draft-ietf-i2nsf-nsf-facing-interface-dm-21: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 17 Feb 2022 04:38:30 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-i2nsf-nsf-facing-interface-dm-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document.  I have a few relatively minor comments:

3.2.  Event Clause

 - It looks like your tree diagram is reproduced twice?

 3.3.  Condition Clause

How do the conditions combine?  E.g., if I set both fields in ipv4 and ipv6 in
the same rule?  Is the requirements that all fields set in the condition must
match for the rule to be evaluated?  Perhaps this could be clarified here, and
in the description of the condition container in the YANG module.

In terms of the YANG:

     identity priority-by-order {
       base priority-usage;
       description
         "Identity for priority by order. This indicates the
          priority of a security policy rule follows the order of the
          configuration. The earlier the configuration is, the higher
          the priority is.";
     }

Except for the base identities, where it helpful for the description to make it
clear that it is a base identity, I don't think that you need text like
"Identity for priority by order", although strictly is does no harm either. 
I'll leave it to the authors to decide whether they change this, but if you do,
then please consistently change it for all non base identities.

     identity disk-alarm {
       base system-alarm;
       description
         "Identity for disk alarm. Disk is the hardware to store
          information for a long period, i.e., Hard Disk and Solid-State
          Drive. A disk-alarm is emitted when the disk usage is
          exceeding a threshold.";
       reference
         "draft-ietf-i2nsf-nsf-monitoring-data-model-14: I2NSF NSF
          Monitoring Interface YANG Data Model - System alarm for disk";
     }

Would "storage-alarm" be a better generic name than disk-alarm?

     identity device-type {
       description
         "Base identity for types of device. This identity is used for
          type of the device for the source or destination of a packet
          or traffic flow.";
       reference
         "draft-ietf-i2nsf-capability-data-model-26:
          I2NSF Capability YANG Data Model";
     }

I assume that in many cases, particular packet flows, then NSF would not be
able to know what type of device it was?  I wasn't quite sure how this would
work.

     identity redirection {
       base egress-action;
       description
         "Identity for redirection. This action redirects the packet to
          another destination.";
     }

Could the description clarify the difference between redirection and forwarding
please?

5.  XML Configuration Examples of Low-Level Security Policy Rules

Should all the example rules have the same name?  Would they be expected to
have different names?

Am I right in understanding that a rule in figure 6 (or 7) are combined with
the rule in figure 8.  If so, what in the policy actually binds these together
so that the NSFs know to work together?  Is it the common name that binds them
all together?  If both v4 and v6 are handling by the same device then you can't
have two list entries in the same list with the same key.

Regards,
Rob