John,
All we need is to have two different names to differentiate
- Set of rules with Users/tenants oriented attributes
- Set of rules that are applied to NSFs (i.e. port/addresses based).
Consumer facing and NSF facing would be good, but with the definition for
“Consumer” in the terminology draft , “consumer” can also mean controller
consuming NSFs (i.e. the NSF facing interface). If we use the “consumer facing
interface”, can you modify the definition for “consumer”?
Consumer: A Consumer is a Role that is assigned to an I2NSF
Component that can receive information from another I2NSF
Component. See also: Provider, Role.
Thanks, Linda
From: John Strassner [mailto:straz...@gmail.com]
Sent: Wednesday, October 19, 2016 2:10 AM
To: Linda Dunbar <linda.dun...@huawei.com>; John Strassner <straz...@gmail.com>
Subject: Re: you could be correct, but we are dealing with a group of people
who commonly interpret "Interface" as "port"
I'm confused.
There is no argument about Consumer-Facing and NSF-Facing Interfaces.
Do you want two different names for the Capability Interface, one for
Consumer-Facing and one for NSF-Facing Interfaces? Or do you want something
else?
I am troubled that the list is silent.
regards,
John
On Tue, Oct 18, 2016 at 6:27 PM, Linda Dunbar
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:
John,
You can be correct. But the Interim meeting, most people expressed the desire
of using “interface” to mean the “port” on the controller: one port facing user
(i.e. the User/client facing interface), another port facing NSFs (NSF-Facing
interface).
Sept 13 meeting minutes:
Final agreement: We
Two interfaces
- Consumer/Client Facing Interface
- NSF Facing Interface
Within these we have "sets of operations"
One of these sets is the "Capabilities set of operations"
At the time I didn’t realize that “consumer” also applicable to “Controller”
consuming the NSFs. That is why I want to use a different term.
All we need is to have two different names to differentiate
- Set of rules with Users/tenants oriented attributes
- Set of rules that are applied to NSFs (i.e. port/addresses based).
Let’s use have two names and move forward.
Can you give me a call?
Thanks, Linda
From: John Strassner [mailto:straz...@gmail.com<mailto:straz...@gmail.com>]
Sent: Tuesday, October 18, 2016 2:19 PM
To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Cc: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>;
Adrian Farrel <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>; John Strassner
<straz...@gmail.com<mailto:straz...@gmail.com>>
Subject: The (in)famous Capability Interface
Hi all,
recently, a number of questions have been raised about the Capability
Interface. There are two sources of confusion:
1) What, exactly, is an "interface"? Can we use a different word instead of
interface?
2) Why do we need another interface (or similar word)?
Clarifying the first issue.
A number of people have stated that to them, an "interface" is synonymous with
"communication". This is NOT what was meant when this I-D was written. Indeed,
the definition of Interface, from that I-D, is as follows:
Interface: A set of operations one object knows it can invoke on,
and expose to, another object. It is a subset of all operations
that a given object implements. The same object may have multiple
types of interfaces to serve different purposes. An example of
multiple interfaces can be seen by considering the interfaces
include a firewall uses; these include:
* multiple interfaces for data packets to traverse through,
* an interface for a controller to impose policy, or retrieve
the results of execution of a policy rule.
See also: Consumer Interface, I2NSF Interface, Provider Interface
Note that the above definition implies a **shared boundary** across which two
entities send and/or receive data. In other words, what's important is the set
of standard operations that can be invoked, and **not** the fact that this is a
form of communication.
Clarifying the second issue.
The reason that a separate interface for exchanging capability information was
proposed is to minimize the attack surface. The capability interface is for
exchanging **all** capabilities, so that two entities may negotiate and agree
on what set of capabilities will actually be used. Clearly, this is different
than operation on either the consumer-facing or NSF-facing interfaces, since
those interfaces are constrained to using **only** the set of capabilities that
have been agreed upon to use. This follows the well-known Principle of Least
Privilege (i.e., in a particular abstraction, every function must be able to
access **only** the information and resources that are necessary for the
legitimate purpose of that function.
Exposing the set of **all** capabilities over a widely used interface (like the
consumer- or NSF-facing interfaces) is a **bad idea**. It risks an attacker
understanding the complete set of capabilities of the system. Furthermore, from
a software componentization point-of-view, there is a significant difference
between exposing and negotiating between the set of all capabilities (which is
the purpose of the Capability Interface) and simply using a selected set of
capabilities (which is the purpose of the consumer-facing or NSF-facing
interfaces).
I hope this clarifies these two issues. I'll wait a couple of days before
issuing the next update to the Terminology Draft.
best regards,
John
--
regards,
John
--
regards,
John
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
