Hi Daniel, Please see my comments inline: Thanks for your comments.
发件人: I2nsf [mailto:[email protected]] 代表 Daniel Migault 发送时间: 2016年8月15日 21:52 收件人: [email protected] 主题: [I2nsf] comments on draft-basprez-i2nsf-capabilities-00 Hi, Please find my comments reading the document. In addition to these comments I have two questions regarding the policy model. The draft provide example for a policy where actions are "deny" or "allow". I am wondering if I2NSF considers also more complex actions and be a service such as "anti-dns-reflexion-attack" - or if there is a preferred way to do this? [Frank]: right now, for I2NSF capability interface, various actions are supported, i.e., allow, deny, call a function, redirect, send notification, URL, etc, and it is not exhausted and can be added as individual value to action attribute any time. For your suggestion, I think it makes sense. But I suggest to define this kind of service actions for the service interface (customer-facing interface), since they are more appropriate to be used for this interface. In addition, although the draft is describing policies, but is there any "future work" or intentions to model strategies. In other words, do we think that strategies will have their own structure or do we expect strategies being described vi the policies conditions? [Frank]: what exactly do you mean for strategies here? Are they like the condition resolution strategies below? Or other examples? BR, Daniel 3. Policy model """ Moreover, it is known that packet filter rules are prioritized and it is possible to specify a default action. More precisely, packet filters implement the First Matching Rule (FMR) or Last Matching Rule (LMR) resolution strategies. """ My understanding is that the document provides an abstract way to describe policies. It is not clear to me weather LMR or FMT are part of the policies themselves. I think what confuses me is that LMR or FMT are not part of policies, but instead related to how to interpret a "set of policies" in which case it would not be a parameter of a single policy. What is not clear to me is whether LMR FMT are part of the policies (implicit or explicit), or the implementation of the policies - that is given a set of policies, and the southbound NFS the implementation the controller uses one or the other. [Frank]: Firstly, I support that I2NSF policy should include the condition resolution strategies since the requirement is solid and it is indeed useful. In other, this strategy is part of the i2nsf policy. Secondly, I don’t get what is your real concern. For example, what is the difference between implicit or explicit way? Could you clarify more? """ For instance, in Figure Figure 1 the conditions are s1 [ S1 (read as s1 subset of S1) and s2 [ S2 (s1 subset of S2), both s1 and s2 match the packet x1, while only s2 matches x2. """ The sentence needs some nits "Figure" is repeated and ther eis a "]" missing. I also find the notation confusing. From the text this is what I understand: s1 is a condition. On the other hand I also understand that s1 is the value of the selector that is testes against S1 the subset of accepatble values. It also seems to me that index for packets and those used for the selectors are different and so it may be better to use a different notation. I might by wrong but here is the text I would expect: NEW TEXT: """ A condition selector c(S, x.s) is met with packet x if the selector s from x is a subset of S. For instance, in Figure 1 the multiselector condition is expressed as the intersection of selector conditions c([IP_start, ..., IP_stop], x.ip_src) and c([port_start, ..., port_stop], x.port_dst). """ Some nits should be corrected from the line above. c = s1 X s2 X ... X sm [ S1 \times S1 X S2 X ... X Sm = S I also suggest that if you are using a specific notation with [] you explicitly provide the explanation of the notation. It seems you use the notation and then add text to clarify the use of it. I beleive this could be done once for all and have formal and informal description separated. In the text below, it is not clear to me how the use of chain can be used as how it could be added. Maybe some additional text could clarify this. """ However, security controls may have specific characteristics that automatic processes or administrators need to know when they have to generate configurations, like the available resolution strategies and the possibility to set default actions. We have ignored, to simplify this presentation, options to generate configurations that may have better performance, like the use of chains or ad hoc structures [Taylor]. However, security controls may have specific characteristics that automatic processes or administrators need to know when they have to generate configurations, like the available resolution strategies and the possibility to set default actions. We have ignored, to simplify this presentation, options to generate configurations that may have better performance, like the use of chains or ad hoc structures [Taylor]. Adding support to these forms of optimization is certainly feasible with a limited effort but it was outside the scope of this paper, that is, to show that adding security awareness to NFV management and orchestration features is possible. It is one of the task for future work. """ section 4.1 time structure has not been defined.
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
