Hi Linda, As I said, all of the examples are not really **clients**, but **servers** (I view the admin as having a "server" role, since the admin is using at least one application to configure or monitor functionality).
I'm not sure if this is a "better" name, but I am a distributed systems person, and to me, "client" implies "client-server" computing. I see no reason to restrict (or imply a restriction of) I2NSF to this model of computing. I personally prefer "peer". An even more neutral term would be "requestor" (vs "provider"). best regards, John On Sun, Jun 26, 2016 at 6:28 AM, Linda Dunbar <linda.dun...@huawei.com> wrote: > John, > > > > The draft-ietf-i2nsf-framework has those examples of I2NSF clients: > > · An overlay network Mgr (e.g. Video Conference Network Mgr) who > needs to dynamically inform the underlay network to allow, rate limiting or > deny flows (some of which are encrypted) based on specific fields in the > packets for a certain time span. > > · Enterprise Administrators and management system need to request > provider network to enforce some rules to their specific flows. > > · A IoT management system sending requests to underlay network to > block flows that match their specific conditions. > > > > Simply put, “I2NSF client” can be users (administrators), different domain > manager, orchestration system, or others, who need to specify their > desired flow policies. > > > > Is there a better name? > > > > > > Linda > > > > *From:* John Strassner [mailto:straz...@gmail.com] > *Sent:* Saturday, June 25, 2016 9:02 PM > *To:* Linda Dunbar; John Strassner > *Cc:* I2NSF@ietf.org > *Subject:* Re: [I2nsf] Should we call "South Bound Interface" for the > interface between "controller <-> NSF", and "North Bound Interface" for the > interface between "Client <-> controller"? > > > > Hi Linda, > > > > During the I2NSF early stage (before the WG was created), "capability > interface" was used to represent the interface between controller <-> NSF, > and "service interface" was used to represent the interface between the > Client <-> controller. > > <jcs> > The term "capability interface" doesn't bother me. However, I don't think > that we are using it to its full potential - see below. > > The term "client interface" does bother me, because > 1) to me, it implies a client-server architecture (or a 3-tier > architecture on a stretch), and I don't understand why we should be limited > to that > 2) what is the client? To me, a client is a host. Aren't we talking > about the application here? The examples in your figure are arguably > SERVERS, > not CLIENTS. :-) > </jcs > > As many people use the terminologies loosely, the "Capability Interface" > being interchangeably used with "Capability Layer", and "Service Interface" > being interchangeably used with "Service Layer". > > <jcs> > Warning, this is probably just me, but... > > ...I do NOT like "layers", because abstractions should work for > everything, not just sometimes. Look at our "layers" - we repeatedly > violate the true notion of a layer (e.g., MPLS). Look at all of the > "inter-layer" compatibility problems we've had over the years. Why do we > need to use layers in I2NSF? I would strongly argue to use "interface"; if > that is not acceptable, then choose a different term (e.g., planes) that > does not have the traditional limitations of layers. > </jcs> > > The I2NSF Terminology Draft has defined the "Capability Layer" > (independent of which interface to the controller) for exposing the > capability of a domain (over Client Facing Interface), or for exposing > the capability of a NSF (over the NSF Facing Interface). > > By this definition, ECA Policy’s "Event" capability can be discovered > independently from the "Condition" capability, or "Action" capability. > > <jcs> > Sorry, I disagree. > > Events, conditions, and actions are NOT capabilities. Capabilities are > defined in the Capabilities Draft as: > > Capabilities are functions that NSFs can perform. This interface > is used to advertise, select, and activate capabilities of selected > NSFs in a vendor-independent manner. > > Put another way, Capabilities are used to define functions that MAY be > used. There is no guarantee that they will be actually used. Furthermore, > Events, Conditions, and Actions are used to construct an ECA policy rule. > Events, Conditions, and Actions are types of Boolean statements (at least > in ECA rules) and have nothing to do with Capabilities. > > While you MAY be able to relate a rule to Capabilities, they are two > completely separate things. > </jcs> > > Therefore, continue using the “Capability Interface” can cause more > confusion in the future as its sound is too close to the “Capability > layer”. > > > <jcs> > Agree. So let's get rid of Capability **layer**. It isn't a layer, > because... > > > > ...wait for it... > > > > ...Capabilities could be used to describe NSF functions as well as > Controller functions. Thus, there is no "layer" in the classical definition > of the term "layer". > </jcs> > > > > Therefore, we are asking people to state which of the following options > should be used: > > > > 1. Use “Client Facing Interface” for "Client <-> controller"; and > “NSF Facing Interface” for "controller <-> NSF", > > 2. Use “Controller North Bound Interface” for "Client <-> > controller"; and “Controller South Bound Interface” for “controller <-> > NSF", or > > > > Or you can provide a better option. > > > > <jcs> > > I choose option 3. :-) > > > > The problem with "Client-Facing Interface" is that I'm not sure what a > "Client" is in NSF. > > NSF-Facing Interface is OK; my problem is, why are we introducing Yet > Another Term? > > > > The problem with Northbound and Southbound is that there is no clear > "north" and "south" here. Look at all of the projects that propose various > data models at both the device interface level AND the network management > application layer. So tell me, which is "south" here? :-) > > > > Now, as for option 3, I'm thinking about it. However, I do think that you > have spotted an important inconsistency, so let's take time to fix it and > not rush into rash decisions. > </jcs> > > > > best regards, > > John > > > > > > > > On Thu, Jun 23, 2016 at 3:31 PM, Linda Dunbar <linda.dun...@huawei.com> > wrote: > > I2NSF WG: > > > > Need your opinion for a good name to represent “Client Facing Interface” > and “NSF Facing Interface” of the I2NSF reference model: > > +-----------------------------------------------------+ > > | I2NSF Client | > > | E.g. Overlay Network Mgnt, Enterprise network Mgnt | > > | another network domain’s mgnt, etc. | > > +----------+------------------------------------------+ > > | > > | Client Facing Interface > > | > > +-----+---------------+ > > |Network Operator mgmt| +-------------+ > > | Security Controller | < --------- > | Developer’s | > > +----------+----------+ Registration | Mgnt System | > > | Interface +-------------+ > > | > > | NSF Facing Interface > > | > > +----------------------+----------------------------+ > > | | > > | | > > +---+--+ +------+ +------+ +--+---+ > > + NSF-1+ ------- + NSF-n+ +NSF-1 + ----- +NSF-m + . . . > > +------+ +------+ +------+ +------+ > > > > Vendor A Vendor B > > > > > > During the I2NSF early stage (before the WG was created), "capability > interface" was used to represent the interface between controller <-> NSF, > and "service interface" was used to represent the interface between the > Client <-> controller. > > > > As many people use the terminologies loosely, the "Capability Interface" > being interchangeably used with "Capability Layer", and "Service Interface" > being interchangeably used with "Service Layer". > > > > The I2NSF Terminology Draft has defined the "Capability Layer" > (independent of which interface to the controller) for exposing the > capability of a domain (over Client Facing Interface), or for exposing > the capability of a NSF (over the NSF Facing Interface). > > By this definition, ECA Policy’s "Event" capability can be discovered > independently from the "Condition" capability, or "Action" capability. > > > > Therefore, continue using the “Capability Interface” can cause more > confusion in the future as its sound is too close to the “Capability > layer”. > > > > Therefore, we are asking people to state which of the following options > should be used: > > > > 1. Use “Client Facing Interface” for "Client <-> controller"; and > “NSF Facing Interface” for "controller <-> NSF", > > 2. Use “Controller North Bound Interface” for "Client <-> > controller"; and “Controller South Bound Interface” for “controller <-> > NSF", or > > > > Or you can provide a better option. > > > > Thanks, Linda > > > > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > -- > > regards, > > John > -- regards, John
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
