Re: [I2nsf] comments about I2NSF framework draft://Progress with draft-ietf-i2nsf-framework-05

["Ganduri, Rajasekhar" <[e-mail]>]

Yes, I think this is something we can use as our foundation with some minor changes as suggested by Christian. Overall, this looks as a good document.



________________________________
From: [e-mail] <[e-mail]>
Sent: Monday, May 29, 2017 7:49 AM
To: [e-mail]; [e-mail]
Subject: Re: [I2nsf] comments about I2NSF framework draft://Progress with draft-ietf-i2nsf-framework-05

Hello WG,

I agree with Adrian that this document looks sound overall. Here's a few minor comments/questions for clarification/nits from my side.

1. Section 1 (end of first paragraph):
* Not sure I understand what lies beneath the "internal functionality" of NSFs - wouldn't "capabilities" be sufficient?

2. Section 3.2 (bottom of page 6):
* The "Hence, this abstraction..." sentence reads a bit fuzzy and complicated to me. Did you mean: "Hence, this abstraction enables NSF features (or a subset thereof) to be treated as building blocks by an I2NSF system: thus, developers..."? If so, I would rephrase accordingly.
* I would suggest s/Interface to flow-based NSFs/interfaces to flow-based NSFs" (top of page 7)
* s/dedcribed/described
* Expand DOTS (Distributed-Denial-of-Service Open Threat Signaling) and provide a reference to the DOTS architecture draft
* It seems to me there is a slight overlap between the Monitoring and the Notification I/F Groups, since the former explicitly indicates that the I/F could be a report-based I/F, whereas the latter is meant to receive notification events, which could be seen as a specific instantiation of reports. Besides, upon receipt of a notification or a report (in the case of the Monitoring I/F Group), the controller may take actions accordingly. Maybe one option to clarify this would consist in merging both groups with the appropriate elaboration about reports and notifications?

3. Section 3.3 (bottom of page 7):
* s/An NSF's capabilities/NSF capabilities

4. Section 4 (middle of page 8)
* s/usermay/user may
* Not sure what is meant by "the while provider platform - the whole I2NSF system? If so, I would be more specific.
* The "The authentication between the user..." sentence (bottom of page 8) reads strange to me and introduces a qualitative comment which I believe out of scope. Did you mean: "Mutual authentication between ISNF users and the ISNF system (or a subset of the NSF functions it controls) is required to reduce the risk of NSF-targeted (DDoS) threats." I also think that this notion of NSF attestation should be clarified, especially when a user is not cleared to perform such attestation (but may be granted access to some NSFs for the enforcement of his/her security policy. Likewise, An NSF instance (configuration) may be altered because the I2NSF system made a decision, e.g., according to a network-originated event but without jeopardizing the behavior of the said NSF: what becomes the value of the attestation in that context? I think this last sentence of section 4 should be either carefully developed (possibly in a specific section) around the notions of user clearance, user profiles, attestation, global consistency of the I2NSF system, or deleted.

5. Section 6.1:
* s/maybe/may be (top of page 10, first paragraph)

6. Section 6.2:
* s/used/by using (bottom of page 10)
* s/trusted channels as described in the previous section/the trusted connection mentioned in Section 6.1

7. Section 6.3:
* The statement of the first bullet can also apply to physical NSFs: I fail to see why vNSFs differ from that standpoint.
* s/polices/policies (second bullet)
* s/Policies to one vNSF/Policies enforced by one vNSF instance
* The cluster design depicted in Figure 2 suggests a few lines about the need for global consistency, and especially coordination between NSF managers of different clusters, especially when a same vNSF (instance) may be invoked by both NSF managers.

8. Section 7:
* s/etc/etc. (bottom of page 12)
* I would delete "simple" in the last sentence of the section
* s/specify/specific (before "profile")

9. Section 7.1:
* I would delete "simple" before "user" (bottom of page 13) and would rephrase the sentence like: "I2NSF user flow policies should have a similar structure as NSF policies, but with user-specific semantics (e.g., description of the packet contents, description of the ECA-based rules, etc.)."
* s/IPSec/IPsec (bottom of page 13)

10. Section 8:
* s/resource/resources (bottom of page 15)
* I would rephrase the "Therefore, it is very important..." sentence as: "It is therefore required that the I2NSF system supports dynamic discovery capabilities as well as a query mechanism so that the I2NSF system can expose the security services and their corresponding parameters it supports to the user, possibly yielding negotiation capabilities between the user the I2NSF system provider (or security service provider). Such dynamic negotiation between a user (including a 3rd party) and the I2NSF system provider is meant to facilitate the delivery of the required security service: the outcomes of such negotiation would indeed feed the I2NSF computation logic to dynamically allocate NSF resources and enforce security policies that accommodate the user requirements."

11. Section 10:
* I would remove "i.e., the last bullet listed above" part of the sentence.

12. Section 11:
* I would rephrase the first sentence as "NSF control and monitoring demand trustworthy, robust and fully secured access."

Cheers,

Christian.

-----邮件原件-----
发件人: I2nsf [mailto:[e-mail]] 代表 Adrian Farrel
发送时间: 2017年5月19日 1:49
收件人: [e-mail]
主题: [I2nsf] Progress with draft-ietf-i2nsf-framework-05

Hi WG,

I am about to do a document shepherd review prior to starting a WG last call. In conversation with Linda just now I think I spotted a few areas where I am going to make chunky suggestions for additional text, but overall the document looks sound.

If you care deeply about this work and haven't looked at the framework for a while, now would be a good time. Don't wait for WG last call.

Thanks,
Adrian



_______________________________________________
I2nsf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________
I2nsf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2nsf


_______________________________________________
I2nsf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2nsf

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.