Hi Diego,
El 22/10/2016 a las 13:05, Diego R. Lopez escribió:
> 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”.
>
[Gabi] ok
>> - 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.
[Gabi] I think removing the “provider" and “enterprise" references avoid
confusion, just suggesting .... “It is very possible that the underlay network
does not have the capability or resource to enforce the flow security policies
requested by the overlay network”
>
>> - 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.
[Gabi] Sure.
Regards, Gabi.
>
> Be goode,
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/ <http://people.tid.es/diego.lopez/>
>
> e-mail: [email protected] <mailto:[email protected]>
> Tel: +34 913 129 041
> Mobile: +34 682 051 091
> ----------------------------------
>
>
>
> _______________________________________________
> I2nsf mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/i2nsf
> <https://www.ietf.org/mailman/listinfo/i2nsf>
--
-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email protected] <mailto:[email protected]>
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
