[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07

I2NSF Working Group                                             R. Kumar
Internet-Draft                                                 A. Lohiya
Intended status: Informational                          Juniper Networks
Expires: May 4, 2017                                               D. Qi
                                                               Bloomberg
                                                                N. Bitar
                                                         S. Palislamovic
                                                                   Nokia
                                                                  L. Xia
                                                                  Huawei
                                                        October 31, 2016


  Information model for Client-Facing Interface to Security Controller
            draft-kumar-i2nsf-client-facing-interface-im-00

Abstract

   This document defines information model for the client-facing
   interface to security controller based on the requirements identfied
   in the [I-D.kumar-i2nsf-client-facing-interface-req].  The
   information model defines various managed objects and the
   relationship among these objects needed to build the client
   interfaces.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 4, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Kumar, et al.              Expires May 4, 2017                  [Page 1]


Internet-Draft     Client Interface Information Model       October 2016


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in this Document . . . . . . . . . . . . . .   3
   3.  Information Model for Multi Tenancy . . . . . . . . . . . . .   4
     3.1.  Policy-Domain . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Policy-Tenant . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Policy-Role . . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Policy-User . . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  Policy-Management-Authentication-method . . . . . . . . .   6
   4.  Information Model for Policy Endpoint Groups  . . . . . . . .   6
     4.1.  Meta Data Source  . . . . . . . . . . . . . . . . . . . .   7
     4.2.  User-Group  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Device-Group  . . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Application-Group . . . . . . . . . . . . . . . . . . . .   8
     4.5.  Location-Group  . . . . . . . . . . . . . . . . . . . . .   9
   5.  Information Model for Threat Prevention . . . . . . . . . . .   9
     5.1.  Threat-Feed . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Custom-List . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Malware-Scan-Group  . . . . . . . . . . . . . . . . . . .  10
     5.4.  Event-Map-Group . . . . . . . . . . . . . . . . . . . . .  11
   6.  Information Model for Telemetry Data  . . . . . . . . . . . .  11
     6.1.  Telemetry-Data  . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Telemetry-Source  . . . . . . . . . . . . . . . . . . . .  12
     6.3.  Telemetry-Destination . . . . . . . . . . . . . . . . . .  12
   7.  Information Model for Policy Instance . . . . . . . . . . . .  13
     7.1.  Policy-Calendar . . . . . . . . . . . . . . . . . . . . .  13
     7.2.  Policy-Action . . . . . . . . . . . . . . . . . . . . . .  14
     7.3.  Policy-Rule . . . . . . . . . . . . . . . . . . . . . . .  14
     7.4.  Policy-Instance . . . . . . . . . . . . . . . . . . . . .  15
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   10. Informative References  . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16







Kumar, et al.              Expires May 4, 2017                  [Page 2]


Internet-Draft     Client Interface Information Model       October 2016


1.  Introduction

   The security controller's client-facing interfaces would be built
   using a set of objects, with each object capturing a unique set of
   information from security admin.  The objects may have relationship
   with other objects to express complete requirement.  An information
   model captures the managed objects and relationship among these.  The
   information model proposed in this draft is in accordance with the
   client interface requirements as defined in
   [I-D.kumar-i2nsf-client-facing-interface-req].

   The [RFC3444] explains the difference between information and data
   model.  This draft use those guidlines to define the information
   model in this draft.  A data model, that represents an implementation
   of this proposed information model in a specific data representation
   language, will be defined in a separate draft.

2.  Conventions Used in this Document

   BSS:  Business Support System

   CLI:  Command Line Interface

   CMDB:  Configuration Management Database

   Controller:  Used interchangeably with Service Provider Security
      Controller or management system throughout this document

   CRUD:  Create, Retrieve, Update, Delete

   FW:  Firewall

   GUI:  Graphical User Interface

   IDS:  Intrusion Detection System

   IPS:  Intrusion Protection System

   LDAP:  Lightweight Directory Access Protocol

   NSF:  Network Security Function, defined by
      [I-D.ietf-i2nsf-problem-and-use-cases]

   OSS:  Operation Support System

   RBAC:  Role Based Access Control

   SIEM:  Security Information and Event Management



Kumar, et al.              Expires May 4, 2017                  [Page 3]


Internet-Draft     Client Interface Information Model       October 2016


   URL:  Universal Resource Locator

   vNSF:  Refers to NSF being instantiated on Virtual Machines

3.  Information Model for Multi Tenancy

   The multi-tenancy is an important aspect of any application that
   enables multiple administrative domains for managing the application
   resources.  An oganization may have multiple tenants or departments
   such as HR, Finance, Legal, with each tenant having a need to manage
   its own security policies.

   There are multiple managed objects that constitute multi-tenancy
   aspects.  This section lists these objects and any relationship among
   these objects.

3.1.  Policy-Domain

   This object defines an oragnization boundary for the purpose of
   policy management.  This may vary based on how security controller is
   deployed and hosted.  For example, if an Enterprise host a security
   controller in their network; the domain in this case could just be
   the one that reperesents that Enterprise.  But if a cloud service
   provider host managed services, then a domain could represent a
   single customer of the service provider.  The multi-tenancy model
   should be applicable in all such environments.

   The domain object SHALL have following infomation:

   Name:  Name of the organization or customer representing this domain

   Address:  Address of the organization or customer

   Contact:  Contact information of the organization or customer

   Date:  Date this account was created or last modified

   Authentication Method:  Authentication method to be used for this
      domain.  It should be reference to a 'policy-management-auth-
      method' object

3.2.  Policy-Tenant

   This object defines an entity within an organization that wants to
   manage its own security posture.  The entity could be a department or
   a division that manages its own security policies due to regulatory
   compliance or organizational structure.




Kumar, et al.              Expires May 4, 2017                  [Page 4]


Internet-Draft     Client Interface Information Model       October 2016


   The tenant object SHALL have the following information:

   Name:  Name of the department or division within an organization

   Date:  Date this account was created or last modified

   Domain:  This field identifies the domain to which this tenent
      belongs.  This should be reference to a 'policy-domain' object

3.3.  Policy-Role

   This object defines a set of permissions assigned to a user in an
   organization that want to manage its own security posture.  It
   provides a convenient way to assign policy users to a job function or
   set of permissions within the organization.

   The role object SHALL have following information:

   Name:  This field identifies the name of the role

   Date:  Date this role was created or last modified

   Access Profile:  This field identifies the access profile for the
      role.  The profile grants or denies access to policy objects.
      Multiple access profiles can be concatenated together

3.4.  Policy-User

   This object represents a unique identity within an organization.
   This identity authenticates with the security controller using
   credentials such as a password or token in order to do policy
   management.  A user may be an individual, system, or application
   requiring access to security controller.

   The user object SHALL have following information:

   Name:  Name of the user

   Date:  Date this user was created or last modified

   Password:  User password for basic authentication

   Email:  E-mail address of the user

   Scope Type:  This field identifies whether the user has domain-wide
      or tenent-wide privileges





Kumar, et al.              Expires May 4, 2017                  [Page 5]


Internet-Draft     Client Interface Information Model       October 2016


   Scope Reference:  This field should be reference to either a 'policy-
      domain' or a 'policy-tenant' object

   Role:  This field should be reference to a 'policy-role' object that
      defines the specific permissions

3.5.  Policy-Management-Authentication-method

   This object represents authentication schemes supported by security
   controller.

   This object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Authentication Method:  This field identifies the authentication
      methods.  It could be a password based, token based, certificate
      based or single sign-on authentication

   Mutual Authentication:  This field indicates whether mutual
      authentication is mandatory or not

   Token Server:  This field stores the information about server that
      validates the token submitted as credentials

   Certificate Server:  This field stores the infromation about server
      that validates certificates submitted as credentials

   Single Sign-on Server:  This field stores the infromation about
      server that validates user credentials

4.  Information Model for Policy Endpoint Groups

   The policy endpoint groups are very important part of building user-
   construct policy.  The security admins could use these objects to
   represent a logical entity in their business enviroment, where a
   security policy is to be applied.

   There are multiple managed objects that constitute policy endpoint
   groups.  This section lists these objects and relationship among
   these objects.








Kumar, et al.              Expires May 4, 2017                  [Page 6]


Internet-Draft     Client Interface Information Model       October 2016


4.1.  Meta Data Source

   This object represents information source for the meta-data or tag.
   The meta-data in a group must be mapped to corresponding contents to
   enforce a security policy.

   The meta data source object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Tag Type:  This field identifies the Endpoint group type.  It can be
      either a 'User' group or 'App' group or 'Device' group, or
      'Location' group based policy

   Tag Server Information:  This field identifies the information
      related to the source of the tag such as IP address and UDP/TCP
      port information

   Tag Application Protocol:  This filed identifies the protocol e.g.
      LDAP, Active Directory, or CMDB

   Tag Server Credentials:  This field identifies the credential
      information needed to access the tag server

4.2.  User-Group

   This object represents a user group based on either tag or other
   information.

   The user-group object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

    Group Type:  This field identifies whether the user group is based
      on 'User-tag', 'User-names', or 'IP-addresses'

   Meta-data Server:  This field should be reference to a 'meta-data-
      source' object

   Group Member:  This field is the 'User-tag, or 'User-names', or IP
      addresses based on the 'Group Type'

   Risk Level:  This field represents the threat level; valid range may
      be 0 to 9



Kumar, et al.              Expires May 4, 2017                  [Page 7]


Internet-Draft     Client Interface Information Model       October 2016


4.3.  Device-Group

   This object represents a device group based on either tag or other
   information.

   The device-group object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

    Group Type:  This field identifies whether the device group is based
      on 'Device-tag' or 'Device-names', or IP addresses

   Meta-data Server:  This field should be reference to a 'meta-data-
      source' object

   Group Member:  This field is the 'Device-tag, or 'Device-names', or
      IP addresses based on the 'Group Type'

   Risk Level:  This field represents the threat level; valid range may
      be 0 to 9

4.4.  Application-Group

   This object represents an application group based on either tag or
   other information.

   The application-group object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

    Group Type:  This field identifies whether the device group is based
      on 'App-tag' or 'App-names', or IP addresses

   Meta-data Server:  This field should be reference to a 'meta-data-
      source' object

   Group Member:  This field is the 'Device-tag, or 'Device-names', or
      IP addresses and port information based on the 'Group Type'

   Risk Level:  This field represents the threat level; valid range may
      be 0 to 9






Kumar, et al.              Expires May 4, 2017                  [Page 8]


Internet-Draft     Client Interface Information Model       October 2016


4.5.  Location-Group

   This object represents an location group based on either tag or other
   information.

   The location-group object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

    Group Type:  This field identifies whether the location group is
      based on 'Location-tag' or 'Location-names', or IP addresses

   Meta-data Server:  This field should be reference to a 'meta-data-
      source' object

   Group Member:  This field is the 'Location-tag, or 'Location-names',
      or IP addresses based on the 'Group Type'

   Risk Level:  This field represents the threat level; valid range may
      be 0 to 9

5.  Information Model for Threat Prevention

   The threat prevention plays an important part in the overall security
   posture by reducing the attack surface.  This information could come
   in the form of threat feeds such as Botnet, GeoIP usually from a
   third party or external service.

   There are multiple managed objects that constitute this category.
   This section lists these objects and relationship among these
   objects.

5.1.  Threat-Feed

   This object represents threat feed such as Botnet servers and GeoIP.

   The threat-feed object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Feed Type:  This field identifies whether a feed type is IP address
      based or URL based.





Kumar, et al.              Expires May 4, 2017                  [Page 9]


Internet-Draft     Client Interface Information Model       October 2016


   Feed Server:  This field identifies the information about the feed
      provider, it may be an external service or local server

   Feed Priority:  This field represents the feed priority level to
      resolve conflict if there are multiple feed sources; valid range
      may be 0 to 9

5.2.  Custom-List

   This object represents custom list created for the purpose of
   defining exception to threat feeds.  An organization may want to
   allow certain exception to threat feeds obtained from a third party

   The custom-list object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   List Type:  This field identifies whether the list type is IP address
      based or URL based.

   List Property:  This field identifies the attributes of the list
      property e.g.  Blacklist or Whitelist.

   List Content:  This field contains the blacklist or whitelist
      contents such as IP addresses or URL names.

5.3.  Malware-Scan-Group

   This object represents information needed to detect malware.  This
   information could come from a local server or uploaded periodically
   from third party.

   The malware-scan-group object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Signature Server:  This field contains information about the server
      from where signatures can be downloaded periodically as updates
      become available

   File Types:  This field contains list of file types needed to be
      scanned for the virus





Kumar, et al.              Expires May 4, 2017                 [Page 10]


Internet-Draft     Client Interface Information Model       October 2016


   Malware Signatures:  This field contains list of malware signatures
      or hash

5.4.  Event-Map-Group

   This object represents an event map containing security events and
   threat levels used for dyanmic policy enforcement.

   The event-map-group object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Secuirty Events:  This contains a list of security events

   Threat Map:  This contains a list of threat levels

6.  Information Model for Telemetry Data

   Telemetry provides visibility into the network activities which can
   be tapped for further security analytics e.g. detecting potential
   vulnerabilities, malicious activities etc.

6.1.  Telemetry-Data

   This object contains information collected for telemetry.

   The telemetry-data object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Logs:  This field identifies whether 'Logs' need to be collected

   Syslogs  This field identifies whether 'Syslogs' need to be collected

   SNMP:  This field identifies whether 'SNMP traps' and 'SNMP alarms'
      need to be collected

   sFlow:  This field identifies whether 'sFlow' data need to be
      collected

   NetFlow:  This field identifies whether 'NetFlow' data need to be
      collected





Kumar, et al.              Expires May 4, 2017                 [Page 11]


Internet-Draft     Client Interface Information Model       October 2016


   Interface Stats:  This field identifies whether 'Interface' data such
      as packet bytes and counts need to be collected

6.2.  Telemetry-Source

   This object contains information related to telemetry source.  The
   source would be a NSF element in the network.

   The telemetry-source object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Source Type:  This field contains type of the NSF telemetry source:
      "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS-NSF", "PROXY-NSF",
      "VPN-NSF", "DNS", "ACTIVE-DIRECTORY","IP Reputation Authority",
      "Web Reputation Authority", "Anti-Malware Sandbox", "Honey Pot",
      "DHCP", "Other Third Party", "ENDPOINT"

   NSF Access Parameters:  This field contains information such as IP
      address and protocol (UDP or TCP) port number of the NSF providing
      telemetry data

   NSF Access Credentials:  This field contains username and passwod to
      authenticate with the NSF

   Collection Interval:  This field contains time in milliseconds
      between data collections.  For example, value of 5000 means data
      is streamed to collector every 5 seconds.  Value of 0 means data
      streaming is event-based.

   Collection Method:  This field contains method of collection whether
      it is PUSH-based or PULL-based

   Heartbeat Interval:  This field contains time in seconds the source
      must send telemetry heartbeat

   QoS Marking:  This field contains DSCP value source MUST mark on its
      generated telemetry packets

6.3.  Telemetry-Destination

   This object contains information related to telemetry destination.
   The destination is usually a collector which is either a part of
   security controller or external system such as SIEM.

   The telemetry-destination object SHALL have following information:



Kumar, et al.              Expires May 4, 2017                 [Page 12]


Internet-Draft     Client Interface Information Model       October 2016


   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Collector State:  This field contains the state info regarding the
      collector

   Collector Access Parameter:  This field contains the infromation such
      as IP address and protocol (UDP or TCP) port number for the
      collector's destination

   Collector Access Credentials:  This field contains the username and
      passwod for the collector

   Data Encoding:  This field contains the telemetry data encoding,
      which could in the form of a schema

   Data Transport:  This field contains streaming telemetry data
      protocols: whether it is gRPC, protocol buffer over UDP, etc.

7.  Information Model for Policy Instance

   In order to enforce a security policy, a policy instance must have
   complete information such as where and when a policy need to be
   applied.  The policy instantination is done by combining the managed
   objects described so far and a few others listed below.

7.1.  Policy-Calendar

   This object contains information related to scheduling a policy.  The
   policy could be activated based on a time calendar or security event
   including threat level changes.

   The Policy Calendar object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Enforecment Type:  This field identifies whether the policy
      enforcement is 'ADMIN-ENFORCED' or 'TIME-ENFORCED', or 'EVENT-
      ENFORCED'

   Time Information:  This field contains time calendar such as 'BEGIN-
      TIME' and 'END-TIME' for one time enforcement or recurring time
      calendar for periodic enforcement





Kumar, et al.              Expires May 4, 2017                 [Page 13]


Internet-Draft     Client Interface Information Model       October 2016


   Event Map:  This field contains security events and threat map when
      this policy need to be activated

7.2.  Policy-Action

   This object represents actions that a security admin want to perform
   based on certain traffic class.

   The action object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Primary Action:  This field identifies the action when a policy rule
      is matched by NSF.  The action could be one of 'PERMIT', 'DENY',
      'RATE-LIMIT', 'TRAFFIC-CLASS', 'AUTHENTICATE-SESSION', 'IPS, 'APP-
      FIREWALL'

   Secondary Action:  The security admin can also specify additional
      action if a rule is matched.  This could be one of 'LOG',
      'SYSLOG', 'SESSION-LOG'

7.3.  Policy-Rule

   This object represents rules that a security admin want to define in
   order to express its business objectives through a security policy.

   The policy-rule object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Source:  This field identfies the source of the traffic.  This could
      be reference to either 'Policy Endpoint Group' or 'threat-feed' or
      'custom-list' if security admin wants to specify the source
      otherwise the default is to match all traffic

   Destination:  This field identfies the destination of the traffic.
      This could be reference to either 'Policy Endpoint Group' or
      'threat-feed' or 'custom-list' if security admin wants to specify
      the destination otherwise the default is to match all traffic

   Exception:  This field identifies the exception consideration when
      'Source' and 'Destination' are matched for a given communication.
      This should be reference to 'Policy Endpoint Group' object




Kumar, et al.              Expires May 4, 2017                 [Page 14]


Internet-Draft     Client Interface Information Model       October 2016


   Action:  This field identifies the action taken when 'Source' and
      'Destination' are matched for a given communication

   Precedence:  This field identifies the precedence assigned to this
      rule by security admin.  This is helpful in conflict resolution
      when two or more rules match a given traffic class

7.4.  Policy-Instance

   This object represents a security policy expressed by security admin
   that would be taken by security controller and enforced on NSF as per
   the instructions specfied in policy instance.

   The policy-instance object SHALL have following information:

   Name:  This field identifies the name of this object

   Date:  Date this object was created or last modified

   Rules:  This field contains list of rules.  If the rule does not have
      a user defined precedence, then any conflict must be manually
      resolved

   Scheduling Type:  This field specifies when this policy should be
      scheduled.  The policy could be scheduled based on time calendar
      or event-map

   Scheduling Information:  This field contanins either the 'Calendar'
      or 'Event-map' based on 'Schedule type'

   Owner:  This field defines the owner of this policy.  Only the owner
      is authrozied to modify the the contents of the policy

8.  IANA Considerations

   This document requires no IANA actions.  RFC Editor: Please remove
   this section before publication.

9.  Acknowledgements

   The authors would like to thank Kunal Modasiya, Prakash T.  Sehsadri
   and Srinivas Nimmagadda from Juniper Networks for helpful
   discussions.








Kumar, et al.              Expires May 4, 2017                 [Page 15]


Internet-Draft     Client Interface Information Model       October 2016


10.  Informative References

   [I-D.ietf-i2nsf-problem-and-use-cases]
              Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C.
              Jacquenet, "I2NSF Problem Statement and Use cases", draft-
              ietf-i2nsf-problem-and-use-cases-02 (work in progress),
              October 2016.

   [I-D.ietf-i2nsf-terminology]
              Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
              Birkholz, "Interface to Network Security Functions (I2NSF)
              Terminology", draft-ietf-i2nsf-terminology-02 (work in
              progress), October 2016.

   [I-D.kumar-i2nsf-client-facing-interface-req]
              Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
              S., and L. Xia, "Requirements for Client-Facing Interface
              to Security Controller", draft-kumar-i2nsf-client-facing-
              interface-req-02 (work in progress), October 2016.

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444,
              DOI 10.17487/RFC3444, January 2003,
              <http://www.rfc-editor.org/info/rfc3444>.

Authors' Addresses

   Rakesh Kumar
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   US

   Email: rkkumar@juniper.net


   Anil Lohiya
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   US

   Email: alohiya@juniper.net








Kumar, et al.              Expires May 4, 2017                 [Page 16]


Internet-Draft     Client Interface Information Model       October 2016


   Dave Qi
   Bloomberg
   731 Lexington Avenue
   New York, NY  10022
   US

   Email: DQI@bloomberg.net


   Nabil Bitar
   Nokia
   755 Ravendale Drive
   Mountain View, CA  94043
   US

   Email: nabil.bitar@nokia.com


   Senad Palislamovic
   Nokia
   755 Ravendale Drive
   Mountain View, CA  94043
   US

   Email: senad.palislamovic@nokia.com


   Liang Xia
   Huawei
   101 Software Avenue
   Nanjing, Jiangsu  210012
   China

   Email: Frank.Xialiang@huawei.com

















Kumar, et al.              Expires May 4, 2017                 [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/