Re: [I2nsf] Terminology discussion #2: "capability" & "capability interface"
Awesome, thanks Sue! regards, John On Tue, Sep 13, 2016 at 11:29 AM, Susan Hares <sha...@ndzh.com> wrote: > 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:i2nsf-boun...@ietf.org] *On Behalf Of *John > Strassner > *Sent:* Monday, September 12, 2016 8:48 PM > *To:* Linda Dunbar; John Strassner > *Cc:* i2nsf@ietf.org; 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 <linda.dun...@huawei.com> > 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 > -- regards, John ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] Terminology discussion #2: "capability" & "capability interface"
"this seemed to me to warrant a separate interface for security reasons." If I'm interpreting this correctly, you want to be able to ensure that capabilities are only shared with consumers of the service on a need to know basis? Like perhaps in application this would look like an NSF containing multiple discrete services, with only a select few of that are allowed to participate in capability discovery and advertisement? I see your comment coming from a place much like how network engineers disable LLDP on access ports to reduce leaking information that may help a threat actor find vulnerabilities in existing code, or map out the network, etc. Please let me know if my interpretation is correct. Warmly, Annika Sparkles On Mon, Sep 12, 2016 at 7:47 PM, John Strassnerwrote: > 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 > 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 > > ___ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
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 Dunbarwrote: > 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 ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
[I2nsf] Terminology discussion #2: "capability" & "capability interface"
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 ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf