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<mailto: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<mailto: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<mailto:straz...@gmail.com>] Sent: Saturday, June 25, 2016 9:02 PM To: Linda Dunbar; John Strassner Cc: I2NSF@ietf.org<mailto: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<mailto: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<mailto:I2nsf@ietf.org> https://www.ietf.org/mailman/listinfo/i2nsf -- regards, John -- regards, John _______________________________________________ I2nsf mailing list I2nsf@ietf.org<mailto: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
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
