[I2nsf] Robert Wilton's Discuss on draft-ietf-i2nsf-consumer-facing-interface-dm-28: (with DISCUSS and COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-i2nsf-consumer-facing-interface-dm-28: Discuss

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/about/groups/iesg/statements/handling-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-consumer-facing-interface-dm/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for this document.  There is one issue that I think are worthy of
discussion:

(1) p 7, sec 3.2.  Condition Sub-model

   Case (firewall):  This field represents the layer-2 header (e.g., MAC
             addresses), layer-3 header (e.g., IPv4 or IPv6 addresses,
             ICMPv4 or ICMPv6 parameters, and transport layer protocol)
             and layer-4 header (e.g., port numbers) of the network
             traffic.  Note that the YANG module only provides high-
             level ICMP messages that are concretely specified by either
             ICMPv4 or ICMPv6 messages (e.g., Destination Unreachable:
             Port Unreachable which is ICMPv4's type 3 and code 3 or
             ICMPv6's type 1 and code 4).  Also note that QUIC protocol
             [RFC9000] is excluded in the data model as it is not
             considered in the initial I2NSF documents [RFC8329].  The
             QUIC traffic should not be treated as UDP traffic.  The
             data model should be extended or augmented appropriately to
             support the handling of QUIC traffic according to the needs
             of the implementer.

(2) p 8, sec 3.2.  Condition Sub-model

   Note that due to the exclusion of QUIC protocol in the I2NSF
   documents, HTTP/3 is also excluded in the document along with the
   QUIC protocol.  HTTP/3 should neither be interpreted as HTTP/1.1 nor
   HTTP/2.  The data model should be extended or augmented appropriately
   to support the handling of HTTP/3 traffic according to the needs of
   the implementer.

Is there a concrete plan for adding support for QUIC and HTTP/3, given that it
stated that these cannot be handled as UDP or HTTP/1.1 or HTTP/2?


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

(3) p 38, sec 6.1.  YANG Module of Consumer-Facing Interface

           leaf-list system-alarm {
             type identityref {
               base i2nsfmi:system-alarm;
             }
             description
               "The security policy rule according to
                system alarms.";
           }
         }
         container condition {
           description
           "Conditions for general security policies.";

Please include documentation here for the condition container as to how the
different fields are combined (i.e., that all configured conditions must match
for a rule to trigger).

(4) p 4, sec 3.  YANG Tree Diagram of Policy

   Resolution-strategy:  This field represents how to resolve conflicts
             that occur between actions of the same or different policy
             rules that are matched and contained in this particular
             NSF.  The resolution strategy is described in Section 3.2
             of [I-D.ietf-i2nsf-capability-data-model] in detail.

Given you document the default for language above, would it name sense to
document the default matching rule here as well?

(5) p 7, sec 3.2.  Condition Sub-model

   The Condition object describes the network traffic pattern or fields
   that must be matched against the observed network traffic for the
   rule to trigger.  The fields used to express the required conditions
   to trigger the rule are organized around the class of NSFs expected
   to be able to observe or compute them.  Figure 5 shows the YANG tree
   of the Condition object.  The Condition Sub-model SHALL have the
   following information:

I find the use of "Case" confusing in the descriptions below.  I mistakenly
thought that you were referring to the YANG case statements under choice, and
hence only one of these conditions can be expressed for a given rule.

(6) p 20, sec 6.1.  YANG Module of Consumer-Facing Interface

     identity fmr {

Using longer identity names for the resolution-strategies may make the module
more readable.  E.g. 'first-matching-rule' might be clearer than fmr.  If you
change this, then I would suggest changing it for the other
resolution-strategies as well (and the any default values).

(7) p 37, sec 6.1.  YANG Module of Consumer-Facing Interface

         leaf priority {
           type uint8;
           description
             "The priority of the rule to indicate the order of the
              rules to be matched. A higher value means a higher priority.
              The packet or flow will be matched with the rule with
              the highest priority value first and continues to a lower
              priority value. Once a rule matches the packet or flow,
              the NSF should execute the rule and terminate the matching
              process. If multiple rules have an equal priority, the
              actual order is undefined. The handling of the selection
              of those rules depends on the implementer, e.g., non-rule
              selection, first rule selection or random rule selection.";
         }

Did you consider using an "order-by-user" list to define the priority instead? 
I.e., process the rules in the order that they are specified in the list.

(8) p 39, sec 6.1.  YANG Module of Consumer-Facing Interface

                   error-message
                     "An end port number MUST be equal to or greater than
                      a start port number.";

I would suggest changing this to 'must', or otherwise you need to add the
standard RFC 2119 boilerplate to the YANG module (pyang can help with this).

(9) p 43, sec 6.1.  YANG Module of Consumer-Facing Interface

                 description
                   "This represents the repetition time.  In the case
                    where the frequency is weekly, the days can be
                    set.";

This comment is slightly misleading.  I would suggest deleting, or perhaps
rewording "In the case where the frequency is weekly, the days can be set.";"

(10) p 43, sec 6.1.  YANG Module of Consumer-Facing Interface

                 leaf-list date {

'date' is a somewhat confusing name for this.  Would 'day-of-month' be better?

(11) p 44, sec 6.1.  YANG Module of Consumer-Facing Interface

                 leaf-list month {

'month' is a confusing name for this.  Would 'month-and-day' be better?

(12) p 44, sec 6.1.  YANG Module of Consumer-Facing Interface

                   description
                     "This represents the repeated date and month of
                      every year.  More than one can be specified.
                      A pattern used here is Month and Date (MM-DD).";

So, if you wanted the policy to apply for a particular 3 weeks per year, then I
presume that it would be necessary to list each of those day separately?  Did
you consider allowing ranges here, or what that be too much complexity?

Regards,
Rob