Re: [I2nsf] Terminology discussion #2: "capability" & "capability interface"

["Susan Hares" <[e-mail]>]

John: 

 

For discussion at the interim:

+1 to John’s belief we agreed upon customer facing rather than client. 

+1 to John’s concept of specifying separate action that use/manipulate capabilities from monitoring functions. 

 

My comment is practical and design-based. 

Practical: The monitoring and telemetry information is undergoing substantial growth in the IETF standardization, and the industry. It is important to let the capabilities grow separately.  

Design based: These are orthogonal functions.  Why should we mix them? 

 

Sue 

 

From: I2nsf [mailto:[e-mail]] On Behalf Of John Strassner
Sent: Monday, September 12, 2016 8:48 PM
To: Linda Dunbar; John Strassner
Cc: [e-mail]; Diego R. Lopez
Subject: Re: [I2nsf] Terminology discussion #2: "capability" & "capability interface"

 

Hi Linda,

 

 

>From the Terminology I-D:

 

Client-Facing Interface:  See Consumer-Facing Interface.
      See also:  Interface, NSF-Facing Interface.

 

Consumer-Facing Interface:  An Interface dedicated to communication
      with Consumers of NSF data and Services. This is typically
      defined per I2NSF administrative domain.  See also: Interface,
      NSF-Facing Interface.

 

   NSF-Facing Interface:  An Interface dedicated to communication with
      a set of NSFs. This is typically defined per I2NSF administrative
      domain. See also:  Interface, Consumer-Facing Interface.

 

Therefore,

 

   1) I'll bring this up in tomorrow's telecom, but I was pretty sure we had

       previously decided to use **consumer**, not **client**

   2) The point of having a separate Capability Interface is to separate

        actions involving using and manipulating capabilities from other

        actions, such as monitoring. This is because capabilities are

        mechanisms that reflect all or part of the functionality of NSFs.

        As such, they are the building blocks for configuration and

        monitoring; this seemed to me to warrant a separate interface

        for security reasons.

 

best regards,

John

 

On Mon, Sep 12, 2016 at 10:27 AM, Linda Dunbar <[e-mail]> wrote:

As the I2NSF Terminology has defined two types of the “capability”:

-        the “capability” from NSFs and 

-        the “capability” from controller (i.e. as the response to Client’s inquiry). 

 

I find it not necessary to have the “capability interface” as we already have Client Facing interface and NSF facing interface.

 

   Capability:  Defines a set of features that are available from a

      managed entity (see also I2NSF Capability). Examples of "managed

      entities" are NSFs and Controllers, where NSF Capabilities and

      Controller Capabilities define functionality of an NSF and about

      Controller, respectively. These functions may, but do not have

      to, be used. All Capabilities are announced through the

      Registration Interface.

 

Linda

 




-- 

regards,

John