I2NSF Working Group                                             S. Hares
Internet-Draft                                                    Huawei
Intended status: Standards Track                                J. Jeong
Expires: May 8, September 12, 2019                                       J. Kim
                                                 Sungkyunkwan University
                                                            R. Moskowitz
                                                          HTT Consulting
                                                                  Q. Lin
                                                                  Huawei
                                                        November 4, 2018
                                                          March 11, 2019

                    I2NSF Capability YANG Data Model
               draft-ietf-i2nsf-capability-data-model-02
               draft-ietf-i2nsf-capability-data-model-03

Abstract

   This document defines a YANG data model for capabilities that enable
   a user to control of various
   Network Security Functions (NSFs) in the
   framework for Interface to Network Security
   Functions (I2NSF). (I2NSF) framework to cetrally manage capabilities of varios
   NSFs.

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 https://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 8, September 12, 2019.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4   3
     3.1.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5   4
   5.  The Structure and Objective of NSF Capabilities . . . . . . .   6
     5.1.  Generic Network Security Function Identification  .  YANG Tree Diagram . . .   6
     5.2.  Event Capabilities . . . . . . . . . . . . . . . . . . .   6
     5.3.  Condition Capabilities  . . . . . . . . . . . . . . . . .   7
     5.4.  Action Capabilities . . . . . . . . . . . . . . . . . . .   7
     5.5.  Resolution Strategy Capabilities  . . . . . . . . . . . .   7
     5.6.  Default Action Capabilities . . . . . . . . . . . . . . .   8
     5.7.  RPC for Acquiring Appropriate Network Security Function .   8
   6.  Data Model Structure  . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Network Security Function Identification  . . . . . . . .   8
     6.2.
     5.1.  Capabilities of Generic Network Security Function . . . .   9
       6.2.1.  Event Capabilities  . . . . .   6
   6.  YANG Data Modules . . . . . . . . . . . .  10
       6.2.2.  Condition Capabilities . . . . . . . . . .   8
     6.1.  I2NSF Capability YANG Data Module . . . . .  12
       6.2.3.  Action Capabilities . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . .  14
       6.2.4.  Resolution Strategy Capabilities . . . . . . . . . .  16
       6.2.5.  Capabilities of Advanced Network Security Function .  16
       6.2.6.  Content  36
   8.  Security Capabilities . . . . Considerations . . . . . . . .  17
       6.2.7.  Attack Mitigation Capabilities . . . . . . . . . . .  18
       6.2.8.  RPC for Acquiring Appropriate Network Security
               Function  37
   9.  References  . . . . . . . . . . . . . . . . . . . . . .  19
   7.  YANG Modules . . .  37
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  37
     9.2.  Informative References  . . .  20
     7.1.  I2NSF Capability YANG Data Module . . . . . . . . . . . .  20
   8.  IANA Considerations . .  39
   Appendix A.  Changes from draft-ietf-i2nsf-capability-data-
                model-02 . . . . . . . . . . . . . . . . . . .  57
   9.  Security Considerations . . .  40
   Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . .  57
   10. References . .  40
   Appendix C.  Contributors . . . . . . . . . . . . . . . . . . . .  40
   Authors' Addresses  . . .  57
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  57
     10.2.  Informative References . . . . . . . . . . . . . . . . .  57
   Appendix A.  Example: Extended VoIP-VoLTE Security Function
                Capabilities Module  . . . . . . . . . . . . . . . .  59
   Appendix B.  Example: Configuration XML of Capability Module  . .  60
     B.1.  Example: Configuration XML of Generic Network Security
           Function Capabilities . . . . . . . . . . . . . . . . . .  60
     B.2.  Example: Configuration XML of Extended VoIP/VoLTE
           Security Function Capabilities Module . . . . . . . . . .  62
   Appendix C.  Changes from draft-ietf-i2nsf-capability-data-
                model-01 . . . . . . . . . . . . . . . . . . . . . .  63

   Appendix D.  Acknowledgments  . . . . . . . . . . . . . . . . . .  64
   Appendix E.  Contributors . . . . . . . . . . . . . . . . . . . .  64
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  64  41

1.  Introduction

   As the industry becomes more sophisticated and network devices (e.g.,
   Internet of Things, Self-driving vehicles, and VoIP/VoLTE
   smartphones), service providers have a lot of problems mentioned in
   [RFC8192].  To resolve these problems, [i2nsf-nsf-cap-im] specifies
   the information model of the capabilities of Network Security
   Functions (NSFs).

   This document provides a data model using YANG [RFC6020][RFC7950]
   that defines the capabilities of NSFs to express centrally manage
   capabilities of those security devices.  This YANG data model is based on the
   information model for I2NSF NSF capabilities [i2nsf-nsf-cap-im].  The security devices can
   register their own capabilities into Network Operator Management
   (Mgmt) System (i.e., Security Controller) with this YANG data model
   through the registration interface [RFC8329].
   After  With the capabilities
   of the NSFs are registered, this those security devices registered centrally, those security
   devices can be easily managed [RFC8329].  This YANG data model can be used by the IN2SF user or Service Function Forwarder
   (SFF) [i2nsf-sfc] to acquire appropriate NSFs that can be controlled
   by is
   based on the Network Operator Mgmt System.

   The information model for I2NSF NSF capabilities
   [i2nsf-nsf-cap-im].

   This YANG data model uses an "Event-Condition-Action" (ECA) policy
   model that is used as the basis for the design of I2NSF Policy
   described in [RFC8329] and [i2nsf-nsf-cap-im].  Rules.  The "ietf-i2nsf-capability" "ietf-
   i2nsf-capability" YANG module defined in this document provides the
   following features:

   o  Configuration of identification  Definition for generic general capabilities of network security
      function policy functions.

   o  Configuration of  Definition for event capabilities for of generic network security
      function policy
      function.

   o  Configuration of  Definition for condition capabilities for of generic network security function policy
      function.

   o  Configuration  Definition for condition capabilities of advanced network security
      function.

   o  Definition for action capabilities for of generic network security
      function policy
      function.

   o  Configuration of  Definition for resolution strategy capabilities for of generic network
      security function policy function.

   o  Configuration of  Definition for default action capabilities for of generic network
      security function policy

   o  RPC for acquiring appropriate network security function according
      to type of NSF and/or target devices. function.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119]. [RFC2119][RFC8174].

3.  Terminology

   This document uses the terminology described in
   [i2nsf-terminology][i2nsf-nsf-cap-im]
   [RFC8431][supa-policy-info-model].  Especially, the following terms
   are from [supa-policy-info-model]:

   o  Data Model: A data model is a representation of concepts of
      interest to an environment in a form that is dependent on data
      repository, data definition language, query language,
      implementation language, and protocol.

   o  Information Model: An information model is a representation of
      concepts of interest to an environment in a form that is
      independent of data repository, data definition language, query
      language, implementation language, and protocol.

3.1.  Tree Diagrams

   A simplified graphical representation of the data model is used in
   this document.  The meaning of the symbols in these diagrams
   [RFC8431]
   [RFC8340] is as follows:

   o  Brackets "[" and "]" enclose list keys.

   o  Abbreviations before data node names: "rw" means configuration
      (read-write) and "ro" state data (read-only).

   o  Symbols after data node names: "?" means an optional node and "*"
      denotes a "list" and "leaf-list".

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

4.  Overview

   This section explains overview how the YANG data model can be used by in
   I2NSF User, Developer's Mgmt System, and SFF. framework described in [RFC8329].  Figure 1 shows capabilities
   of NSFs in I2NSF Framework.  As shown in this figure, Developer's
   Mgmt System can register NSFs with capabilities that the network
   security device can support.  To register NSFs in this way, the
   Developer's Mgmt System utilizes this standardized capabilities YANG
   data model through registration interface.  Through this registration  With the capabilities of
   capabilities,
   those network security devices registered centrally, those security
   devices can be easily managed, which can resolve the a lot of
   problems [RFC8192] can be resolved. described in [RFC8192].  The following shows use cases.

   Note [i2nsf-nsf-yang] is used to configure security policy rules of NSFs
   generic network security functions and [i2nsf-advanced-nsf-dm] is
   used to configure security policy rules of advanced network security
   functions according to the capabilities of network security devices
   registed in I2NSF Framework.

       +-------------------------------------------------------+
       |  I2NSF User (e.g., Overlay Network Mgmt, Enterprise   |
       |  Network Mgmt, another network domain's mgmt, etc.)   |
       +--------------------+----------------------------------+
                            |
  Consumer-Facing Interface |
                            |
                            |                 I2NSF
          +-----------------+------------+ Registration  +-------------+
          | Network Operator Mgmt System |  Interface    | Developer's |
          | (i.e., Security Controller)  | < --------- > | Mgmt System |
          +-----------------+------------+               +-------------+
                            |                          New NSF
                            |                          E = {}
  NSF-Facing Interface      |                          C = {IPv4, IPv6}
                            |                          A = {Allow, Deny}
                            |
       +---------------+----+------------+-----------------+
       |               |                 |                 |
   +---+---+       +---+---+         +---+---+         +---+---+
   | NSF-1 |  ...  | NSF-m |         | NSF-1 |   ...   | NSF-n |  ...
   +-------+       +-------+         +-------+         +-------+
     NSF-1           NSF-m             NSF-1             NSF-n
 E = {}            E = {user}        E = {dev}         E = {time}
 C = {IPv4}        C = {IPv6}        C = {IPv4, IPv6}  C = {IPv4}
 A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny}

   Developer Mgmt System A            Developer Mgmt System B

             Figure 1: Capabilities of NSFs in I2NSF Framework

   o  If I2NSF User network manager wants to apply security policy rules about
      blocking malicious users, it is a tremendous burden to apply all
      of these rules to NSFs one by one.  This problem can be resolved
      by standardizing managing the capabilities of NSFs.  If I2NSF User network manager wants to
      block malicious users with IPv6, I2NSF User network manager sends the
      security policy rules about blocking the users to Network Operator
      Mgmt System. System using I2NSF user (i.e., a web browser or a software).
      When the Network Operator Mgmt System receives the security policy
      rules, it automatically sends that security policy rules to
      appropriate NSFs (i.e., NSF-m in Developer Mgmt System A and NSF-1
      in Developer Mgmt System B) which can support the capabilities
      (i.e., IPv6).  Therefore, I2NSF User need not consider NSFs where
      to apply the rules.

   o  If NSFs find the malicious packets, it is a tremendous burden for
      I2NSF User
      network manager to apply the rule about blocking the malicious
      packets to NSFs one by one.  This problem can be resolved by standardizing
      managing the capabilities of NSFs.  If NSFs find the malicious suspicious
      packets with IPv4, they can ask the Network Operator Mgmt System
      for information about the suspicious packets with IPv4.  to alter
      specific rules and/or configurations.  When the Network Operator
      Mgmt System receives the rules for malicious packets, information, it inspects
      whether the rules information
      about the suspicious packets with IPv4.  If the suspicious packets
      are reasonable determined to be malicious packets, the Network Operator Mgmt
      System creates and sends the rules security policy rule against
      malicious packets to appropriate NSFs (i.e., NSF-1 in Developer
      Mgmt System A and NSF-1 and NSF-n in Developer Mgmt System B)
      which can support the capabilities (i.e., IPv4).  Therefore, the
      new rules security policy rule against malicious packets can be applied
      to appropriate NSFs without control intervention of I2NSF USer.

   o  If NSFs humans.

5.  YANG Tree Diagram

   This section shows an YANG tree diagram of Service Function Chaining (SFC) [i2nsf-sfc] fail, it is
      a tremendous burden capabilities for I2NSF User to reconfigure network
   security functions, as defined in the policy [i2nsf-nsf-cap-im].

5.1.  Capabilities of
      SFC immediately. Network Security Function

   This problem can be resolved by periodically
      acquiring information of appropriate NSFs section shows YANG tree diagram for capabilities of SFC.  If SFF needs
      information of Web Application Firewall network
   security functions.

   module: ietf-i2nsf-capability
     +--rw nsf
        +--rw time-capabilities*                  enumeration
        +--rw event-capabilities
        |  +--rw system-event-capa*   identityref
        |  +--rw system-alarm-capa*   identityref
        +--rw condition-capabilities
        |  +--rw generic-nsf-capabilities
        |  |  +--rw ipv4-capa*   identityref
        |  |  +--rw ipv6-capa*   identityref
        |  |  +--rw tcp-capa*    identityref
        |  |  +--rw udp-capa*    identityref
        |  |  +--rw icmp-capa*   identityref
        |  +--rw advanced-nsf-capabilities
        |     +--rw antivirus-capa*    identityref
        |     +--rw antiddos-capa*     identityref
        |     +--rw ips-capa*          identityref
        |     +--rw http-capa*         identityref
        |     +--rw voip-volte-capa*   identityref
        +--rw action-capabilities
        |  +--rw ingress-action-capa*   identityref
        |  +--rw egress-action-capa*    identityref
        |  +--rw log-action-capa*       identityref
        +--rw resolution-strategy-capabilities*   identityref
        +--rw default-action-capabilities*        identityref

     Figure 2: YANG Tree Diagram for SFC, it can ask the
      Network Operator Mgmt System to acquire the location information
      of appropriate Web Application Firewall.  When the Network
      Operator Mgmt System receives requested information from SFF, it
      sends location information of Web Application Firewall to the SFF.
      Therefore, the policy about the NSFs of SFC can be periodically
      updated without control of I2NSF USer.

5.  The Structure and Objective of NSF Capabilities

5.1.  Generic of Network Security Function Identification
                                 Functions

   This YANG tree diagram shows a identification for generic capabilities of network security
   functions.
   These objects

   The NSF includes NSF capabilities.  The NSF capabilities include time
   capabilities, event capabilities, condition capabilities, action
   capabilities, resolution strategy capabilities, and default action
   capabilities.

   Time capabilities are used to specify capabilities when to execute
   the I2NSF policy rule.  The time capabilities are defined as location information absolute
   time and target device
   information.

5.2. periodic time.

   Event Capabilities

   This shows a event capabilities for generic network security
   functions policy.  This is are used to specify capabilities about any
   important occurrence in time of a change in the system being managed,
   and/or in the environment of the system being managed.  When used in how to trigger
   the context evaluation of I2NSF Policy Rules, it is used to determine whether the Condition condition clause of the I2NSF Policy Rule can be evaluated or
   not.  These object of Rule.  The
   event capabilities is are defined as user security
   event capabilities, device security event capabilities, system
   security event capabilities, and time security event capabilities.
   These object of system alarm.  The
   event capabilities capability can be extended according to specific vendor event
   condition features.

5.3.  The event capability is described in detail in
   [i2nsf-nsf-cap-im].

   Condition Capabilities

   This shows a condition capabilities for generic network security
   functions policy.  This is are used to specify capabilities about of a set of
   attributes, features, and/or values that are to be compared with a
   set of known attributes, features, and/or values in order to
   determine whether or not the set of Actions actions in that (imperative)
   I2NSF Policy Rule policy rule can be executed or not.  These object of  The condition
   capabilities capability
   is defined classified as packet security condition capabilities,
   packet payload capabilities of generic network security condition capabilities, target
   functions and advanced network security functions.  The condition capabilities, user
   capabilities of generic network security condition capabilities, context
   condition capabilities, functions are defined as
   IPv4 capability, IPv6 capability, tcp capability, udp capability, and generic context
   icmp capability.  The condition capabilities.
   These object capabilities of advanced network
   security functions are defined as antivirus capability, antiddos
   capability, ips capability, http capability, and VoIP/VoLTE
   capability.  The condition capabilities capability can be extended according to
   specific vendor condition features.

5.4.  The condition capability is
   described in detail in [i2nsf-nsf-cap-im].

   Action Capabilities

   This shows a action capabilities for generic network security
   functions policy.  This is used to specify capabilities how to control
   and monitor aspects of flow-based NSFs when the event and condition
   clauses are satisfied.  NSFs provide security functions by executing
   various Actions.  These object of  The action capabilities is are defined as
   ingress action capabilities, capability, egress action capabilities, capability, and apply
   profile log action capabilities.  These object of
   capability.  The action capabilities capability can be extended according to
   specific vendor action features.

5.5.  The action capability is described
   in detail in [i2nsf-nsf-cap-im].

   Resolution Strategy Capabilities

   This shows a resolution strategy capabilities for generic network
   security functions policy.  This can be are used to specify capabilities how
   to resolve conflicts that occur between the actions of the same or
   different policy rules that are matched and contained in this
   particular NSF.  These objects  The resolution strategy capabilities are defined as first-matching-rule
   capability
   First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized
   Matching Rule (PMR) with Errors (PMRE), and last-matching-rule capability.  These objects Prioritized Matching Rule
   with No Errors (PMRN).  The resolution strategy capability can be
   extended according to specific vendor action features.  The
   resolution strategy features.

5.6. capability is described in detail in
   [i2nsf-nsf-cap-im].

   Default Action Capabilities

   This shows a default action policy for generic network security
   functions.  This can be capabilities are used to specify capabilities about a
   predefined action how to
   execute I2NSF policy rule when no other alternative rule matches a packet.  The default
   action was matched by the
   currently executing capabilities are defined as pass, drop, reject, alert, and
   mirror.  The default action capability can be extended according to
   specific vendor action features.  The default action capability is
   described in detail in [i2nsf-nsf-cap-im].

6.  YANG Data Modules
6.1.  I2NSF Policy Rule.

5.7.  RPC for Acquiring Appropriate Network Security Function Capability YANG Data Module

   This shows a RPC for acquiring section introduces an appropriate network security
   function according to type of NSF and/or target devices.  If the SFF
   [i2nsf-sfc]does not have the location information of network security
   functions that it should send in own cache table, this can be used to
   acquire the information.  These objects are defined as input data
   (i.e., NSF type and target devices) and output data (i.e., location
   information of NSF).

6.  Data Model Structure

   This section shows an overview of a structure tree of capabilities
   for generic YANG data module for capabilities of
   network security functions, as defined in the [i2nsf-nsf-cap-im].

6.1.

<CODE BEGINS> file "ietf-i2nsf-capability@2019-03-11.yang"

module ietf-i2nsf-capability {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
  prefix
    iicapa;

  organization
    "IETF I2NSF (Interface to Network Security Function Identification

   The data model for network security function identification has the
   following structure:

   module: ietf-i2nsf-capability
       +--rw nsf* [nsf-name]
          +--rw nsf-name                    string
          +--rw nsf-type?                   nsf-type
          +--rw nsf-address
          |  +--rw (nsf-address-type)?
          |     +--:(ipv4-address)
          |     |  +--rw ipv4-address    inet:ipv4-address
          |     +--:(ipv6-address)
          |        +--rw ipv6-address    inet:ipv6-address
          +--rw target-device
          |  +--rw pc?                 boolean
          |  +--rw mobile-phone?       boolean
          |  +--rw voip-volte-phone?   boolean
          |  +--rw tablet?             boolean
          |  +--rw iot?                boolean
          |  +--rw vehicle?            boolean
          +--rw generic-nsf-capabilities
          |  +--rw net-sec-capabilities
          |     uses net-sec-caps
          +--rw advanced-nsf-capabilities
          |  +--rw advaneced-sec-capabilities
          |     uses advaneced-sec-caps
          +--rw complete-nsf-capabilities
             +--rw con-sec-control-capabilities
             |  uses i2nsf-con-sec-control-caps
             +--rw attack-mitigation-capabilities
                uses i2nsf-attack-mitigation-control-caps

           Figure 2: Data Model Structure for NSF-Identification

   This document also utilizes Functions)
     Working Group";

  contact
    "WG Web: <http://tools.ietf.org/wg/i2nsf>
     WG List: <mailto:i2nsf@ietf.org>

     WG Chair: Adrian Farrel
     <mailto:Adrain@olddog.co.uk>

     WG Chair: Linda Dunbar
     <mailto:Linda.duhbar@huawei.com>

     Editor: Susan Hares
     <mailto:shares@ndzh.com>

     Editor: Jaehoon Paul Jeong
     <mailto:pauljeong@skku.edu>

     Editor: Jinyong Tim Kim
     <mailto:timkim@skku.edu>";

  description
    "This module describes a formal capability model
    for policy reconciliation
   proposed by Basile et al.  [Policy-Reconciliation], which handles
   conflict resolution, I2NSF devices.

    Copyright (c) 2018 IETF Trust and the use persons
    identified as authors of external data, the code.  All rights reserved.

    Redistribution and target device.

   The nsf-type object can be used for configuration about type use in source and binary forms, with or
    without modification, is permitted pursuant to, and subject
    to the license terms contained in, the Simplified BSD License
    set forth in Section 4.c of a
   NSF.  The types the IETF Trust's Legal Provisions
    Relating to IETF Documents
    (http://trustee.ietf.org/license-info).

    This version of NSF consists this YANG module is part of Network Firewall, Web Application
   Firewall, Anti-Virus, IDS, IPS, and DDoS Mitigator.  The nsf-address
   object can be used for configuration about location of a NSF.  The
   target-device object can be used for configuration about target
   devices.  We will add additional type of a NSF for more generic
   network security functions.

6.2.  Capabilities of Generic Network Security Function

   The data model for Generic NSF capabilities has the following
   structure:

          +--rw generic-nsf-capabilities
             +--rw net-sec-capabilities
                uses i2nsf-net-sec-caps

    Figure 3: Data Model Structure for Capabilities of Network Security
                                 Function

6.2.1.  Event Capabilities

   The data model for event capabilities has the following structure:

     +--rw i2nsf-net-sec-caps
             +--rw net-sec-capabilities
                +--rw time
                |  +--rw time-zone
                |  |  +--rw time-zone-offset?   boolean
                |  +--rw time-inteval
                |     +--rw absolute-time-inteval
                |     |  +--rw start-time?   boolean
                |     |  +--rw end-time?     boolean
                |     +--rw periodic-time-inteval
                |        +--rw day?     boolean
                |        +--rw month?   boolean
                +--rw event
                |  +--rw usr-event
                |  |  +--rw usr-sec-event-content?   boolean
                |  |  +--rw usr-sec-event-format
                |  |  |  +--rw unknown?   boolean
                |  |  |  +--rw guid?      boolean
                |  |  |  +--rw uuid?      boolean
                |  |  |  +--rw uri?       boolean
                |  |  |  +--rw fqdn?      boolean
                |  |  |  +--rw fqpn?      boolean
                |  |  +--rw usr-sec-event-type
                |  |     +--rw unknown?                 boolean
                |  |     +--rw user-created?            boolean
                |  |     +--rw user-grp-created?        boolean
                |  |     +--rw user-deleted?            boolean
                |  |     +--rw user-grp-deleted?        boolean
                |  |     +--rw user-logon?              boolean
                |  |     +--rw user-logoff?             boolean
                |  |     +--rw user-access-request?     boolean
                |  |     +--rw user-access-granted?     boolean
                |  |     +--rw user-access-violation?   boolean
                |  +--rw dev-event
                |  |  +--rw dev-sec-event-content          boolean
                |  |  +--rw dev-sec-event-format
                |  |  |  +--rw unknown?   boolean
                |  |  |  +--rw guid?      boolean
                |  |  |  +--rw uuid?      boolean
                |  |  |  +--rw uri?       boolean
                |  |  |  +--rw fqdn?      boolean
                |  |  |  +--rw fqpn?      boolean
                |  |  +--rw dev-sec-event-type
                |  |  |  +--rw unknown?                    boolean
                |  |  |  +--rw comm-alarm?                 boolean
                |  |  |  +--rw quality-of-service-alarm?   boolean
                |  |  |  +--rw process-err-alarm?          boolean
                |  |  |  +--rw equipment-err-alarm?        boolean
                |  |  |  +--rw environmental-err-alarm?    boolean
                |  |  +--rw dev-sec-event-type-severity
                |  |     +--rw unknown?         boolean
                |  |     +--rw cleared?         boolean
                |  |     +--rw indeterminate?   boolean
                |  |     +--rw critical?        boolean
                |  |     +--rw major?           boolean
                |  |     +--rw minor?           boolean
                |  |     +--rw warning?         boolean
                |  +--rw sys-event
                |  |  +--rw sys-sec-event-content?   boolean
                |  |  +--rw sys-sec-event-format
                |  |  |  +--rw unknown?   boolean
                |  |  |  +--rw guid?      boolean
                |  |  |  +--rw uuid?      boolean
                |  |  |  +--rw uri?       boolean
                |  |  |  +--rw fqdn?      boolean
                |  |  |  +--rw fqpn?      boolean
                |  |  +--rw sys-sec-event-type
                |  |     +--rw unknown?                boolean
                |  |     +--rw audit-log-written-to?   boolean
                |  |     +--rw audit-log-cleared?      boolean
                |  |     +--rw policy-created?         boolean
                |  |     +--rw policy-edited?          boolean
                |  |     +--rw policy-deleted?         boolean
                |  |     +--rw policy-executed?        boolean
                |  +--rw time-event
                |     +--rw time-sec-event-begin?       boolean
                |     +--rw time-sec-event-end?         boolean
                |     +--rw time-sec-event-time-zone?   boolean
                +--rw condition
                |  ...
               +--rw action
                |  ...
                +--rw resolution-strategy
                   ...

     Figure 4: Data Model Structure for Event Capabilities of Network
                             Security Function

   These objects are defined as capabilities of user security event,
   device security event, system security event, and time security
   event.  These objects can be extended according to specific vendor
   event features.  We will add additional event objects for more
   generic network security functions.

6.2.2.  Condition Capabilities

   The data model for condition capabilities has the following
   structure:

   +--rw i2nsf-net-sec-caps
         +--rw net-sec-capabilities
            +--rw time
            |  +--rw time-zone
            |  |  +--rw time-zone-offset?   boolean
            |  +--rw time-inteval
            |     +--rw absolute-time-inteval
            |     |  +--rw start-time?   boolean
            |     |  +--rw end-time?     boolean
            |     +--rw periodic-time-inteval
            |        +--rw day?     boolean
            |        +--rw month?   boolean
            +--rw event
            |  ...
            +--rw condition
            |  +--rw packet-security-condition
            |  |  +--rw packet-security-mac-condition
            |  |  |  +--rw pkt-sec-cond-mac-dest?         boolean
            |  |  |  +--rw pkt-sec-cond-mac-src?          boolean
            |  |  |  +--rw pkt-sec-cond-mac-8021q?        boolean
            |  |  |  +--rw pkt-sec-cond-mac-ether-type?   boolean
            |  |  |  +--rw pkt-sec-cond-mac-tci?          string
            |  |  +--rw packet-security-ipv4-condition
            |  |  |  +--rw pkt-sec-cond-ipv4-header-length?     boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-tos?               boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-total-length?      boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-id?                boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-fragment?          boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-fragment-offset?   boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-ttl?               boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-protocol?          boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-src?               boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-dest?              boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-ipopts?            boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-sameip?            boolean
            |  |  |  +--rw pkt-sec-cond-ipv4-geoip?             boolean
            |  |  +--rw packet-security-ipv6-condition
            |  |  |  +--rw pkt-sec-cond-ipv6-dscp?             boolean
            |  |  |  +--rw pkt-sec-cond-ipv6-ecn?              boolean
            |  |  |  +--rw pkt-sec-cond-ipv6-traffic-class?    boolean
            |  |  |  +--rw pkt-sec-cond-ipv6-flow-label?       boolean
            |  |  |  +--rw pkt-sec-cond-ipv6-payload-length?   boolean
            |  |  |  +--rw pkt-sec-cond-ipv6-next-header?      boolean
            |  |  |  +--rw pkt-sec-cond-ipv6-hop-limit?        boolean
            |  |  |  +--rw pkt-sec-cond-ipv6-src?              boolean
            |  |  |  +--rw pkt-sec-cond-ipv6-dest?             boolean
            |  |  +--rw packet-security-tcp-condition
            |  |  |  +--rw pkt-sec-cond-tcp-src-port?      boolean
            |  |  |  +--rw pkt-sec-cond-tcp-dest-port?     boolean
            |  |  |  +--rw pkt-sec-cond-tcp-seq-num?       boolean
            |  |  |  +--rw pkt-sec-cond-tcp-ack-num?       boolean
            |  |  |  +--rw pkt-sec-cond-tcp-window-size?   boolean
            |  |  |  +--rw pkt-sec-cond-tcp-flags?         boolean
            |  |  +--rw packet-security-udp-condition
            |  |  |  +--rw pkt-sec-cond-udp-src-port?    boolean
            |  |  |  +--rw pkt-sec-cond-udp-dest-port?   boolean
            |  |  |  +--rw pkt-sec-cond-udp-length?      boolean
            |  |  +--rw packet-security-icmp-condition
            |  |     +--rw pkt-sec-cond-icmp-type?      boolean
            |  |     +--rw pkt-sec-cond-icmp-code?      boolean
            |  |     +--rw pkt-sec-cond-icmp-seg-num?   boolean
            |  +--rw packet-payload-condition
            |  |  +--rw pkt-payload-content?   boolean
            |  +--rw acl-number?                  boolean
            |  +--rw application-condition
            |  |  +--rw application-object?   boolean
            |  |  +--rw application-group?    boolean
            |  |  +--rw application-label?    boolean
            |  |  +--rw category
            |  |     +--rw application-category?   boolean
            |  +--rw target-condition
            |  |  +--rw device-sec-context-cond?   boolean
            |  +--rw users-condition
            |  |  +--rw user
            |  |  |  +--rw (user-name)?
            |  |  |     +--:(tenant)
            |  |  |     |  +--rw tenant?   boolean
            |  |  |     +--:(vn-id)
            |  |  |        +--rw vn-id?    boolean
            |  |  +--rw group
            |  |     +--rw (group-name)?
            |  |     |  +--:(tenant)
            |  |     |  |  +--rw tenant?          boolean
            |  |     |  +--:(vn-id)
            |  |     |     +--rw vn-id?           boolean
            |  |     +--rw security-grup    boolean
            |  +--rw url-category-condition
            |  |  +--rw pre-defined-category?    boolean
            |  |  +--rw user-defined-category?   boolean
            |  +--rw context-condition
            |  |  +--rw temp?   string
            |  +--rw gen-context-condition
            |     +--rw geographic-location
            |        +--rw src-geographic-location?    boolean
            |        +--rw dest-geographic-location?   boolean
            +--rw action
            |  ...
            +--rw resolution-strategy
               ...

   Figure 5: Data Model Structure for Condition Capabilities of Network
                             Security Function

   These objects are defined as capabilities of packet security
   condition, packet payload security condition, target security
   condition, user security condition, context condition, and generic
   context condition.  These objects can be extended according to
   specific vendor condition features.  We will add additional condition
   objects for more generic network security functions.

6.2.3.  Action Capabilities

   The data model for action capabilities has the following structure:

   +--rw i2nsf-net-sec-caps
         +--rw net-sec-capabilities
            +--rw time
            |  +--rw time-zone
            |  |  +--rw time-zone-offset?   boolean
            |  +--rw time-inteval
            |     +--rw absolute-time-inteval
            |     |  +--rw start-time?   boolean
            |     |  +--rw end-time?     boolean
            |     +--rw periodic-time-inteval
            |        +--rw day?     boolean
            |        +--rw month?   boolean
            +--rw event
            |  ...
            +--rw condition
            |  ...
            +--rw action
            |  +--rw rule-log?         boolean
            |  +--rw session-log?      boolean
            |  +--rw ingress-action
            |  |  +--rw ingress-action-type
            |  |     +--rw pass?     boolean
            |  |     +--rw drop?     boolean
            |  |     +--rw reject?   boolean
            |  |     +--rw alert?    boolean
            |  |     +--rw mirror?   boolean
            |  +--rw egress-action
            |     +--rw egress-action-type
            |        +--rw invoke-signaling?       boolean
            |        +--rw tunnel-encapsulation?   boolean
            |        +--rw forwarding?             boolean
            |        +--rw redirection?            boolean
            +--rw resolution-strategy
               ...

     Figure 6: Data Model Structure for Action Capabilities of Network
                             Security Function

   These objects are defined capabilities as ingress action, egress
   action, and apply profile action.  These objects can be extended
   according to specific vendor action feature.  We will add additional
   action objects for more generic network security functions.

6.2.4.  Resolution Strategy Capabilities

   The data model for resolution strategy capabilities has the following
   structure:

   +--rw i2nsf-net-sec-caps
         +--rw net-sec-capabilities
            +--rw time
            |  +--rw time-zone
            |  |  +--rw time-zone-offset?   boolean
            |  +--rw time-inteval
            |     +--rw absolute-time-inteval
            |     |  +--rw start-time?   boolean
            |     |  +--rw end-time?     boolean
            |     +--rw periodic-time-inteval
            |        +--rw day?     boolean
            |        +--rw month?   boolean
            +--rw event
            |  ...
            +--rw condition
            |  ...
            +--rw action
            |  ...
            +--rw resolution-strategy
               +--rw first-matching-rule?   boolean
               +--rw last-matching-rule?    boolean

    Figure 7: Data Model Structure for Resolution Strategy Capabilities
                       of Network Security Function

   These objects are defined capabilities as first-matching-rule and
   last-matching-rule.  These objects can be extended according to
   specific vendor resolution strategy features.  We will add additional
   resolution strategy objects for more generic network security
   functions.

6.2.5.  Capabilities of Advanced Network Security Function

   The data model for advanced NSF capabilities has the following
   structure:

          +--rw advanced-nsf-capabilities
          |  +--rw advanced-sec-capabilities
          |     +--rw antivirus
          |     |  +--rw detect?                  boolean
          |     |  +--rw exception-application?   boolean
          |     |  +--rw exception-signature?     boolean
          |     |  +--rw whitelists?              boolean
          |     +--rw antiddos
          |     |  +--rw syn-flood-action?           boolean
          |     |  +--rw udp-flood-action?           boolean
          |     |  +--rw http-flood-action?          boolean
          |     |  +--rw https-flood-action?         boolean
          |     |  +--rw dns-request-flood-action?   boolean
          |     |  +--rw dns-reply-flood-action?     boolean
          |     |  +--rw icmp-flood-action?          boolean
          |     |  +--rw sip-flood-action?           boolean
          |     |  +--rw detect-mode?                boolean
          |     |  +--rw baseline-learn?             boolean
          |     +--rw ips
          |        +--rw signature-set?         boolean
          |        +--rw exception-signature?   boolean
                ...

    Figure 8: Data Model Structure for Capabilities of Advanced Network
                             Security Function

   These objects are defined capabilities of advanced network security
   functions such as antivirus, antiddos, and ips.  A detailed data
   model for the configuration of the advanced network security
   functions is described in [i2nsf-advanced-nsf-dm].

6.2.6.  Content Security Capabilities

   The data model for content security capabilities has the following
   structure:

   +--rw complete-nsf-capabilities
     +--rw con-sec-control-capabilities
     |  +--rw anti-virus?             boolean
     |  +--rw ips?                    boolean
     |  +--rw ids?                    boolean
     |  +--rw url-filter?             boolean
     |  +--rw data-filter?            boolean
     |  +--rw mail-filter?            boolean
     |  +--rw sql-filter?             boolean
     |  +--rw file-blocking?          boolean
     |  +--rw file-isolate?           boolean
     |  +--rw pkt-capture?            boolean
     |  +--rw application-behavior?   boolean
     |  +--rw voip-volte?             boolean
     +--rw attack-mitigation-capabilities
                ...

    Figure 9: Data Model Structure for Content Security Capabilities of
                         Network Security Function

   Content security is composed of a number of distinct security
   Capabilities; each such Capability protects against a specific type
   of threat in the application layer.  Content security is a type of
   Generic Network Security Function (GNSF), which summarizes a well-
   defined set of security Capabilities.

6.2.7.  Attack Mitigation Capabilities

   The data model for attack mitigation capabilities has the following
   structure:

   +--rw complete-nsf-capabilities
     ...
     +--rw attack-mitigation-capabilities
        +--rw (attack-mitigation-control-type)?
           +--:(ddos-attack)
           |  +--rw (ddos-attack-type)?
           |     +--:(network-layer-ddos-attack)
           |     |  +--rw network-layer-ddos-attack-types
           |     |     +--rw syn-flood-attack?           boolean
           |     |     +--rw udp-flood-attack?           boolean
           |     |     +--rw icmp-flood-attack?          boolean
           |     |     +--rw ip-fragment-flood-attack?   boolean
           |     |     +--rw ipv6-related-attack?        boolean
           |     +--:(app-layer-ddos-attack)
           |        +--rw app-layer-ddos-attack-types
           |           +--rw http-flood-attack?      boolean
           |           +--rw https-flood-attack?     boolean
           |           +--rw dns-flood-attack?       boolean
           |           +--rw dns-amp-flood-attack?   boolean
           |           +--rw ssl-flood-attack?       boolean
           +--:(single-packet-attack)
              +--rw (single-packet-attack-type)?
                 +--:(scan-and-sniff-attack)
                 |  +--rw ip-sweep-attack?           boolean
                 |  +--rw port-scanning-attack?      boolean
                 +--:(malformed-packet-attack)
                 |  +--rw ping-of-death-attack?      boolean
                 |  +--rw teardrop-attack?           boolean
                 +--:(special-packet-attack)
                    +--rw oversized-icmp-attack?    boolean
                    +--rw tracert-attack?           boolean

   Figure 10: Data Model Structure for Attack Mitigation Capabilities of
                         Network Security Function

   Attack mitigation is composed of a number of GNSFs; each one protects
   against a specific type of network attack.  Attack Mitigation
   security is a type of GNSF, which summarizes a well-defined set of
   security Capabilities.

6.2.8.  RPC for Acquiring Appropriate Network Security Function

   The data model for RPC for Acquiring Appropriate Network Security
   Function has the following structure:

     rpcs:
       +---x call-appropriate-nsf
          +---w input
          |  +---w nsf-type         nsf-type
          |  +---w target-device
          |     +---w pc?                 boolean
          |     +---w mobile-phone?       boolean
          |     +---w voip-volte-phone?   boolean
          |     +---w tablet?             boolean
          |     +---w iot?                boolean
          |     +---w vehicle?            boolean
          +--ro output
             +--ro nsf-address
                +--ro (nsf-address-type)?
                   +--:(ipv4-address)
                   |  +--ro ipv4-address    inet:ipv4-address
                   +--:(ipv6-address)
                      +--ro ipv6-address    inet:ipv6-address

    Figure 11: RPC for Acquiring Appropriate Network Security Function

   This shows a RPC for acquiring an appropriate network security
   function according to type of NSF and/or target devices.  If the SFF
   [i2nsf-sfc]does not have the location information of network security
   functions that it should send in own cache table, this can be used to
   acquire the information.  These objects are defined as input data
   (i.e., NSF type and target devices) and output data (i.e., location
   information of NSF).

7.  YANG Modules

7.1.  I2NSF Capability YANG Data Module

   This section introduces a YANG module for the information model of
   network security functions, as defined in the [i2nsf-nsf-cap-im].

  <CODE BEGINS> file "ietf-i2nsf-capability@2018-11-04.yang"

  module ietf-i2nsf-capability {
    namespace
      "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
    prefix
      i2nsf-capability;

    import ietf-inet-types{
      prefix inet;
    }
    organization
      "IETF I2NSF (Interface to Network Security Functions)
       Working Group";

    contact
      "WG Web: <http://tools.ietf.org/wg/i2nsf>
       WG List: <mailto:i2nsf@ietf.org>

       WG Chair: Adrian Farrel
       <mailto:Adrain@olddog.co.uk>

       WG Chair: Linda Dunbar
       <mailto:Linda.duhbar@huawei.com>

       Editor: Susan Hares
       <mailto:shares@ndzh.com>

       Editor: Jaehoon Paul Jeong
       <mailto:pauljeong@skku.edu>

       Editor: Jinyong Tim Kim
       <mailto:timkim@skku.edu>";

    description
      "This module describes a capability model
      for I2NSF devices.";

    revision "2018-11-04"{
      description "The fifth revision";
      reference
        "draft-ietf-i2nsf-capability-04";
    }

    grouping i2nsf-nsf-location {
      description
        "This provides a location for capabilities.";
      container nsf-address {
        description
         "This is location information for capabilities.";
        choice nsf-address-type {
          description
            "nsf address type: ipv4 and ipv4";
          case ipv4-address {
            description
              "ipv4 case";
            leaf ipv4-address {
              type inet:ipv4-address;
              mandatory true;
              description
                "nsf address type is ipv4";
            }
          }
          case ipv6-address {
            description
              "ipv6 case";
            leaf ipv6-address {
              type inet:ipv6-address;
              mandatory true;
              description
                "nsf address type is ipv6";
            }
          }
        }
      }
    }

    typedef nsf-type {
        type enumeration {
          enum network-firewall {
            description
              "If type of a NSF is Network Firewall.";
          }

          enum web-app-firewall {
            description
              "If type of a NSF is Web Application
              Firewall.";
          }

          enum anti-virus {
            description
              "If type of a NSF is Anti-Virus";
          }

          enum ids {
            description
              "If type of a NSF is IDS.";
          }

          enum ips {
            description
              "If type of a NSF is IPS.";
          }
          enum ddos-mitigator {
            description
              "If type of a NSF is DDoS Mitigator.";
          }
        }
        description
          "This is used for type of NSF.";
    }

    grouping i2nsf-it-resources {
      description
        "This provides a link between capabilities
         and IT resources. This has a list of IT resources
         by name.";
      container target-device {
        description
          "it-resources";

        leaf pc {
          type boolean;
          description
            "If type of a device is PC.";
        }

        leaf mobile-phone {
          type boolean;
          description
            "If type of a device is mobile-phone.";
        }

        leaf voip-volte-phone {
          type boolean;
          description
            "If type of a device is voip-volte-phone.";
        }

        leaf tablet {
          type boolean;
          description
            "If type of a device is tablet.";
        }

        leaf iot {
          type boolean;
          description
            "If type of a device is Internet of Things.";
        }
        leaf vehicle {
          type boolean;
          description
            "If type of a device is vehicle.";
        }

      }
    }

    grouping capabilities-information {
      description
        "This includes information of capabilities.";

      leaf nsf-type {
        type nsf-type;
        description
          "This is type of NSF.";
      }
      uses i2nsf-nsf-location;
      uses i2nsf-it-resources;
    }

    grouping i2nsf-net-sec-caps {
      description
        "i2nsf-net-sec-caps";
      container net-sec-capabilities {
        description
          "net-sec-capabilities";

        container time {
            description
              "This is capabilities for time";
            container time-zone {
              description
                "This can be used to apply rules
                according to time zone";

              leaf time-zone-offset {
                type boolean;
                description
                  "This is offset for UTC time zone";
              }

            }

            container time-inteval {
              description
                "This can be used to apply rules
                according to time inteval";
              container absolute-time-inteval {
                description
                  "This can be used to apply rules according to
                   absolute time inteval";
                leaf start-time {
                  type boolean;
                  description
                    "This is start time for absolute time inteval";
                }
                leaf end-time {
                  type boolean;
                  description
                    "This is end time for absolute time inteval";
                }
              }
              container periodic-time-inteval {
                description
                  "This can be used to apply rules according to
                   periodic time inteval";
                leaf day {
                  type boolean;
                  description
                    "This is day for periodic time inteval";
                }
                leaf month {
                  type boolean;
                  description
                    "This is month for periodic time inteval";
                }
              }
            }
        }

        container event {
          description
            " This is abstract. An event is defined as any important
              occurrence in time of a change in the system being
              managed, and/or in the environment of the system being
              managed. When used in the context of policy rules for
              a flow-based NSF, it is used to determine whether the
              Condition clause of the Policy Rule can be evaluated
              or not. Examples of an I2NSF event include time and
              user actions (e.g., logon, logoff, and actions that
              violate any ACL.).";

            container usr-event {
              description "TBD";
              leaf usr-sec-event-content {
                type boolean;
                description
                 "This is a mandatory string that contains the content
                  of the UserSecurityEvent. The format of the content
                  is specified in the usrSecEventFormat class
                  attribute, and the type of event is defined in the
                  usrSecEventType class attribute. An example of the
                  usrSecEventContent attribute is a string hrAdmin,
                  with the usrSecEventFormat set to 1 (GUID) and the
                  usrSecEventType attribute set to 5 (new logon).";
              }

              container usr-sec-event-format {
                description
                 "This is a mandatory uint 8 enumerated integer, which
                  is used to specify the data type of the
                  usrSecEventContent attribute. The content is
                  specified in the usrSecEventContent class attribute,
                  and the type of event is defined in the
                  usrSecEventType class attribute. An example of the
                  usrSecEventContent attribute is string hrAdmin,
                  with the usrSecEventFormat attribute set to 1 (GUID)
                  and the usrSecEventType attribute set to 5
                  (new logon).";
                leaf unknown {
                  type boolean;
                  description
                    "If SecEventFormat is unknown";
                }
                leaf guid {
                  type boolean;
                  description
                    "If SecEventFormat is GUID
                    (Generic Unique IDentifier)";
                }
                leaf uuid {
                  type boolean;
                  description
                    "If SecEventFormat is UUID
                    (Universal Unique IDentifier)";
                }
                leaf uri {
                  type boolean;
                  description
                    "If SecEventFormat is URI
                    (Uniform Resource Identifier)";
                }
                leaf fqdn {
                  type boolean;
                  description
                    "If SecEventFormat is FQDN
                    (Fully Qualified Domain Name)";
                }
                leaf fqpn {
                  type boolean;
                  description
                    "If SecEventFormat is FQPN
                    (Fully Qualified Path Name)";
                }
              }

              container usr-sec-event-type {
                leaf unknown {
                    type boolean;
                    description
                      "If usrSecEventType is unknown";
                }
                leaf user-created {
                    type boolean;
                    description
                      "If usrSecEventType is new user
                      created";
                }
                leaf user-grp-created {
                    type boolean;
                    description
                      "If usrSecEventType is new user
                      group created";
                }
                leaf user-deleted {
                    type boolean;
                    description
                      "If usrSecEventType is user
                      deleted";
                }
                leaf user-grp-deleted {
                    type boolean;
                    description
                      "If usrSecEventType is user
                      group deleted";
                }
                leaf user-logon {
                    type boolean;
                    description
                      "If usrSecEventType is user
                      logon";
                }
                leaf user-logoff {
                    type boolean;
                    description
                      "If usrSecEventType is user
                      logoff";
                }
                leaf user-access-request {
                    type boolean;
                    description
                      "If usrSecEventType is user
                      access request";
                }
                leaf user-access-granted {
                    type boolean;
                    description
                      "If usrSecEventType is user
                      granted";
                }
                leaf user-access-violation {
                    type boolean;
                    description
                      "If usrSecEventType is user
                      violation";
                }
                description
                 "This is a mandatory uint 8 enumerated integer, which
                  is used to specify the type of event that involves
                  this user. The content and format are specified in
                  the usrSecEventContent and usrSecEventFormat class
                  attributes, respectively. An example of the
                  usrSecEventContent attribute is string hrAdmin,
                  with the usrSecEventFormat attribute set to 1 (GUID)
                  and the usrSecEventType attribute set to 5
                 (new logon).";
              }

            }
            container dev-event {
              description "TBD";

              leaf dev-sec-event-content {
                type boolean;
                mandatory true;
                description
                 "This is a mandatory string that contains the content
                  of the DeviceSecurityEvent. The format of the
                  content is specified in the devSecEventFormat class
                  attribute, and the type of event is defined in the
                  devSecEventType class attribute. An example of the
                  devSecEventContent attribute is alarm, with the
                  devSecEventFormat attribute set to 1 (GUID), the
                  devSecEventType attribute set to 5 (new logon).";
              }

              container dev-sec-event-format {
                description
                 "This is a mandatory uint 8 enumerated integer,
                  which is used to specify the data type of the
                  devSecEventContent attribute.";

                leaf unknown {
                  type boolean;
                  description
                    "If SecEventFormat is unknown";
                }
                leaf guid {
                  type boolean;
                  description
                    "If SecEventFormat is GUID
                    (Generic Unique IDentifier)";
                }
                leaf uuid {
                  type boolean;
                  description
                    "If SecEventFormat is UUID
                    (Universal Unique IDentifier)";
                }
                leaf uri {
                  type boolean;
                  description
                    "If SecEventFormat is URI
                    (Uniform Resource Identifier)";
                }
                leaf fqdn {
                  type boolean;
                  description
                    "If SecEventFormat is FQDN
                    (Fully Qualified Domain Name)";
                }
                leaf fqpn {
                  type boolean;
                  description
                    "If SecEventFormat is FQPN
                    (Fully Qualified Path Name)";
                }
              }

              container dev-sec-event-type {
                description
                 "This is a mandatory uint 8 enumerated integer,
                  which is used to specify the type of event
                  that was generated by this device.";

                leaf unknown {
                    type boolean;
                    description
                      "If devSecEventType is unknown";
                }
                leaf comm-alarm {
                    type boolean;
                    description
                      "If devSecEventType is communications
                      alarm";
                }
                leaf quality-of-service-alarm {
                    type boolean;
                    description
                      "If devSecEventType is quality of service
                      alarm";
                }
                leaf process-err-alarm {
                    type boolean;
                    description
                      "If devSecEventType is processing error
                      alarm";
                }
                leaf equipment-err-alarm {
                    type boolean;
                    description
                      "If devSecEventType is equipment error
                      alarm";
                }
                leaf environmental-err-alarm {
                    type boolean;
                    description
                      "If devSecEventType is environmental error
                      alarm";
                }

              }
              container dev-sec-event-type-severity {
                description
                 "This is a mandatory uint 8 enumerated integer,
                  which is used to specify the perceived
                  severity of the event generated by this
                  Device.";

                leaf unknown {
                    type boolean;
                    description
                      "If devSecEventType is unknown";
                }
                leaf cleared {
                    type boolean;
                    description
                      "If devSecEventTypeSeverity is cleared";
                }
                leaf indeterminate {
                    type boolean;
                    description
                      "If devSecEventTypeSeverity is
                      indeterminate";
                }
                leaf critical {
                    type boolean;
                    description
                      "If devSecEventTypeSeverity is critical";
                }
                leaf major{
                    type boolean;
                    description
                      "If devSecEventTypeSeverity is major";
                }
                leaf minor {
                    type boolean;
                    description
                      "If devSecEventTypeSeverity is minor";
                }
                leaf warning {
                    type boolean;
                    description
                      "If devSecEventTypeSeverity is warning";
                }
              }
            }
            container sys-event {
              description "TBD";
              leaf sys-sec-event-content {
                type boolean;
                description
                 "This is a mandatory string that contains a content
                  of the SystemSecurityEvent. The format of a content
                  is specified in a sysSecEventFormat class attribute,
                  and the type of event is defined in the
                  sysSecEventType class attribute. An example of the
                  sysSecEventContent attribute is string sysadmin3,
                  with the sysSecEventFormat attribute set to 1(GUID),
                  and the sysSecEventType attribute set to 2
                  (audit log cleared).";
              }

              container sys-sec-event-format {
                description
                 "This is a mandatory uint 8 enumerated integer, which
                  is used to specify the data type of the
                  sysSecEventContent attribute.";

                leaf unknown {
                  type boolean;
                  description
                    "If SecEventFormat is unknown";
                }
                leaf guid {
                  type boolean;
                  description
                    "If SecEventFormat is GUID
                    (Generic Unique IDentifier)";
                }
                leaf uuid {
                  type boolean;
                  description
                    "If SecEventFormat is UUID
                    (Universal Unique IDentifier)";
                }
                leaf uri {
                  type boolean;
                  description
                    "If SecEventFormat is URI
                    (Uniform Resource Identifier)";
                }
                leaf fqdn {
                  type boolean;
                  description
                    "If SecEventFormat is FQDN
                    (Fully Qualified Domain Name)";

                }
                leaf fqpn {
                  type boolean;
                  description
                    "If SecEventFormat is FQPN
                    (Fully Qualified Path Name)";
                }
              }

              container sys-sec-event-type {
                description
                 "This is a mandatory uint 8 enumerated integer, which
                  is used to specify the type of event that involves
                  this device.";

                leaf unknown {
                    type boolean;
                    description
                      "If sysSecEventType is unknown";
                }
                leaf audit-log-written-to {
                    type boolean;
                    description
                    "If sysSecEventTypeSeverity
                     is that audit log is written to";
                }
                leaf audit-log-cleared {
                    type boolean;
                    description
                    "If sysSecEventTypeSeverity
                     is that audit log is cleared";
                }
                leaf policy-created {
                    type boolean;
                    description
                    "If sysSecEventTypeSeverity
                     is that policy is created";
                }
                leaf policy-edited{
                    type boolean;
                    description
                    "If sysSecEventTypeSeverity
                     is that policy is edited";
                }
                leaf policy-deleted{
                    type boolean;
                    description
                    "If sysSecEventTypeSeverity
                     is that policy is deleted";
                }
                leaf policy-executed{
                    type boolean;
                    description
                    "If sysSecEventTypeSeverity
                     is that policy is executed";
                }
              }
            }
            container time-event {
              description "TBD";

              leaf time-sec-event-begin {
                type boolean;
                description
                  "This is a mandatory DateTime attribute, and
                  represents the beginning of a time period.
                  It has a value that has a date and/or a time
                  component (as in the Java or Python libraries).";
              }

              leaf time-sec-event-end {
                type boolean;
                description
                  "This is a mandatory DateTime attribute, and
                   represents the end of a time period. It has
                   a value that has a date and/or a time component
                   (as in the Java or Python libraries). If this is
                   a single event occurrence, and not a time period
                   when the event can occur, then the
                   timeSecEventPeriodEnd attribute may be ignored.";
              }

              leaf time-sec-event-time-zone {
                type boolean;
                description
                  "This is a mandatory string attribute, and defines a
                   time zone that this event occurred in using the
                   format specified in ISO8601.";
              }
            }

        }

        container condition {
          description
            " This is abstract.  A condition is defined as a set
            of attributes, features, and/or values that are to be
            compared with a set of known attributes, features,
            and/or values in order to determine whether or not the
            set of Actions in that (imperative) I2NSF Policy Rule
            can be executed or not. Examples of I2NSF Conditions
            include matching attributes of a packet or flow, and
            comparing the internal state of an NSF to a desired state.";

            container packet-security-condition {
              description "TBD";

              container packet-security-mac-condition {
                description
                  "The purpose of this Class is to represent packet MAC
                   packet header information that can be used as part of
                   a test to determine if the set of Policy Actions in
                   this ECA Policy Rule should be execute or not.";

                leaf pkt-sec-cond-mac-dest {
                  type boolean;
                  description
                    "The MAC destination address (6 octets long).";
                }

                leaf pkt-sec-cond-mac-src {
                  type boolean;
                  description
                    "The MAC source address (6 octets long).";
                }

                leaf pkt-sec-cond-mac-8021q {
                  type boolean;
                  description
                    "This is an optional string attribute, and defines
                     The 802.1Q tab value (2 octets long).";
                }

                leaf pkt-sec-cond-mac-ether-type {
                  type boolean;
                  description
                    "The EtherType field (2 octets long). Values up to
                     and including 1500 indicate the size of the payload
                     in octets; values of 1536 and above define which
                     protocol is encapsulated in the payload of the
                     frame.";
                }
                leaf pkt-sec-cond-mac-tci {
                  type string;
                  description
                    "This is an optional string attribute, and defines
                     the Tag Control Information. This consists of a 3
                     bit user priority field, a drop eligible indicator
                     (1 bit), and a VLAN identifier (12 bits).";
                }
              }

              container packet-security-ipv4-condition {
                description
                  "The purpose of this Class is to represent packet IPv4
                   packet header information that can be used as part of
                   a test to determine if the set of Policy Actions in
                   this ECA Policy Rule should be executed or not.";

                leaf pkt-sec-cond-ipv4-header-length {
                  type boolean;
                  description
                    "The IPv4 packet header consists of 14 fields,
                     of which 13 are required.";
                }

                leaf pkt-sec-cond-ipv4-tos {
                  type boolean;
                  description
                    "The ToS field could specify a datagram's priority
                     and request a route for low-delay, high-throughput,
                     or highly-reliable service..";
                }

                leaf pkt-sec-cond-ipv4-total-length {
                  type boolean;
                  description
                    "This 16-bit field defines the entire packet size,
                     including header and data, in bytes.";
                }

                leaf pkt-sec-cond-ipv4-id {
                  type boolean;
                  description
                    "This field is an identification field and is
                     primarily used for uniquely identifying
                     the group of fragments of a single IP datagram.";
                }

                leaf pkt-sec-cond-ipv4-fragment {
                  type boolean;
                  description
                    "IP fragmentation is an Internet Protocol (IP)
                     process that breaks datagrams into smaller pieces
                     (fragments), so that packets may be formed that
                     can pass through a link with a smaller maximum
                     transmission unit (MTU) than the original
                     datagram size.";
                }

                leaf pkt-sec-cond-ipv4-fragment-offset {
                  type boolean;
                  description
                    "Fragment offset field along with Don't Fragment
                     and More Fragment flags in the IP protocol
                     header are used for fragmentation and reassembly
                     of IP datagrams.";
                }

                leaf pkt-sec-cond-ipv4-ttl {
                  type boolean;
                  description
                    "The ttl keyword is used to check for a specific
                     IP time-to-live value in the header of
                     a packet.";
                }

                leaf pkt-sec-cond-ipv4-protocol {
                  type boolean;
                  description
                    "Internet Protocol version 4(IPv4) is the fourth
                     version of the Internet Protocol (IP).";
                }

                leaf pkt-sec-cond-ipv4-src {
                  type boolean;
                  description
                    "Defines the IPv4 Source Address.";
                }

                leaf pkt-sec-cond-ipv4-dest {
                  type boolean;
                  description
                    "Defines the IPv4 Destination Address.";
                }

                leaf pkt-sec-cond-ipv4-ipopts {
                  type boolean;
                  description
                    "With the ipopts keyword you can check if
                     a specific ip option is set. Ipopts has
                     to be used at the beginning of a rule.";
                }

                leaf pkt-sec-cond-ipv4-sameip {
                  type boolean;
                  description
                    "Every packet has a source IP-address and
                     a destination IP-address. It can be that
                     the source IP is the same as RFC 8341; see
    the destination IP."; RFC itself for full legal notices.";

  revision "2019-03-11"{
    description "Initial revision.";
    reference
      "RFC XXXX: I2NSF Capability YANG Data Model";
  }

                leaf pkt-sec-cond-ipv4-geoip

  /*
   * Identities
   */

  identity event {
                  type boolean;
    description
                    "The geoip keyword enables you to match on
                     the source, destination or source and destination
                     IP addresses
      "Base identity for event of network traffic and to see to
                     which country it belongs. To do this, Suricata
                     uses GeoIP API with MaxMind database format.";
                } policy.";
    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - Event";
  }

              container packet-security-ipv6-condition

  identity system-event-capa {
    base event;
    description
                   "The purpose of this Class is to represent packet
                   IPv6 packet header information that can be used as
                   part of a test to determine if the set of Policy
                   Actions in this ECA Policy Rule should be executed
                   or not.";

                leaf pkt-sec-cond-ipv6-dscp
      "Identity for system event";
    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - System alarm";
  }

  identity system-alarm-capa {
                  type boolean;
    base event;
    description
                    "Differentiated Services Code Point (DSCP)
                     of ipv6.";
      "Identity for system alarm";
    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - System alarm";
  }

                leaf pkt-sec-cond-ipv6-ecn

  identity access-violation {
                  type boolean;
    base system-event-capa;
    description
                    "ECN allows end-to-end notification of network
                     congestion without dropping packets.";
      "Identity for access violation
      among system events";

    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - System event";
  }
                leaf pkt-sec-cond-ipv6-traffic-class

  identity configuration-change {
                  type boolean;
    base system-event-capa;
    description
                    "The bits of this field hold two values. The 6
                     most-significant bits are used
      "Identity for
                     differentiated services, which is used to
                     classify packets."; configuration change
      among system events";
    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - System event";
  }

                leaf pkt-sec-cond-ipv6-flow-label

  identity memory-alarm {
                  type boolean;
    base system-alarm-capa;
    description
                    "The flow label when set to a non-zero value
                     serves as a hint to routers and switches
                     with multiple outbound paths that these
                     packets should stay on the same path so that
                     they will not be reordered.";
      "Identity for memory alarm
      among system alarms";
    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - System alarm";
  }

                leaf pkt-sec-cond-ipv6-payload-length

  identity cpu-alarm {
                  type boolean;
    base system-alarm-capa;
    description
                    "The size of the payload in octets,
                     including any extension headers.";
      "Identity for cpu alarm
      among system alarms";
    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - System alarm";
  }

                leaf pkt-sec-cond-ipv6-next-header

  identity disk-alarm {
                  type boolean;
    base system-alarm-capa;
    description
                    "Specifies the type of the next header.
                     This field usually specifies the transport
                     layer protocol used by a packet's payload.";
      "Identity for disk alarm
      among system alarms";
    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - System alarm";
  }

                leaf pkt-sec-cond-ipv6-hop-limit

  identity hardware-alarm {
                  type boolean;
    base system-alarm-capa;
    description
                    "Replaces the time to live field of IPv4.";
      "Identity for hardware alarm
      among system alarms";
    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - System alarm";
  }

                leaf pkt-sec-cond-ipv6-src

  identity interface-alarm {
                  type boolean;
    base system-alarm-capa;
    description
                    "The IPv6 address of the sending node.";
      "Identity for interface alarm
      among system alarms";
    reference
      "draft-hong-i2nsf-nsf-monitoring-data-model-06
       - System alarm";
  }

                leaf pkt-sec-cond-ipv6-dest

  identity condition {
                  type boolean;
    description
                    "The IPv6 address
      "Base identity for conditions of the destination node(s).";
                } policy";
  }

              container packet-security-tcp-condition

  identity ipv4-capa {
    base condition;
    description
                  "The purpose of this Class is to represent packet
                   TCP packet header information that can be used as
                   part of a test to determine if the set
      "Identity for capabilities of Policy
                   Actions in this ECA Policy Rule should be executed
                   or not.";

                leaf pkt-sec-cond-tcp-src-port {
                  type boolean;
                  description
                    "This is a mandatory string attribute, and
                    defines the Source Port number (16 bits)."; IPv4 condition";
    reference
      "RFC 791: Internet Protocol";
  }

                leaf pkt-sec-cond-tcp-dest-port

  identity exact-ipv4-header-length {
                  type boolean;
    base ipv4-capa;
    description
                    "This is a mandatory string attribute, and
                    defines the Destination Port number (16 bits).";
      "Identity for exact header length capability
      of IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Header Length";
  }

                leaf pkt-sec-cond-tcp-seq-num

  identity range-ipv4-header-length {
                  type boolean;
    base ipv4-capa;
    description
                    "If the SYN flag is set (1), then this is the
                     initial sequence number.";
      "Identity for range header length capability
      of IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Header Length";
  }

                leaf pkt-sec-cond-tcp-ack-num
  identity ipv4-tos {
                  type boolean;
    base ipv4-capa;
    description
                    "If the ACK flag is set then the value
      "Identity for type of this
                     field is the next sequence number that the sender
                     is expecting."; service capability
      of IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Type of Service";
  }

                leaf pkt-sec-cond-tcp-window-size

  identity exact-ipv4-total-length {
                  type boolean;
    base ipv4-capa;
    description
                    "The size
      "Identity for exact total length capability
      of the receive window, which specifies
                     the number IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Total Length";
  }

  identity range-ipv4-total-length {
    base ipv4-capa;
    description
      "Identity for range total length capability
      of windows size units (by default,bytes)
                     (beyond the segment identified by the sequence
                     number in the acknowledgment field) that the sender IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Total Length";
  }

  identity ipv4-id {
    base ipv4-capa;
    description
      "Identity for identification capability
      of this segment is currently willing to recive."; IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Identification";
  }

                leaf pkt-sec-cond-tcp-flags

  identity ipv4-fragment-flags {
                  type boolean;
    base ipv4-capa;
    description
                    "This is a mandatory string attribute, and defines
                     the nine Control bit
      "Identity for fragment flags (9 bits).";
                } capability
      of IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Fragmentation  Flags";
  }

              container packet-security-udp-condition

  identity exact-ipv4-fragment-offset {
    base ipv4-capa;
    description
                  "The purpose of this Class is to represent packet UDP
                   packet header information that can be used as part
                   of a test to determine if the set
      "Identity for exact fragment offset capability
      of Policy Actions
                   in this ECA Policy Rule should be executed or not.";

                leaf pkt-sec-cond-udp-src-port IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Fragmentation  Offset";
  }

  identity range-ipv4-fragment-offset {
                  type boolean;
    base ipv4-capa;
    description
                    "This is a mandatory string attribute, and
                    defines the UDP Source Port number (16 bits).";
      "Identity for range fragment offset capability
      of IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Fragmentation  Offset";
  }

                leaf pkt-sec-cond-udp-dest-port

  identity exact-ipv4-ttl {
                  type boolean;
    base ipv4-capa;
    description
                    "This is a mandatory string attribute, and
                    defines the UDP Destination Port number (16 bits).";
      "Identity for exact time to live capability
      of IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Time To Live (TTL)";
  }

                leaf pkt-sec-cond-udp-length

  identity range-ipv4-ttl {
                  type boolean;
    base ipv4-capa;
    description
                    "This is a mandatory string attribute, and defines
                     the length in bytes
      "Identity for range time to live capability
      of the UDP header and data
                     (16 bits).";
                } IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Time To Live (TTL)";
  }

              container packet-security-icmp-condition

  identity ipv4-protocol {
    base ipv4-capa;
    description
                  "The internet control message
      "Identity for protocol condition.";

                leaf pkt-sec-cond-icmp-type capability
      of IPv4 condition";
    reference
      "RFC 790: Assigned numbers - Assigned Internet
       Protocol Number
       RFC 791: Internet Protocol - Protocol";
  }

  identity exact-ipv4-address {
                  type boolean;
    base ipv4-capa;
    description
                    "ICMP type, see Control messages.";
      "Identity for exact address capability
      of IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Address";
  }

                leaf pkt-sec-cond-icmp-code

  identity range-ipv4-address {
                  type boolean;
    base ipv4-capa;
    description
                    "ICMP subtype, see Control messages.";
      "Identity for range-address capability
      of IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Address";
  }

                leaf pkt-sec-cond-icmp-seg-num

  identity ipv4-ipopts {
                  type boolean;
    base ipv4-capa;
    description
                    "The icmp Sequence Number.";
                }
              }
      "Identity for option capability
      of IPv4 condition";
    reference
      "RFC 791: Internet Protocol - Options";
  }

            container packet-payload-condition

  identity ipv4-sameip {
    base ipv4-capa;
    description "TBD";
              leaf pkt-payload-content
      "Identity for sameIP capability
      of IPv4 condition";
  }

  identity ipv4-geoip {
                type boolean;
    base ipv4-capa;
    description
                  "The content keyword is very important in
                   signatures. Between the quotation marks you
                   can write on what you would like the
                   signature to match.";
              }
      "Identity for geography capability
      of IPv4 condition";
  }
            leaf acl-number

  identity ipv6-capa {
              type boolean;
    base condition;
    description
               "This is acl-number.";
      "Identity for capabilities of IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification";
  }

            container application-condition

  identity ipv6-traffic-class {
    base ipv6-capa;
    description
                "TBD";

              leaf application-object
      "Identity for traffic class capability
      of IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Traffic Class";
  }

  identity exact-ipv6-flow-label {
                type boolean;
    base ipv6-capa;
    description
                  "This is application object.";
      "Identity for exact flow label capability
      of IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Flow Label";
  }
              leaf application-group

  identity range-ipv6-flow-label {
                type boolean;
    base ipv6-capa;
    description
                  "This is application group.";
      "Identity for range flow label capability
      of IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Flow Label";
  }
              leaf application-label

  identity exact-ipv6-payload-length {
                type boolean;
    base ipv6-capa;
    description
                  "This is application label.";
      "Identity for exact payload length capability
      of IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Payload Length";
  }
              container category

  identity range-ipv6-payload-length {
    base ipv6-capa;
    description
                  "TBD";
                leaf application-category
      "Identity for range payload length capability
      of IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Payload Length";
  }
  identity ipv6-next-header {
                  type boolean;
    base ipv6-capa;
    description
                    "TBD";

                }
              }
      "Identity for next header capability
      of IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Next Header";
  }

            container target-condition

  identity exact-ipv6-hop-limit {
    base ipv6-capa;
    description "TBD";

              leaf device-sec-context-cond
      "Identity for exact hop limit capability
      of IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Hop Limit";
  }

  identity range-ipv6-hop-limit {
                type boolean;
    base ipv6-capa;
    description
                  "The device attribute that can identify a device,
                   including the device type (i.e., router, switch,
                   pc, ios, or android) and the device's owner as
                   well.";
              }
      "Identity for range hop limit capability
      of IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Hop Limit";
  }
            container users-condition

  identity exact-ipv6-address {
    base ipv6-capa;
    description "TBD";

              container user{
                description
                  "The user (or user group) information with which
                   network flow is associated: The user has many
                   attributes such as name, id, password, type,
                   authentication mode and so on. Name/id is often
                   used in the security policy to identify the user.
                   Besides, NSF is aware of the IP
      "Identity for exact address capability
      of the
                   user provided by a unified user management system
                   via network. Based on name-address association,
                   NSF is able to enforce the security functions
                   over the given user (or user group)";

                choice user-name IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Address";
  }

  identity range-ipv6-address {
    base ipv6-capa;
    description
                    "The name
      "Identity for range address capability
      of the user.
                     This must be unique.";

                  case tenant {
                    description
                      "Tenant information.";

                    leaf tenant IPv6 condition";
    reference
      "RFC 2460: Internet Protocol, Version 6 (IPv6)
      Specification - Address";

  }

  identity tcp-capa {
                      type boolean;
    base condition;
    description
                        "User's tenant information.";
                    }
      "Identity for capabilities of tcp condition";
    reference
      "RFC 793: Transmission Control Protocol";
  }

                  case vn-id

  identity exact-tcp-port-num {
    base tcp-capa;
    description
                      "VN-ID information.";

                    leaf vn-id
      "Identity for exact port number capability
      of tcp condition";
    reference
      "RFC 793: Transmission Control Protocol - Port Number";
  }

  identity range-tcp-port-num {
                      type boolean;
    base tcp-capa;
    description
                        "User's VN-ID information.";
                    }
                  }
                }
      "Identity for range port number capability
      of tcp condition";
    reference
      "RFC 793: Transmission Control Protocol - Port Number";
  }
              container group

  identity exact-tcp-seq-num {
    base tcp-capa;
    description
                  "The user (or user group) information with which
                   network flow is associated: The user has many
                   attributes such as name, id, password, type,
                   authentication mode and so on. Name/id is often
                   used in the security policy to identify the user.
                   Besides, NSF is aware of the IP address
      "Identity for exact sequence number capability
      of the
                   user provided by a unified user management system
                   via network. Based on name-address association,
                   NSF is able to enforce the security functions
                   over the given user (or user group)";

                choice group-name tcp condition";
    reference
      "RFC 793: Transmission Control Protocol - Sequence Number";
  }

  identity range-tcp-seq-num {
    base tcp-capa;
    description
                    "The name
      "Identity for range sequence number capability
      of the user.
                     This must be unique.";

                  case tenant tcp condition";
    reference
      "RFC 793: Transmission Control Protocol - Sequence Number";
  }

  identity exact-tcp-ack-num {
    base tcp-capa;
    description
                      "Tenant information.";

                    leaf tenant
      "Identity for exact acknowledgement number capability
      of tcp condition";
    reference
      "RFC 793: Transmission Control Protocol - Acknowledgement Number";
  }

  identity range-tcp-ack-num {
                      type boolean;
    base tcp-capa;
    description
                        "User's tenant information.";
                    }
      "Identity for range acknowledgement number capability
      of tcp condition";
    reference
      "RFC 793: Transmission Control Protocol - Acknowledgement Number";
  }

                  case vn-id

  identity exact-tcp-window-size {
    base tcp-capa;
    description
                      "VN-ID information.";

                    leaf vn-id
      "Identity for exact window size capability
      of tcp condition";
    reference
      "RFC 793: Transmission Control Protocol - Window Size";
  }

  identity range-tcp-window-size {
                      type boolean;
    base tcp-capa;
    description
                        "User's VN-ID information.";
                    }
                  }
      "Identity for range window size capability
      of tcp condition";
    reference
      "RFC 793: Transmission Control Protocol - Window Size";
  }
                leaf security-grup

  identity tcp-flags {
                  type boolean;
                  mandatory true;
    base tcp-capa;
    description
                    "security-grup.";
                }
              }
      "Identity for flags capability
      of tcp condition";
    reference
      "RFC 793: Transmission Control Protocol - Flags";
  }

            container url-category-condition

  identity udp-capa {
    base condition;
    description
                "TBD";
              leaf pre-defined-category
      "Identity for capabilities of udp condition";
    reference
      "RFC 768: User Datagram Protocol";
  }

  identity exact-udp-port-num {
                type boolean;
    base udp-capa;
    description
                  "This is pre-defined-category.";
      "Identity for exact port number capability
      of udp condition";
    reference
      "RFC 768: User Datagram Protocol - Port Number";
  }
              leaf user-defined-category

  identity range-udp-port-num {
                type boolean;
    base udp-capa;
    description
                  "This user-defined-category.";
              }
      "Identity for range port number capability
      of udp condition";
    reference
      "RFC 768: User Datagram Protocol - Port Number";
  }

            container context-condition

  identity exact-udp-total-length {
    base udp-capa;
    description "TBD";
              leaf temp
      "Identity for exact total-length capability
      of udp condition";
    reference
      "RFC 768: User Datagram Protocol - Total Length";
  }

  identity range-udp-total-length {
                type string;
    base udp-capa;
    description
                  "This is temp
      "Identity for context condition.";

              } range total-length capability
      of udp condition";
    reference
      "RFC 768: User Datagram Protocol - Total Length";
  }
            container gen-context-condition

  identity icmp-capa {
    base condition;
    description "TBD";

              container geographic-location
      "Identity for capabilities of icmp condition";
    reference
      "RFC 792: Internet Control Message Protocol";
  }

  identity icmp-type {
    base icmp-capa;
    description
                  "The location where network traffic is associated
                   with. The region can be the geographic location
                   such as country, province, and city,
                   as well as the logical network location such as
                   IP address, network section, and network domain.";

                leaf src-geographic-location {
      "Identity for icmp type boolean; capability
      of icmp condition";
    reference
      "RFC 792: Internet Control Message Protocol";
  }

  identity http-capa {
    base condition;
    description
                    "This is mapped to ip address. We can acquire
                     source region through ip address stored the
                     database.";
      "Identity for capabilities of http condition";
  }
                leaf dest-geographic-location

  identity uri {
                  type boolean;
    base http-capa;
    description
                    "This is mapped to ip address. We can acquire
                     destination region through ip address stored
                     the database.";
                }
              }
            }
      "Identity for uri capabilities of
       http condition";
  }
        container action

  identity url {
    base http-capa;
    description
            "An action is used to control and monitor aspects of
             flow-based NSFs when the event and condition clauses
             are satisfied. NSFs provide security functions by
             executing various Actions. Examples
      "Identity for url capabilities of I2NSF Actions
             include providing intrusion detection and/or protection,
             web and flow filtering, and deep packet inspection
       http condition";
  }

  identity log-action-capa {
    description
      "Identity for packets and flows.";

            leaf capabilities of log action";
  }

  identity rule-log {
              type boolean;
    base log-action-capa;
    description
                "rule-log";
      "Identity for rule log capability
      of log action";
  }
            leaf

  identity session-log {
              type boolean;
    base log-action-capa;
    description
                "session-log";
      "Identity for session log capability
      of log action";
  }

            container ingress-action

  identity ingress-action-capa {
    description "TBD";

              container ingress-action-type
      "Identity for capabilities of ingress action";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Action";
  }

  identity egress-action-capa {
    description
                  "Ingress action type: permit, deny, and mirror.";
                leaf
      "Base identity for egress action";
  }

  identity default-action-capa {
    description
      "Identity for capabilities of default action";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Default action";
  }

  identity pass {
                  type boolean;
    base ingress-action-capa;
    base egress-action-capa;
    base default-action-capa;
    description
                    "If ingress action is
      "Identity for pass";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Actions and
       default action";
  }
                leaf

  identity drop {
                  type boolean;
    base ingress-action-capa;
    base egress-action-capa;
    base default-action-capa;
    description
                    "If ingress action is
      "Identity for drop";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Actions and
       default action";
  }
                leaf

  identity reject {
                  type boolean;
    base ingress-action-capa;
    base egress-action-capa;
    base default-action-capa;
    description
                    "If ingress action is
      "Identity for reject";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Actions and
       default action";
  }
                leaf

  identity alert {
                  type boolean;
    base ingress-action-capa;
    base egress-action-capa;
    base default-action-capa;
    description
                    "If ingress action is
      "Identity for alert";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Actions and
       default action";
  }
                leaf

  identity mirror {
                  type boolean;
    base ingress-action-capa;
    base egress-action-capa;
    base default-action-capa;
    description
                    "If ingress action is
      "Identity for mirror";
                }
              }
            }
            container egress-action {
              description "TBD";

              container egress-action-type {
                description
                  "Egress-action-type: invoke-signaling,
                   tunnel-encapsulation,
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Actions and forwarding.";
                leaf
       default action";
  }

  identity invoke-signaling {
                  type boolean;
    base egress-action-capa;
    description
                    "If egress action is
      "Identity for invoke signaling";
  }
                leaf

  identity tunnel-encapsulation {
                  type boolean;
    base egress-action-capa;
    description
                    "If egress action is
      "Identity for tunnel encapsulation";
  }
                leaf forwarding

  identity forwarding {
    base egress-action-capa;
    description
      "Identity for forwarding";

  }

  identity redirection {
    base egress-action-capa;
    description
      "Identity for redirection";
  }

  identity resolution-strategy-capa {
    description
      "Base identity for resolution strategy";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Resolution Strategy";
  }

  identity fmr {
    base resolution-strategy-capa;
    description
      "Identity for First Matching Rule (FMR)";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Resolution Strategy";
  }

  identity lmr {
    base resolution-strategy-capa;
    description
      "Identity for Last Matching Rule (LMR)";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Resolution Strategy";
  }

  identity pmr {
                  type boolean;
    base resolution-strategy-capa;
    description
                    "If egress action is forwarding";
      "Identity for Prioritized Matching Rule (PMR)";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Resolution Strategy";
  }
                leaf redirection

  identity pmre {
                  type boolean;
    base resolution-strategy-capa;
    description
                    "If egress action is redirection";
                }
              }
            }
      "Identity for Prioritized Matching Rule
      with Errors (PMRE)";

    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Resolution Strategy";
  }
        container resolution-strategy

  identity pmrn {
    base resolution-strategy-capa;
    description
            "The resolution strategies can be used to
            specify how to resolve conflicts that occur between
            the actions
      "Identity for Prioritized Matching Rule
      with No Errors (PMRN)";
    reference
      "draft-ietf-i2nsf-capability-04: Information Model
       of the same or different policy rules that
            are matched and contained in this particular NSF";

          leaf first-matching-rule NSFs Capabilities - Resolution Strategy";
  }

  identity advanced-nsf-capa {
            type boolean;
    description
              "If the resolution strategy is first matching rule";
      "Base identity for advanced
      network security function capabilities";
    reference
      "RFC 8329: Framework for Interface to Network Security
       Functions - Differences from ACL Data Models
       draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller";
  }

          leaf last-matching-rule

  identity antivirus-capa {
            type boolean;
    base advanced-nsf-capa;
    description
              "If the resolution strategy is last matching rule";
          }
        }
      }
      "Identity for antivirus capabilities";
    reference
      "RFC 8329: Framework for Interface to Network Security
       Functions - Differences from ACL Data Models
       draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antivirus";
  }

    grouping i2nsf-advanced-sec-caps

  identity antiddos-capa {
    base advanced-nsf-capa;
    description
        "i2nsf-advanced-sec-caps";
      container advanced-sec-capabilities
      "Identity for antiddos capabilities";
    reference
      "RFC 8329: Framework for Interface to Network Security
       Functions - Differences from ACL Data Models
       draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }

  identity ips-capa {
    base advanced-nsf-capa;
    description
          "net-sec-capabilities";

        container antivirus
      "Identity for IPS capabilities";
    reference
      "RFC 8329: Framework for Interface to Network Security
       Functions - Differences from ACL Data Models
       draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Intrusion Prevention System";
  }

  identity voip-volte-capa {
    base advanced-nsf-capa;
    description
            "antivirus";

          leaf
      "Identity for VoIP/VoLTE capabilities";
    reference
      "RFC 3261: SIP: Session Initiation Protocol
       RFC 8329: Framework for Interface to Network Security
       Functions - Differences from ACL Data Models
       draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller";
  }

  identity detect {
            type boolean;
    base antivirus-capa;
    description
              "detect capability";
      "Identity for detect capabilities
      of antivirus";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antivirus";
  }
          leaf

  identity exception-application {
            type boolean;
    base antivirus-capa;
    description
              "exception-application capability";
      "Identity for exception application capabilities
      of antivirus";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antivirus";

  }
          leaf

  identity exception-signature {
            type boolean;
    base antivirus-capa;
    description
              "exception-signature capability";
      "Identity for exception signature capabilities
      of antivirus";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antivirus";
  }
          leaf

  identity whitelists {
            type boolean;
    base antivirus-capa;
    description
              "exception-signature capability";
          }
      "Identity for whitelists capabilities
      of antivirus";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antivirus";
  }

        container antiddos {
          description
            "antiddos";

          leaf

  identity syn-flood-action {
            type boolean;
    base antiddos-capa;
    description
              "syn-flood-action capability";
      "Identity for syn flood action capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }
          leaf

  identity udp-flood-action {
            type boolean;
    base antiddos-capa;
    description
              "udp-flood-action capability";
      "Identity for udp flood action capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }
          leaf

  identity http-flood-action {
            type boolean;
    base antiddos-capa;
    description
              "http-flood-action capability";
      "Identity for http flood action capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }
          leaf

  identity https-flood-action {
            type boolean;
    base antiddos-capa;
    description
              "https-flood-action capability";
      "Identity for https flood action capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }
          leaf

  identity dns-request-flood-action {
            type boolean;
    base antiddos-capa;
    description
              "dns-request-flood-action capability";
      "Identity for dns request flood action capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }
          leaf

  identity dns-reply-flood-action {
            type boolean;
    base antiddos-capa;
    description
              "dns-reply-flood-action capability";
      "Identity for dns reply flood action capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }
          leaf

  identity icmp-flood-action {
            type boolean;
    base antiddos-capa;
    description
              "icmp-flood-action capability";
      "Identity for icmp flood action capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }
          leaf

  identity sip-flood-action {
            type boolean;
    base antiddos-capa;
    description
              "sip-flood-action capability";
      "Identity for sip flood action capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }
          leaf

  identity detect-mode {
            type boolean;
    base antiddos-capa;
    description
              "detect
      "Identity for detect mode capability"; capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }
          leaf

  identity baseline-learn {
            type boolean;
    base antiddos-capa;
    description
              "baseline-learn capability";
          }
      "Identity for baseline learn capabilities
      of antiddos";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Antiddos";
  }

        container ips {
          description
            "ips";

          leaf

  identity signature-set {
            type boolean;
            description
              "signature-set capability";
          }
          leaf exception-signature {
            type boolean;
    base ips-capa;
    description
              "exception-signature capability";

          }
        }
      }
      "Identity for signature set capabilities
      of IPS";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Intrusion Prevention System";
  }

    grouping i2nsf-con-sec-control-caps {
      description
        "i2nsf-con-sec-control-caps";

      container con-sec-control-capabilities {
        description
          "content-security-control-capabilities";

        leaf anti-virus
  identity ips-exception-signature {
          type boolean;
    base ips-capa;
    description
            "antivirus";
        }
        leaf
      "Identity for ips {
          type boolean;
          description
            "ips";
        }

        leaf ids {
          type boolean;
          description
            "ids";
        }

        leaf url-filter {
          type boolean;
          description
            "url-filter";
        }
        leaf data-filter {
          type boolean;
          description
            "data-filter";
        }
        leaf mail-filter {
          type boolean;
          description
            "mail-filter";
        }
        leaf sql-filter {
          type boolean;
          description
            "sql-filter";
        }
        leaf file-blocking {
          type boolean;
          description
            "file-blocking";
        }
        leaf file-isolate {
          type boolean;
          description
            "file-isolate";
        }
        leaf pkt-capture {
          type boolean;
          description
            "pkt-capture"; exception signature capabilities
      of IPS";
    reference
      "draft-dong-i2nsf-asf-config-01: Configuration of
       Advanced Security Functions with I2NSF Security
       Controller - Intrusion Prevention System";
  }
        leaf application-behavior

  identity voice-id {
          type boolean;
    base voip-volte-capa;
    description
            "application-behavior";
      "Identity for voice-id capabilities
      of VoIP/VoLTE";
    reference
      "RFC 3261: SIP: Session Initiation Protocol";
  }
        leaf voip-volte

  identity user-agent {
          type boolean;
    base voip-volte-capa;
    description
            "voip-volte";
        }
      }

    }
      "Identity for user agent capabilities
      of VoIP/VoLTE";
    reference
      "RFC 3261: SIP: Session Initiation Protocol";
  }

  /*
   *  Grouping
   */

  grouping i2nsf-attack-mitigation-control-caps nsf-capabilities {
    description
        "i2nsf-attack-mitigation-control-caps";

      container attack-mitigation-capabilities
      "Capabilities of network security funtion";
    reference
      "RFC 8329: Framework for Interface to Network Security
       Functions - I2NSF Flow Security Policy Structure
       draft-ietf-i2nsf-capability-04: Information Model
       of NSFs Capabilities - Capability Information Model Design";

    leaf-list time-capabilities {
        description
          "attack-mitigation-capabilities";
        choice attack-mitigation-control-type
      type enumeration {
          description
            "attack-mitigation-control-type";
          case ddos-attack
        enum absolute-time {
          description
              "ddos-attack";
            choice ddos-attack-type
            "Capabilities of absolute time.
             If network security function has the absolute time
             capability, the network security function
             supports rule execution according to absolute time.";
        }
        enum periodic-time {
          description
                "ddos-attack-type";
              case network-layer-ddos-attack {
            "Capabilities of periodic time.
             If network security function has the periodic time
             capability, the network security function
             supports rule execution according to periodic time.";
        }
      }
      description
                  "network-layer-ddos-attack";
        "This is capabilities for time";
    }

    container network-layer-ddos-attack-types event-capabilities {
      description
                    "network-layer-ddos-attack-type";
                  leaf syn-flood-attack
        "Capabilities of events.
         If network security function has
         the event capabilities, the network security functions
         supports rule execution according to system event
         and system alarm.";

      reference
        "RFC 8329: Framework for Interface to Network Security
         Functions - I2NSF Flow Security Policy Structure
         draft-ietf-i2nsf-capability-04: Information Model
         of NSFs Capabilities - Design Principles and ECA
         Policy Model Overview
         draft-hong-i2nsf-nsf-monitoring-data-model-06: A YANG
         Data Model for Monitoring I2NSF Network Security
         Functions - System Alarm and System Events";

      leaf-list system-event-capa {
        type boolean;
                    description
                      "syn-flood-attack";
                  }
                  leaf udp-flood-attack identityref {
                    type boolean;
                    description
                      "udp-flood-attack";
          base system-event-capa;
        }
                  leaf icmp-flood-attack {
                    type boolean;
        description
                      "icmp-flood-attack";
          "Capabilities for a system event";
      }
                  leaf ip-fragment-flood-attack

      leaf-list system-alarm-capa {
        type boolean;
                    description
                      "ip-fragment-flood-attack";
                  }
                  leaf ipv6-related-attack identityref {
                    type boolean;
                    description
                      "ip-fragment-flood-attack";
          base system-alarm-capa;
        }
        description
          "Capabilities for a system alarm";
      }

    }
              case app-layer-ddos-attack {
                description
                  "app-layer-ddos-attack";

    container app-layer-ddos-attack-types condition-capabilities {
      description
                    "app-layer-ddos-attack-types";
                  leaf http-flood-attack {
                    type boolean;
                    description
                      "http-flood-attack";
                  }
                  leaf https-flood-attack {
                    type boolean;
                    description
                      "https-flood-attack";
                  }
                  leaf dns-flood-attack
        "Capabilities of conditions.";

      container generic-nsf-capabilities {
                    type boolean;
        description
                      "dns-flood-attack";
                  }
                  leaf dns-amp-flood-attack
          "Capabilities of conditions.
           If a network security function has
           the condition capabilities, the network security function
           supports rule execution according to conditions of IPv4,
           IPv6, foruth layer, ICMP, and payload.";
        reference
          "RFC  791: Internet Protocol
           RFC  792: Internet Control Message Protocol
           RFC  793: Transmission Control Protocol
           RFC 2460: Internet Protocol, Version 6 (IPv6)
           Specification - Next Header
           RFC 8329: Framework for Interface to Network Security
           Functions - I2NSF Flow Security Policy Structure
           draft-ietf-i2nsf-capability-04: Information Model
           of NSFs Capabilities - Design Principles and ECA Policy
           Model Overview";

        leaf-list ipv4-capa {
          type boolean;
                    description
                      "dns-amp-flood-attack";
                  }
                  leaf ssl-flood-attack identityref {
                    type boolean;
                    description
                      "ssl-flood-attack";
                  }
                }
              }
            }
            base ipv4-capa;
          }

          case single-packet-attack {
            description
              "single-packet-attack";
            choice single-packet-attack-type {
              description
                "single-packet-attack-type";
              case scan-and-sniff-attack {
          description
                  "scan-and-sniff-attack";
                leaf ip-sweep-attack {
                  type boolean;
                  description
                    "ip-sweep-attack";
            "Capabilities for an IPv4 packet";
          reference
            "RFC 791: Internet Protocol";
        }
                leaf port-scanning-attack

        leaf-list ipv6-capa {
          type boolean;
                  description
                    "port-scanning-attack";
                }
              }
              case malformed-packet-attack identityref {
                description
                  "malformed-packet-attack";
                leaf ping-of-death-attack {
                  type boolean;
                  description
                    "ping-of-death-attack";
            base ipv6-capa;
          }
                leaf teardrop-attack {
                  type boolean;
          description
                    "teardrop-attack";
                }
            "Capabilities for an IPv6 packet";
          reference
            "RFC 2460: Internet Protocol, Version 6 (IPv6)
             Specification - Next Header";
        }
              case special-packet-attack {
                description
                  "special-packet-attack";
                leaf oversized-icmp-attack

        leaf-list tcp-capa {
          type boolean;
                  description
                    "oversized-icmp-attack";
                }
                leaf tracert-attack identityref {
                  type boolean;
                  description
                    "tracert-attack";
                }
              }
            }
            base tcp-capa;
          }
        }
      }
    }

    list nsf {
      key "nsf-name";
      description
        "nsf-name";
      leaf nsf-name {
        type string;
        mandatory true;
          description
          "nsf-name";
            "Capabilities for a tcp packet";
          reference
            "RFC 793: Transmission Control Protocol";
        }

      uses capabilities-information;

      container generic-nsf-capabilities

        leaf-list udp-capa {
        description
          "generic-nsf-capabilities";
        uses i2nsf-net-sec-caps;
      }
      container advanced-nsf-capabilities
          type identityref {
        description
          "advanced-nsf-capabilities";
        uses i2nsf-advanced-sec-caps;
            base udp-capa;
          }

      container complete-nsf-capabilities {
          description
          "generic-nsf-capabilities";
        uses i2nsf-con-sec-control-caps;
        uses i2nsf-attack-mitigation-control-caps;
      }
            "Capabilities for an udp packet";
          reference
            "RFC 768: User Datagram Protocol";
        }

    rpc call-appropriate-nsf

        leaf-list icmp-capa {
      description
        "We can acquire appropriate NSF that we want
        If we give
          type of NSF that we want to use,
        we acquire the location information of NSF";

      input identityref {
          leaf nsf-type {
              type nsf-type;
              mandatory true;
            base icmp-capa;
          }
          description
                "This is used to acquire NSF
                This is mandatory";
            "Capabilities for an ICMP packet";
          reference
            "RFC 2460: Internet Protocol, Version 6 (IPv6) ";
        }
          uses i2nsf-it-resources;
      }
      output

      container advanced-nsf-capabilities {
          uses i2nsf-nsf-location;
      }
   }
  }

  <CODE ENDS>

              Figure 12: YANG Data Module
        description
          "Capabilities of I2NSF Capability

8.  IANA Considerations

   No IANA considerations exist for this document at this time.  URL
   will be added.

9.  Security Considerations

   This document introduces no additional security threats and SHOULD
   follow the advanced network security requirements functions,
           such as stated in [RFC8329].

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC7950]  Bjorklund, M., "The YANG 1.1 Data Modeling Language",
              RFC 7950, August 2016.

   [RFC8192]  Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
              and J. Jeong, "Interface to Network Security Functions
              (I2NSF): Problem Statement and Use Cases", RFC 8192, July
              2017.

   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework anti virus, anti DDoS, IPS, and VoIP/VoLTE.";
        reference
          "RFC 8329: Framework for Interface to Network Security
              Functions", RFC 8329, February 2018.

   [RFC8431]  Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
              S., and N. Bahadur, "A YANG
           Functions - Differences from ACL Data Model for Routing
              Information Base (RIB)", RFC RFC8431, September 2018.

10.2.  Informative References

   [i2nsf-advanced-nsf-dm]
              Pan, W. and L. Xia, "Configuration Models
           draft-dong-i2nsf-asf-config-01: Configuration of
           Advanced Security Functions with I2NSF Security Controller", draft-dong-
              i2nsf-asf-config-01 (work in progress), October 2018.

   [i2nsf-nsf-cap-im]
              Xia, L., Strassner, J., Basile, C., and D. Lopez,
              "Information Model
           Controller";

        leaf-list antivirus-capa {
          type identityref {
            base antivirus-capa;
          }
          description
            "Capabilities for an antivirus";
          reference
            "draft-dong-i2nsf-asf-config-01: Configuration of NSFs Capabilities", draft-ietf-
              i2nsf-capability-04 (work in progress), October 2018.

   [i2nsf-nsf-yang]
              Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
              "I2NSF Network
             Advanced Security Function-Facing Interface YANG
              Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-01
              (work in progress), July 2018.

   [i2nsf-sfc]
              Hyun, S., Jeong, J., Park, J., and S. Hares, "Service
              Function Chaining-Enabled Functions with I2NSF Architecture", draft-hyun-
              i2nsf-nsf-triggered-steering-06 (work in progress), July
              2018.

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

   [Policy-Reconciliation]
              Basile, C., Lioy, A., Pitscheider, C., and S. Zhao, "A
              Formal Model
             Controller";
        }

        leaf-list antiddos-capa {
          type identityref {
            base antiddos-capa;
          }
          description
            "Capabilities for an antiddos";
          reference
            "draft-dong-i2nsf-asf-config-01: Configuration of Policy Reconciliation",
              Euromicro Euromicro International Conference on Parallel,
              Distributed and Network-Based Processing (PDP), March
              2015.

   [supa-policy-info-model]
              Strassner, J., Halpern, J., and S. Meer, "Generic Policy
              Information Model
             Advanced Security Functions with I2NSF Security
             Controller";
        }

        leaf-list ips-capa {
          type identityref {
            base ips-capa;
          }
          description
            "Capabilities for Simplified Use an ips";
          reference
            "draft-dong-i2nsf-asf-config-01: Configuration of Policy
              Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
              model-03 (work in progress), May 2017.

Appendix A.  Example: Extended VoIP-VoLTE
             Advanced Security Function Capabilities
             Module

   This section gives Functions with I2NSF Security
             Controller";
        }

        leaf-list http-capa {
          type identityref {
            base http-capa;
          }
          description
            "Capabilities for a simple example http";
          reference
            "draft-dong-i2nsf-asf-config-01: Configuration of how VoIP-VoLTE
             Advanced Security
   Function Capabilities module could be extended.

     module
     ex-voip-volte-capa Functions with I2NSF Security
             Controller";
        }

        leaf-list voip-volte-capa {
       namespace "http://example.com/voip-volte-capa";
       prefix "voip-volte-capa";

       import ietf-i2nsf-capability
          type identityref {
         prefix capa;
            base voip-volte-capa;
         }
          description
            "Capabilities for a voip and volte";
          reference
            "draft-dong-i2nsf-asf-config-01: Configuration of
             Advanced Security Functions with I2NSF Security
             Controller";
        }

       augment "/capa:nsf/capa:generic-nsf-capabilities/"
               + "capa:net-sec-control-capabilities/"
               + "capa:condition/capa:condition-type" {
         case voice-condition {
           leaf sip-header-method
      }
    }
    container action-capabilities {
             type boolean;
      description
               "SIP header method.";
           }

           leaf sip-header-uri
        "Capabilities of actions.
         If network security function has
         the action capabilities, the network security function
         supports rule execution according to actions.";

      leaf-list ingress-action-capa {
        type boolean; identityref {
          base ingress-action-capa;
        }
        description
               "SIP header URI.";
          "Capabilities for an action";
      }

           leaf sip-header-from

      leaf-list egress-action-capa {
        type boolean; identityref {
          base egress-action-capa;
        }
        description
               "SIP header From.";
          "Capabilities for an egress action";
      }

           leaf sip-header-to

      leaf-list log-action-capa {
        type boolean; identityref {
          base log-action-capa;
        }
        description
               "SIP header To.";
          "Capabilities for a log action";
      }

           leaf sip-header-expire-time
    }

    leaf-list resolution-strategy-capabilities {
      type boolean; identityref {
        base resolution-strategy-capa;
      }
      description
               "SIP header expire time.";
        "Capabilities for a resolution strategy.
        The resolution strategies can be used to
        specify how to resolve conflicts that occur between
        the actions of the same or different policy rules that
        are matched and contained in this particular NSF";
      reference
        "draft-ietf-i2nsf-capability-04: Information Model
         of NSFs Capabilities - Resolution strategy";
    }

           leaf sip-header-user-agent

    leaf-list default-action-capabilities {
      type boolean; identityref {
        base default-action-capa;
      }
      description
               "SIP header user agent.";
        "Capabilities for a default action.
         A default action is used to execute I2NSF policy rule
         when no rule matches a packet. The default action is
         defined as pass, drop, reject, alert, and mirror.";
      reference
        "draft-ietf-i2nsf-capability-04: Information Model
         of NSFs Capabilities - Default action";
    }
  }

  /*
   * Data nodes
   */

  container nsf {
    description
      "The list of capabilities of
       network security function";
    uses nsf-capabilities;
  }
}

<CODE ENDS>

              Figure 13: Example: Extended VoIP-VoLTE Security Function
                            Capabilities 3: YANG Data Module

Appendix B.  Example: Configuration XML of I2NSF Capability Module

7.  IANA Considerations

   This section gives a xml examples for a configuration of Capability
   module according document requests IANA to a requirement.

B.1.  Example: Configuration register the following URI in the
   "IETF XML of Generic Network Security Function
      Capabilities Registry" [RFC3688]:

      URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability

      Registrant Contact: The IESG.

      XML: N/A; the requested URI is an XML namespace.

   This section gives a xml example for generic network security
   function capability configuration according document requests IANA to register the following YANG module in
   the "YANG Module Names" registry [RFC7950].

      name: ietf-i2nsf-capability

      namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability

      prefix: iicapa

      reference: RFC XXXX

8.  Security Considerations

   The YANG module specified in this document defines a requirement.

   Requirement: Register packet filter according data schema
   designed to requirements.

   1.  The location of the NSF is 221.159.112.150.

   2. be accessed through network management protocols such as
   NETCONF [RFC6241] or RESTCONF [RFC8040].  The NSF can obtain lowest NETCONF layer is
   the best effect if secure transport layer, and the packet was generated by
       PC or IoT.

   3. required transport secure
   transport is Secure Shell (SSH) [RFC6242].  The NSF can apply policies according to time.

   4. lowest RESTCONF layer
   is HTTPS, and the required transport secure transport is TLS
   [RFC8446].

   The NSF should be able NETCONF access control model [RFC8341] provides a means of
   restricting access to block the source packets specific NETCONF or destination
       packets with IPv4 address.

   5.  The NSF should be able RESTCONF users to pass, reject, a
   preconfigured subset of all available NETCONF or alert packets.

   6.  Here is XML example RESTCONF protocol
   operations and content.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the generic network security function
       capability configuration:

  <?xml version="1.0" encoding="UTF-8"?>
  <rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
   <target>
    <running />
   </target>
   <config>
    <nsf xmlns="urn:ietf:params:xml:ns:yang:" +
                        "ietf-i2nsf-capability">
      <nsf-name>Huawei-Firewall</nsf-name>
      <nsf-address>
       <ipv4-address>221.159.112.150</ipv4-address>
      </nsf-address>
      <target-device>
       <pc>true</pc>
      </target-device>
      <target-device>
       <iot>true</iot>
      </target-device>
      <generic-nsf-capabilities>
       <net-sec-control-capabilities>
        <nsc-capabilities-name>ipv4-packet-filter<nsc-capabilities-name>
        <time-zone>
         <start-time>true</start-time>
         <end-time>true</end-time>
        </time-zone>
        <condition>
          <packet-security-ipv4-condition>
           <pkt-sec-cond-ipv4-src>true</pkt-sec-cond-ipv4-src>
           <pkt-sec-cond-ipv4-dest>true</pkt-sec-cond-ipv4-dest>
          </packet-security-ipv4-condition>
        </condition>
        <action>
         <ingress-action-type>
          <pass>true</pass>
          <reject>true</reject>
          <alert>true</alert>
         </ingress-action-type>
        </action>
      </net-sec-control-capabilities>
     </generic-nsf-capabilities>
    </nsf>
   </config>
  </edit-config>
  </rpc>

    Figure 14: Example:
              Network Configuration XML Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6087]  Bierman, A., "Guidelines for Authors and Reviewers of YANG
              Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
              January 2011, <https://www.rfc-editor.org/info/rfc6087>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC7950]  Bjorklund, M., "The YANG 1.1 Data Modeling Language",
              RFC 7950, August 2016.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8192]  Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
              and J. Jeong, "Interface to Network Security Functions
              (I2NSF): Problem Statement and Use Cases", RFC 8192, July
              2017.

   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework for Generic Interface to Network Security
                            Function Capability

B.2.  Example:
              Functions", RFC 8329, February 2018.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration XML
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8431]  Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
              S., and N. Bahadur, "A YANG Data Model for Routing
              Information Base (RIB)", RFC RFC8431, September 2018.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

9.2.  Informative References

   [i2nsf-advanced-nsf-dm]
              Pan, W. and L. Xia, "Configuration of Extended VoIP/VoLTE Advanced Security
      Function Capabilities Module

   This section gives a xml example for extended VoIP-VoLTE security
   function capabilities (See Figure 13) configuration according to a
   requirement.

   Requirement: Register VoIP/VoLTe security function according to
   requirements.

   1.  The location of the NSF is 221.159.112.151.

   2.  The NSF can obtain the best effect if the packet was generated by
       VoIP-VoLTE phone.

   3.  The NSF should be able to block the malicious sip packets
              Functions with
       user agent.

   4.  The NSF should be able I2NSF Security Controller", draft-dong-
              i2nsf-asf-config-01 (work in progress), October 2018.

   [i2nsf-nsf-cap-im]
              Xia, L., Strassner, J., Basile, C., and D. Lopez,
              "Information Model of NSFs Capabilities", draft-ietf-
              i2nsf-capability-04 (work in progress), October 2018.

   [i2nsf-nsf-yang]
              Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
              "I2NSF Network Security Function-Facing Interface YANG
              Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-01
              (work in progress), July 2018.

   [i2nsf-terminology]
              Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
              Birkholz, "Interface to pass, reject, or alert packets.

   Here is XML example for the VoIP-VoLTE security function capabilities
   configuration:

    <?xml version="1.0" encoding="UTF-8"?>
    <rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
     <target>
      <running />
     </target>
     <config>
      <nsf xmlns="urn:ietf:params:xml:ns:yang:" +
                 "ietf-i2nsf-capability">
      <nsf-name>Cisco-VoIP-VoLTE</nsf-name>
      <nsf-address>
        <ipv4-address>221.159.112.151</ipv4-address>
      </nsf-address>
      <generic-nsf-capabilities>
       <net-sec-control-capabilities>
        <nsc-capabilities-name>sip-packet-filter<nsc-capabilities-name>
         <condition>
           <sip-header-user-agent>true</sip-header-user-agent>
         </condition>
         <action>
          <ingress-action-type>
            <pass>true</pass>
            <reject>true</reject>
            <alert>true</alert>
          </ingress-action-type>
         </action>
       </net-sec-control-capabilities>
      </generic-nsf-capabilities>
      </nsf>
     </config>
    </edit-config>
    </rpc>

       Figure 15: Example: Configuration XML for Extended VoIP/VoLTE Network Security Function Capabilities Functions (I2NSF)
              Terminology", draft-ietf-i2nsf-terminology-07 (work in
              progress), January 2019.

   [supa-policy-info-model]
              Strassner, J., Halpern, J., and S. Meer, "Generic Policy
              Information Model for Simplified Use of Policy
              Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
              model-03 (work in progress), May 2017.

Appendix C. A.  Changes from draft-ietf-i2nsf-capability-data-model-01 draft-ietf-i2nsf-capability-data-model-02

   The following changes are made from draft-ietf-i2nsf-capability-data-
   model-01:
   model-03:

   o  We revised this YANG data module according to guidelines for
      authors and reviewers of YANG data model documents [RFC6087].

   o  We changed the structure of the overall YANG data module.

   o  We changed enumeration type to identity type for scalable
      components.

   o  We added capabilities a description for the YANG tree diagram of advanced network security functions such
      as anti-virus, anti-ddos, and IPS. the YANG data
      module.

   o  We revised overall sentences of this YANG data model document.

   o  We added configuration examples to make it easier for reviewers to
      understand.

Appendix D. B.  Acknowledgments

   This work was supported by Institute for Information & communications
   Technology Promotion (IITP) grant funded by the Korea government
   (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence
   Technology Development for the Customized Security Service
   Provisioning).

Appendix E. C.  Contributors

   This document is made by the group effort of I2NSF working group.
   Many people actively contributed to this document.  The following are
   considered co-authors:

   o  Hyoungshick Kim (Sungkyunkwan University)

   o  Daeyoung Hyun (Sungkyunkwan University)

   o  Dongjin Hong (Sungkyunkwan University)

   o  Liang Xia (Huawei)

   o  Jung-Soo Park (ETRI)

   o  Tae-Jin Ahn (Korea Telecom)

   o  Se-Hui Lee (Korea Telecom)

Authors' Addresses

   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Phone: +1-734-604-0332
   EMail: shares@ndzh.com

   Jaehoon Paul Jeong
   Department of Software
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4957
   Fax:   +82 31 290 7996
   EMail: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php

   Jinyong Tim Kim
   Department of Computer Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 10 8273 0930
   EMail: timkim@skku.edu

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI
   USA

   Phone: +1-248-968-9809
   EMail: rgm@htt-consult.com
   Qiushi Lin
   Huawei
   Huawei Industrial Base
   Shenzhen, Guangdong 518129
   China

   EMail: linqiushi@huawei.com