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 _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
