Hi, I want to thank Diego and John for useful suggestions and comments. We have incorporated most of the changes suggested here (some of them verbatim).
We also did a thorough analysis of the document and removed/modified any confusing and incorrect text. We have done following changes across the board: 1. Change developer back to vendor, I see even other working group draft are using this term. The “developer” caused confusion as rightly pointed by John. 2. Change “user-intent” to “user-construct”. Even though, authors have some reservation, but in light of showing consensus we changed it. I could not find better term to describe what we want to accomplish. I just posed the updated draft https://tools.ietf.org/html/draft-kumar-i2nsf-client-facing-interface-req-02 with above changes. Regards, Rakesh From: I2nsf <i2nsf-boun...@ietf.org> on behalf of "Diego R. Lopez" <diego.r.lo...@telefonica.com> Date: Saturday, October 22, 2016 at 4:42 AM To: "i2nsf@ietf.org" <i2nsf@ietf.org> Subject: Re: [I2nsf] with regarding to WG adoption for the revised draft-kumar-i2nsf-client-facing-interface-req-01.txt Hi, When going through the document I found that most of my original comments were addressed and therefore I was not going to object adoption, taking into account the urgency that many in the WG see for this adoption, but after reading John’s comments I think there are a couple of issues that require further discussion before. The first and foremost is the question of intent and how the term is used and developed in the document, as this is a term that cannot be considered only in the realm of this document, and in the current version the definition of what intent is and the proposed constructs seems key for the evolution of the draft. The second, that I must confess I originally overlooked but I see as a serious aspect, is the discussion on how this draft is going to be combined with other existing ones that predate it and that also include requirements. I support John’s request of a detailed discussion and agreement at least in these two points, that I think that are essential. A few other comments inline below. I’ve trimmed John’s original message to make text more readable. On 20 Oct 2016, at 09:21 , John Strassner <straz...@gmail.com<mailto:straz...@gmail.com>> wrote: * You continue to say that the "interfaces are based on user-intent instead of ..." but do not define what user-intent is * The "definition" in the paragraph above section 2 on page 4 doesn't make sense. You state that it is not "some free-form natural language", but rather "client-oriented expressions such as application names, application groups, device groups, user groups etc." - this is starting to describe a language, which is completely out of scope of I2NSF * You continue "with a vocabulary of verbs (e.g., drop, tap, throttle), prepositions, conjunctions, conditionals, adjectives, and nouns instead of using standard n-tuples from the packet header" - you are now describing a language that looks a lot like English, but have not defined either the grammatical rules for using such language elements, or where these come from and how they are defined (plus, it is completely out of scope of I2NSF) * Worse, you allude to mapping intent to device functions, but do not describe how this is done DRL> In a separate discussion with Rakesh I suggested to refer to an external definition of intent, well accepted in the networking community (I think Sue can be of an invaluable help for this) and consider the list of constructs as requirements of what a proper support of intent would have to provide. Instead of defining the language (mandating constructs) the draft would define what any proper language should have to incorporate, in the spirit of a requirements document * Section 1 * Your use of "developer" is confusing. For example, "developer's specific devices" is not (I hope) what you mean - I'm a developer and I don't have a device; in fact, I write programs for devices from multiple vendors. * The bulk of section 1 assumes a "single developer" approach, which is, as you say, not valid. What I **think** you are talking about is a single development environment. However, this needs to be substantiated. DRL> I feel guilty for this. I insisted in having the term “vendor” substituted by “developer” through the whole document, to reflect that NSFs could be provided as open-source software. Facing how this substitution works, I agree we need to think in more detail where to use each term. * The 2nd paragraph above section 2 on page 4 ("In order to...working group") doesn't make sense. You allude to ease (not easiness), but then say that this is completely out of scope. What, then, is the point you are trying to make? DRL> Reading the draft for the first time I had the same impression. I’d propose an alternate writing: “In order to ease the deployment of security policies across different developers and devices, the Interface to Network Security Functions (I2NSF) working group in the IETF is defining a client-facing interface from the security controller to clients [I-D. ietf-i2nsf- framework] [I-D. ietf-i2nsf-terminology]. Deployment facilitation should be agnostic to type of device, be it physical or virtual, or type of the policy, be it dynamic or static. Using these interfaces, it would become possible to write different kinds of application (e.g. GUI portal, template engine, etc.) to control the implementation of security policies on security functional elements, though how these applications are implemente are completely out of the scope of the I2NSF working group, which is only focused on the interfaces" * Section 3.2 * The first bullet ("Agnostic of network topology and NSF location in the network") conflicts with the principles expressed in section 3.1 * The second bullet (*Agnostic to the features and capabilities supported in NSFs") doesn't make sense to me. If I was defining either an API or a language for I2NSF, I would choose nouns and verbs based upon a set of expected capabilities. Referring to DDoS as "foo" does no one any good. * Fourth bullet ("Agnostic to the network function type...) is unclear; is "routing" or "forwarding" an agnostic term? DRL> I wonder whether using a term other than “agnostic” could make things clearer in these points. In my understanding we could substitute the problematic clauses by: * “Not depending on particular topology properties or on the actual NSF location in the network” * “Not requiring the exact knowledge of the concrete features and capabilities supported in the deployed NSFs” * “Independent of the nature of the function that will apply the expressed policies” Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lo...@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf