Hi, I think it is better to have crisp and clear terminology, and make the changes now, rather than wait and end up with ambiguous or confusing documents.
While your clarifications are helpful, I don't think that they address my concerns, and they definitely don't address Diego's concerns (which I wholeheartedly agree with). Furthermore, I don't see what absolute coordinates (north vs. south) really buys you. What if you have stacked controllers (e.g., a controller that is managing multiple controllers)? Finally, what if you don't have a controller, but some other entity? best regards, John On Sun, Jun 26, 2016 at 3:41 AM, Loa Andersson <l...@pi.nu> wrote: > Folks, > > I think this comment would have been fine, and I guess I supported it if > it would have been here two years ago. As it is now I think there are to > much water under the bridges, and actually to many documents involved. > We have a common usage of "North Bound" or "Northbound" and South Bound" > or Southbound". The pain in changing is much greater than the gain. > > However, I would support adding text to the terminology section like > this: > > North Bound Interface - the interface between the client and the > controller > > South Bound Interface - the interface between the controller and the NSF > > /Loa > > On 2016-06-26 04:02, John Strassner wrote: > >> 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 >> >> >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf >> >> -- regards, John
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
