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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Rob,
I will reflect your comments on the revision:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-30

I attach the revision letter for your reference.

If you have further comments, please let me know.

Thanks.

Best Regards,
Paul


On Mon, Apr 17, 2023 at 11:07 PM Rob Wilton (rwilton) <[e-mail]>
wrote:

> Hi Paul,
>
>
>
> I’ll clear my discuss.
>
>
>
> One further comment:
>
>
>
> 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.
>
> => [PAUL] Yes, it is possible to use “order-by-user”. As far as I know,
> most implementation does not actually define the order to match the rule
> for similar priority values, since the priority values are supposed to be
> the ones that define the order. The implementation itself can be chosen
> based on the order of the user’s specified list or based on the
> alphabetical order of the rule’s key (i.e., rule name). According to your
> comment, we updated the description text to be clearer as follows:
>
>
>
> I meant marking the containing list “rule” as “ordered-by user” rather
> than having a priority leaf that defines a partial order.  I don’t think
> that it would be helpful to have an “ordered-by user” list alongside a
> priority leaf.  I think that it should be one or the other.
>
>
>
> Regards,
>
> Rob
>
>
>
>
>
> *From:* Mr. Jaehoon Paul Jeong <[e-mail]>
> *Sent:* 15 April 2023 07:48
> *To:* Rob Wilton (rwilton) <[e-mail]>; Erik Kline <
> [e-mail]>; Dirk Hugo <[e-mail]>; Andrew Alston
> <[e-mail]>; Paul Wouters <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail]; skku-iotlab-members <
> [e-mail]>; Patrick Lingga <
> [e-mail]>; Mr. Jaehoon Paul Jeong <[e-mail]>
> *Subject:* Re: [I2nsf] Robert Wilton's Discuss on
> draft-ietf-i2nsf-consumer-facing-interface-dm-28: (with DISCUSS and COMMENT)
>
>
>
> Dear Robert Wilton, Erik Kline, Dirk Von Hugo, Andrew Alston, and Paul
> Wouters,
>
> Here is the revised draft to address all your comments:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-29
>
>
>
> I attach the revision letter.
>
>
>
> Thanks for your valuable comments.
>
>
>
> Best Regards,
>
> Paul
>
>
>
>
>
> On Thu, Apr 13, 2023 at 9:10 PM Robert Wilton via Datatracker <
> [e-mail]> wrote:
>
> 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
>
>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>