Hi, To add to the reviews you've already had, here are my comments.
Thanks for the work, Adrian === Abstract s/in which/to which/ --- Introduction Expand NSF on first use --- I think your use of RFC 2119 language is not appropriate in this document. I suggest making everything normal lowercase English and deleting the two paragraphs at the top of Section 2. --- BSS, CDN, ICN, and OSS are not used in the document and can be removed from section 2.1. --- In 2.2, the term used in is "I2NSF Consumer" I suggest you write Consumer: Equivalent to "I2NSF Consumer" --- 3.1 has... The Consumer-Facing Interface is used to enable different users of a given I2NSF system to define, manage, and monitor security policies for specific flows within an administrative domain. In today's world, where everything is connected, preventing unwanted traffic has become a key challenge. More and more networks are implemented as a form of overlay network, with their paths or links among nodes being provided by other networks (a.k.a. underlay networks). The overlay network's own security solutions cannot prevent various attacks from saturating the access links to the overlay network nodes, which may cause various components of one or more overlay nodes (e.g., CPU or link bandwidth) to become overloaded, and unable to handle their own legitimate traffic. An I2NSF system can be used by overlay networks to request certain flow-based security rules to be enforced by underlay networks. This operates in a similar manner to how traditional networks use firewalls or IPS devices to enforce traffic rules. The I2NSF system can reduce, or even eliminate, unwanted traffic, which prevents unwanted traffic from consuming critical node resources. The same approach can be used by enterprise networks to request their specific flow security policies to be enforced by the provider network that interconnects their users. The location and implementation of I2NSF policies are irrelevant to the consumer of I2NSF policies. This nearly all seems like marketing talk to me. It probably isn't untrue, but it seems out of place in the section that is supposed to talk about the Consumer-Facing Interface. I think you could reduce to... The Consumer-Facing Interface is used to enable different users of a given I2NSF system to define, manage, and monitor security policies for specific flows within an administrative domain. The location and implementation of I2NSF policies are irrelevant to the consumer of I2NSF policies. If you wanted to merge the rest of the material in to Section 1, that would be OK, but equally, you could decide that Section 1 already says enough and just delete the surplus text. --- I'm struggling a little with .... 3.3. Registration Interface NSFs provided by different vendors may have different capabilities. In order to automate the process of utilizing multiple types of security functions provided by different vendors, it is necessary to have an interface for vendors to define the capabilities of their NSFs. This Interface Group is called the Registration Interface Group. An NSF's capabilities can either be pre-configured or retrieved dynamically through the Registration Interface Group. If a new function that is exposed to the consumer is added to an NSF, then those capabilities SHOULD be notified to security controllers via the Registration Interface Group. There is definitely an ambiguity about this. Is the section talking about the "Registration Interface Group"? What are the component interfaces in this group? --- 6.1. Network Connecting I2NSF Users and I2NSF Controller [TBD: should we add the Remote Attestation to this section?] I think you have added remote attestation and can remove this note. --- 6.2 The network connection between the Security Controller and NSFs can rely either on: Should you be making clear that in the open environment anything from a few up to all of the NSFs can be hosted in external administrative domains. Thus "closed" is very tightly defined, and "open" is anything that is not completely closed. --- I can't help thinking that section 9.2 is way too detailed for this document. I don't think there is anything wrong in what it says, but it looks more like an information model for a specific capability exchange than something that belongs in a general framework. Can you see whether there is a different document that this belongs in? _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
