Subject: [I2nsf] Comments/questions about draft-ietf-i2nsf-framework-03.txt

From: Gabriel Lopez <[email-masked]>
Date: Thu, 6 Oct 2016 12:52:37 +0200

Dear all,

Taking a look at the draft I have noted some comments.

**********

- “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?

- 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.

- Section 4. The terms “client” should be clarified here to avoid ambiguity.

- 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”

- 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.

- 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.

- 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”.

	- 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.

just my too cents.

Regards, Gabi.

-----------------------------------------------------------
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-masked] <mailto:[email-masked]>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sat, 22 Oct 2016 11:05:42 +0000

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-masked]<mailto:[email-masked]>> wrote:

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”.

DRL> Indeed. See above

DRL> Noted

- Section 7.1.

DRL> Thanks for the suggestion. I’ll work on it

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

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

DRL> Noted

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-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: Gabriel López <[email-masked]>
Date: Mon, 24 Oct 2016 16:13:06 +0200

Hi Diego,

El 22/10/2016 a las 13:05, Diego R. Lopez escribió:
>> On 6 Oct 2016, at 12:52 , Gabriel Lopez <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
[Gabi] ok
> 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”

> 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.

> http://people.tid.es/diego.lopez/ <http://people.tid.es/diego.lopez/>
> 
> e-mail: [email-masked] <mailto:[email-masked]>
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> _______________________________________________
> I2nsf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>