<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc ipr="trust200902" docName="draft-zhang-i2nsf-info-model-monitoring-07" category="exp">

  <front>
    <title abbrev="IM for NSF Monitoring">An Information Model for the Monitoring of Network Security Functions (NSF)</title>

    <author initials="L." surname="Xia" fullname="Liang Xia">
      <organization>Huawei</organization>
      <address>
        <email>frank.xialiang@huawei.com</email>
      </address>
    </author>
    <author initials="D." surname="Zhang" fullname="Dacheng Zhang">
      <organization>Huawei</organization>
      <address>
        <email>dacheng.zhang@huawei.com</email>
      </address>
    </author>
    <author initials="Y." surname="Wu" fullname="Yi Wu">
      <organization>Aliababa Group</organization>
      <address>
        <email>anren.wy@alibaba-inc.com</email>
      </address>
    </author>
    <author initials="R." surname="Kumar" fullname="Rakesh Kumar">
      <organization>Juniper Networks</organization>
      <address>
        <email>rkkumar@juniper.net</email>
      </address>
    </author>
    <author initials="A." surname="Lohiya" fullname="Anil Lohiya">
      <organization>Juniper Networks</organization>
      <address>
        <email>alohiya@juniper.net</email>
      </address>
    </author>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization>Fraunhofer SIT</organization>
      <address>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>

    <date year="2018" month="October" day="24"/>

    
    
    

    <abstract>


<t>The Network Security Functions (NSF) NSF-facing interface exists
between the Service Provider’s management system (or Security
Controller) and the NSF to enforce security policy provisioning and
network security status monitoring. This document focuses on the
monitoring part and defines the corresponding information model for it.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>According to <xref target="I-D.ietf-i2nsf-terminology"/>, the interface
provided by an NSF (e.g., FW, IPS, Anti-DDOS, or Anti-Virus function) to
administrative entities (e.g., NMS, security controller) to enable remote
management (i.e. configuring and monitoring) is referred to as an
“I2NSF NSF-Facing Interface”. Monitoring procedures intent to
acquire vital types of data at rest with respect to NSF, e.g. alarms, records, or counters,
via data in motion, e.g. queries, notifications, or events. The
monitoring of NSF plays an important role in the overall
security framework, if done in a timely and comprehensive way. The
monitoring information generated by an NSF can very well be an early
indication of anomalous behavior or malicious activity, such as denial of service attacks.</t>

<t>This draft defines a comprehensive NSF monitoring information model
that provides visibility into NSF. This document will not go into the
design details of NSF-Facing Interfaces. Instead, it is focused
on specifying the information and illustrates the methods that enable NSF to provide
the information required in order to be monitored in a scalable and 
efficient way via the NSF-Facing Interface. The information
model for monitoring presented in this document is a complement to the
information model for the security policy provisioning part of the
NSF-Facing Interface specified in <xref target="I-D.xibassnez-i2nsf-capability"/>.</t>

</section>
<section anchor="terminology" title="Terminology">

<section anchor="key-words" title="Key Words">

<t>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 <xref target="RFC2119"></xref>.</t>

</section>
<section anchor="definition-of-terms" title="Definition of Terms">

<t>This document uses the terms defined in <xref target="I-D.ietf-i2nsf-terminology"/>.</t>

</section>
</section>
<section anchor="use-cases-for-nsf-monitoring-data" title="Use cases for NSF Monitoring Data">

<t>As mentioned earlier, monitoring plays a critical role in the
overall security framework. The monitoring of the NSF provides very
valuable information to the security controller in maintaining the
provisioned security posture. Besides this, there are various other
reasons to monitor the NSF as listed below:</t>

<t><list style="symbols">
  <t>The security administrator can configure a policy that is
triggered on a specific event occurring in the NSF or the network.
If a security controller detects the specified event, it
configures additional security functions as defined by policies.</t>
  <t>The events triggered by NSF as a result of security policy
violation can be used by SIEM to detect any suspicious
activity in a larger correlation context.</t>
  <t>The events and activity logs from NSF can be used to build
advanced analytics, such as behavior and predictive models to
improve security posture in large deplyoments.</t>
  <t>The security controller can use events from the NSF for
achieving high availability. It can take corrective actions such
as restarting a failed NSF, horizontally scaling the NSF, etc.</t>
  <t>The events and activity logs from the NSF can aid in the root
cause analysis of an operational issue - therefore improve debugging.</t>
  <t>The activity logs from the NSF can be used to build historical
data for operational and business reasons.</t>
</list></t>

</section>
<section anchor="classification-of-nsf-monitoring-data" title="Classification of NSF Monitoring Data">

<t>In order to maintain a strong security posture, it is not only
necessary to configure NSF security policies but also to continuously
monitor NSF by consuming acquirable and therefore observable information. This enables
security admins to assess the state of the network topology in a timely fashion. It is
not possible to block all the internal and external threats based on
static security posture. A more practical approach is supported by enabling dynamic security measures - for which
continuous visibility is required. This draft defines a set of information elements
(and their scope) that can be acquired from NSF and can be used as
monitoring information. In essence, these types of monitoring information can be
leveraged to support constant visibility on multiple levels of
granularity and can be consumed by corresponding functions.</t>

<t>Three basic domains about the monitoring of information originating from a
system entity <xref target="RFC4949"/> or a NSF are highlighted in this document.</t>

<t><list style="symbols">
  <t>Retention and Emission</t>
  <t>Notifications and Events</t>
  <t>Unsolicited Poll and Solicited Push</t>
</list></t>

<t>The Alarm Management Framework in <xref target="RFC3877"/> defines an Event as “something
that happens which may be of interest. A fault, a change in status, crossing a
threshold, or an external input to the system, for example.” In the I2NSF
domain, I2NSF events <xref target="I-D.ietf-i2nsf-terminology"/> are created and the scope of the
Alarm Management Framework Events is still applicable due to its broad
definition. The model presented in this document elaborates on the work-flow of
creating I2NSF events in the context of NSF monitoring and on how initial I2NSF
events are created.</t>

<t>As with I2NSF components, every generic system entity can include a set of
capabilities <xref target="I-D.ietf-i2nsf-terminology"/> that creates information about the context,
composition, configuration, state or behavior of that system entity. This
information is intended to be provided to other consumers of informations—and
in the scope of this document, to monitor that information in an automated
fashion.</t>

<section anchor="retention-and-emission" title="Retention and Emission">

<t>Typically, a system entity populates standardized interface, such as SNMP,
NETCONF, RESTCONF or CoMI to provide and emit created information directly via
NSF-Facing Interfaces <xref target="I-D.ietf-i2nsf-terminology"/>. Alternatively, the created
information is retained inside the system entity (or hierarchy of system
entities in a composite device) via records or counters that are not exposed
directly via NSF-Facing Interfaces.</t>

<t>Information emitted via standardized interfaces can be consumed by an I2NSF
Agent <xref target="I-D.ietf-i2nsf-terminology"/> that includes the capability to consume information not
only via I2NSF Interfaces but also via interfaces complementary to the
standardized interfaces a generic system entity provides.</t>

<t>Information retained on a system entity requires a corresponding I2NSF Agent to
access aggregated records of information, typically in the form of logfiles or
databases. There are ways to aggregate records originating from different system
entities over a network, for examples via Syslog <xref target="RFC5424"/> or Syslog over TCP <xref target="RFC6587"/>. But even
if records are conveyed, the result is the same kind of retention in form of a
bigger aggregate of records on another system entity.</t>

<t>An I2NSF Agent is required to process fresh <xref target="RFC4949"/> records created by
I2NSF Functions in order to provide them to other I2NSF Components via corresponding
I2NSF Interfaces timely. This process is effectively based on homogenizing functions
that can access and convert specific kinds of records into information that can
be provided and emitted via I2NSF interfaces.</t>

<t>Retained or emitted, the information required to support monitoring processes
has to be processed by an I2NSF Agent at some point in the work-flow. Typical
locations of these I2NSF Agents are:</t>

<t><list style="symbols">
  <t>a system entity that creates the information</t>
  <t>a system entity that retains an aggregation of records</t>
  <t>an I2NSF Component that includes the capabilities of using standardized
interfaces provided by other system entities that are not I2NSF Components</t>
  <t>an I2NSF Component that creates the information</t>
</list></t>

</section>
<section anchor="notifications-and-events" title="Notifications and Events">

<t>A specific task of I2NSF Agents is to process I2NSF Policy Rules
<xref target="I-D.ietf-i2nsf-terminology"/>. Rules are composed of three clauses: Events,
Conditions, and Actions. In consequence, an I2NSF Event is required to trigger
an I2NSF Policy Rule. “An I2NSF 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.” <xref target="I-D.ietf-i2nsf-terminology"/>, which aligns well with the
generic definition of Event from <xref target="RFC3877"/>.</t>

<t>The model illustrated in this document introduces a complementary type of
information that can be conveyed—notification.</t>

<t><list style="hanging">
  <t hangText='Notification:'>
  An occurrence of a change of context, composition, configuration, state or
behavior of a system entity that can be directly or indirectly observed by an
I2NSF Agent and can be used as input for an event-clause in I2NSF Policy Rules.</t>
  <t>A notification is similar to an I2NSF Event with the exception that it is
created by a system entity that is not an I2NSF Component and that
its importances is yet to be assessed. Semantically, a notification is not an
I2NSF Event in the context of I2NSF, although they can potentially use the exact
same information or data model. In respect to <xref target="RFC3877"/>, a Notification is a
specific subset of events, because they convey information about “something
that happens which may be of interest”.
In consequence, Notifications may contain information with very low expressiveness or
relevance. Hence, additional post-processing functions, such as
aggregation, correlation or simple anomaly detection, might have to be employed
to satisfy a level of expressiveness that is required for an event-clause of an
I2NSF Policy Rule.</t>
</list></t>

<t>It is important to note that the consumer of a notification (the observer)
assesses the importance of a notification and not the producer. The producer can
include metadata in a notification that supports the observer in assessing the
importance (even metadata about severity), but the deciding entity is an I2NSF Agent.</t>

</section>
<section anchor="unsolicited-poll-and-solicited-push" title="Unsolicited Poll and Solicited Push">

<t>The freshness of the monitored information depends on the acquisition method.
Ideally, an I2NSF Agent is accessing every relevant information about the I2NSF
Component and is emitting I2NSF Events to a monitoring NSF timely. Publication of
events via a pubsub/broker model, peer-2-peer meshes, or static defined channels
are only a few examples on how a solicited push of I2NSF Events can be
facilitated. The actual mechanic implemented by an I2NSF Component is out of the
scope of this document.</t>

<t>Often, corresponding management interfaces have to be queried in intervals or
on-demand if required by an I2NSF Policy rule. In some cases, a collection of
information has to be conducted via login mechanics provided by a system
entity. Accessing records of information via this kind of unsolicited polls can
introduce a significant latency in regard to the freshness of the monitored
information. The actual definition of intervals implemented by an I2NSF
Component is also out of scope of this document.</t>

</section>
<section anchor="i2nsf-monitoring-terminology-for-retained-information" title="I2NSF Monitoring Terminology for Retained Information">

<t><list style="hanging">
  <t hangText='Records:'>
  Unlike information emitted via notifications and events, records
do not require immediate attention from an analyst but may be
useful for visibility and retroactive cyber forensic. Depending on the record
format, there are different qualities in regard to structure and detail. Records
are typically stored in logfiles or databases on a system entity or NSF.
Records in the form of logfiles usually include less structures but potentially
more detailed information in regard to changes of an system entity’s
characteristics. In contrast, databases often use more strict schemas or data
models, therefore enforcing a better structure, but inhibit storing information
that do not match those models (‘closed world assumption’). Records can be
continuously processed by I2NSF Agents that act as I2NSF Producer and emit
events via functions specifically tailored to a certain type of record.
Typically, records are information generated by NSF or system entity about their operational
and informational data, or various changes in system characteristics, such as user activities,
network/traffic status, network activity, etc. They are important for
debugging, auditing and security forensic.</t>
  <t hangText='Counters:'>
  A specific representation of continuous value changes of information
elements that potentially occur in
high frequency. A prominent example are network interface counters, e.g. PDU amount or
byte amount, drop counters, error counters etc. Counters are useful in debugging and
visibility into operational behavior of the NSF. An I2NSF Agent that observes
the progression of counters can act as an I2NSF Producer and emit events in respect
to I2NSF Policy Rules.</t>
</list></t>

</section>
</section>
<section anchor="conveyance-of-nsf-monitoring-information" title="Conveyance of NSF Monitoring Information">

<t>As per the use cases of NSF monitoring data, information needs to be conveyed to
various I2NSF Consumers based on requirements imposed by I2NSF Capabilities and
work-flows. There are
multiple aspects to be considered in regard to emission of monitoring
information to
requesting parties as listed below:</t>

<t><list style="symbols">
  <t>Pull-Push Model: A set of data can be pushed by a NSF to the
requesting party or pulled by the requesting party from a NSF. Specific
types of information might need both the models at the same time if there are
multiple I2NSF Consumers with varying requirements. In general, any I2NSF Event
including a high severity assessment is considered to be of great importance
and should be processed as soon as possible (push-model). Records, in contrast, 
are typically not as critical (pull-model). The I2NSF Architecture does not
mandate a specific scheme for each type of information and is therefore out of
scope of this document.</t>
  <t>Pub-Sub Model: In order for an I2NSF Provider to push monitoring
information to multiple appropriate I2NSF Consumers, a subscription can be
maintained by both I2NSF Components. Discovery of available monitoring
information can be supported by an I2NSF Controller that takes on the role
of a broker and therefore includes I2NSF Capabilities that support registration.</t>
  <t>Export Frequency: Monitoring information can be emitted immediately
upon generation by a NSF to requesting I2NSF Consumers or can be pushed
periodically. The frequency of exporting the data depends upon its
size and timely usefulness. It is out of the scope of I2NSF and left
to each NSF implementation.</t>
  <t>Authentication: There may be a need for authentication between
I2NSF Producer of monitoring information and corresponding I2NSF Consumer
to ensure that critical information remains confidential. Authentication in 
the scope of I2NSF can also require a corresponding content authorization.
This may be necessary, for example, if a NSF emits monitoring information to
I2NSF Consumer
outside its administrative domain. The I2NSF Architecture does not mandate when
and how specific authentication has to be implemented.</t>
  <t>Data-Transfer Model: Monitoring information can be pushed by NSF using a
connection-less model that does require a persistent connection or
streamed over a persistent connection. An appropriate model depends on the
I2NSF Consumer requirements and the semantics of the information to be conveyed.</t>
  <t>Data Model and Interaction Model for Data in Motion: There are a lot of
transport mechanisms such as IP, UDP, TCP. There are also open source implementations for
specific set of data such as systems counter, e.g. IPFIX <xref target="RFC7011"/> or
NetFlow <xref target="RFC3954"/>. The I2NSF does not
mandate any specific method for a given data set, it is up to each
implementation.</t>
</list></t>

<section anchor="information-types-and-acquisition-methods" title="Information Types and Acquisition Methods">

<t>In this document most information types defined, benefit from high visibility with respect to value changes, e.g. alarms or records.
In contrast, values that change monotonically in a continuous way do not benefit from this high visibility.
On the contrary, emitting each change would result in a useless amount of value updates.
Hence, values, such as counter, are best acquired in periodic intervals.</t>

<t>The mechanism provided by YANG Push <xref target="I-D.ietf-netconf-yang-push"/> and YANG Subscribed Notifications <xref target="I-D.ietf-netconf-subscribed-notifications"/> address exactly these set of requirements.
YANG also enables semantically well-structured information, as well as subscriptions to datatores or event streams - on-change or periodically.</t>

<t>In consequence, this information model is intended to support data models used in solicited or unsolicited event streams that potentially are facilitated by subscription mechanism.
A subset of information elements defined in the information model address this domain of application.</t>

</section>
</section>
<section anchor="basic-information-model-for-all-monitoring-data" title="Basic Information Model for All Monitoring Data">

<t>As explained in the above section, there is a wealth of data
available from the NSF that can be monitored. Firstly, there must be
some general information with each monitoring message sent from an NSF
that helps consumer in identifying meta data with that message, which
are listed as below:</t>

<t><list style="symbols">
  <t>message_version: Indicate the version of the data format and is a
two-digit decimal numeral starting from 01</t>
  <t>message_type: Event, Alert, Alarm, Log, Counter, etc</t>
  <t>time_stamp: Indicate the time when the message is generated</t>
  <t>vendor_name: The name of the NSF vendor</t>
  <t>NSF_name: The name (or IP) of the NSF generating the message</t>
  <t>Module_name: The module name outputting the message</t>
  <t>Severity: Indicates the level of the logs. There are total eight
levels, from 0 to 7. The smaller the numeral is, the higher the
severity is.</t>
</list></t>

</section>
<section anchor="extended-information-model-for-monitoring-data" title="Extended Information Model for Monitoring Data">

<t>This section covers the additional information associated with the
system messages. The extended information model is only for the
structured data such as alarm. Any unstructured data is specified with
basic information model only.</t>

<section anchor="system-alarm" title="System Alarm">

<t>Characteristics:</t>

<t><list style="symbols">
  <t>acquisition_method: subscription</t>
  <t>emission_type: on-change</t>
  <t>dampening_type: no-dampening</t>
</list></t>

<section anchor="memory-alarm" title="Memory Alarm">

<t>The following information should be included in a Memory
Alarm:</t>

<t><list style="symbols">
  <t>event_name: ‘MEM_USAGE_ALARM’</t>
  <t>module_name: Indicate the NSF module responsible for
generating this alarm</t>
  <t>usage: specifies the amount of memory used</t>
  <t>threshold: The threshold triggering the alarm</t>
  <t>severity: The severity of the alarm such as critical, high,
medium, low</t>
  <t>message: ‘The memory usage exceeded the threshold’</t>
</list></t>

</section>
<section anchor="cpu-alarm" title="CPU Alarm">

<t>The following information should be included in a CPU Alarm:</t>

<t><list style="symbols">
  <t>event_name: ‘CPU_USAGE_ALARM’</t>
  <t>usage: Specifies the amount of CPU used</t>
  <t>threshold: The threshold triggering the event</t>
  <t>severity: The severity of the alarm such as critical, high,
medium, low</t>
  <t>message: ‘The CPU usage exceeded the threshold’</t>
</list></t>

</section>
<section anchor="disk-alarm" title="Disk Alarm">

<t>The following information should be included in a Disk Alarm:</t>

<t><list style="symbols">
  <t>event_name: ‘DISK_USAGE_ALARM’</t>
  <t>usage: Specifies the amount of disk space used</t>
  <t>threshold: The threshold triggering the event</t>
  <t>severity: The severity of the alarm such as critical, high,
medium, low</t>
  <t>message: ‘The disk usage exceeded the threshold’</t>
</list></t>

</section>
<section anchor="hardware-alarm" title="Hardware Alarm">

<t>The following information should be included in a Hardware
Alarm:</t>

<t><list style="symbols">
  <t>event_name: ‘HW_FAILURE_ALARM’</t>
  <t>component_name: Indicate the HW component responsible for
generating this alarm</t>
  <t>threshold: The threshold triggering the alarm</t>
  <t>severity: The severity of the alarm such as critical, high,
medium, low</t>
  <t>message: ‘The HW component has failed or degraded’</t>
</list></t>

</section>
<section anchor="interface-alarm" title="Interface Alarm">

<t>The following information should be included in a Interface
Alarm:</t>

<t><list style="symbols">
  <t>event_name: ‘IFNET_STATE_ALARM’</t>
  <t>interface_Name: The name of interface</t>
  <t>interface_state: ‘UP’, ‘DOWN’, ‘CONGESTED’</t>
  <t>threshold: The threshold triggering the event</t>
  <t>severity: The severity of the alarm such as critical, high,
medium, low</t>
  <t>message: ‘Current interface state’</t>
</list></t>

</section>
</section>
<section anchor="system-events" title="System Events">

<t>Characteristics:</t>

<t><list style="symbols">
  <t>acquisition_method: subscription</t>
  <t>emission_type: on-change</t>
  <t>dampening_type: on_repetition</t>
</list></t>

<section anchor="access-violation" title="Access Violation">

<t>The following information should be included in this event:</t>

<t><list style="symbols">
  <t>event_name: ‘ACCESS_DENIED’</t>
  <t>user: Name of a user</t>
  <t>group: Group to which a user belongs</t>
  <t>login_ip_address: Login IP address of a user</t>
  <t>authentication_mode: User authentication mode. e.g., Local
Authentication, Third-Party Server Authentication,
Authentication Exemption, SSO Authentication</t>
  <t>message: ‘access denied’</t>
</list></t>

</section>
<section anchor="configuration-change" title="Configuration Change">

<t>The following information should be included in this event:</t>

<t><list style="symbols">
  <t>event_name: ‘CONFIG_CHANGE’</t>
  <t>user: Name of a user</t>
  <t>group: Group to which a user belongs</t>
  <t>login_ip_address: Login IP address of a user</t>
  <t>authentication_mode: User authentication mode. e.g., Local
Authentication, Third-Party Server Authentication,
Authentication Exemption, SSO Authentication</t>
  <t>message: ‘Configuration modified’</t>
</list></t>

</section>
</section>
<section anchor="system-log" title="System Log">

<t>Characteristics:</t>

<t><list style="symbols">
  <t>acquisition_method: subscription</t>
  <t>emission_type: on-change</t>
  <t>dampening_type: on_repetition</t>
</list></t>

<section anchor="access-logs" title="Access Logs">

<t>Access logs record administrators’ login, logout, and operations
on the device. By analyzing them, security vulnerabilities can be
identified. The following information should be included in
operation report:</t>

<t><list style="symbols">
  <t>Administrator: Administrator that operates on the device</t>
  <t>login_ip_address: IP address used by an administrator to log
in</t>
  <t>login_mode: Specifies the administrator logs in mode e.g.
root, user</t>
  <t>operation_type: The operation type that the administrator
execute, e.g., login, logout, configuration, etc</t>
  <t>result: Command execution result</t>
  <t>content: Operation performed by an administrator after
login.</t>
</list></t>

</section>
<section anchor="resource-utilization-logs" title="Resource Utilization Logs">

<t>Running reports record the device system’s running status, which
is useful for device monitoring. The following information should be
included in running report:</t>

<t><list style="symbols">
  <t>system_status: The current system’s running status</t>
  <t>CPU_usage: Specifies the CPU usage</t>
  <t>memory_usage: Specifies the memory usage</t>
  <t>disk_usage: Specifies the disk usage</t>
  <t>disk_left: Specifies the available disk space left</t>
  <t>session_number: Specifies total concurrent sessions</t>
  <t>process_number: Specifies total number of system
processes</t>
  <t>in_traffic_rate: The total inbound traffic rate in pps</t>
  <t>out_traffic_rate: The total outbound traffic rate in pps</t>
  <t>in_traffic_speed: The total inbound traffic speed in bps</t>
  <t>out_traffic_speed: The total outbound traffic speed in
bps</t>
</list></t>

</section>
<section anchor="user-activity-logs" title="User Activity Logs">

<t>User activity logs provide visibility into users’ online records
(such as login time, online/lockout duration, and login IP
addresses) and the actions users perform. User activity reports are
helpful to identify exceptions during user login and network access
activities.</t>

<t><list style="symbols">
  <t>user: Name of a user</t>
  <t>group: Group to which a user belongs</t>
  <t>login_ip_address: Login IP address of a user</t>
  <t>authentication_mode: User authentication mode. e.g., Local
Authentication, Third-Party Server Authentication,
Authentication Exemption, SSO Authentication</t>
  <t>access_mode: User access mode. e.g., PPP, SVN, LOCAL</t>
  <t>online_duration: Online duration</t>
  <t>lockout_duration: Lockout duration</t>
  <t>type: User activities. e.g., Successful User Login, Failed
Login attempts, User Logout, Successful User Password Change,
Failed User Password Change, User Lockout, User Unlocking,
Unknown</t>
  <t>cause: Cause of a failed user activity</t>
</list></t>

</section>
</section>
<section anchor="system-counters" title="System Counters">

<t>Characteristics:</t>

<t><list style="symbols">
  <t>acquisition_method: subscription or query</t>
  <t>emission_type: periodical</t>
  <t>dampening_type: none</t>
</list></t>

<section anchor="interface-counters" title="Interface counters">

<t>Interface counters provide visibility into traffic into and out
of NSF, bandwidth usage.</t>

<t><list style="symbols">
  <t>interface_name: Network interface name configured in NSF</t>
  <t>in_total_traffic_pkts: Total inbound packets</t>
  <t>out_total_traffic_pkts: Total outbound packets</t>
  <t>in_total_traffic_bytes: Total inbound bytes</t>
  <t>out_total_traffic_bytes: Total outbound bytes</t>
  <t>in_drop_traffic_pkts: Total inbound drop packets</t>
  <t>out_drop_traffic_pkts: Total outbound drop packets</t>
  <t>in_drop_traffic_bytes: Total inbound drop bytes</t>
  <t>out_drop_traffic_bytes: Total outbound drop bytes</t>
  <t>in_traffic_ave_rate: Inbound traffic average rate in pps</t>
  <t>in_traffic_peak_rate: Inbound traffic peak rate in pps</t>
  <t>in_traffic_ave_speed: Inbound traffic average speed in
bps</t>
  <t>in_traffic_peak_speed: Inbound traffic peak speed in bps</t>
  <t>out_traffic_ave_rate: Outbound traffic average rate in
pps</t>
  <t>out_traffic_peak_rate: Outbound traffic peak rate in pps</t>
  <t>out_traffic_ave_speed: Outbound traffic average speed in
bps</t>
  <t>out_traffic_peak_speed: Outbound traffic peak speed in
bps.</t>
</list></t>

</section>
</section>
<section anchor="nsf-events" title="NSF Events">

<t>Characteristics:</t>

<t><list style="symbols">
  <t>acquisition_method: subscription</t>
  <t>emission_type: on-change</t>
  <t>dampening_type: none</t>
</list></t>

<section anchor="ddos-event" title="DDoS Event">

<t>The following information should be included in a DDoS Event:</t>

<t><list style="symbols">
  <t>event_name: ‘SEC_EVENT_DDoS’</t>
  <t>sub_attack_type: Any one of Syn flood, ACK flood, SYN-ACK
flood, FIN/RST flood, TCP Connection flood, UDP flood, Icmp
flood, HTTPS flood, HTTP flood, DNS query flood, DNS reply
flood, SIP flood, and etc.</t>
  <t>dst_ip: The IP address of a victum under attack</t>
  <t>dst_port: The port numbers that the attrack traffic aims
at.</t>
  <t>start_time: The time stamp indicating when the attack
started</t>
  <t>end_time: The time stamp indicating when the attack ended. If
the attack is still undergoing when sending out the alarm, this
field can be empty.</t>
  <t>attack_rate: The PPS of attack traffic</t>
  <t>attack_speed: the bps of attack traffic</t>
  <t>rule_id: The ID of the rule being triggered</t>
  <t>rule_name: The name of the rule being triggered</t>
  <t>profile: Security profile that traffic matches.</t>
</list></t>

</section>
<section anchor="session-table-event" title="Session Table Event">

<t>The following information should be included in a Session Table
Event:</t>

<t><list style="symbols">
  <t>event_name: ‘SESSION_USAGE_HIGH’</t>
  <t>current: The number of concurrent sessions</t>
  <t>max: The maximum number of sessions that the session table
can support</t>
  <t>threshold: The threshold triggering the event</t>
  <t>message: ‘The number of session table exceeded the
threshold’</t>
</list></t>

</section>
<section anchor="virus-event" title="Virus Event">

<t>The following information should be included in a Virus
Event:</t>

<t><list style="symbols">
  <t>event_Name: ‘SEC_EVENT_VIRUS’</t>
  <t>virus_type: Type of the virus, e.g., trojan, worm, macro
Virus type</t>
  <t>virus_name</t>
  <t>dst_ip: The destination IP address of the packet where the
virus is found</t>
  <t>src_ip: The source IP address of the packet where the virus
is found</t>
  <t>src_port: The source port of the packet where the virus is
found</t>
  <t>dst_port: The destination port of the packet where the virus
is found</t>
  <t>src_zone: The source security zone of the packet where the
virus is found</t>
  <t>dst_zone: The destination security zone of the packet where
the virus is found</t>
  <t>file_type: The type of the file where the virus is hided
within</t>
  <t>file_name: The name of the file where the virus is hided
within</t>
  <t>virus_info: The brief introduction of virus</t>
  <t>raw_info: The information describing the packet triggering
the event.</t>
  <t>rule_id: The ID of the rule being triggered</t>
  <t>rule_name: The name of the rule being triggered</t>
  <t>profile: Security profile that traffic matches.</t>
</list></t>

</section>
<section anchor="intrusion-event" title="Intrusion Event">

<t>The following information should be included in a Intrustion
Event:</t>

<t><list style="symbols">
  <t>event_name: The name of event: ‘SEC_EVENT_Intrusion’</t>
  <t>sub_attack_type: Attack type, e.g., brutal force, buffer
overflow</t>
  <t>src_ip: The source IP address of the packet</t>
  <t>dst_ip: The destination IP address of the packet</t>
  <t>src_port:The source port number of the packet</t>
  <t>dst_port: The destination port number of the packet</t>
  <t>src_zone: The source security zone of the packet</t>
  <t>dst_zone: The destination security zone of the packet</t>
  <t>protocol: The employed transport layer protocol, e.g.,TCP,
UDP</t>
  <t>app: The employed application layer protocol, e.g.,HTTP,
FTP</t>
  <t>rule_id: The ID of the rule being triggered</t>
  <t>rule_name: The name of the rule being triggered</t>
  <t>profile: Security profile that traffic matches</t>
  <t>intrusion_info: Simple description of intrusion</t>
  <t>raw_info: The information describing the packet triggering
the event.</t>
</list></t>

</section>
<section anchor="botnet-event" title="Botnet Event">

<t>The following information should be included in a Botnet
Event:</t>

<t><list style="symbols">
  <t>event_name: the name of event: ‘SEC_EVENT_Botnet’</t>
  <t>botnet_name: The name of the detected botnet</t>
  <t>src_ip: The source IP address of the packet</t>
  <t>dst_ip: The destination IP address of the packet</t>
  <t>src_port: The source port number of the packet</t>
  <t>dst_port: The destination port number of the packet</t>
  <t>src_zone: The source security zone of the packet</t>
  <t>dst_zone: The destination security zone of the packet</t>
  <t>protocol: The employed transport layer protocol, e.g.,TCP,
UDP</t>
  <t>app: The employed application layer protocol, e.g.,HTTP,
FTP</t>
  <t>role: The role of the communicating parties within the
botnet:  <list style="numbers">
      <t>the packet from zombie host to the attacker</t>
      <t>The packet from the attacker to the zombie host</t>
      <t>The packet from the IRC/WEB server to the zombie host</t>
      <t>The packet from the zombie host to the IRC/WEB server</t>
      <t>The packet from the attacker to the IRC/WEB server</t>
      <t>The packet from the IRC/WEB server to the attacker</t>
      <t>The packet from the zombie host to the victim</t>
    </list></t>
  <t>botnet_info: Simple description of Botnet</t>
  <t>rule_id: The ID of the rule being triggered</t>
  <t>rule_name: The name of the rule being triggered</t>
  <t>profile: Security profile that traffic matches</t>
  <t>raw_info: The information describing the packet triggering
the event.</t>
</list></t>

</section>
<section anchor="web-attack-event" title="Web Attack Event">

<t>The following information should be included in a Web Attack
Alarm:</t>

<t><list style="symbols">
  <t>event_name: the name of event: ‘SEC_EVENT_WebAttack’</t>
  <t>sub_attack_type: Concret web attack type, e.g., sql
injection, command injection, XSS, CSRF</t>
  <t>src_ip: The source IP address of the packet</t>
  <t>dst_ip: The destination IP address of the packet</t>
  <t>src_port: The source port number of the packet</t>
  <t>dst_port: The destination port number of the packet</t>
  <t>src_zone: The source security zone of the packet</t>
  <t>dst_zone: The destination security zone of the packet</t>
  <t>req_method: The method of requirement. For instance, ‘PUT’ or
‘GET’ in HTTP</t>
  <t>req_url: Requested URL</t>
  <t>url_category: Matched URL category</t>
  <t>filtering_type: URL filtering type, e.g., Blacklist,
Whitelist, User-Defined, Predefined, Malicious Category,
Unknown</t>
  <t>rule_id: The ID of the rule being triggered</t>
  <t>rule_name: The name of the rule being triggered</t>
  <t>profile: Security profile that traffic matches.</t>
</list></t>

</section>
</section>
<section anchor="nsf-logs" title="NSF Logs">

<t>Characteristics:</t>

<t><list style="symbols">
  <t>acquisition_method: subscription</t>
  <t>emission_type: on-change</t>
  <t>dampening_type: on_repetition</t>
</list></t>

<section anchor="ddos-logs" title="DDoS Logs">

<t>Besides the fields in an DDoS Alarm, the following information
should be included in a DDoS Logs:</t>

<t><list style="symbols">
  <t>attack_type: DDoS</t>
  <t>attack_ave_rate: The average pps of the attack traffic within
the recorded time</t>
  <t>attack_ave_speed: The average bps of the attack traffic
within the recorded time</t>
  <t>attack_pkt_num: The number attack packets within the recorded
time</t>
  <t>attack_src_ip: The source IP addresses of attack traffics. If
there are a large amount of IP addresses, then pick a certain
number of resources according to different rules.</t>
  <t>action: Actions against DDoS attacks, e.g., Allow, Alert,
Block, Discard, Declare, Block-ip, Block-service.</t>
</list></t>

</section>
<section anchor="virus-logs" title="Virus Logs">

<t>Besides the fields in an Virus Alarm, the following information
should be included in a Virus Logs:</t>

<t><list style="symbols">
  <t>attack_type: Virus</t>
  <t>protocol: The transport layer protocol</t>
  <t>app: The name of the application layer protocol</t>
  <t>times: The time of detecting the virus</t>
  <t>action: The actions dealing with the virus, e.g., alert,
block</t>
  <t>os: The OS that the virus will affect, e.g., all, android,
ios, unix, windows</t>
</list></t>

</section>
<section anchor="intrusion-logs" title="Intrusion Logs">

<t>Besides the fields in an Intrusion Alarm, the following
information should be included in a Intrusion Logs:</t>

<t><list style="symbols">
  <t>attack_type: Intrusion</t>
  <t>times: The times of intrusions happened in the recorded
time</t>
  <t>os: The OS that the intrusion will affect, e.g., all,
android, ios, unix, windows</t>
  <t>action: The actions dealing with the intrusions, e.g., e.g.,
Allow, Alert, Block, Discard, Declare, Block-ip,
Block-service</t>
  <t>attack_rate: NUM the pps of attack traffic</t>
  <t>attack_speed: NUM the bps of attack traffic</t>
</list></t>

</section>
<section anchor="botnet-logs" title="Botnet Logs">

<t>Besides the fields in an Botnet Alarm, the following information
should be included in a Botnet Logs:</t>

<t><list style="symbols">
  <t>attack_type: Botnet</t>
  <t>botnet_pkt_num:The number of the packets sent to or from the
detected botnet</t>
  <t>action: The actions dealing with the detected packets, e.g.,
Allow, Alert, Block, Discard, Declare, Block-ip, Block-service,
etc</t>
  <t>os: The OS that the attack aiming at, e.g., all, android,
ios, unix, windows, etc.</t>
</list></t>

</section>
<section anchor="dpi-logs" title="DPI Logs">

<t>DPI Logs provide statistics on uploaded and downloaded files and
data, sent and received emails, and alert and block records on
websites. It’s helpful to learn risky user behaviors and why access
to some URLs is blocked or allowed with an alert record.</t>

<t><list style="symbols">
  <t>type: DPI action types. e.g., File Blocking, Data Filtering,
Application Behavior Control</t>
  <t>file_name: The file name</t>
  <t>file_type: The file type</t>
  <t>src_zone: Source security zone of traffic</t>
  <t>dst_zone: Destination security zone of traffic</t>
  <t>src_region: Source region of the traffic</t>
  <t>dst_region: Destination region of the traffic</t>
  <t>src_ip: Source IP address of traffic</t>
  <t>src_user: User who generates traffic</t>
  <t>dst_ip: Destination IP address of traffic</t>
  <t>src_port: Source port of traffic</t>
  <t>dst_port: Destination port of traffic</t>
  <t>protocol: Protocol type of traffic</t>
  <t>app: Application type of traffic</t>
  <t>policy_id: Security policy id that traffic matches</t>
  <t>policy_name: Security policy name that traffic matches</t>
  <t>action: Action defined in the file blocking rule, data
filtering rule, or application behavior control rule that
traffic matches.</t>
</list></t>

</section>
<section anchor="vulnerabillity-scanning-logs" title="Vulnerabillity Scanning Logs">

<t>Vulnerability scanning logs record the victim host and its
related vulnerability information that should to be fixed. the
following information should be included in the report:</t>

<t><list style="symbols">
  <t>victim_ip: IP address of the victim host which has
vulnerabilities</t>
  <t>vulnerability_id: The vulnerability id</t>
  <t>vulnerability_level: The vulnerability level. e.g., high,
middle, low</t>
  <t>OS: The operating system of the victim host</t>
  <t>service: The service which has vulnerabillity in the victim
host</t>
  <t>protocol: The protocol type. e.g., TCP, UDP</t>
  <t>port: The port number</t>
  <t>vulnerability_info: The information about the
vulnerability</t>
  <t>fix_suggestion: The fix suggestion to the vulnerability.</t>
</list></t>

</section>
<section anchor="web-attack-logs" title="Web Attack Logs">

<t>Besides the fields in an Web Attack Alarm, the following
information should be included in a Web Attack Report:</t>

<t><list style="symbols">
  <t>attack_type: Web Attack</t>
  <t>rsp_code: Response code</t>
  <t>req_clientapp: The client application</t>
  <t>req_cookies: Cookies</t>
  <t>req_host: The domain name of the requested host</t>
  <t>raw_info: The information describing the packet triggering
the event.</t>
</list></t>

</section>
</section>
<section anchor="nsf-counters" title="NSF Counters">

<t>Characteristics:</t>

<t><list style="symbols">
  <t>acquisition_method: subscription or query</t>
  <t>emission_type: periodical</t>
  <t>dampening_type: none</t>
</list></t>

<section anchor="firewall-counters" title="Firewall counters">

<t>Firewall counters provide visibility into traffic signatures,
bandwidth usage, and how the configured security and bandwidth
policies have been applied.</t>

<t><list style="symbols">
  <t>src_zone: Source security zone of traffic</t>
  <t>dst_zone: Destination security zone of traffic</t>
  <t>src_region: Source region of the traffic</t>
  <t>dst_region: Destination region of the traffic</t>
  <t>src_ip: Source IP address of traffic</t>
  <t>src_user: User who generates traffic</t>
  <t>dst_ip: Destination IP address of traffic</t>
  <t>src_port: Source port of traffic</t>
  <t>dst_port: Destination port of traffic</t>
  <t>protocol: Protocol type of traffic</t>
  <t>app: Application type of traffic</t>
  <t>policy_id: Security policy id that traffic matches</t>
  <t>policy_name: Security policy name that traffic matches</t>
  <t>in_interface: Inbound interface of traffic</t>
  <t>out_interface: Outbound interface of traffic</t>
  <t>total_traffic: Total traffic volume</t>
  <t>in_traffic_ave_rate: Inbound traffic average rate in pps</t>
  <t>in_traffic_peak_rate: Inbound traffic peak rate in pps</t>
  <t>in_traffic_ave_speed: Inbound traffic average speed in
bps</t>
  <t>in_traffic_peak_speed: Inbound traffic peak speed in bps</t>
  <t>out_traffic_ave_rate: Outbound traffic average rate in
pps</t>
  <t>out_traffic_peak_rate: Outbound traffic peak rate in pps</t>
  <t>out_traffic_ave_speed: Outbound traffic average speed in
bps</t>
  <t>out_traffic_peak_speed: Outbound traffic peak speed in
bps.</t>
</list></t>

</section>
<section anchor="policy-hit-counters" title="Policy Hit Counters">

<t>Policy Hit Counters record the security policy that traffic
matches and its hit count. It can check if policy configurations are
correct.</t>

<t><list style="symbols">
  <t>src_zone: Source security zone of traffic</t>
  <t>dst_zone: Destination security zone of traffic</t>
  <t>src_region: Source region of the traffic</t>
  <t>dst_region: Destination region of the traffic</t>
  <t>src_ip: Source IP address of traffic</t>
  <t>src_user: User who generates traffic</t>
  <t>dst_ip: Destination IP address of traffic</t>
  <t>src_port: Source port of traffic</t>
  <t>dst_port: Destination port of traffic</t>
  <t>protocol: Protocol type of traffic</t>
  <t>app: Application type of traffic</t>
  <t>policy_id: Security policy id that traffic matches</t>
  <t>policy_name: Security policy name that traffic matches</t>
  <t>hit_times: The hit times that the security policy matches the
specified traffic.</t>
</list></t>

</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">

<t>This document makes no request of IANA.</t>

<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>

</section>
<section anchor="Security" title="Security Considerations">

<t>The monitoring information of NSF should be protected by the secure
communication channel, to ensure its confidentiality and integrity. In
another side, the NSF and security controller can all be faked, which
lead to undesireable results, i.e., leakage of NSF’s important
operational information, faked NSF sending false information to mislead
security controller. The mutual authentication is essential to protected
against this kind of attack. The current mainstream security
technologies (i.e., TLS, DTLS, IPSEC, X.509 PKI) can be employed
approriately to provide the above security functions.</t>

<t>In addition, to defend against the DDoS attack caused by a lot of
NSFs sending massive monitoring information to the security controller,
the rate limiting or similar mechanisms should be considered in NSF and
security controller, whether in advance or just in the process of DDoS
attack.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC3877" target='https://www.rfc-editor.org/info/rfc3877'>
<front>
<title>Alarm Management Information Base (MIB)</title>
<author initials='S.' surname='Chisholm' fullname='S. Chisholm'><organization /></author>
<author initials='D.' surname='Romascanu' fullname='D. Romascanu'><organization /></author>
<date year='2004' month='September' />
<abstract><t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes management objects used for modelling and storing alarms.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3877'/>
<seriesInfo name='DOI' value='10.17487/RFC3877'/>
</reference>



<reference  anchor="RFC4765" target='https://www.rfc-editor.org/info/rfc4765'>
<front>
<title>The Intrusion Detection Message Exchange Format (IDMEF)</title>
<author initials='H.' surname='Debar' fullname='H. Debar'><organization /></author>
<author initials='D.' surname='Curry' fullname='D. Curry'><organization /></author>
<author initials='B.' surname='Feinstein' fullname='B. Feinstein'><organization /></author>
<date year='2007' month='March' />
<abstract><t>The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.</t><t>This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model.  An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided.  This memo defines an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='4765'/>
<seriesInfo name='DOI' value='10.17487/RFC4765'/>
</reference>



<reference  anchor="RFC4949" target='https://www.rfc-editor.org/info/rfc4949'>
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials='R.' surname='Shirey' fullname='R. Shirey'><organization /></author>
<date year='2007' month='August' />
<abstract><t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='FYI' value='36'/>
<seriesInfo name='RFC' value='4949'/>
<seriesInfo name='DOI' value='10.17487/RFC4949'/>
</reference>



<reference  anchor="RFC5424" target='https://www.rfc-editor.org/info/rfc5424'>
<front>
<title>The Syslog Protocol</title>
<author initials='R.' surname='Gerhards' fullname='R. Gerhards'><organization /></author>
<date year='2009' month='March' />
<abstract><t>This document describes the syslog protocol, which is used to convey event notification messages.  This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages.  It also provides a message format that allows vendor-specific extensions to be provided in a structured way.</t><t>This document has been written with the original design goals for traditional syslog in mind.  The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC.  Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues.  This document tries to provide a foundation that syslog extensions can build on.  This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5424'/>
<seriesInfo name='DOI' value='10.17487/RFC5424'/>
</reference>



<reference  anchor="RFC6587" target='https://www.rfc-editor.org/info/rfc6587'>
<front>
<title>Transmission of Syslog Messages over TCP</title>
<author initials='R.' surname='Gerhards' fullname='R. Gerhards'><organization /></author>
<author initials='C.' surname='Lonvick' fullname='C. Lonvick'><organization /></author>
<date year='2012' month='April' />
<abstract><t>There have been many implementations and deployments of legacy syslog over TCP for many years.  That protocol has evolved without being standardized and has proven to be quite interoperable in practice. This memo describes how TCP has been used as a transport for syslog messages.  This document defines a Historic Document for the Internet  community.</t></abstract>
</front>
<seriesInfo name='RFC' value='6587'/>
<seriesInfo name='DOI' value='10.17487/RFC6587'/>
</reference>



<reference  anchor="RFC7011" target='https://www.rfc-editor.org/info/rfc7011'>
<front>
<title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information</title>
<author initials='B.' surname='Claise' fullname='B. Claise' role='editor'><organization /></author>
<author initials='B.' surname='Trammell' fullname='B. Trammell' role='editor'><organization /></author>
<author initials='P.' surname='Aitken' fullname='P. Aitken'><organization /></author>
<date year='2013' month='September' />
<abstract><t>This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network.  In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.  This document obsoletes RFC 5101.</t></abstract>
</front>
<seriesInfo name='STD' value='77'/>
<seriesInfo name='RFC' value='7011'/>
<seriesInfo name='DOI' value='10.17487/RFC7011'/>
</reference>



<reference anchor="I-D.ietf-core-yang-cbor">
<front>
<title>CBOR Encoding of Data Modeled with YANG</title>

<author initials='M' surname='Veillette' fullname='Michel Veillette'>
    <organization />
</author>

<author initials='A' surname='Pelov' fullname='Alexander Pelov'>
    <organization />
</author>

<author initials='A' surname='Somaraju' fullname='Abhinav Somaraju'>
    <organization />
</author>

<author initials='R' surname='Turner' fullname='Randy Turner'>
    <organization />
</author>

<author initials='A' surname='Minaburo' fullname='Ana Minaburo'>
    <organization />
</author>

<date month='September' day='14' year='2018' />

<abstract><t>This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output and notifications defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049].</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-yang-cbor-07' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-yang-cbor-07.txt' />
</reference>



<reference anchor="I-D.ietf-netconf-subscribed-notifications">
<front>
<title>Customized Subscriptions to a Publisher's Event Streams</title>

<author initials='E' surname='Voit' fullname='Eric Voit'>
    <organization />
</author>

<author initials='A' surname='Clemm' fullname='Alexander Clemm'>
    <organization />
</author>

<author initials='A' surname='Prieto' fullname='Alberto Prieto'>
    <organization />
</author>

<author initials='E' surname='Nilsen-Nygaard' fullname='Einar Nilsen-Nygaard'>
    <organization />
</author>

<author initials='A' surname='Tripathy' fullname='Ambika Tripathy'>
    <organization />
</author>

<date month='September' day='28' year='2018' />

<abstract><t>This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams.  Applying these elements allows a subscriber to request for and receive a continuous, custom feed of publisher generated information.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-netconf-subscribed-notifications-17' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-netconf-subscribed-notifications-17.txt' />
</reference>



<reference anchor="I-D.ietf-netconf-yang-push">
<front>
<title>Subscription to YANG Datastores</title>

<author initials='A' surname='Clemm' fullname='Alexander Clemm'>
    <organization />
</author>

<author initials='E' surname='Voit' fullname='Eric Voit'>
    <organization />
</author>

<author initials='A' surname='Prieto' fullname='Alberto Prieto'>
    <organization />
</author>

<author initials='A' surname='Tripathy' fullname='Ambika Tripathy'>
    <organization />
</author>

<author initials='E' surname='Nilsen-Nygaard' fullname='Einar Nilsen-Nygaard'>
    <organization />
</author>

<author initials='A' surname='Bierman' fullname='Andy Bierman'>
    <organization />
</author>

<author initials='B' surname='Lengyel' fullname='Balazs Lengyel'>
    <organization />
</author>

<date month='October' day='22' year='2018' />

<abstract><t>Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore.  Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-netconf-yang-push-20' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-netconf-yang-push-20.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC3954" target='https://www.rfc-editor.org/info/rfc3954'>
<front>
<title>Cisco Systems NetFlow Services Export Version 9</title>
<author initials='B.' surname='Claise' fullname='B. Claise' role='editor'><organization /></author>
<date year='2004' month='October' />
<abstract><t>This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs.  The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner.  A template defines a collection of fields, with corresponding descriptions of structure and semantics.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3954'/>
<seriesInfo name='DOI' value='10.17487/RFC3954'/>
</reference>



<reference anchor="I-D.ietf-i2nsf-framework">
<front>
<title>Framework for Interface to Network Security Functions</title>

<author initials='D' surname='Lopez' fullname='Diego Lopez'>
    <organization />
</author>

<author initials='E' surname='Lopez' fullname='Edward Lopez'>
    <organization />
</author>

<author initials='L' surname='Dunbar' fullname='Linda Dunbar'>
    <organization />
</author>

<author initials='J' surname='Strassner' fullname='John Strassner'>
    <organization />
</author>

<author initials='R' surname='Kumar' fullname='Rakesh Kumar'>
    <organization />
</author>

<date month='November' day='20' year='2017' />

<abstract><t>This document describes the framework for the Interface to Network Security Functions (I2NSF), and defines a reference model (including major functional components) for I2NSF.  Network security functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-i2nsf-framework-10' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-i2nsf-framework-10.txt' />
</reference>



<reference anchor="I-D.ietf-i2nsf-terminology">
<front>
<title>Interface to Network Security Functions (I2NSF) Terminology</title>

<author initials='S' surname='Hares' fullname='Susan Hares'>
    <organization />
</author>

<author initials='J' surname='Strassner' fullname='John Strassner'>
    <organization />
</author>

<author initials='D' surname='Lopez' fullname='Diego Lopez'>
    <organization />
</author>

<author initials='L' surname='Xia' fullname='Liang Xia'>
    <organization />
</author>

<author initials='H' surname='Birkholz' fullname='Henk Birkholz'>
    <organization />
</author>

<date month='July' day='2' year='2018' />

<abstract><t>This document defines a set of terms that are used for the Interface to Network Security Functions (I2NSF) effort.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-i2nsf-terminology-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-i2nsf-terminology-06.txt' />
</reference>



<reference anchor="I-D.xia-i2nsf-capability-interface-im">
<front>
<title>Information Model of Interface to Network Security Functions Capability Interface</title>

<author initials='L' surname='Xia' fullname='Liang Xia'>
    <organization />
</author>

<author initials='J' surname='Strassner' fullname='John Strassner'>
    <organization />
</author>

<author initials='K' surname='Li' fullname='Kepeng Li'>
    <organization />
</author>

<author initials='D' surname='Zhang' fullname='Dacheng Zhang'>
    <organization />
</author>

<author initials='E' surname='Lopez' fullname='Edward Lopez'>
    <organization />
</author>

<author initials='N' surname='Bouthors' fullname='Nicolas Bouthors'>
    <organization />
</author>

<author initials='L' surname='Fang' fullname='Luyuan Fang'>
    <organization />
</author>

<date month='July' day='1' year='2016' />

<abstract><t>This draft is focused on the capability interface of NSFs (Network Security Functions) and proposes its information model for managing the various network security functions.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-xia-i2nsf-capability-interface-im-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-xia-i2nsf-capability-interface-im-06.txt' />
</reference>



<reference anchor="I-D.xibassnez-i2nsf-capability">
<front>
<title>Information Model of NSFs Capabilities</title>

<author initials='L' surname='Xia' fullname='Liang Xia'>
    <organization />
</author>

<author initials='J' surname='Strassner' fullname='John Strassner'>
    <organization />
</author>

<author initials='C' surname='Basile' fullname='Cataldo Basile'>
    <organization />
</author>

<author initials='D' surname='Lopez' fullname='Diego Lopez'>
    <organization />
</author>

<date month='July' day='3' year='2017' />

<abstract><t>This document defines the concept of an NSF (Network Security Function) Capability, as well as its information model. Capabilities are a set of features that are available from a managed entity, and are represented as data that unambiguously characterizes an NSF. Capabilities enable management entities to determine the set offer features from available NSFs that will be used, and simplify the management of NSFs.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-xibassnez-i2nsf-capability-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-xibassnez-i2nsf-capability-02.txt' />
</reference>




    </references>


<section numbered="no" anchor="Acknowledgements" title="Acknowledgements">

</section>


  </back>

<!-- ##markdown-source:
H4sIAACqz1sAA+196W7jVrrgfz4FkfxwVSApSyc3NwYGaJeXlG7Ky1h2qjOD
gUGJR9JpU6TCQ9qlahRwH2Tm5e6TzLedjaRcS/d0B5jqpSxRZ/327RyOx+PE
NFmZ32VFVarDtKlblehtTZ9M89033/z0zXdJXi3KbAM/53W2bMZv11m5Guvv
SrMc63JZjTdVrgr4t9RNVWv47Zsfk0XWHKbqzTbZ6sMkTZtqcZge7JQ54C/V
ZpstmuhRrrbNGp78Sb7rMldl0MTsNrVamuBBVTfxExh2A32CJ7osNG4saBFP
bNq5f1ZWB0mjmwI6HJXpFPZWb7JGV2V6jltM4XvarBV8s1tNq2V6oZrHqr5P
Z2rR1rrZpWdtucBeJn12MTt7nmTzea0eDtPpOY0Az4IRkqxt1lV9mIxhsbDy
V5P0LzqDlTHIX2kAtjyp6tVh+rLNHpWGb2qT6eIwXdZZeT95o7MCW/55TT9P
YE92wJNJ+j8QY27Ik2yxVjCofTo4bM6NJoTsgVF/m6SvWzfkb5q/0VBHsJI5
/Df9ua7arR8yK2tVTh53f4al4u9APItwyOtJ+ku7yWo36nV2r8zaPaTB/6Mt
9VbVFujGD1/f32PDP/+VW0xK1diRjybpq2qtdx6sR6Uu/LP3jAzMgQ2HRn45
SV/o+n5dFW/d2C9VeR8+pdHP6qwt19USJphNb/zYAOT7yVwa/9noZrJ0LSe5
SkomwQeFXHR9dvzdt9/+JB//9O8//igfv//x336wH3/63jb44fvvvpeP//bD
v9u2P37z7bf4cTo+mWjVLMeLqlbjHfL0Yg6EmOJH/BS2gS0vqnI5BnYxi1rP
VT4uq0Yv9YL4w3AveKSGetHg29asuRl+SrTlLre1P/30w/fRwljEADw2CjFy
mHYe9Ns2qt7osiqq1c62Dh5Je+AVab7IttlcF8CzQIvQcJkt1FhvbNfBn6fn
bph5Zkyp3vYG6/XXyiTJeDxOs7lpapA1SXIDYuR9ggMlxRgmRTnjFgBCVZvG
JHPorFRJ8mim6gcNP13V1YPOVX1g0k1WZiuF0hAEp2nUJn0GosfOlBxXZVNX
RaHq58CXOY2CcqmpUoWIgcGMXdW2KvQC/uDgBlaHy4E+SSnLdw1BlTQtTO1k
2yS9WWuTgv5oaSVL+GCUSStaduIbptusbmghuVqCwDa0ICDMWpltVeYMAS+O
N04cA8MwaDc6zwuVJF+C3Iat5S1BMkmOFjAMDQB7+9vf+oTy7t2IZnMQTrYM
xjyd72BNBJdnarKajNKz16N0ejUbgfxo9Pjk5BI+wiLo268aVGa6FBQ+h+mS
LIdJNKIcyRwg2xAt2NEuzqG7g94iQAmhIZsXKq3VBpkqQOczPVETbL3Uq7YW
ZARAf54CyEEvKgBejiNlBlokX0y/w40gSZ0xSU3thr+YhBoNdr9QeQuQJ5DA
jLiTxe+trlX6oJusSJvdFrG4BC3RZGnWwHSmSR91s8ZPW7XAPjjVKMWdggDN
6o0ZwY+IC0MwW1Qtzm9GyYPOeCCNiEXgSbffW1UDuEZpJGqot3pAPY/0FZER
amPY5LbIdrjpVG+2YCRksAeALKKYMF09qDorisSB3kmUUaphU2AKYdMsbfRG
FTuCLxoJtQJpbRCTj9muN3dInytVwhRNREIL+AsT79JHVRTpXOFzldXFDkRh
LpvDDWRltQGNA7Q0V+vsQcNu4X/wSC80PgXxoQENOyCddrFG7IKdBOof+xoR
BFnTZIt7M0E5gwyIdptjrayzGVzcnn0QnyXNGlAsTGFSFAIs55A+CM1dPn/U
sENAWrqquA1yO/TVqxJW0YDiM4KqHi0CTqclyKssB1w0SMosNPIEloOkpZc7
YmbiWL9SxBHM2hKzifzYKLCscvwM6xd+EiEnu0m6w9SK6DxH/AOpgraGxoAr
gQ//kKVmASSNw+G0iVoCcWraeLZLkZxFnPZ2R0QTTph4SRZKQ+AiGI5nayLQ
aou/gqWBAHdYOOIynhTjJHYBEzjE0HoF4ppX4qRnqNjevZug0L0J1Gzy5Zfp
L2qXvkZmZ1V3D18f8Wv6xfnt7OaLEf9NLy7p8/Xpf7+dXp+e4OfZy6NXr9wH
bpHAl8vbV/I7fvI9jy/Pz08vTrjz+dFv8Aex8sXl1c308uLo1RcWiIkDYgaS
jPFKQh/AjbAmThLrBvv8TzG3/teEdnSC7KMtl+J+jWUvOy4pNwQ6qhcjDBeD
LlI8BLlbA5ouw5595wBs9SYDHQZKFZVHhaOhzNCqHkUEwwIvhcU3IEqKUNwl
Iu7Svrhjcozlp7UEPL+DzEoesqIlgg8JjWlvSIORKM8AuPB/4dbEER7sISBK
04CqASsapENO0NOG9DGgCNH0kNUk9Sp8lNQqM2gewcyyardewF4BqhZFriqq
x8Mk+Yp256YKlDGqH5C+VofCTJY7SFRotP2bWq9WCjm+Io5nRliw5kmrBYwq
4tItQVYjdtEE7cQldh2AD0hB0JJMLJ7HaGyUe+SpyuIAr3lOdJeFOHSmYuYJ
bS5cDmw5sftnTRlsBxoJvDLU1m3RsOaIxAQsADRPwXhGWAGvoBTG3rPp6Tli
gPcAzAaWX2u2rJ6go1VQLCpB9cO8bMvZ8QAO6k3TXSJyresLDAIMUVcbpzvt
CpBxW13kOFP+kJULZF2AzQ4o33il6JQnDgscDiqWjDCSjkhBGB3YIFGqHjni
ymndsMdtsasoqDDpUVSAT1wgrM5uhRZuyWJJrhT401o9IMWs9QpW+ABaUPwF
UHkNjdCAw8uQ4rVmgmLcEw5hyNACmU1WX7qEIWDzZGetgYHfwnqA0XeknqyS
ZCusWXwgtO2icTmZzi1511VFRJnhJgnaRhu2VtJqi7YO06c2plXpmBkYNq4c
jHM1b1crdArsQt4zexffADeDYgr2BishgxEFZjg77mneGrRyEFQkK0jGHhfg
qjkT0pqJPTk7DZS+FV/IwIBlaNOlEmugoKFTlWDHlQrsF5OBiQf9vXDBqWL2
Qh9g3gLrFKaStoDSFtgHRrGCDbvNichMuyGEkw3uzA4P4mqOdl9XPItRxnaP
SWI5aNgxMAgokkHguikr/q1j11RbUlSRMbzMzJpGn5KgxM0DPMAkLFinFtXi
PkV143wqixlgef7SrAE3QILgP5N4xRgkMO+AVjgCdoUNbtFnJr2WbYGagJUQ
7qbdonXPQom2iVDKd2W2CQfbAB2QGB0TvTyuNTCTh3hkzxpnAFqTtmM5G0XS
MtSCii0xkzwTrOgaGBDI8jlrE6Fl8aByL9TIrQgIPTN73Ak0iVPAlAJZR7oR
eNC5YHssdx44KRQq/xWzkQCMSIqcomDraDeCKtBgV6bYiSz0ZFVnZQuSkOjG
L5dpkgEfO+lOLZHrUSuFSAZs5BXyE0BwXgHdNz2rI1w6PAQ5kZGQI2BliYQw
yIHegTElca5371DnZgxNoBOUrAX8f8hynqQod65Vw4YUbed0A/IKrfCv0ovQ
xeQfSU7CT7elIabFUa9A3NOvM/8Io1lk5B6hm5uee1f9zBpabAJKzA5W7Qiq
5GlQtP/Xf/5vU6HLgkFhopw1UDv4aEyyIJB2CHsCFjASKALkj2UGWBuh6YeB
WtJcHIYZgTGIfImCI0GOM+uqyMl5RsfT8qIut23jLDkC84j4RL3J0MmY/Nd/
/h8kP/yZIggJo3LE36w2GbZvCSkLZHbS0RxmIt6wTscTIGP4E6M36E8CMADk
JOXylmSNRhkC4iBPcmebW5MWXaAn3CgwReYVe4ocjELv5H68BMsR6Z7WTJ5Q
uEnRhWK+WC0SEDJuEYZbwyC0HIAvw8zqXA+OCVn1FDLhOdCnA9sYmo1wPlAi
FERASRYRP7KgLhdFmysnj5LQIduHCxZGNLuJXWfHk7KzUUKLMZpjMVaTZfxV
VEUdhCeWPHi0UBagkWOqJaKUi1ZXqYu0wVey8K1oqU1HKpjxeIxBR8FBQEQB
WkexY4CmfDg9Mn2atQ0QMGAgsZosIfduj2RIbnZb1DzFDpksRsW22oJwRHBS
Ei2rc/2WiE28Z2+Mzi7Or0bJxenN8eUFmGPXpzP6hFA8rs6nQUSCNeVGN45v
wi3kGk3DgoIMgw77PuyDqCiI49GuxL0QunmGLo5qjNCw34o+WSAZ7MYxlAzW
bJ3Vi/WOvAf6OXEBTjIYLBGh7YdRqecUGpEYYBgCZFQhc6A1od5AL1hVuNc9
oSK02AJFDFBDgGH7YYSYIQUGT5hJj1YoGZ7iHuE7iU67eL+YcDhihC3YTYKG
Ia2IuTxAlDMA8ddwiS64I5Ykysl9+8n2SAnrvXdA5FDLPm3URSwfji+FOp1X
ztChUDBauWm2WtVqRRTqUBpx7AhtFGYdKznxN2wFMF2C64JEkKAhj4YgB3PF
63/EcAZaqHaSgGw6xkGul0vo5vIcnggx7gGbEWs20mqGgD7bGVgJK2bMlbE5
IU+p983xFf+M+TPkoheANBTmiV66JZFUr8oHtVM5M5a41Vpsa9Bo6b1G3YCd
rJgBmFh4ZMmcvPNgv5Ufn0QSS8dYwoIKKSPsBPariBRC1RKVf2Q12aGtjJnv
Eh7HZ6DCAKiVTbCGjRfV3OPY6S2CaUQ6SY/o2YkQ49quD70UQOKCZZNzC0CP
birYl34bWZaJs6otJVJ4HuAPpq0L0yC8TQhFikNH0SsZJgn1kJW+Vo7wBnQo
cq4dD9W2qU0gDcSRA7N708mxoPeVrDPjdSE9i4SSIBaVK9iGoHE0orljsQA4
mdMScL7EgmX7yqhwGCJVCox1eT+yDTp72decZQnZsJZsxbcWkGPHskslTwlS
zR5NS0ZrKPGSQOKFybk+U2jV0SZdIn1iUfv2z/bBXgchOfJU12TmHrcQAV2b
kBn5pysON1636JrvU9n0q4iXDSlFRiu6VYsCQzHmUFYxwowuRwkNx7+PxA9D
4x2VExAk+49u++x5dGSGxAkT1ypY6QR9lKNedxt9pDzjLsi5cZAUZwV4Jsj6
JOwCVyUwLeYKsc55zpy28HVV2zaqfNB1VZLpLp7DUDdyVvbleNmLysA/RJcK
c3BkfeNYVofmUYifN0hKJvDdJuzrsYfhM05DqRrJQ6s4ZUNafUfWazIkj8Q+
IXUCRm+Y+4S5QzIEVqZCpQDOIXzhszXo0w8x6JPQoB+WELw6Z5kRgvw3CkNZ
+ZVE8qsX6hDHcynuKIJ6zDSNgOwzyYT2GmWCyTXUGw0uJNkKMWFa5ILKX6it
hzDF7BKv+IZ3KmG9AVHBbmzWJOh9WlpHHEOXnWpEmHNoDcNIMwXE2XgXorsD
niaJeKrnZ9Kv0Lto1lW7on2xJ7ityJwgIwthxxvGChOyOuKwCgdNiXJJLAS5
+oDAcZEXnUVmiRNxWAHEQTB2akewXQ4L86KIcgf8y48Pb3wxSbqyKxbC2AWB
hFHacEJCPbnQ6M6DPwGjYaabwsIVZpEKRYmDCdZqkUz0GRaMPY5FWEd2h/Pm
kkDdjaLEBoAYCHJLAVpM4u8kR0INNxiYgk0/2NyjgpYVMHmCNgIMYJZIjBR8
I/DG67Zk6YT1EOtQQD7pC27wAqizl80wJ1Zr8bBCbeR4M/NHVPqMiiaYu+vn
idC2KErHAQMdkVeQvrHhlmVhzQEa+40MMBvOAOrIbCFIZySOL7AhxRPb9VBj
WpFNNAZLeobQ8eMyJRoMrwCnPx+RD4aD5UDc5OuIDNCmY4FJkOCDQ4FkcjO9
LcNwZ9efV8ABuYtBUYyYpbQULwAL5EpER8/WZ/uXlk3ULnTdDHCfD9/FkgxN
b7RhvZ8nYTcUqKHFSnUTYrxftfPCp1JscAvN5Szdgnho51/P6+pe1SxrRulW
qXr83Rj/wL7MWnERj4T9rf2AaqtUBfAX5jTQb87SpXr0PpuE1kBgO4hjKaE3
uGTtEvvGyjmwKinaZhNOLXD4RuFMMLG2Krljc3sQYY6r9SbHYNAJSONyCVJ4
1HGbg5KtwHwN+J/Lm8hwoAYPWUHiqSrHOSqNPCUnU9g9XKCwdk02GchI8g2o
hoAiwZiSXFjshLTgnQ3gdqyQEy8HTCRM2AtcYhs7i/xqwP6Ro7phv18KYABC
1udtA67ZwuKMcL2YRzgFGGXE7AAsjKiVC4oZoJStcxud3s9TSSft5VAdG3Qe
ynswn0SYp+CMoH8v6kksMFaCdGJQDUNy2vmM09CvuGb4kRl3Wxb6PlbYoR9a
9rwPq32ts5WTQLf0AjvcqFyjYZc1NuLAyZRS8rcNST9Wuwkoj2XLRUNBUgjn
ATcPM26Uj17s5sDBmHMsjV5M0hMSX5TCkTQxLSbhPYRlHD5K8zvgxQUJPYLB
igZ6pFoMqgLFIjHwgGRzVLDjoknGVWIFgaTUBZKGglucT51YkO8NSLWmlYAV
q6QCyc2tjYN2gc2VUHqSV9sR7dHu2CK3CfNoaQdgjK4zTHCCNDBYw2BdNvAr
DAAx2BeKGTLzaFpYlgbrzSzWIC0cCLiizNbQUH6YK3q5ZmCugBxqvyXWgbpc
A84bgmwnk8i2mlAXPFqg9VkZV0jx7GBRkGv6WNUFWvZgRZC5ffDc4c9K5DDP
Hcc7IoeZHfgFZcVE4FlzwcZnQqXjS2GskUooRJxUtgQ2hc5kJ4rnJZQ6CcP7
YTxvbzGn1PnE1OV0rI7qERKS4X4kFEiAIdJ9tq7JUoZ2ZNGhBp9EAMTXtmgC
y2JtAfbXQChLMs0l8Wfz975SFOs/UC7ueHPOCsTSFFeYAbqjRTNYElm+1Mjx
ewICkkP2hyn7Y84tqJVk21wUKEyxZ0WrQiYI6cvmzxntoUNDfi2GDqhiZlmz
G4AqCIkHBCxl8tg64ICPbNwXy7sqY64ovjq5TbMNPiN/d4fikb4Cm9XVNmxe
12GGggBoN09zicTUpa9soar4bnlsWJ8SZ8wUl852YrgEBTFuTSKW84o8AQtX
WQWHQBuOu+xjlCB3Ke4euhuD/jUVypD7Zs35jlaLlNcRmAmKC95aV8HYT4ky
wUdZEaXywAyhOAfmFSxHWBvM5gFdOFhUGxOLloCYkx3HYRQREeHCo2FmIXFF
DhkBI1gI5rpErXjBrSQPGFdaxHGbKiHKNI2tqKUVDJQjXrVFMUYfgY+TEf+w
K03eiQRI0KS1ppdUK6Px2ZmDVNoWBuSmrHw7LVjfM5XNhFETVzgSlQyTb4qY
SeeVxE1Evot7SOEECuHppdfrHpxdrLEPntU7NhQ95ki7sUgtRhQwDGx3cQVZ
VRHXW2dNfDxbAx3gixEIG1phTCdwSEn8mnXVFnkcXwfcmAqNBONLl54h2Pkk
o9dbSLiBJu6YIRS5Mb7m9hmiww1xs3ax93qx1hgGQOsmrxTFfPBER07mmZeh
pMkV56mwxsnqql6duwmLv8hA3e+bINnNx7N2bonOFblJAMEJDjo6RKFqJNG9
1O7rhKgYa1uTldnBPyXL+azYNqxHslV1TLVEa90IPZiVGnZDHi3aS1woWah9
KxK2iarBAlfOlWhypAOPFDprtSpUQlELcVfjsjqXpBgQMGE8AsWFHPKhEO1X
6ekben5mNdZhKEUH1m4tfWe0g2XZbr3pgU1DeRBwepfvpLTZyZEEhLSuciZZ
pkqnSCXKVHE9KcVBUA7ZoAStQDcmMfqtlBxyCSCrPvTEpAowcJK9p8Qrw26F
WpLWIaKmfJqLhTuQHbXQmeKkFNkWiS1BwYxFExFs1C6VU3BJR/vtr4vjZGE/
vW0hSOsssWDQJoWEu+PsHlezUSA9Z3tl0tkCio5kACCktdGztJ5aN91OYV8M
z9C5YP1WYEQZU4GHKzSNktp0eIlpBAnK7AMBKKzOngF9VOmBnTpn1rja673i
LLXi7BFAQIIXIzVOsnWw5uMQgSNOZIB1uOObOisNnpQVifU083h9iatrpeIN
oFhyEGRMPhzna8SXUSaAPjCIQU1dUmFkaSMndQIwUBkWiUghwWBDst9CQcgT
xYG9DrxjS8bVxUmiwIU3OmI3MJccqORcOg5BSXYuGA9Oq59IOPW8Ctkqo40X
FWmOBqHNCWoOAJmNcT7H9GqU3p7APzfHV2GBBsdGYI+gSVs8LRqzNJ1lCXIG
gZVjR2Zvx1hzVgz06dXZ9C+cjcBzylSRkVyo5gwj+Zyk+OmH7zE56gmyr1Lx
RIKdm+OoLDvSFUbTZR2qsQXc7TYV6ZT0JBNGdwI83JD1xPlVH6s954NmVEAe
5wA3lYnDsWx+ScgTcyclfJQsIxk8gf/QPVAZuVHR0UoU++K+2qSJ2CzUR/SV
5AVBLFQNsJQrzclCXw2PsIm3Hy2O9tVZ4SS59KmqmuSRiyaTsJcZH8kGs1Ux
OCGoEGJL64wtZXPtFjEIm5DEDC/f+8COWpAI53jq1NVVw7hW1/lIn83WWsqO
Qpu/HV38TDF7zBnbg+lYtQropd9m7rR7J/Mk7TGDgu3zHP0zTrwVOym8EKKP
bN+EhiXmkbp8x/aEDExLj11sJgoejHD7lLZG5glMKxKlSNIYFTPucGzK4gvL
3kEG2pRwnUb2QNLLsBGa+6cJO6Wb1vLxCUXDiV0MY7hYL8wWhn7jZfW8fcRo
ELJHBEUWpMPhBCsuXBZyqBQ/PHnXlaS8H4sy4VbUcWRsco2x5f30BRWvD18E
cgSoGDqpBxZVkYWzZ3M5YyRVcSRE6Rzno8KMrhWNiTd1o8MwYerdhbwn6Zmu
TSOlnGgqtRjRVQnlAsS/6mdFiSsDu2CDdsQKV2dLHfi0smRoVbE1PjOIiQqy
dvgILqbVmAIk1541djyptiCHSdxgOpJlPWFpdveAKhX10pSPQHMCW55aPWiP
+mwyl7PCSzuax2qc65VuKHu3gd2WuEo8JGePSNGGvvk2nBHlrxTNjACFqqY/
IENH6atqNbIxHgqZYT80ee9gwM22s0jyhdHaYWdZ4Ahrc+FC7A7z5FV9xxeD
oCTCT+ExS26ATeFbtx3W2U6vnoftrUcgBrvMi/2BMttCBUNs6IHM2Dbbthnq
NhMH22+P86suD01fqlVUn9lUeA2AwqgBYILPi4wE3CgffmT9bAArhQSJLHLk
eCepEv4Jb+GxXr7m81qnb0TWDLNej+3IOBYOS8l35E0Eef3ICTCmWmiSMq4G
SKKvAhneLR2ToHUMSkTKUco56ySQ2pGdQwoarcQdCsNOI22C05+4lISPy/Sn
w7kkCT3jlRLVJslxHC7m8j5vm9yx/XMYyVJsYyNbwhFOR+BvOZC7woO78mMJ
nGYf4RK+BItnU4F/LmsgrxK87Oqxa6P78It403KAnvvz8Q9aMikHId6D89Pz
u9vZ0c+nd0evjq7PD4iBQ/KOOJEjjkTr7EZxRIePXUb8ogUdOF6LaD504Bd6
cebIhjdINw+gGLAHaJi13FdbL2cZyw1vHFsRI1j6Fn6iZt6oER9zREwxglVj
GKAFkQQQDYQXQIaNGVkaChysblKklcNlHXBi8sv0+Or205HkOvcxBD/1MCQQ
ne2BKI72seCkOf8fg5PX9QGwPNHm/tOB6Xv3oXkynf3yseDMcTyzxSTHHxGq
tLwPAuvLrM4fUal8MmjtCPvEycvXd2dH01e31yF43XmrIZHy8rX//WOEyh9J
TER7wIiLHBfHPLFa1RmAz+HAX/jxyUhwQ+zDwvTs4vTmbnZzdBOiwaXq7i56
NpK/kSlqSPWqMODt1cEIeOfy9QX+Pb68+Pl0dnN6cvBHYoVjKswNKoC42lYA
b1W5rST/Z+hyaFWrrWq01LYj+rmkJ/3V3vjw8fgnNiBg9hF/dHx8OpvdnZxe
TAU7mMk+TC8yWxCO3/H5Ci8MPOR7A9GMlJJtznyj91CuDLajeqU7vb0TN+4Q
bXcsG75yjl00bhx+vEOL6hDvXemFk/GXScq3c72q+KaBOKw7wqMrdT6+ogzb
jEsQO016ncCeVVwUMUpns8vOrzHFyKEWvNMpYNDjsGQ7PRbs/iOxhOcRpz/f
Hb88Aj76jKX3YCnGByyITPgOW8N2/+U8DWswdAkefqGLNjhOGF+HYw4YWyjB
VuAr8hESV7pgEsmY8UHOSfpix0Vkb0WOboJ77B4wNVT7VJlk/iRyoG0x5kfQ
beIWgmUmVc3UexRu4DD+KlUU1M3n+3j1w6QZEGXrz2DFdwYBrUNHulXWD8Jk
2rHSom4Edc1kS1QLI+B9KiNH+W5/gk+Ej98zpYFdnXY0Nt4j+gYA36iR8EMH
jZ2jHhLU4EjsISZdN3wzB47B8MVf2D6iNNRheukWAh8QU3ugky2ByDEagCuY
WMF1rSRBcNsAQXAyS4jyui1Lrg7gqm4hTI8pyREcwE/S1FY4cXRJmzSoW5Q+
8e2T76WzJJSPdbQiojJewh1PzJhZiE7fszrshe7RoP3unA0WJ+jIDTcMnTxi
ebCnh1t6S9u1w4RrjyZdcDHwHCgzS9YPy5qy3cxR6AddKdIDxOB2zU1pm1JS
sbcbPw8OiKfByUey6e6kdu2uJpuObDXqqss5eDpor3FtG/5OIf4t9QTi3tsV
fnuybzAreP8qf2paaoB95/15e517E9vesG/qzyxBKu3IXn7EvHAb1PbJhUj2
0G23oAyFBsjrim62duW/z6xxyrXcGJ0cSZuv8UoezNDnTg5QVl6UcSJyTxl/
Fay9eIrmsnw/SeNVWr5FzwsjxciIeMZWQsT+4JXBmZFByELgeeloiKtTRJJI
fGnj5LP5MWR+MJyilbFeD1d0dXUF/X+9gLVdHh+9IqIlMriz6AeRzrRjHzC0
iEaCRq86VENuFamn27gQ1c48a2k1SAbU4hWrojNyO2G7DH4sR4dtghC3jUhR
dTtfZcbghZFi6yK4eKDhn+1gtGT5dlviprCwFTrflvdl9UiboNNqoPzciSnr
GYcFtrvQkLOFn59mzaHHjWc9dgNmnc/GDcddS9Xz0BduMf1ne4WGlUj0hWy7
tkm4WnOUzuHBo86bNauRSexus39w0SutJS/d3XJGQhITRyJgUSA6Sbm9xzv5
byIJC/rnXjVeqO7t4KRq0KM3A5by9qagh8MTRO3dDK4DjI/1wE9ugAqGO7vY
28lN0e3VnWlwI9Qp2s3+PvFM4Y5s8+xBic6cdrRdxpeFPaEwtyq739MZf3qi
J84qGnPftF112Z95zwA09VOq2m/5squjO3tGE6XfP9h2b4ChfXfnlnXvnby/
897s+4aI9s797bEkfyTun5UmcuLq5KSaSUnvp8TKXe9+nGJ2enx3+uvpxc0d
tqJABaz5jm+8loVgsg0v8QYBN9uV6bKoqnyUHh3/Yj/OfrsYw1cAlzw4m158
fT27sV/x3pdjXwwmT29PruzH6WKz9b1f3txczcIv9vPJxYxFf/igxjtFfefZ
1DUnX0yu6sxNA8YLm5ddkwUcnabdpEAGqLBo57YLOS58xBYLNNgCN4H72OAL
CO49BeoN3dnKpcKUOb9D41HsWkxyU/Y7tZeUAwpd1lumTrkfJyFUmX/sACnl
WCfpdIlpff/YXf1GG11Vrquxp87kZGvGCXy65BngqlWR+9LaLd2U85UMGngL
V4AzBCdPJgAJWgrH4QTAVMNN8QjmnRYvYHpi48X4WK6mcBfvuubDxQD7uoBG
x6Nph/4tEfJEcCp4pJNZ9hgHWi5yYOSGXL5P5sRomGQvS85m08sLyWC9nP78
kjMs7DHKVp0ruMeX3GRvpGwhe6M3QN2B8yjNPBXLk7ShZaWEbKlJ+qTof5w5
6c3M80SJLKLUbiqLXwHxycCm7j0gX3Tl3q/T61sWfA/YwcaMdu5WRX5uI0JN
Xf01AzsczDfgkU22qPHqY14qdvUDITq7oienOnNedyyGcCI2ZJApqV5a0bXR
ODDd2w9sS0KlXrjhJBj0/pF4HIy1dUbyAk7GIjn35Ch8obcbJRaT4QbfP9TA
gt7Sm7OCBblI6FvRQR8MKVyZHy5c2XvHFMnZHxNFRRBWbAIyISnSh1W6xgJJ
GBALUjjUSYMMy60PH4SJDBmBR5nXWlGSz72thepACcwoK7PHoHF8awJVZVou
FjB43hZYEPtM/tBSGl9V05KE+WShwUOQuTYsnsMtcO4nFCZuBXssKdF48MXK
k3ndop9BLwnC08N4sBvfcgWm7FLynx/B8Z8ibyJR0JUEXnj3J3mC6/d1+1gO
/2Q2FirCd+MV3NHeD5P6Cv0i28EibTPBCBirFOE4uSLjZbvtdA+KWocHQIuV
Aiw3V39EbpFwBJOpiIQZX7PDkmBrZYdr9Q+VH8yqL6qmhFafzKfcfw+PNk/y
KHclBp3Txz3g5suG+Axn6cn3n8WJPaX8mRX/blasClk6vdBFVomvuWxL60zZ
E8esaMW2YAoAOkvhP99OQjqnKt231WauVbrG4ylyvQrLfYyFS5+bTp+wke0U
jPNkv+n18devT1+kcmfTR/YeWG084Eet+SO6Di/7gyA1sGZ02/UmCfj4KWH2
wjHxH1Eg/4Ol62s1t7bGJ0tYP8aeErSnpSx0597DltAxuK01WtswS9a3iszv
BRUG/NUe81hIbj149JfZbJQez67PPkvmv0My1+p3F62keAEf8IuPWk3SM7qc
0tBNAKP04Or25iClgomDn0/hI1AMylo7YFuDpL/mY9WYY7qmxBk8vcOa0FVV
4xluon76MbVPxTlqiLKFUvB39ywikhcF7ALPw6CIf42naOkLpavGJ/ZM4BUw
pf187l77dywzdpJZfzTZEMaeObX9ryqAoiAyL8G/XExxdJBvqC+5zZGNHu4R
OMmTYWqc4TCIGvKC8Kfgoc8/INRt1H+7dUwbRxat08ySklP8io/fdwYNahDs
qPN9ozpn/MlRt/cN1nNEUTsZR9JWQ6PgUuNxnpRvaiCcanwA2B9Rppdw+aL3
cATCGAgmje8bsvc74UuYnZCqpfaIbkr0L4H1d5HVcvPNV1LwcGhvTU6zFR7w
bxjF8jZNy8VHSCP28BhM+ALTzCO6tSKrMcavFrBuNeIfxnprP8nbOSdxuPA9
JMqNPplG/Rx9Iv3VhlpiY3efjRuZtKHk2G/VUjAW6MIE2QA8u8C3ooqF4CI+
FglEzYIIvP2S4v72Ot8otplZHNBrpyhvJlNdzny0mGNS9FLSjO6Z993pCpq8
rnSOo+gKRgbL+s0IWpd59Wj6gZr3oMs3HEJZ8uERHTtXH23T0MvtQNdEbrCR
O3b9WdQBfh2CmBthH9QwZSRwG4TaByLTr9QOTv9ibUzIZB/AYpYPLZP1Mj4X
t+dsSOxL5cRZH9t8T+Ynigm8hySk1SezcDBLnxi8lyAuhZXfgfiOTCjDZ33x
ZrLaeSv4Qr1+8OCDUOj6yfCfjsIYgTiClKsOUaggJNP8aryPYGn7NkSxEq6m
gj/7ydXQ0PW0hm/kKNMWXPjMviICxinlK98biReO8VVnxl6tC6ymNF6HjpfF
FHIrPwksfk8hvSjPv+MjAccCX5ZDd+ocmDSoqCtUVpcp2E/3O1vlxvfI8U0U
j+udLaHDo/l4/htMUArC0yR85idDbNgDr3QHjaKri/gaxMTWdiEU5BYRuqrC
FnedocH3whZU8b0iZ9bIJWwHSuCFvedOrl8aSCGQAWkTTp0cBRuXkpryvsVs
n1/hedg7FSdPOhS+Bw6P9zchncsE/NVyTWd02zYcf28HawPNBv27uB2XO1Lh
2uO6cqfITXcBON7JfgcwHpR9uVknURYPyG1OhtJgvqG3EK7kk88kBSIUrYOQ
EAba8PtlyWWZxe+cTXW+N9wgvZh+uv3IFtnXM7bsujdDEKnNhazJHuQLV6mM
wLpw/Bh5KNiau8tR3gLL/hO9GSDdm+/51Z2NoNK82SLjynGWQL8GJyfoJa78
Y3hqw4eROLJEEYbGJHQFPd4VHA3Re72EqBi+TWip32DVBYr/jztEpMICeV4N
kWU/FhEulet01xnmUDtnRGiccOXOo+3sJ++3pMsHhhrTD1Z8uYN6Os8RmZKo
upxFhy2whp8rPvvrJ5Zi1WTPCNIXv69gfoF+GPVL3Sixtb0N+ckuF+PINoo8
WNEzALHBYJy7mbYDdAlcvLkzLXj6xut5eJb6Zy5yGXYdCtq9xwQKWn6yWRyM
ce3JLzKGggggxjrM9m5BtdLXfIIXI+e5siGfRaHxnifr0PDXkMVdw6q612hk
H/MH+xzxKdErvkAmiqa4WJJF+z80YpryfWL/8rLkM12rR3zbr69K7j16b1Ey
3v6e0f3ao6RTi8xWE94lx4kPV23sX2eMtpTtlLjXK9M9+3OlSsao3Jn22Zj4
bEz8PcYEHiixBfC+DNnXxMerwxreoLkr3d3XPipRt/XcdhUPVdFu5CT851Lu
/89Kub+0d3W/1E0g9gcehoai6ZB2SNWJULW1IMFCalhi052uWFAJP2MR7tJ2
j86S8rEvurl00XyWrZ9l698tW4EA74JoJtIjRzSDqt94OEvCbN76i7RkcLnS
fnp0cURXr+L11vb+xi/x6Tu5OMzf1km3Q5fugmVKOUBDfu8evbfn+uw4Pc01
HTlvwlvH5GreWm2qB76vfhu8Jonu6E+gsyzKQaa3MPvLO/uewcG7b/noVny7
uY3f7TywkENdrQhejcavWKL3ZMstx8j74T3G1qZCJbWq6Y0/U7zRV961Cc3Y
eLeXOzukLPxV23zHcUFOJoA0twe2C5WR84n1/AbMRKqq5iPneNf6ROEBdhCC
2cq+fuAgeGdZEr5KIboZkyZhgMjJgGVWmN4NumDj4gqSgSXLa+NbemtQ57wn
3plhDENH3uTJoE5slih62xF7JJPoqDhdF00XXzp4JTDGml4RhObqM978zavZ
KD2hf6dXs9PjUfqXyQ/f/JRe/TJ9Hpxo4NfG0a3DNV8X3nlLr79zUl7hYV+R
wjd+2mvxiA5ytVQYmXR7UWHWi09LyusI5MZgALRxkN5k9I66/ZdNx6zrQT6i
27FJ2xZ6w+8d4Rfo0Rsdw8uIHZXHr2kQEhzCJ1KcIopF3zF/4Dda1OlfW+Pe
r2jfyAo4o3StIC5JxuMxuBToROI1GphqL1S+kqtF//Zl99G75G+H4par/L99
UVZfvEv+L7r2AEZamQAA

-->

</rfc>

