Hi Gabi, With the due apologies for the delay in replying (due to a period dedicated to project calls, you know how it is…) let me try to address your comments inline below.
On 6 Oct 2016, at 12:52 , Gabriel Lopez <[email protected]<mailto:[email protected]>> wrote: - “This draft proposes that a capability interface to NSFs can be developed on a flow-based paradigm….” - What about the other three interfaces: registration, monitoring and notification? DRL> We have to align the text with the recent agreements on the different interfaces and their naming. At the moment of the writing of that paragraph “capability” was a synonym of “NSF-facing”. - Section 3.3 talks about the “Registration Interface” communicating the Security Controller and the Developer’s Mngt systems, and Section 3.2.1 also talks about “Registration Interface” but now referring to the communication between the Security Controller and the NSF. - Interface’s name should be change here. DRL> Indeed. See above - Section 4. The terms “client” should be clarified here to avoid ambiguity. DRL> Noted - Section 7.1. -In the last example, the text says: - An Event can be "the client has passed AAA process"; → the term client should also be clarified, do you mean “end user”, “endpoint”? - I like the example based on IPsec, but I think the example could be something like (just suggesting): • Event: “traffic type X detected” • Condition: “from domain-A to domain-B” • Action: “Establish an IPsec tunnel” DRL> Thanks for the suggestion. I’ll work on it - In general, sometimes IPS/IDP examples are used, sometimes IPsec ones, sometimes Firewalls o DDoS, but they are not related from one section to another. I suggest to make use of one or two running examples across the whole document. DRL> Good point. I’d say the reason comes from the fact that the current document combines contributions from several others. I’ll go through it trying to align examples, or justifying the use of a different one in a particular section. - Section 8 - This sentence “It is very possible that the underlay network (or provider network) does not have the capability or resource to enforce the flow security policies requested by the overlay network (or enterprise network)” is quite confusing. - The association between underlay/provider and overlay/enterprise is not described. DRL> I think the association is clear, as an implicit one backed by common practice, but if you can you suggest a better wording it would be welcome. - Section 9. - Section 9.1 -In this section Firewalls, IPS and IDS are described but it seems more a closed list rather than examples. I think it should be clarified. BTW, security gateways (IPsec) may be included in the list of “commonly deployed NSF”. DRL> Noted - Section 9 is labelled “Registration consideration” but talks about “traffic characterization” - What “Registration” means here? capability registration? security services? and why it is related with traffic characterization should be described. DRL> The section is intended to consider the aspects related to public registries, typically run by IANA. You are right this is not clear in the text. I will update the introduction to this section. I plan to update the draft during the coming days, trying to address your comments and suggestions, as well as others. Stay tuned. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
