I am starting to update the terminology draft, and will send to my co-authors first and then to the list.
best regards, John On Thu, Jun 30, 2016 at 6:06 AM, Linda Dunbar <linda.dun...@huawei.com> wrote: > Diego, > > > > Got it. Can the I2NSF Terminology authors update the draft to reflect it? > > > > Thanks, Linda > > > > *From:* Diego R. Lopez [mailto:diego.r.lo...@telefonica.com] > *Sent:* Thursday, June 30, 2016 8:00 AM > *To:* Linda Dunbar > *Cc:* John Strassner; I2NSF@ietf.org > *Subject:* Re: Is "Requester " a better name? (was RE: [I2nsf] what is > the "client" to I2NSF controller? > > > > Hi Linda, > > > > I’d say the former you name is what I’d call the “consumer” or > “requester”. And that the second is the controller. Or am I missing > something? > > > > Be goode, > > > > On 30 Jun 2016, at 15:54 , Linda Dunbar <linda.dun...@huawei.com> wrote: > > > > John and Diego, > > > > Thank you very much for the explanation. > > > > We probably need to further differentiate the following two requesters > because one is Flow Security Policy over a domain and the other is a Flow > Security Policy in an individual NSF. > > - “Requester for Flow Security Policies from a Controller” which > can have higher level condition matching, such as Tenant/customer ID, or > higher level event such as if the Tenant is AAA certified. > > - “Requester for Flow Security Policies from an individual NSF” > which matches on concrete fields of packets or state of the flows. > > > > Thanks, Linda > > > > *From:* Diego R. Lopez [mailto:diego.r.lo...@telefonica.com > <diego.r.lo...@telefonica.com>] > *Sent:* Thursday, June 30, 2016 1:26 AM > *To:* John Strassner > *Cc:* Linda Dunbar; I2NSF@ietf.org > *Subject:* Re: [I2nsf] what is the "client" to I2NSF controller? (was RE: > Should we call "South Bound Interface" for the interface between > "controller <-> NSF", and "North Bound Interface" for the interface between > "Client <-> controller"? > > > > I agree with John’s suggestions, and just to add another option we could > talk of “consumers” and “providers” (of I2NSF services) > > > > Be goode, > > > > On 30 Jun 2016, at 06:17 , John Strassner <straz...@gmail.com> wrote: > > > > 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 > > > > -- > "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 > ---------------------------------- > > > > > ------------------------------ > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener información privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilización, > divulgación y/o copia sin autorización puede estar prohibida en virtud de > la legislación vigente. Si ha recibido este mensaje por error, le rogamos > que nos lo comunique inmediatamente por esta misma vía y proceda a su > destrucción. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this transmission in error, do not read it. Please immediately reply to the > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, > pode conter informação privilegiada ou confidencial e é para uso exclusivo > da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário > indicado, fica notificado de que a leitura, utilização, divulgação e/ou > cópia sem autorização pode estar proibida em virtude da legislação vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destruição > > > > -- > "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 > ---------------------------------- > > > > > ------------------------------ > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener información privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilización, > divulgación y/o copia sin autorización puede estar prohibida en virtud de > la legislación vigente. Si ha recibido este mensaje por error, le rogamos > que nos lo comunique inmediatamente por esta misma vía y proceda a su > destrucción. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this transmission in error, do not read it. Please immediately reply to the > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, > pode conter informação privilegiada ou confidencial e é para uso exclusivo > da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário > indicado, fica notificado de que a leitura, utilização, divulgação e/ou > cópia sem autorização pode estar proibida em virtude da legislação vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destruição > -- regards, John
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
