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 <[email protected]> on behalf of "Diego R. Lopez"
<[email protected]>
Date: Saturday, October 22, 2016 at 4:42 AM
To: "[email protected]" <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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: [email protected]
Tel: +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
