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) <[email protected]> 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 <[email protected]> > *Sent:* 15 April 2023 07:48 > *To:* Rob Wilton (rwilton) <[email protected]>; Erik Kline < > [email protected]>; Dirk Hugo <[email protected]>; Andrew Alston > <[email protected]>; Paul Wouters <[email protected]> > *Cc:* The IESG <[email protected]>; [email protected]; skku-iotlab-members < > [email protected]>; Patrick Lingga < > [email protected]>; Mr. Jaehoon Paul Jeong <[email protected]> > *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 < > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > >
Revision-Letter-for-Consumer-Facing Interface-30-20230417.pdf
Description: Adobe PDF document
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
