Skip to main content

An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents
RFC 4827

Document Type RFC - Proposed Standard (May 2007) Errata
Authors Markus Isomaki , Eva Leppanen
Last updated 2020-01-21
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Ted Hardie
Send notices to (None)
RFC 4827
I2NSF Working Group                                        S. Hares, Ed.
Internet-Draft                                                    Huawei
Intended status: Standards Track                           J. Jeong, Ed.
Expires: March 12, 2021                                           J. Kim
                                                 Sungkyunkwan University
                                                            R. Moskowitz
                                                          HTT Consulting
                                                                  Q. Lin
                                                                  Huawei
                                                       September 8, 2020

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

Abstract

   This document defines a YANG data model for the capabilities of
   various Network Security Functions (NSFs) in the Interface to Network
   Security Functions (I2NSF) framework to centrally manage the
   capabilities of the various 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 March 12, 2021.

Copyright Notice

   Copyright (c) 2020 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

Hares, et al.            Expires March 12, 2021                 [Page 1]
Internet-Draft      I2NSF Capability YANG Data Model      September 2020

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Network Security Function (NSF) Capabilities  . . . . . .   6
   5.  YANG Data Model of I2NSF NSF Capability . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  41
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  41
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  42
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  42
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  45
   Appendix A.  Configuration Examples . . . . . . . . . . . . . . .  47
     A.1.  Example 1: Registration for the Capabilities of a General
           Firewall  . . . . . . . . . . . . . . . . . . . . . . . .  47
     A.2.  Example 2: Registration for the Capabilities of a Time-
           based Firewall  . . . . . . . . . . . . . . . . . . . . .  49
     A.3.  Example 3: Registration for the Capabilities of a Web
           Filter  . . . . . . . . . . . . . . . . . . . . . . . . .  50
     A.4.  Example 4: Registration for the Capabilities of a
           VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . .  51
     A.5.  Example 5: Registration for the Capabilities of a HTTP
           and HTTPS Flood Mitigator . . . . . . . . . . . . . . . .  52
   Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  53
   Appendix C.  Contributors . . . . . . . . . . . . . . . . . . . .  54
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  55

1.  Introduction

   As the industry becomes more sophisticated and network devices (e.g.,
   Internet of Things, Self-driving vehicles, and smartphone using Voice
   over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a
   lot of problems described in [RFC8192].  To resolve these problems,
   [I-D.ietf-i2nsf-capability] specifies the information model of the
   capabilities of Network Security Functions (NSFs) in a framework of
   the Interface to Network Security Functions (I2NSF) [RFC8329].

   This document provides a YANG data model [RFC6020][RFC7950] that
   defines the capabilities of NSFs to centrally manage the capabilities
   of those security devices.  The security devices can register their
   own capabilities into a Network Operator Management (Mgmt) System

Hares, et al.            Expires March 12, 2021                 [Page 2]
Internet-Draft      I2NSF Capability YANG Data Model      September 2020

   (i.e., Security Controller) with this YANG data model through the
   registration interface [RFC8329].  With the capabilities of those
   security devices maintained centrally, those security devices can be
   more easily managed [RFC8329].  This YANG data model is based on the
   information model for I2NSF NSF capabilities
   [I-D.ietf-i2nsf-capability].

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

   o  Definition for general capabilities of network security functions.

   o  Definition for event capabilities of generic network security
      functions.

   o  Definition for condition capabilities of generic network security
      functions.

   o  Definition for condition capabilities of advanced network security
      functions.

   o  Definition for action capabilities of generic network security
      functions.

   o  Definition for resolution strategy capabilities of generic network
      security functions.

   o  Definition for default action capabilities of generic network
      security functions.

2.  Terminology

   This document uses the terminology described in [RFC8329].

   This document follows the guidelines of [RFC8407], uses the common
   YANG types defined in [RFC6991], and adopts the Network Management
   Datastore Architecture (NMDA).  The meaning of the symbols in tree
   diagrams is defined in [RFC8340].

3.  Overview

   This section provides as overview of how the YANG data model can be
   used in the I2NSF framework described in [RFC8329].  Figure 1 shows
   the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF
   Framework.  As shown in this figure, an NSF Developer's Management

gt; SIP NOTIFY
               |               |         |   (PA)     |
               +-------+-------+         +------------+
                 ^     ^     ^
                 |     |     |
                 |     |     |       +---------------+
        +--------+     |     +-------|  XCAP server  |
        |              |             +-------+-------+
        |              |                 ^         ^
        | SIP Publish  |                 |  XCAP   |
        |              |                 |         |
     +--+--+        +--+--+         +-------+   +-------+
     | PUA |        | PUA |         | XCAP  |   | XCAP  |
     |     |        |     |         | client|   | client|
     +-----+        +-----+         +-------+   +-------+

        Figure 1: Framework for Presence Publishing and Event State
                                Composition

   The protocol interface between XCAP server and the event state
   compositor is not specified here.

Isomaki & Leppanen          Standards Track                     [Page 5]
RFC 4827        XCAP for Manipulating Presence Document         May 2007

4.  Application Usage ID

   XCAP requires application usages to define a unique application usage
   ID (AUID) in either the IETF tree or a vendor tree.  This
   specification defines the 'pidf-manipulation' AUID within the IETF
   tree, via the IANA registration in Section 13.

5.  MIME Type

   The MIME type for this application usage is 'application/pidf+xml'.

6.  Structure of Manipulated Presence Information

   The XML Schema of the presence information is defined in the Presence
   Information Data Format (PIDF) [3].  The PIDF also defines a
   mechanism for extending presence information.  See [8], [9], [11],
   and [12] for currently defined PIDF extensions and their XML Schemas.

   The namespace URI for PIDF is 'urn:ietf:params:xml:ns:pidf' which is
   also the XCAP default document namespace.

7.  Additional Constraints

   There are no constraints on the document beyond those described in
   the XML schemas (PIDF and its extensions) and in the description of
   PIDF [3].

8.  Resource Interdependencies

   There are no resource interdependencies beyond the possible
   interdependencies defined in PIDF [3] and XCAP [2] that need to be
   defined for this application usage.

9.  Naming Conventions

   The XCAP server MUST store only a single XCAP manipulated presence
   document for each user.  The presence document MUST be located under
   the "users" tree, using filename "index".  See an example in
   Section 11.

10.  Authorization Policies

   This application usage does not modify the default XCAP authorization
   policy, which allows only a user (owner) to read, write, or modify
   their own documents.  A server can allow privileged users to modify
   documents that they do not own, but the establishment and indication
   of such policies is outside the scope of this document.

Isomaki & Leppanen          Standards Track                     [Page 6]
RFC 4827        XCAP for Manipulating Presence Document         May 2007

11.  Example

   The section provides an example of a presence document provided by an
   XCAP Client to an XCAP Server.  The presence document illustrates the
   situation where a (human) presentity has left for vacation, and
   before that, has set his presence information so that he is only
   available via e-mail.  In the absence of any published soft state
   information, this would be the sole input to the compositor forming
   the presence document.  The example document contains PIDF extensions
   specified in "RPID: Rich Presence Extensions to the Presence
   Information Data Format (PIDF)" [8] and "CIPID: Contact Information
   in Presence Information Data Format" [9].

   It is assumed that the presentity is a SIP user with Address-of-
   Record (AOR) sip:someone@example.com.  The XCAP root URI for
   example.com is assumed to be http://xcap.example.com.  The XCAP User
   Identifier (XUI) is assumed to be identical to the SIP AOR, according
   to XCAP recommendations.  In this case, the presence document would
   be located at http://xcap.example.com/pidf-manipulation/users/
   sip:someone@example.com/index.

   The presence document is created with the following XCAP operation:

  PUT /pidf-manipulation/users/sip:someone@example.com/index HTTP/1.1
  Host: xcap.example.com
  Content-Type: application/pidf+xml
  ...

  <?xml version="1.0" encoding="UTF-8"?>
        <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
             xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
             xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
             entity="sip:someone@example.com">

          <tuple id="x8eg92m">
            <status>
              <basic>closed</basic>
            </status>
            <rp:user-input>idle</rp:user-input>
            <rp:class>auth-1</rp:class>
            <contact priority="0.5">sip:user@example.com</contact>
            <note>I'm available only by e-mail.</note>
            <timestamp>2004-02-06T16:49:29Z</timestamp>
          </tuple>

          <tuple id="x8eg92n">
            <status>

Isomaki & Leppanen          Standards Track                     [Page 7]
RFC 4827        XCAP for Manipulating Presence Document         May 2007

              <basic>open</basic>
            </status>
            <rp:class>auth-1</rp:class>
            <contact priority="1.0">mailto:someone@example.com</contact>
            <note>I'm reading mail a couple of times a week</note>
          </tuple>

          <dm:person id="p1">
             <rp:class>auth-A</rp:class>
             <ci:homepage>http://www.example.com/~someone</ci:homepage>
             <rp:activities>
                 <rp:vacation/>
             </rp:activities>
          </dm:person>

        </presence>

  When the user wants to change the note related to e-mail service,
  it is done with the following XCAP operation:

  PUT /pidf-manipulation/users/sip:someone@example.com/index/
  ~~/presence/tuple%5b@id='x8eg92n'%5d/note HTTP/1.1
  If-Match: "xyz"
  Host: xcap.example.com
  Content-Type: application/xcap-el+xml
  ...

  <note>I'm reading mails on Tuesdays and Fridays</note>

12.  Security Considerations

   A presence document may contain information that is highly sensitive.
   Its delivery to watchers needs to happen strictly according to the
   relevant authorization policies.  It is also important that only
   authorized clients are able to manipulate the presence information.

   The XCAP base specification mandates that all XCAP servers MUST
   implement HTTP Digest authentication specified in RFC 2617 [5].
   Furthermore, XCAP servers MUST implement HTTP over TLS [6].  It is
   recommended that administrators of XCAP servers use an HTTPS URI as
   the XCAP root services' URI, so that the digest client authentication
   occurs over TLS.  By using these means, XCAP client and server can
   ensure the confidentiality and integrity of the XCAP presence
   document manipulation operations, and that only authorized clients
   are allowed to perform them.

Isomaki & Leppanen          Standards Track                     [Page 8]
RFC 4827        XCAP for Manipulating Presence Document         May 2007

13.  IANA Considerations

   There is an IANA consideration associated with this specification.

13.1.  XCAP Application Usage ID

   This section registers a new XCAP Application Usage ID (AUID)
   according to the IANA procedures defined in [2].

   Name of the AUID: pidf-manipulation

   Description: Pidf-manipulation application usage defines how XCAP is
   used to manipulate the contents of PIDF-based presence documents.

14.  Acknowledgements

   The authors would like to thank Jari Urpalainen, Jonathan Rosenberg,
   Hisham Khartabil, Aki Niemi, Mikko Lonnfors, Oliver Biot, Alex Audu,
   Krisztian Kiss, Jose Costa-Requena, George Foti, and Paul Kyzivat for
   their comments.

15.  References

15.1.  Normative References

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

   [2]   Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

   [3]   Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
         J. Peterson, "Presence Information Data Format (PIDF)",
         RFC 3863, August 2004.

   [4]   Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.

   [5]   Franks, J., "HTTP Authentication: Basic and Digest Access
         Authentication", RFC 2617, June 1999.

   [6]   Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

15.2.  Informative References

   [7]   Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", RFC 3856, August 2004.

Isomaki & Leppanen          Standards Track                     [Page 9]
RFC 4827        XCAP for Manipulating Presence Document         May 2007

   [8]   Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
         "RPID: Rich Presence Extensions to the Presence Information
         Data Format (PIDF)", RFC 4480, July 2006.

   [9]   Schulzrinne, H., "CIPID: Contact Information for the Presence
         Information Data Format", RFC 4482, July 2006.

   [10]  Rosenberg, J., "A Data Model for Presence", RFC 4479,
         July 2006.

   [11]  Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP)
         User Agent Capability Extension to Presence Information Data
         Format (PIDF)", Work in Progress, July 2006.

   [12]  Schulzrinne, H., "Timed Presence Extensions to the Presence
         Information Data Format (PIDF) to Indicate Status Information
         for Past and Future Time Intervals", RFC 4481, July 2006.

Authors' Addresses

   Markus Isomaki
   Nokia
   P.O. BOX 100
   00045 NOKIA GROUP
   Finland

   EMail: markus.isomaki@nokia.com

   Eva Leppanen
   Nokia
   P.O. BOX 785
   33101 Tampere
   Finland

   EMail: eva-maria.leppanen@nokia.com

Isomaki & Leppanen          Standards Track                    [Page 10]Hares, et al.            Expires March 12, 2021                 [Page 3]
Internet-Draft      I2NSF Capability YANG Data Model      September 2020

   System can register NSFs and the capabilities that the network
   security device can support.  To register NSFs in this way, the
   Developer's Management System utilizes this standardized capability
   YANG data model through the I2NSF Registration Interface [RFC8329].
   That is, this Registration Interface uses the YANG module described
   in this document to describe the capability of a network security
   function that is registered with the Security Controller.  With the
   capabilities of those network security devices maintained centrally,
   those security devices can be more easily managed, which can resolve
   many of the problems described in [RFC8192].

   In Figure 1, a new NSF at a Developer's Management Systems has
   capabilities of Firewall (FW) and Web Filter (WF), which are denoted
   as (Cap = {FW, WF}), to support Event-Condition-Action (ECA) policy
   rules where 'E', 'C', and 'A' mean "Event", "Condition", and
   "Action", respectively.  The condition involves IPv4 or IPv6
   datagrams, and the action includes "Allow" and "Deny" for those
   datagrams.

   Note that the NSF-Facing Interface [RFC8329] is used to configure the
   security policy rules of the generic network security functions, and
   The configuration of advanced security functions over the NSF-Facing
   Interface is used to configure the security policy rules of advanced
   network security functions (e.g., anti-virus and Distributed-Denial-
   of-Service (DDoS) attack mitigator), respectively, according to the
   capabilities of NSFs registered with the I2NSF Framework.

Hares, et al.            Expires March 12, 2021                 [Page 4]
Internet-Draft      I2NSF Capability YANG Data Model      September 2020

       +------------------------------------------------------+
       |  I2NSF User (e.g., Overlay Network Mgmt, Enterprise  |
       |  Network Mgmt, another network domain's mgmt, etc.)  |
       +--------------------+---------------------------------+
           I2NSF            ^
  Consumer-Facing Interface |
                            |
                            v                  I2NSF
          +-----------------+------------+  Registration  +-------------+
          | Network Operator Mgmt System |   Interface    | Developer's |
          | (i.e., Security Controller)  |<-------------->| Mgmt System |
          +-----------------+------------+                +-------------+
                            ^                                 New NSF
                            |                           Cap = {FW, WF}
              I2NSF         |                           E = {}
       NSF-Facing Interface |                           C = {IPv4, IPv6}
                            |                           A = {Allow, Deny}
                            v
       +---------------+----+------------+-----------------+
       |               |                 |                 |
   +---+---+       +---+---+         +---+---+         +---+---+
   | NSF-1 |  ...  | NSF-m |         | NSF-1 |   ...   | NSF-n |  ...
   +-------+       +-------+         +-------+         +-------+
     NSF-1           NSF-m             NSF-1             NSF-n
 Cap = {FW, WF}    Cap = {FW, WF}    Cap = {FW, WF}    Cap = {FW, WF}
 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's Mgmt System A          Developer's Mgmt System B

             Figure 1: Capabilities of NSFs in I2NSF Framework

   A use case of an NSF with the capabilities of firewall and web filter
   is described as follows.

   o  If a network manager wants to apply security policy rules to block
      malicious users with firewall and web filter, it is a tremendous
      burden for a network administrator to apply all of the needed
      rules to NSFs one by one.  This problem can be resolved by
      managing the capabilities of NSFs in this document.

   o  If a network administrator wants to block malicious users for IPv6
      traffic, he sends a security policy rule to block the users to the
      Network Operator Management System using the I2NSF User (i.e., web
      application).

Hares, et al.            Expires March 12, 2021                 [Page 5]
Internet-Draft      I2NSF Capability YANG Data Model      September 2020

   o  When the Network Operator Management System receives the security
      policy rule, it automatically sends that security policy rules to
      appropriate NSFs (i.e., NSF-m in Developer's Management System A
      and NSF-1 in Developer's Management System B) which can support
      the capabilities (i.e., IPv6).  This lets an I2NSF User not
      consider NSFs where the rule is applied.

   o  If NSFs encounter the suspicious IPv6 packets of malicious users,
      they can filter the packets out according to the configured
      security policy rule.  Therefore, the security policy rule against
      the malicious users' packets can be automatically applied to
      appropriate NSFs without human intervention.

4.  YANG Tree Diagram

   This section shows a YANG tree diagram of capabilities of network
   security functions, as defined in the [I-D.ietf-i2nsf-capability].

4.1.  Network Security Function (NSF) Capabilities

   This section explains a YANG tree diagram of NSF capabilities and its
   features.  Figure 2 shows a YANG tree diagram of NSF capabilities.
   The NSF capabilities in the tree include time capabilities, event
   capabilities, condition capabilities, action capabilities, resolution
   strategy capabilities, and default action capabilities.  Those
   capabilities can be tailored or extended according to a vendor's
   specific requirements.  Refer to the NSF capabilities information
   model for detailed discussion [I-D.ietf-i2nsf-capability].

Hares, et al.            Expires March 12, 2021                 [Page 6]
Internet-Draft      I2NSF Capability YANG Data Model      September 2020

   module: ietf-i2nsf-capability
     +--rw nsf* [nsf-name]
        +--rw nsf-name            string
        +--rw time-capabilities*                  enumeration
        +--rw event-capabilities
        |  +--rw system-event-capability*   identityref
        |  +--rw system-alarm-capability*   identityref
        +--rw condition-capabilities
        |  +--rw generic-nsf-capabilities
        |  |  +--rw ipv4-capability*   identityref
        |  |  +--rw icmp-capability*   identityref
        |  |  +--rw ipv6-capability*   identityref
        |  |  +--rw icmpv6-capability*   identityref
        |  |  +--rw tcp-capability*    identityref
        |  |  +--rw udp-capability*    identityref
        |  +--rw advanced-nsf-capabilities
        |  |  +--rw anti-virus-capability*    identityref
        |  |  +--rw anti-ddos-capability*     identityref
        |  |  +--rw ips-capability*          identityref
        |  |  +--rw url-capability*          identityref
        |  |  +--rw voip-volte-capability*   identityref
        |  +--rw context-capabilities*        identityref
        +--rw action-capabilities
        |  +--rw ingress-action-capability*   identityref
        |  +--rw egress-action-capability*    identityref
        |  +--rw log-action-capability*       identityref
        +--rw resolution-strategy-capabilities*   identityref
        +--rw default-action-capabilities*        identityref
        +--rw ipsec-method*                       identityref

      Figure 2: YANG Tree Diagram of Capabilities of Network Security
                                 Functions

   Time capabilities are used to specify the capabilities which describe
   when to execute the I2NSF policy rule.  The time capabilities are
   defined in terms of absolute time and periodic time.  The absolute
   time means the exact time to start or end.  The periodic time means
   repeated time like day, week, or month.  See Section 3.4.6
   (Capability Algebra) in [I-D.ietf-i2nsf-capability] for more
   information about the time-based condition (e.g., time period) in the
   capability algebra.

   Event capabilities are used to specify the capabilities that describe
   the event that would trigger the evaluation of the condition clause
   of the I2NSF Policy Rule.  The defined event capabilities are system
   event and system alarm.  See Section 3.1 (Design Principles and ECA

Hares, et al.            Expires March 12, 2021                 [Page 7]
Internet-Draft      I2NSF Capability YANG Data Model      September 2020

   Policy Model Overview) in [I-D.ietf-i2nsf-capability] for more
   information about the event in the ECA policy model.

   Condition capabilities are used to specify capabilities 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 in that (imperative)
   I2NSF policy rule can be executed.  The condition capabilities are
   classified in terms of generic network security functions and
   advanced network security functions.  The condition capabilities of
   generic network security functions are defined as IPv4 capability,
   IPv6 capability, TCP capability, UDP capability, and ICMP capability.
   The condition capabilities of advanced network security functions are
   defined as anti-virus capability, anti-DDoS capability, Intrusion
   Prevention System (IPS) capability, HTTP capability, and VoIP/VoLTE
   capability.  See Section 3.1 (Design Principles and ECA Policy Model
   Overview) in [I-D.ietf-i2nsf-capability] for more information about
   the condition in the ECA policy model.  Also, see Section 3.4.3
   (I2NSF Condition Clause Operator Types) in
   [I-D.ietf-i2nsf-capability] for more information about the operator
   types in an I2NSF condition clause.

   Action capabilities are used to specify the capabilities that
   describe the control and monitoring aspects of flow-based NSFs when
   the event and condition clauses are satisfied.  The action
   capabilities are defined as ingress-action capability, egress-action
   capability, and log-action capability.  See Section 3.1 (Design
   Principles and ECA Policy Model Overview) in
   [I-D.ietf-i2nsf-capability] for more information about the action in
   the ECA policy model.  Also, see Section 7.2 (NSF-Facing Flow
   Security Policy Structure) in [RFC8329] for more information about
   the ingress and egress actions.  In addition, see Section 9.1 (Flow-
   Based NSF Capability Characterization) for more information about
   logging at NSFs.

   Resolution strategy capabilities are used to specify the capabilities
   that describe conflicts that occur between the actions of the same or
   different policy rules that are matched and contained in this
   particular NSF.  The resolution strategy capabilities are defined as
   First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized
   Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE),
   and Prioritized Matching Rule with No Errors (PMRN).  See
   Section 3.4.2 (Conflict, Resolution Strategy and Default Action) in
   [I-D.ietf-i2nsf-capability] for more information about the resolution
   strategy.

   Default action capabilities are used to specify the capabilities that
   describe how to execute I2NSF policy rules when no rule matches a


RFC 4827        XCAP for Manipulating Presence Document         May 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Isomaki & Leppanen          Standards Track                    [Page 11]