Subject: [IPFIX] WGLC comments on draft-ietf-ipfix-configuration-model-04

From: Atsushi Kobayashi <[email-masked]>
Date: Thu, 10 Dec 2009 16:49:27 +0900

Dear Gerhard, Benoit, and Paul,

I would like to show the respect for your great effort for writing this
document. This document contains all of parameters and statistics with
regard to IPFIX and PSAMP specification. Thus, it needs hard review even
if except for section 6.

I put my comments and questions in inline, please see it.

> 
> 
> 
> IP Flow Information Export WG                                   G. Muenz
> Internet-Draft                                               TU Muenchen
> Intended status: Standards Track                               B. Claise
> Expires: April 26, 2010                                        P. Aitken
>                                                      Cisco Systems, Inc.
>                                                         October 23, 2009
> 
> 
>               Configuration Data Model for IPFIX and PSAMP
>                <draft-ietf-ipfix-configuration-model-04>
> 
> Status of this Memo
> 
>    This Internet-Draft is submitted to IETF in full conformance with the
>    provisions of BCP 78 and BCP 79.  This document may contain material
>    from IETF Documents or IETF Contributions published or made publicly
>    available before November 10, 2008.  The person(s) controlling the
>    copyright in some of this material may not have granted the IETF
>    Trust the right to allow modifications of such material outside the
>    IETF Standards Process.  Without obtaining an adequate license from
>    the person(s) controlling the copyright in such materials, this
>    document may not be modified outside the IETF Standards Process, and
>    derivative works of it may not be created outside the IETF Standards
>    Process, except to format it for publication as an RFC or to
>    translate it into languages other than English.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
> 
>    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."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on April 26, 2010.
> 
> Copyright Notice
> 
>    Copyright (c) 2009 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 in effect on the date of
>    publication of this document (http://trustee.ietf.org/license-info).
>    Please review these documents carefully, as they describe your rights
>    and restrictions with respect to this document.
> 
> Abstract
> 
>    This document specifies a data model for the configuration of
>    selection processes, caches, exporting processes, and collecting

Why do you capitalize the first letter of above terms?

>    processes of IPFIX and PSAMP compliant monitoring devices using UML
>    (Unified Modeling Language) class diagrams.  The configuration data
>    is encoded in Extensible Markup Language (XML).  The structure of the
>    data model is specified in a YANG module to ensure compatibility with
>    the NETCONF protocol.
> 
> 
> Table of Contents
> 
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
>      1.1.  IPFIX Documents Overview . . . . . . . . . . . . . . . . .  6
>      1.2.  PSAMP Documents Overview . . . . . . . . . . . . . . . . .  6
> 
>    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
> 
>    3.  Structure of the Configuration Data Model  . . . . . . . . . .  8
>      3.1.  UML Representation . . . . . . . . . . . . . . . . . . . . 10
>      3.2.  Exporter Configuration . . . . . . . . . . . . . . . . . . 15
>      3.3.  Collector Configuration  . . . . . . . . . . . . . . . . . 17
> 
>    4.  Configuration Parameters . . . . . . . . . . . . . . . . . . . 18
>      4.1.  ObservationPoint Class . . . . . . . . . . . . . . . . . . 18
>      4.2.  SelectionProcess Class . . . . . . . . . . . . . . . . . . 19
>        4.2.1.  Selector Class . . . . . . . . . . . . . . . . . . . . 20
>        4.2.2.  Sampler Classes  . . . . . . . . . . . . . . . . . . . 21
>        4.2.3.  Filter Classes . . . . . . . . . . . . . . . . . . . . 22
>      4.3.  Cache Class  . . . . . . . . . . . . . . . . . . . . . . . 23
>        4.3.1.  CacheLayout Class  . . . . . . . . . . . . . . . . . . 25
>      4.4.  ExportingProcess Class . . . . . . . . . . . . . . . . . . 26
>        4.4.1.  Destination Class  . . . . . . . . . . . . . . . . . . 27
>        4.4.2.  FileWriter Class . . . . . . . . . . . . . . . . . . . 29
>        4.4.3.  Options Class  . . . . . . . . . . . . . . . . . . . . 30
>      4.5.  CollectingProcess Class  . . . . . . . . . . . . . . . . . 31
>        4.5.1.  Receiver Class . . . . . . . . . . . . . . . . . . . . 32
>        4.5.2.  FileReader Class . . . . . . . . . . . . . . . . . . . 33
>      4.6.  Transport Layer Security Class . . . . . . . . . . . . . . 33
>      4.7.  Transport Session Class  . . . . . . . . . . . . . . . . . 37
>        4.7.1.  Template Class . . . . . . . . . . . . . . . . . . . . 38
> 
>    5.  Adaptation to Device Capabilities  . . . . . . . . . . . . . . 39
> 
>    6.  YANG Module of the IPFIX/PSAMP Configuration Data Model  . . . 40
> 
>    7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
>      7.1.  PSAMP Device . . . . . . . . . . . . . . . . . . . . . . . 78
>      7.2.  IPFIX Device . . . . . . . . . . . . . . . . . . . . . . . 81
>      7.3.  Export of Flow Records and Packet Reports  . . . . . . . . 84
>      7.4.  Collector and File Writer  . . . . . . . . . . . . . . . . 89
>      7.5.  Deviations . . . . . . . . . . . . . . . . . . . . . . . . 89
> 
>    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 90
> 
>    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 90
> 
>    Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 91
> 
> 
>    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
>      10.1. Normative References . . . . . . . . . . . . . . . . . . . 91
>      10.2. Informative References . . . . . . . . . . . . . . . . . . 91
> 
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
> 
> 
> 1.  Introduction
> 
>    IPFIX and PSAMP compliant Monitoring Devices (routers, switches,
>    monitoring probes, Collectors etc.) offer various configuration
>    possibilities that allow adapting network monitoring to the goals and
>    purposes of the application, such as accounting and charging, traffic
>    analysis, performance monitoring, security monitoring.  The use of a
>    common vendor-independent configuration data model for IPFIX and
>    PSAMP compliant Monitoring Devices facilitates network management and
>    configuration, especially if Monitoring Devices of different
>    implementers and/or manufacturers are deployed simultaneously.  On
>    the one hand, a vendor-independent configuration data model helps
>    storing and managing the configuration data of Monitoring Devices in
>    a consistent format.  On the other hand, it can be used for local and
>    remote configuration of Monitoring Devices.  However, this requires
>    that Monitoring Devices natively support the configuration data
>    model, or that a mapping between the configuration data model and the
>    device-specific representation of configuration data is provided.
> 

I want to confirm the meaning of "mapping" in last sentence.
If a vender deploy the different configuration model at first, does it
need to replace them with the common configuration data?

>    The purpose of this document is the specification of a vendor-
>    independent configuration data model that covers the commonly
>    available configuration parameters of Selection Processes, Caches,
>    Exporting Processes, and Collecting Processes.  The configuration
>    data model is defined using UML (Unified Modeling Language) class
>    diagrams [UML] while the actual configuration data is encoded in
>    Extensible Markup Language (XML) [W3C.REC-xml-20040204].  An XML
>    document conforming to the configuration data model contains the
>    configuration data of one Monitoring Device.  In order to ensure
>    compatibility with the NETCONF protocol [RFC4741], YANG
>    [I-D.ietf-netmod-yang] is used as the modeling language.  If
>    required, the YANG specification of the configuration data model can
>    be converted into XML Schema language [W3C.REC-xmlschema-0-20041028]
>    using the pyang tool [YANG-WEB].  YANG provides mechanisms to adapt
>    the configuration data model to device-specific constraints and to
>    augment the model with additional device-specific or vendor-specific
>    parameters.
> 
>    For the configuration of remote Monitoring Devices, an appropriate
>    protocol is needed to transfer the XML encoded configuration data.
>    The configuration data model is compatible with the NETCONF protocol
>    [RFC4741].  However, alternative protocols, such as the Simple Object
>    Access Protocol (SOAP) [W3C.REC-soap12-part1-20070427], are also
>    suitable for transferring XML data from a network management system
>    to a Monitoring Device.
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
> 
> 
> 1.1.  IPFIX Documents Overview
> 
>    The IPFIX protocol [RFC5101] provides network administrators with
>    access to IP Flow information.  The architecture for the export of
>    measured IP Flow information out of an IPFIX Exporting Process to a
>    Collecting Process is defined in [RFC5470], per the requirements
>    defined in [RFC3917].  The IPFIX protocol [RFC5101] specifies how
>    IPFIX Data Records and Templates are carried via a number of
>    transport protocols from IPFIX Exporting Processes to IPFIX
>    Collecting Process.  IPFIX has a formal description of IPFIX
>    Information Elements, their name, type and additional semantic
>    information, as specified in [RFC5102].  [I-D.ietf-ipfix-mib]
>    specifies the IPFIX Management Information Base (IPFIX MIB).
>    Finally, [RFC5472] describes what type of applications can use the
>    IPFIX protocol and how they can use the information provided.  It
>    furthermore shows how the IPFIX framework relates to other
>    architectures and frameworks.  The storage of IPFIX Messages in a
>    file is specified in [I-D.ietf-ipfix-file].
> 
> 1.2.  PSAMP Documents Overview
> 
>    The framework for packet selection and reporting [RFC5474] enables
>    network elements to select subsets of packets by statistical and
>    other methods, and to export a stream of reports on the selected
>    packets to a Collector.  The set of packet selection techniques
>    (Sampling, Filtering, and hashing) standardized by PSAMP are
>    described in [RFC5475].  The PSAMP protocol [RFC5476] specifies the
>    export of packet information from a PSAMP Exporting Process to a
>    PSAMP Collector.  Instead of exporting PSAMP Packet Reports, the
>    stream of selected packets may also serve as input to the generation
>    of IPFIX Flow Records.  Like IPFIX, PSAMP has a formal description of
>    its Information Elements, their name, type and additional semantic
>    information.  The PSAMP information model is defined in [RFC5477].
>    [I-D.ietf-psamp-mib] describes the PSAMP Management Information Base
>    (PSAMP MIB).
> 
> 
> 2.  Terminology
> 
>    This document adopts the terminologies used in [RFC5101],
>    [I-D.ietf-ipfix-file], and [RFC5476].  As in these documents, all
>    specific terms have the first letter of a word capitalized when used
>    in this document.  The following listing indicates in which
>    references the definitions of those terms that are commonly used
>    throughout this document can be found:
> 
>    o  Definitions adopted from [RFC5101]:
>       *  Collection Process
>       *  Collector
>       *  Data Record
>       *  Exporter
>       *  Flow Record
>       *  Information Element
>       *  IPFIX Device
>       *  IPFIX Message
>       *  Observation Domain
>       *  Observation Point
>       *  (Options) Template
> 
>    o  Definitions adopted from [I-D.ietf-ipfix-file]:
>       *  File Reader
>       *  File Writer
> 
>    o  Definitions adopted from [RFC5476]:
>       *  Filtering
>       *  Observed Packet Stream
>       *  Packet Report
>       *  PSAMP Device
>       *  Sampling
>       *  Selection Process
>       *  Selection Sequence
>       *  Selection Sequence Report Interpretation
>       *  Selector, Primitive Selector, Composite Selector
> 
>    The terms Metering Process and Exporting Process have different
>    definitions in [RFC5101] and [RFC5476].  In the scope of this
>    document, these terms are used according to the following definitions
>    which cover the deployment in both PSAMP Devices and IPFIX Devices:
> 
>    Metering Process:  The Metering Process generates IPFIX Flow Records
>       or PSAMP Packet Reports, depending on its deployment as part of an
>       IPFIX Device or PSAMP Device.  Inputs to the process are packets
>       observed at one or multiple Observation Points belonging to a
>       single Observation Domain, as well as characteristics describing
>       the packet treatment at these Observation Points.  The function of
>       the Metering Process is split into two types of functional blocks:
>       Selection Processes and Caches.
> 
>    Exporting Process:  Depending on its deployment as part of an IPFIX
>       Device or PSAMP Device, the Exporting Process sends IPFIX Flow
>       Records or PSAMP Packet Reports to one or more Collecting
>       Processes.  The IPFIX Flow Records or PSAMP Packet Reports are
>       generated by one or more Metering Processes.
> 
> 
>    In addition to the existing IPFIX and PSAMP terminology, the
>    following terms are defined:
> 
>    Cache:  The Cache is a functional block in a Metering Process which
>       maintains IPFIX Flow Records or PSAMP Packet Reports.  According
>       to [RFC5101], the maintenance of Flow Records may include creating
>       new records, updating existing ones, computing Flow statistics,
>       deriving further Flow properties, detecting Flow expiration,
>       passing Flow Records to the Exporting Process, and deleting Flow
>       Records.  The maintenance of Packet Reports covers the same set of
>       functions.

In the case of PSAMP Packet Reports, how is the Cache used in Metering
Process? Is a PSAMP Packet Report maintained in Cache until deriving
further properties? It seems an implementation matter.

> 
>    Cache Layout:  The Cache Layout defines the superset of fields that
>       are included in the Packet Reports or Flow Records maintained by
>       the Cache.  The fields are specified by the corresponding
>       Information Elements.  In general, the largest possible subset of
>       the specified fields is derived for every Packet Report or Flow
>       Record.  More specific rules about which fields must be included
>       are given in Section 4.3.1.
> 
>    Cache Mode:  The Cache Mode specifies whether Packet Reports or Flow
>       Records are generated by the Cache.  In the case of Flow Records,
>       it also specifies the Flow expiration policy.
> 
>    Monitoring Device:  A Monitoring Device implements at least one of
>       the functional blocks specified in the context of IPFIX or PSAMP.
>       In particular, the term Monitoring Device encompasses Exporters,
>       Collectors, IPFIX Devices, and PSAMP Devices.
> 
>    Selected Packet Stream:  The Selected Packet Stream is the set of all
>       packets selected by a Selection Process.
> 
> 
> 3.  Structure of the Configuration Data Model
> 
>    The IPFIX reference model in [RFC5470] describes Metering Processes,
>    Exporting Processes, and Collecting Processes as functional blocks of
>    IPFIX Devices.  The PSAMP framework [RFC5474] provides the
>    corresponding information for PSAMP Devices and introduces Selection
>    Processes as functional blocks within Metering Processes.  In
>    Section 2 of the document, the Cache is defined as another functional
>    block within Metering Processes.  Further explanations about the
>    relationship between Selection Processes and Caches are given later
>    on in this section.  IPFIX File Reader and File Writer are defined as
>    specific kinds of Exporting and Collecting Processes in
>    [I-D.ietf-ipfix-file].
> 
>    Monitoring Device implementations usually maintain the separation of
>    various functional blocks although they do not necessarily implement
>    all of them.  Furthermore, they provide various configuration
>    possibilities; some of them are specified as mandatory by the IPFIX
>    protocol [RFC5101] or PSAMP protocol [RFC5476].  The configuration
>    data model enables the setting of commonly available configuration
>    parameters for Selection Processes, Caches, Exporting Processes, and
>    Collecting Processes.  In addition, it allows specifying the
>    composition of functional blocks within a Monitoring Device
>    configuration and their linkage with Observation Points.
> 
>    In a Monitoring Device implementation, the functionality of the
>    Metering Process is commonly split into packet Sampling and Filtering
>    functions performed by Selection Processes, and the maintenance of
>    Flow Records and Packet Reports performed by Caches.  Figure 1
>    illustrates this separation with the example of a basic Metering
>    Process consisting of one Selection Process and one Cache.
> 
>                +-----------------------------------+
>                | Metering Process                  |
>                | +-----------+ Selected            |
>       Observed | | Selection | Packet    +-------+ |  Stream of
>       Packet  -->| Process   |---------->| Cache |--> Flow Records or
>       Stream   | +-----------+ Stream    +-------+ |  Packet Reports
>                +-----------------------------------+
> 
>      Figure 1: Selection Process and Cache forming a Metering Process
> 
>    The configuration data model adopts the separation of Selection
>    Processes and Caches in order to support the flexible configuration
>    and combination of these functional blocks.  As defined in [RFC5476],
>    the Selection Process takes the Observed Packet Stream as its input
>    and selects a subset of that stream as its output (Selected Packet
>    Stream).  The action of the Selection Process on a single packet of
>    its input is defined by a Primitive Selector or a Composite Selector.
>    The Cache generates Flow Records or Packet Reports from the Selected
>    Packet Stream, depending on the configured Cache Mode.
> 
>    The Observed Packet Stream at the input of a Selection Process MUST
>    only contain packets originating from a single Observation Domain.
>    Similarly, the Selected Packet Stream at the input of a Cache MUST
>    only contain packets originating from a single Observation Domain.
>    Packets from Observation Points belonging to different Observation
>    Domains MUST NOT enter the same Selection Process or the same Cache.
> 

Observed packets at different Observation Domain can be input into different
Metering Process. Thus, they can not enter the same Metering Process.
I think that the above sentence is already clear in existing IPFIX
documents. Or it means other something?

>    Beyond the basic Metering Process shown in Figure 1, the
>    configuration data model enables the specification of more complex
>    configurations.  A single Cache may process the output of multiple
>    Selection Processes.  The Selected Packet Stream may be copied to

I cannot image that a single cache process the output from multiple Selection
Process. This sentence seems cause the inconsistency to the
definition of Observation Domain, when a Metering Process consisting of
a sequence of Selection Processes and Cahce.

And I have another question. Are Selection Processes after Cahce
available as an IPFIX Mediation? 

>    enter several Caches, for example one Cache that generates Flow
>    Records and another Cache that generates Packet Reports.  Selection
>    Processes can also be cascaded, such that the Selected Packet Stream
>    at the output of one Selection Process is passed to another Selection
>    Process.  Cascading Selection Processes can be useful in specific
>    contexts such as the example in Section 7.3.
> 
>    The selection of parameters in the configuration data model is based
>    on configuration issues discussed in the IPFIX and PSAMP documents
>    [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475].
>    Furthermore, the structure and content of the IPFIX MIB module
>    [I-D.ietf-ipfix-mib] and the PSAMP MIB module [I-D.ietf-psamp-mib]
>    have been taken into consideration.  Consistency between the
>    configuration data model and the IPFIX and PSAMP MIB modules is an
>    intended goal.  Therefore, parameters in the configuration data model
>    are named according to corresponding managed objects.  Certain IPFIX
>    MIB objects containing state data have been adopted as state
>    parameters in the configuration data model.  State parameters cannot
>    be configured, yet their values can be queried from the Monitoring
>    Device.

They can be queried from other devices as well as Monitoring Device.

> 
>    The next section explains how UML class diagrams are deployed to
>    illustrate the structure of the configuration data model.
>    Thereafter, Section 3.2 and Section 3.3 explain the class diagrams
>    for the configuration of Exporters and Collectors, respectively.
>    Each of the presented classes contains specific configuration
>    parameters which are specified in Section 4.  The formal definition
>    of the configuration data model in YANG is given in Section 6.
>    Section 7 illustrates the usage of the model with example
>    configurations in XML.  Section 5 gives a short introduction to YANG
>    concepts that allow adapting the configuration data model to the
>    capabilities of a device.
> 
> 3.1.  UML Representation
> 
>    We use UML class diagrams [UML] to explain the structure of the
>    configuration data model.  The attributes of the classes are the
>    configuration or state parameters of the Monitoring Device.
> 
>     +------------------------------------------------+
>     | Destination                                    |
>     +------------------------------------------------+
>     | name                                           |<>-----+
>     | exportMemberType = parallel                    |       | 0..1
>     | ipfixVersion = 10                              |       |
>     | transportProtocol                              |   +------------+
>     | destinationIpAddress                           |   | Transport- |
>     | destinationPort = 4739|4740                    |   | Layer-     |
>     | sendBufferSize {opt.}                          |   | Security   |
>     | rateLimit[0..1]                                |   +------------+
>     | localIpAddress[0..*] {SCTP only}               |
>     | timedReliability = 0 {SCTP only}               |
>     | numberOfStreams {opt.} {SCTP only}             |
>     | sourceIpAddress[0..1] {UDP only}               |
>     | templateRefreshTimeout = 600 {UDP only}        |
>     | optionsTemplateRefreshTimeout = 600 {UDP only} |
>     | templateRefreshPacket[0..1] {UDP only}         |
>     | optionsTemplateRefreshPacket[0..1] {UDP only}  |
>     +------------------------------------------------+
> 
>                  Figure 2: UML example: Destination class
> 
>    As an example, Figure 2 shows the UML diagram of the Destination
>    class, which is specified in more detail in Section 4.4.1.  The upper
>    box contains the name of the class.  The lower box lists the
>    attributes of the class.  The only parameters that MUST be configured
>    by the user are name, transportProtocol, and destinationIpAddress.
>    The remaining parameters have either defaults values, specific
                                          ~~~~~~~~~~~~~~~
default value?

>    properties, or a multiplicity indicator starting with zero
> 
>    A default value is indicated after the attribute behind the equality
>    symbol ("=").  It means that this default value MUST be used by the
>    Monitoring Device if the parameter is not configured by the user.  In
>    the example, IPFIX version 10 must be used if not configured
>    differently.  For destinationPort, two default values are indicated,
>    namely the registered ports for IPFIX with and without transport
>    layer security (i.e., DTLS or TLS), respectively.  Note that such
>    alternative default values cannot be formally specified in YANG.
>    Instead, they are described in the "description" statement.
> 
>    An attribute with property "{opt.}", such as sendBufferSize in the
>    Destination class, represents a parameter that MAY be configured by
>    the user.  Otherwise, the Monitoring Device will assign an
>    appropriate value for this parameter.  As a result, the parameter
>    will always exist in the configuration data, yet it is not mandatory
>    for the user to configure it.  Note that this property cannot be
>    formally specified in YANG.  Instead, it is described in the
>    "description" statement.
> 
>    The property "{SCTP only}" ("{UDP only}") means that the
>    corresponding parameters are only available if the transport protocol
>    is SCTP (UDP).  In YANG, this is formalized in a "when" statement.
> 
>    Another property not shown in the example is "{readOnly}" specifying
>    state parameters which cannot be configured by the user.
> 
>    An attribute with a multiplicity indicator of "[0..1]" represents an
>    OPTIONAL configuration parameter.  The parameter is not included in
>    the configuration data unless the user configures it.  Typically, the
>    absence of the parameter has a specific meaning.  For example, not
>    configuring rateLimit in the Destination class means that no rate
>    limiting will be applied to the exported data.
> 
>    A multiplicity indicator of "[0..*]" means that this parameter MAY be
>    configured multiple times with different values.  In the example,
>    multiple local IP addresses may be configured if SCTP is transport
>    protocol.  Note that attributes without this multiplicity indicator
>    MUST NOT appear more than once in each object of the class.
> 
>    If some parameters are related to each other, it can make sense to
>    group these parameters in a subclass.  This is especially useful if
>    different subclasses represent choices of different parameter sets,
>    or if the parameters of a subclass may appear multiple times.  For
>    example, the Destination class MAY contain the parameters of the
>    TransportLayerSecurity subclass.
> 
>    Classes define the structure of the objects of a specific
>    configuration.  Objects and their parameters are encoded as XML
>    elements.  So, one object of the Destination class corresponds to one
>    occurrence of
> 
>      <destination>
>        <name>my-destination</name>
>        ...
>      </destination>
> 
>    There are various possibilities how objects of classes can be related
>    to each other.  In the scope of this document, we use two different
>    types of relationship between objects: aggregation and unidirectional
>    association.  In UML class diagrams, two different arrow types are
>    used as shown in Figure 3.
> 
>             +---+   0..* +---+         +---+ 0..*  1 +---+
>             | A |<>------| B |         | A |-------->| B |
>             +---+        +---+         +---+         +---+
>              (a) Aggregation     (b) Unidirectional association
> 
>             Figure 3: Class relationships in UML class diagrams
> 
>    Aggregation means that one object is part of the other object.  In
>    Figure 3 (a), an object of class B is part of an object of class A.
>    This corresponds to nested XML elements:
> 
>      <a>
>        <b>
>          ...
>        </b>
>        ...
>      </a>
> 
>    Note that we write class names starting with a capital letter
>    throughout this document.  The corresponding XML elements use
>    identical names starting with an uncapitalized letter because they
>    represent objects, not classes.
> 
>    A unidirectional association is a reference to an object.  In
>    Figure 3 (b), an object of class A contains a reference to an object
>    of class B. This corresponds to separate XML elements that are not
>    nested.  To distinguish different objects of class B, class B must
>    have a key.  In the configuration data model, all keys are string
>    parameters called "name", corresponding to XML elements <name>.  The
>    names must be unique within the XML document.  The reference to a
>    specific object of class B is encoded with an XML element <b> which
>    contains the corresponding object name.  In the given example, this
>    may look as follows:
> 
>      <a>
>        ...
>        <b>foo</b>
>        ...
>      </a>
> 
>      <b>
>        <name>foo</name>
>        ...
>      </b>
> 
>    In Figure 3, the indicated numbers define the multiplicity:
> 
>       "1": one only
>       "0..*": zero or more
>       "1..*": one or more
> 
>    In the case of aggregation, the multiplicity indicates how many
>    objects of one class may be included in one object of the other
>    class.  In Figure 3 (a), an object of class A may contain an
>    arbitrary number of objects of class B. In the case of unidirectional
>    association, the multiplicity at the arrowhead specifies the number
>    of objects of a given class that may be referred to.  The
>    multiplicity at the arrow tail specifies how many different objects
>    of one class may refer to a single object of the other class.  In
>    Figure 3 (b), an object of class A refers to single object of class
>    B. One object of class B can be referred to from an arbitrary number
>    of objects of class A.
> 
>    Similar to classes that are referenced in UML associations, classes
>    which contain configuration parameters and which occur with
>    multiplicity greater than one in an aggregation relationship must
>    have a key which allows distinguishing different objects.  This key
>    is necessary because every configuration parameter must be
>    addressable in order to manipulate or delete it.  The values of the
>    key must be unique in the scope of the aggregating object.  Hence,
>    under the assumption that class B in Figure 3 (a) contains at least
>    one configuration parameter, all objects of class B belonging to the
>    same object of class A must have different key values.  Again, the
>    key appears as an attribute called "name" in all concerned classes.
> 
>    A class which contains state parameters but no configuration
>    parameters, such as the Template class (see Section 4.7.1), does not
>    have a key.  This is because state parameters cannot be manipulated
>    or deleted, and therefore do not need to be addressable.
> 
>    Note that the usage of keys as described above is also required by
>    YANG [I-D.ietf-netmod-yang] which mandates the existence of a key for
>    all elements which appear in lists of configuration data.
> 
>    The configuration data model for IPFIX and PSAMP makes use of
>    unidirectional associations to specify the data flow between
>    different functional blocks.  For example, if the output of a
>    Selection Process is processed by a Cache, this corresponds to an
>    object of the SelectionProcess class that contains a reference to an
>    object of the Cache class.  The configuration data model does not
>    mandate that such a reference exists for every functional block that
>    has an output.  If such a reference is absent, the output is dropped
>    without any further processing.  Although such configurations are
>    incomplete, we do not consider them as invalid as they may
>    temporarily occur if a Monitoring Device is configured in multiple
>    steps.  Also, it might be useful to pre-configure certain functions
>    of a Monitoring Device in order to be able to switch to a new
>    configuration more quickly.

It is good idea.
> 
> 3.2.  Exporter Configuration
> 
>    Figure 4 below shows the main classes of the configuration data model
>    which are involved in the configuration of an IPFIX or PSAMP
>    Exporter.  The role of the classes can be briefly summarized as
>    follows:
> 
>    o  The ObservationPoint class specifies an Observation Point (i.e.,
>       an interface or linecard) of the Monitoring Device at which
>       packets are captured for traffic measurements.  An object of the
>       ObservationPoint class may be associated with one or more objects
>       of the SelectionProcess class configuring Selection Processes that
>       process the observed packets in parallel.  As long as an
>       ObservationPoint object is specified without any references to
>       SelectionProcess objects, the Observation Point is not deployed
>       for traffic measurements.
> 
>    o  The SelectionProcess class contains the configuration parameters
>       of a Selection Process.  The Selection Process may be composed of
>       a single Selector or a sequence of Selectors, defining a Primitive
>       or Composite Selector, respectively.
> 
>       The Selection Process selects packets from an Observed Packet
>       Stream originating from one or multiple Observation Points.
>       Therefore, a SelectionProcess object MAY be referred to from
>       multiple ObservationPoint objects.  The corresponding Observation
>       Points must belong to the same Observation Domain.

The Selection Process after Cache handles the Flow Records or Packet
Reports, not packets.

> 
>       A Selection Process MAY pass the Selected Packet Stream to one or
>       multiple Caches.  Therefore, the SelectionProcess class enables
>       references to objects of the Cache class.
> 
>       It is possible to cascade different Selection Processes.  In this
>       case, the Selected Packet Stream at the output of one or multiple
>       Selection Processes is passed to the input of another Selection
>       Process.  Therefore, a SelectionProcess object MAY be referred to
>       from multiple SelectionProcess objects.  For the same reason, one
>       SelectionProcess object may refer to other objects of the same
>       class.  When cascading multiple Selection Processes, it must be
>       ensured that all packets entering a Selection Process have been
>       observed at Observation Points belonging to the same Observation
>       Domain.  A configuration example is given later in Section 7.3.
> 
>       If a Selection Process is configured without any reference to
>       Selection Processes or Caches that receive the selected packets,
>       the selected packets are not accounted in any Packet Report or
>       Flow Record.
> 
>    o  The Cache class contains configuration parameters of a Cache.  A
>       Cache may receive the output of one or more Selection Processes
>       and maintains corresponding Packet Reports or Flow Records.
>       Therefore, an object of the Cache class MAY be referred to from
>       multiple SelectionProcess objects.  However, the configuration
>       MUST ensure that all packets entering the Selection Process have
                                                  ^^^^^^^^^^^^^^^^^ 
Cache?

>       been observed at Observation Points belonging to the same
>       Observation Domain.
> 
>       Configuration parameters of the Cache class specify the size of
>       the Cache, the Cache Mode and Layout, and expiration parameters.
>       The Cache Mode determines if Packet Reports or Flow Records are
>       generated.
> 
>       A Cache MAY pass its output to one or multiple Exporting Process.
>       Therefore, the Cache class enables references to one or multiple
>       objects of the ExportingProcess class.  If a Cache object does not
>       specify any reference to an ExportingProcess object, the Cache
>       output is dropped.
> 
>    o  The ExportingProcess class contains configuration parameters of an
>       Exporting Process.  It includes various transport protocol
>       specific parameters and the export destinations.  An object of the
>       ExportingProcess class MAY be referred to from multiple objects of
>       the Cache class.
> 
>       An Exporting Process MAY be configured as a File Writer according
>       to [I-D.ietf-ipfix-file].
> 
>                         +------------------+
>                         | ObservationPoint |
>                         +------------------+
>                              0..* |
>                                   |
>                              0..* V
>                         +------------------+
>                         | SelectionProcess |
>                         +------------------+<-+
>                              0..* |  0..* |   | 0..*
>                                   |       +---+
>                              0..* V
>                         +------------------+
>                         | Cache            |
>                         +------------------+
>                              0..* |
>                                   |
>                              0..* V
>                         +------------------+
>                         | ExportingProcess |
>                         +------------------+
> 
>              Figure 4: Class diagram of Exporter configuration
> 
> 3.3.  Collector Configuration
> 
>    Figure 5 below shows the main classes of the configuration data model
>    which are involved in the configuration of a Collector.  An object of
>    the CollectingProcess class specifies the local IP addresses,
>    transport protocols and port numbers of a Collecting Process.
>    Alternatively, the Collecting Process MAY be configured as a File
>    Reader according to [I-D.ietf-ipfix-file].
> 
>    An object of the CollectingProcess class may refer to one or multiple
>    ExportingProcess objects configuring Exporting Processes that
>    reexport the received data.  As an example, an Exporting Process can
>    be configured as a File Writer in order to save the received IPFIX
>    Messages in a file.
> 
>            +-------------------+ 0..*  0..* +------------------+
>            | CollectingProcess |----------->| ExportingProcess |
>            +-------------------+            +------------------+
> 
>             Figure 5: Class diagram of Collector configuration
> 
> 
> 4.  Configuration Parameters
> 
>    This section specifies the configuration and state parameters of the
>    configuration data model separately for each class.  Parameters
>    serving as keys are depicted in brackets.
> 
> 4.1.  ObservationPoint Class
> 
>     +-------------------------------+
>     | ObservationPoint              |
>     +-------------------------------+          1 +--------------------+
>     | name                          |<>----------| Interface/Linecard |
>     | observationPointId {readOnly} |            +--------------------+
>     | observationDomainId           |
>     |                               | 0..*  0..* +--------------------+
>     |                               |----------->| SelectionProcess   |
>     +-------------------------------+            +--------------------+
> 
>     +------------------+   +----------------------------------+
>     | Interface        |   | Linecard                         |
>     +------------------+   +----------------------------------+
>     | ifIndex/ifName   |   | entPhysicalIndex/entPhysicalName |
>     | direction = both |   | direction = both                 |
>     +------------------+   +----------------------------------+
> 
>                      Figure 6: ObservationPoint class
> 
>    Figure 6 shows the ObservationPoint class that identifies an
>    Observation Point of the Monitoring Device.  The Observation Point
>    can either be an interface or a linecard.
> 
>    An object of the ObservationPoint class MUST specify the ID of the
>    Observation Domain the Observation Point belongs to.  Observation
>    Points that are configured with the same Observation Domain ID belong
>    to the same Observation Domain.
> 
>    The Observation Point ID (i.e., the value of the Information Element
>    observationPointId [RFC5102]) is assigned by the Monitoring Device.
>    It appears as a state parameter in the ObservationPoint class.
> 
>    The configuration parameters to identify an interface or a linecard
>    are as follows:
> 
>    ifIndex/ifName (interface only):  Either the index or name of the
>       interface MUST be specified according to corresponding objects in
>       the IF-MIB [RFC2863].
> 
>    entPhysicalIndex/entPhysicalName (linecard only):  Either the index
>       or name of the linecard MUST be specified according to
>       corresponding objects in the ENTITY-MIB [RFC4133].
> 
>    direction:  This parameter specifies if ingress traffic, egress
>       traffic, or both ingress and egress traffic is captured, using the
>       values "ingress", "egress", and "both", respectively.  If not
>       configured, ingress and egress traffic is captured (i.e., the
>       default value is "both").  If not applicable (e.g., in the case of
>       a sniffing interface in promiscuous mode), the value of this
>       parameter is ignored.

I have one question.
In the case of a single ifIndex belonging to multiple Observation
Domains, can this Interface class be referred by multiple
ObservationPoint classes?

> 
>    An ObservationPoint object MAY refer to one or multiple
>    SelectionProcess objects configuring Selection Processes that process
>    the observed packets in parallel.
> 
> 4.2.  SelectionProcess Class
> 
>          +--------------------------------+
>          | SelectionProcess               |
>          +--------------------------------+       1..* +----------+
>          | name                           |<>----------| Selector |
>          | selectionSequenceId {readOnly} |            +----------+
>          |                                | 0..*
>          |                                |<---+
>          |                                |    |
>          |                                |----+
>          |                                | 0..*
>          |                                |
>          |                                | 0..*  0..* +----------+
>          |                                |----------->| Cache    |
>          +--------------------------------+            +----------+
> 
>                      Figure 7: SelectionProcess class
> 
>    Figure 7 shows the SelectionProcess class.  The SelectionProcess
>    class contains the configuration parameters of a Selection Process
>    which selects packets from the Observed Packet Stream at its input
>    and outputs the Selected Packet Stream to one or multiple other
>    Selection Processes or Caches.  A non-empty ordered list defines a
>    sequence of Selectors.  The actions defined by the Selectors are
>    applied to the stream of incoming packet in the specified order.
> 
>    The state parameter selectionSequenceId contains the Selection
>    Sequence ID (i.e., the value of the Information Element
>    selectionSequenceId [RFC5477]) which is assigned by the Monitoring
>    Device.  The Selection Sequence ID MUST be unique within the
>    Observation Domain as required by [RFC5477].
> 
>    The output of one Selection Process MAY be processed by other
>    Selection Processes.  Therefore, the SelectionProcess class allows
>    references to itself, meaning that one SelectionProcess object MAY
>    refer to other SelectionProcess objects.
> 
>    A SelectionProcess object MAY include references to one or more
>    objects of the Cache class configuring Caches that receive the
>    Selected Packet Stream and generate corresponding Packet Reports or
>    Flow Records.

If SelectionProcess class embodies the function of Metering Process, I
prefer the name of MeteringProcess class instead of SelectionProcess
from the consistency with IPFIX-MIB.

> 
> 4.2.1.  Selector Class
> 
>     +--------------------------------------+
>     | Selector                             |
>     +--------------------------------------+      1 +-----------------+
>     | name                                 |<>------+ SelectAll/      |
>     | selectorId {readOnly}                |        | SampCountBased/ |
>     | packetsObserved {readOnly}           |        | SampTimeBased/  |
>     | packetsDropped {readOnly}            |        | SampRandOutOfN/ |
>     | selectorDiscontinuityTime {readOnly} |        | SampUniProb/    |
>     |                                      |        | FilterMatch/    |
>     |                                      |        | FilterHash/     |
>     +--------------------------------------+        +-----------------+
> 
>                          Figure 8: Selector class
> 
>    The Selector class in Figure 8 contains the configuration and state
>    parameters of a Selector.  Standardized PSAMP Sampling and Filtering
>    methods are described in [RFC5475]; their configuration parameters
>    are specified in corresponding sampler (SampCountBased,
>    SampTimeBased, SampRandOutOfN, SampUniProb) or filter (FilterMatch,
>    FilterHash) classes.  In addition, the SelectAll class, which has no
>    parameters, is used for a Selector that selects all packets.  The
>    Selector class includes exactly one of these sampler and filter
>    classes, depending on the applied method.
> 
>    The state parameter selectorId contains the Selector ID (i.e., the
>    value of the Information Element selectorId [RFC5477]) assigned by
>    the Monitoring Device.  The Selector ID MUST be unique within the
>    Observation Domain as required by [RFC5477].
> 
>    As state parameters, the Selector class contains the Selector
>    statistics packetsObserved and packetsDropped that correspond to the
>    objects of the ipfixSelectorStatsTable in the IPFIX MIB module
>    [I-D.ietf-ipfix-mib].
> 
> 
> 4.2.2.  Sampler Classes
> 
>         +----------------+   +----------------+   +----------------+
>         | SampCountBased |   | SampTimeBased  |   | SampRandOutOfN |
>         +----------------+   +----------------+   +----------------+
>         | packetInterval |   | timeInterval   |   | population     |
>         | packetSpace    |   | timeSpace      |   | size           |
>         +----------------+   +----------------+   +----------------+
> 
>         +----------------+
>         | SampUniProb    |
>         +----------------+
>         | probability    |
>         +----------------+
> 
>                          Figure 9: Sampler classes
> 
>    The Sampler classes in Figure 9 contain the configuration parameters
>    of specific Sampling algorithms:
> 
>    packetInterval, packetSpace:  For systematic count-based sampling,
>       packetInterval defines the number of packets that are
>       consecutively sampled between gaps of length packetSpace.  These
>       parameters correspond to the Information Elements
>       samplingPacketInterval and samplingPacketSpace [RFC5477].
> 
>    timeInterval, timeSpace:  For systematic time-based sampling,
>       timeInterval defines the time interval during which all arriving
>       packets are sampled. timeSpace is the gap between two sampling
>       intervals.  These parameters correspond to the Information
>       Elements samplingTimeInterval and samplingTimeSpace [RFC5477].
>       The unit is microseconds.
> 
>    size, population:  For n-out-of-N random sampling, size defines the
>       number of elements taken from the parent population. population
>       defines the number of elements in the parent population.  These
>       parameters correspond to the Information Elements samplingSize and
>       samplingPopulation [RFC5477].
> 
>    probability:  For uniform probabilistic sampling, probability defines
>       the sampling probability.  This parameter corresponds to the
>       Information Element samplingProbability [RFC5477].
> 
> 
> 4.2.3.  Filter Classes
> 
>            +--------------------------+
>            | FilterMatch              |
>            +--------------------------+
>            | ieId/ieName              |
>            | ieEnterpriseNumber[0..1] |
>            | value                    |
>            +--------------------------+
> 
>            +--------------------------+
>            | FilterHash               |
>            +--------------------------+    1..* +---------------+
>            | hashFunction = BOB       |<>-------| SelectedRange |
>            | ipPayloadOffset = 0      |         +---------------+
>            | ipPayloadSize = 8        |         | name          |
>            | digestOutput = false     |         | min           |
>            | initialiserValue[0..1]   |         | max           |
>            +--------------------------+         +---------------+
> 
>                          Figure 10: Filter classes
> 
>    The Filter classes in Figure 10 contain the configuration parameters
>    of specific Filtering methods.  For property match filtering, the
>    configuration parameters are:
> 
>    ieId, ieName, ieEnterpriseNumber:  The property to be matched is
>       specified by either ieId or ieName, specifying the ID or name of
>       the Information Element, respectively. ieEnterpriseNumber MUST be
>       used for enterprise-specific Information Elements.  If
>       ieEnterpriseNumber is omitted or zero, this is Information Element
>       is not enterprise-specific but registered at IANA.
> 
>    value:  Matching value.
> 

Can the ranges of value be defined like hash value?
And, I would like to specify its instruction, "match" or "unmatch".

>    For hash-based filtering, the configuration parameters are:
> 
>    hashFunction:  Hash function to be used.  The following parameter
>       values are defined by the configuration data model:
>       *  BOB: BOB Hash Function as specified in [RFC5475], Appendix A.2
>       *  IPSX: IP Shift-XOR (IPSX) Hash Function as specified in
>          [RFC5475], Appendix A.1
>       *  CRC: CRC-32 function as specified in [RFC1141]
>       Default value is "BOB".
> 
>    ipPayloadOffset, ipPayloadSize:  ipPayloadOffset and ipPayloadSize
>       configure the offset and the size of the payload section used as
>       input to the hash function.  Default values are 0 and 8,
>       respectively, corresponding to the minimum configurable values
>       according to [RFC5476], Section 6.2.5.6.  These parameters
>       correspond to the Information Elements hashIPPayloadOffset and
>       hashIPPayloadSize [RFC5477].
> 
>    digestOutput:  digestOutput enables or disables the inclusion of the
>       packet digest in the resulting PSAMP Packet Report.  This requires
>       that the Cache Layout of the Cache generating the Packet Reports
>       includes a digestHashValue field.  This parameter corresponds to
>       the Information Element hashDigestOutput [RFC5477].
> 
>    initialiserValue:  Initializer value to the hash function.  This
>       parameter corresponds to the Information Element
>       hashInitialiserValue [RFC5477].  If not configured by the user,
>       the monitoring device arbitrarily chooses an initializer value.
> 
>    One or more ranges of matching hash values are defined by the min and
>    max parameters of the SelectedRange subclass.  These parameters
>    correspond to the Information Elements hashSelectedRangeMin and
>    hashSelectedRangeMax [RFC5477].
> 
> 4.3.  Cache Class
> 
>    +-----------------------------------+
>    | Cache                             |
>    +-----------------------------------+          1 +-------------+
>    | name                              |<>----------| CacheLayout |
>    | cacheMode                         |            +-------------+
>    | maxRecords {opt.}                 |
>    | activeTimeout {opt.}              | 0..*  0..* +------------------+
>    |   {except Cache Mode "immediate"} |----------->| ExportingProcess |
>    | inactiveTimeout {opt.}            |            +------------------+
>    |   {Cache Mode "timeout" only}     |
>    | activeFlows {readOnly}            |
>    | inactiveFlows {readOnly}          |
>    | cacheDataRecords {readOnly}       |
>    | cacheDiscontinuityTime {readOnly} |
>    +-----------------------------------+
> 
>                           Figure 11: Cache class
> 
>    Figure 11 shows the Cache class that contains the configuration and
>    state parameters of a Cache.  The configuration parameters of the
>    Cache class are as follows:
> 
>    cacheMode:  Configures the Cache Mode.  The following parameter
>       values are specified by the configuration data model:
>       *  immediate: Data Records expire after the first packet
>       *  timeout: Data Records expire after active or inactive timeout
>       *  permanent: Data Records never expire, but are periodically
>          exported with interval set by the active timeout
>       In the case of "immediate", PSAMP Packet Reports are generated.
>       Otherwise, IPFIX Flow Records are generated.
> 
>    maxRecords:  Maximum number of Data Records in the Cache.  If not
>       configured by the user, the Monitoring Device sets this parameter.
> 

When a cache becomes max Records, new Flow Records can be dropped or
push the old one? Does it depend on the implementation matter?

>    activeTimeout:  This parameter configures the active timeout in
>       milliseconds.  It is not available for Cache Mode "immediate".
>       The parameter value zero indicates infinity, meaning that there is
>       no active timeout.  If not configured by the user, the Monitoring
>       Device sets this parameter.
>       In the case of Cache Mode "timeout", the active timeout defines
>       the time after which a Flow Record is expired even though packets
>       matching this Flow are still received by the Cache.  In the case
>       of Cache Mode "permanent", the active timeout defines the interval
>       for periodical export of Flow Records.

In the case of Cache Mode "timeout", the timer for active timeout is set
per a Flow Record. In the case of Cache Mode "permanent", the timer
for active timeout is set per a Cache.

If it is right, each meaning "active timeout" are different. Could you please
add some explanation.

> 
>    inactiveTimeout:  This parameter configures the inactive timeout in
>       milliseconds.  It is not available for Cache Modes "immediate" and
>       "permanent".  The parameter value zero indicates infinity, meaning
>       that there is no inactive timeout.  If not configured by the user,
>       the Monitoring Device sets this parameter.
>       The inactive timeout defines the time after which a Flow Record is
>       expired if no packets matching this Flow are received by the
>       Cache.
> 
>    An object of the Cache class includes an object of the CacheLayout
>    class that defines which fields are included in the Packet Reports or
>    Flow Records.  A Cache object MAY refer to one or multiple
>    ExportingProcess objects configuring different Exporting Processes.
> 
>    As state parameters, the Cache class contains the Metering Process
>    statistics activeFlows, inactiveFlows, and cacheDataRecords that
>    correspond to the objects of the ipfixMeteringProcessStatsTable of
>    the IPFIX MIB module [I-D.ietf-ipfix-mib].
> 

> 
> 4.3.1.  CacheLayout Class
> 
>             +--------------+
>             | CacheLayout  |
>             +--------------+   1..* +--------------------------+
>             |              |<>------| CacheField               |
>             |              |        +--------------------------+
>             |              |        | name                     |
>             |              |        | ieId/ieName              |
>             |              |        | ieLength {opt.}          |
>             |              |        | ieEnterpriseNumber[0..1] |
>             |              |        | isFlowKey[0..1]          |
>             +--------------+        +--------------------------+
> 
>                        Figure 12: CacheLayout class
> 
>    A Cache generates and maintains Packet Reports or Flow Records
>    containing information that has been extracted from the incoming
>    stream of packets.  Using the CacheField class, the CacheLayout class
>    specifies the superset of fields that are included in the Packet
>    Reports or Flow Records (see Figure 12).
> 
>    If Packet Reports are generated (i.e., if Cache Mode is "immediate"),
>    every field specified by the Cache Layout MUST be included in the
>    resulting Packet Report unless the corresponding Information Element
>    is not applicable or cannot be derived from the content or treatment
>    of the incoming packet.
> 
>    If Flow Records are generated (i.e., if Cache Mode is "timeout" or
>    "permanent"), every Flow Key field specified by the Cache Layout MUST
>    be included as Flow Key in the resulting Flow Record unless the
>    corresponding Information Element is not applicable or cannot be
>    derived from the content or treatment of the incoming packet.  Two
>    packets MUST be accounted by different Flow Records if different
>    subsets of the Flow Key fields are applicable or derivable.  Every
>    non-key field specified by the Cache Layout MUST be included in the
>    resulting Flow Record unless the corresponding Information Element is
>    not applicable or cannot be derived for the given Flow.
> 
>    For example, if a non-key field specifies an Information Element
>    whose value is determined by the first packet observed within a Flow
>    (which is the default rule according to [RFC5102]), this field MUST
>    be included in the resulting Flow Record if it can be determined from
>    the first packet of the Flow.
> 
>    The CacheLayout class does not have any parameters.  The
>    configuration parameters of the CacheField class are as follows:
> 
>    ieId, ieName, ieEnterpriseNumber:  These parameters specify a field
>       by the combination of the Information Element identifier or name,
>       and the Information Element enterprise number.  Either ieId or
>       ieName MUST be specified. ieEnterpriseNumber MUST be used for
>       enterprise-specific Information Elements.  If ieEnterpriseNumber
>       is omitted or zero, this is Information Element is not enterprise-
>       specific but registered at IANA.
> 
>    ieLength:  This parameter specifies the length of the field in
>       octets.  A value of 65535 means that the field is encoded as
>       variable-length Information Element.  For Information Elements of
>       integer and float type, the field length MAY be set to a smaller
>       value than the standard length of the abstract data type if the
>       rules of reduced size encoding are fulfilled (see [RFC5101],
>       Section 6.2).  If not configured by the user, the field length is
>       set by the Monitoring Device.
> 
>    isFlowKey:  If present, this field is a Flow Key.
> 
> 4.4.  ExportingProcess Class
> 
>              +--------------------+
>              | ExportingProcess   |
>              +--------------------+   0..* +------------------+
>              | name               |<>------| Destination      |
>              |                    |        +------------------+
>              |                    |
>              |                    |   0..* +------------------+
>              |                    |<>------| FileWriter       |
>              |                    |        +------------------+
>              |                    |
>              |                    |   0..* +------------------+
>              |                    |<>------| Options          |
>              |                    |        +------------------+
>              |                    |
>              |                    |   0..* +------------------+
>              |                    |<>------| TransportSession |
>              +--------------------+        +------------------+
> 
>                      Figure 13: ExportingProcess class
> 
>    The ExportingProcess class in Figure 13 specifies export destinations
>    and files to which the IPFIX Messages are exported using objects of
>    the Destination class and the FileWriter, respectively.  These two
>    classes are described in Section 4.4.1 and Section 4.4.2.  If not
>    configured by the user, the Exporting Process ID is assigned by the
>    Monitoring Device.  The reporting of specific information with
>    Options Templates is defined with objects of the Options class.
>    As state data, the ExportingProcess class contains the list of
>    Transport Sessions that originate from the Exporting Process.  The
>    TransportSession class is specified in Section 4.7.
> 
> 4.4.1.  Destination Class
> 
>     +------------------------------------------------+
>     | Destination                                    |
>     +------------------------------------------------+
>     | name                                           |<>-----+
>     | exportMemberType = parallel                    |       | 0..1
>     | ipfixVersion = 10                              |       |
>     | transportProtocol                              |   +------------+
>     | destinationIpAddress                           |   | Transport- |
>     | destinationPort = 4739|4740                    |   | Layer-     |
>     | sendBufferSize {opt.}                          |   | Security   |
>     | rateLimit[0..1]                                |   +------------+
>     | localIpAddress[0..*] {SCTP only}               |
>     | timedReliability = 0 {SCTP only}               |
>     | numberOfStreams {opt.} {SCTP only}             |
>     | sourceIpAddress[0..1] {UDP only}               |
>     | templateRefreshTimeout = 600 {UDP only}        |
>     | optionsTemplateRefreshTimeout = 600 {UDP only} |
>     | templateRefreshPacket[0..1] {UDP only}         |
>     | optionsTemplateRefreshPacket[0..1] {UDP only}  |
>     +------------------------------------------------+
> 
>                        Figure 14: Destination class
> 
>    The Destination class shown in Figure 14 contains the configuration
>    parameters of one export destination (i.e., Collector) the Exporting
>    Process sends IPFIX Messages to.  Some of the parameters are only
>    applicable if a specific transport protocol (SCTP, UDP, or TCP) is
>    used.  The following parameters apply to all transport protocols:
> 
>    exportMemberType:  Configures the export member type that corresponds
>       to the ipfixTransportSessionGroupMemberType object in
>       [I-D.ietf-ipfix-mib].  The following parameter values are
>       specified by the configuration data model:
>       *  primary: primary target of the Exporting Process
>       *  secondary: secondary target of the Exporting Process used when
>          the primary target is not reachable
>       *  parallel: parallel exporting to all destinations and files of
>          the Exporting Process
>       *  loadBalancing: load-balancing between different destinations
>          and files of the Exporting Process
>       "parallel" is the default value if this parameter is not
>       configured.  If one destination or file is configured as "primary"
>       target, all other destinations and files must be configured as
>       "secondary" targets.  If "parallel" or "loadBalancing" is used,
>       the same type must be configured for all destinations and File
>       Writers of the Exporting Process.
> 
>    ipfixVersion:  Version number of the IPFIX protocol used.  If
>       omitted, the default value is 10 (=0x000a) as specified in
>       [RFC5101].
> 
>    transportProtocol:  One of "sctp", "udp", and "tcp".
> 
>    destinationIpAddress, destinationPort:  Destination IP address and
>       destination port number to be used. destinationIpAddress is a
>       mandatory parameter.  If destinationPort is omitted, standard port
>       4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS)
>       is used.
> 
>    sendBufferSize:  Size of the socket send buffer in bytes.
> 
>    rateLimit:  Maximum number of bytes per second the Exporting Process
>       may export to the given destination as required by [RFC5476].  The
>       number of bytes is calculated from the lengths of the IPFIX
>       Messages exported.  If this parameter is not configured, no rate
>       limiting is performed for this destination.
> 
>    The following parameters are applicable if SCTP is transport
>    protocol:
> 
>    localIpAddress:  This optional parameter MAY appear multiple times to
>       specify the list of eligible local IP addresses of the SCTP
>       association [RFC4960].  If omitted, all locally assigned IP
>       addresses are used by the SCTP endpoint.
> 
>    timedReliability:  Lifetime in milliseconds until an IPFIX Message
>       containing Data Sets only is "abandoned" due to the timed
>       reliability mechanism of PR-SCTP [RFC3758].  If this parameter is
>       set to zero, reliable SCTP transport is used.
> 
>    numberOfStreams:  Number of outbound streams requested for SCTP
>       associations [RFC4960].  If not configured by the user, this
>       parameter is set by the Monitoring Device.
> 
>    The following parameters are applicable if UDP is transport protocol:
> 
>    sourceIpAddress:  This parameter sets the source IP address.  If this
>       parameter is omitted, the address assigned to the outgoing
>       interface is used.
> 
I would like to make available in the case of TCP.

>    templateRefreshTimeout, optionsTemplateRefreshTimeout,
>    templateRefreshPacket, optionsTemplateRefreshPacket:  Template
>       refresh parameters when using UDP as transport protocol.
>       templateRefreshTimeout and optionsTemplateRefreshTimeout are
>       specified in seconds between resendings of (Options) Templates.
>       If omitted, the default value of 600 seconds (10 minutes) is used
>       [RFC5101]. templateRefreshPacket and optionsTemplateRefreshPacket
>       are specified in number of IPFIX Messages.  If omitted, the
>       (Options) Templates are only resent after timeout.
> 
>    Using the TransportLayerSecurity class, transport layer security is
>    enabled and configured for this export destination.  If the transport
>    protocol is SCTP or UDP, transport layer security is realized using
>    DTLS.  In the case of TCP, TLS is used instead.
> 
> 4.4.2.  FileWriter Class
> 
>                       +-----------------------------+
>                       | FileWriter                  |
>                       +-----------------------------+
>                       | name                        |
>                       | exportMemberType = parallel |
>                       | ipfixVersion = 10           |
>                       | file                        |
>                       +-----------------------------+
> 
>                        Figure 15: FileWriter classes
> 
>    Instead of exporting IPFIX Messages to remote destinations, the
>    Exporting Process can write them to a file as proposed in
>    [I-D.ietf-ipfix-file].  The FileWriter class contains the
>    configuration parameters for writing the IPFIX Messages to a specific
>    file:
> 
>    exportMemberType:  Same parameter as in the Destination class.  The
>       File Writers of an Exporting Process belong to the same Transport
>       Session group as any destination configured for the same Exporting
>       Process.
> 
>    ipfixVersion:  Version number of the IPFIX protocol used.  If
>       omitted, the default value is 10 (=0x000a) as specified in
>       [RFC5101].
> 
>    file:  File name and location specified as URI.
> 
> 4.4.3.  Options Class
> 
>                          +-----------------------+
>                          | Options               |
>                          +-----------------------+
>                          | name                  |
>                          | optionsType           |
>                          | optionsTimeout {opt.} |
>                          +-----------------------+
> 
>                          Figure 16: Options class
> 
>    The Options class in Figure 16 defines the type of specific
>    information to be reported, such as statistics, flow keys, Sampling
>    and Filtering parameters etc.  [RFC5101] and [RFC5476] specify
>    several types of reporting information which may be exported.  The
>    following parameter values are specified by the configuration data
>    model:
> 
>    meteringStatistics:  Export of Metering Process statistics using the
>       Metering Process Statistics Options Template [RFC5101].
> 
>    meteringReliability:  Export of Metering Process reliability
>       statistics using the Metering Process Reliability Statistics
>       Options Template [RFC5101].
> 
>    exportingReliability:  Export of Exporting Process reliability
>       statistics using the Exporting Process Reliability Statistics
>       Options Template [RFC5101].
> 
>    flowKeys:  Export of the Flow Key specification using the Flow Keys
>       Options Template [RFC5101].
> 
>    selectionSequence:  Export of Selection Sequence Report
>       Interpretation and Selector Report Interpretation [RFC5476].
> 
>    selectionStatistics:  Export of Selection Sequence Statistics Report
>       Interpretation [RFC5476].
> 
>    accuracy:  Export of Accuracy Report Interpretation [RFC5476].
> 
>    reducingRedundancy:  Export of common properties according to
>       [RFC5473].
> 
>    The Exporting Process MUST choose a template definition according to
>    the options type and available options data.
> 
>    The optionsTimeout parameter specifies the reporting interval (in
>    milliseconds) for periodic export of the option data.  A parameter
>    value of zero means that the export of the option data is not
>    triggered periodically, but whenever the available option data has
>    changed.  This is the typical setting for options types flowKeys,
>    selectionSequence, accuracy, and reducingRedundancy.  If
>    optionsTimeout is not configured by the user, it is set by the
>    Monitoring Device.
> 
> 4.5.  CollectingProcess Class
> 
>            +-------------------+
>            | CollectingProcess |
>            +-------------------+
>            | name              |       0..* +------------------+
>            |                   |<>----------| Receiver         |
>            |                   |            +------------------+
>            |                   |
>            |                   |       0..* +------------------+
>            |                   |<>----------| FileReader       |
>            |                   |            +------------------+
>            |                   |
>            |                   | 0..*  0..* +------------------+
>            |                   |----------->| ExportingProcess |
>            |                   |            +------------------+
>            |                   |
>            |                   |       0..* +------------------+
>            |                   |<>----------| TransportSession |
>            +-------------------+            +------------------+
> 
>                     Figure 17: CollectingProcess class
> 
>    Figure 17 shows the CollectingProcess class that contains the
>    configuration and state parameters of a Collecting Process.  Objects
>    of the Receiver class specify how IPFIX Messages are received from
>    remote Exporters.  The Collecting Process can also be configured as a
>    File Reader using objects of the FileReader class.
> 
>    As state data, the CollectingProcess class contains the list of
>    Transport Sessions that terminate at the Collecting Process.  The
>    TransportSession class is specified in Section 4.7.
> 
>    An CollectingProcess object MAY refer to one or multiple
>    ExportingProcess objects configuring Exporting Processes that export
>    the received data without modifications to a file or to another
>    Collector.
> 
> 4.5.1.  Receiver Class
> 
>        +--------------------------------------+
>        | Receiver                             |
>        +--------------------------------------+   0..1 +------------+
>        | name                                 |<>------| Transport- |
>        | transportProtocol                    |        | Layer-     |
>        | localIpAddress[0..*]                 |        | Security   |
>        | localPort = 4739|4740                |        +------------+
>        | maxAllowedStreams {opt.} {SCTP only} |
>        | templateLifetime = 1800 {UDP only}   |
>        +--------------------------------------+
> 
>                          Figure 18: Receiver class
> 
>    The Receiver class contains the configuration parameters of a
>    listening socket of the Collecting Process.  Some of the parameters
>    are specific to the transport protocol.  The parameters are as
>    follows:
> 
>    transportProtocol:  One of "sctp", "udp", and "tcp".
> 
>    localIpAddress:  Local IP addresses the socket is bound to.  If
>       ipAddress is omitted, the socket is bound to all local IP
>       addresses.  In the case of SCTP, the local IP addresses correspond
>       to the eligible local IP addresses used by the local SCTP endpoint
>       [RFC4960].
> 
>    localPort:  Local port number.  If omitted, standard port 4739 (IPFIX
>       without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS) is used.
> 
>    maxAllowedStreams (available if transport protocol is SCTP):  Maximum
>       number of allowed inbound streams per SCTP association.  If not
>       configured by the user, this parameter is set by the Monitoring
>       Device.
> 
>    templateLifetime (available if transport protocol is UDP):  Template
>       lifetime if UDP is used as transport protocol.  If not configured,
>       the default value 1800 is used, which is three times the default
>       Template refresh timeout (see Section 4.4) as specified in
>       [RFC5101].
> 
>    Using the TransportLayerSecurity class, transport layer security
>    using DTLS and TLS is enabled and configured for this listening
>    socket of the Collecting Process.  If the transport protocol is SCTP
>    or UDP, transport layer security is realized using DTLS.  In the case
>    of TCP, TLS is used instead.
> 
> 4.5.2.  FileReader Class
> 
>                                +------------+
>                                | FileReader |
>                                +------------+
>                                | name       |
>                                | file       |
>                                +------------+
> 
>                        Figure 19: FileReader classes
> 
>    The Collecting Process may import IPFIX Messages from a file as
>    proposed in [I-D.ietf-ipfix-file].  The FileReader class defines the
>    configuration parameter:
> 
>    file:  File name and location specified as URI.
> 
> 4.6.  Transport Layer Security Class
> 
>                   +--------------------------------------+
>                   | TransportLayerSecurity               |
>                   +--------------------------------------+
>                   | localCertificationAuthorityDN[0..*]  |
>                   | localSubjectDN[0..*]                 |
>                   | localSubjectFQDN[0..*]               |
>                   | remoteCertificationAuthorityDN[0..*] |
>                   | remoteSubjectDN[0..*]                |
>                   | remoteSubjectFQDN[0..*]              |
>                   +--------------------------------------+
> 
>                   Figure 20: TransportLayerSecurity class
> 
>    The TransportLayerSecurity class is used in the Exporting Process's
>    Destination class and the Collecting Process's Receiver class to
>    enable and configure transport layer security for IPFIX.  Transport
>    layer security can be enabled without configuring any additional
>    parameters.  In this case, an empty XML element
>    <transportLayerSecurity /> appears in the configuration.  If
>    transport layer security is enabled, the endpoint must use DTLS
>    [RFC4347] if the transport protocol is SCTP or UDP, and TLS [RFC5246]
>    if the transport protocol is TCP.
> 
>    [RFC5101] mandates strong mutual authentication of Exporting
>    Processes and Collecting Process:
> 
>       "IPFIX Exporting Processes and IPFIX Collecting Processes are
>       identified by the fully qualified domain name of the interface on
>       which IPFIX Messages are sent or received, for purposes of X.509
>       client and server certificates as in [RFC3280].
> 
>       To prevent man-in-the-middle attacks from impostor Exporting or
>       Collecting Processes, the acceptance of data from an unauthorized
>       Exporting Process, or the export of data to an unauthorized
>       Collecting Process, strong mutual authentication via asymmetric
>       keys MUST be used for both TLS and DTLS.  Each of the IPFIX
>       Exporting and Collecting Processes MUST verify the identity of its
>       peer against its authorized certificates, and MUST verify that the
>       peer's certificate matches its fully qualified domain name, or, in
>       the case of SCTP, the fully qualified domain name of one of its
>       endpoints.
> 
>       The fully qualified domain name used to identify an IPFIX
>       Collecting Process or Exporting Process may be stored either in a
>       subjectAltName extension of type dNSName, or in the most specific
>       Common Name field of the Subject field of the X.509 certificate.
>       If both are present, the subjectAltName extension is given
>       preference."
> 
>    In order to use transport layer security, appropriate certificates
>    and keys have to be previously installed on the Monitoring Devices.
>    For security reasons, the configuration data model does not offer the
>    possibility to upload any certificates or keys on a Monitoring
>    Device.  If transport layer security is enabled on a Monitoring
>    Device which does not dispose of appropriate certificates and keys,
>    the configuration MUST be rejected with an error.
> 
>    The configuration data model allows restricting the authorization of
>    remote endpoints to certificates issued by specific certification
>    authorities or identifying specific fully qualified domain names for
>    authorization.  Furthermore, the configuration data model allows
>    restricting the utilization of certificates identifying the local
>    endpoint.  This is useful if the Monitoring Device disposes of more
>    than one certificate for the given local endpoint.
> 
>    The configuration parameters are defined as follows:
> 
>    localCertificationAuthorityDN:  This parameter MAY appear one or
>       multiple times to restrict the identification of the local
>       endpoint during the TLS/DTLS handshake to certificates issued by
>       the configured certification authorities.  Each occurrence of this
>       parameter contains the distinguished name of one certification
>       authority.
>       To identify the local endpoint, the Exporting Process or
>       Collecting Process MUST use a certificate issued by one of the
>       configured certification authority.  Certificates issued by any
>       other certification authority MUST NOT be sent to the remote peer
>       during TLS/DTLS handshake.  If none of the certificates installed
>       on the Monitoring Device fulfills the specified restrictions, the
>       configuration MUST be rejected with an error.
>       If localCertificationAuthorityDN is not configured, the choice of
>       certificates identifying the local endpoint is not restricted with
>       respect to the issuing certification authority.
> 
>    localSubjectDN, localSubjectFQDN:  Each of these parameters MAY
>       appear one or multiple times to restrict the identification of the
>       local endpoint during the TLS/DTLS handshake to certificates
>       issued for specific subjects or for specific fully qualified
>       domain names.  Each occurrence of localSubjectDN contains a
>       distinguished name identifying the local endpoint.  Each
>       occurrence of localSubjectFQDN contains a fully qualified domain
>       name which is assigned to the local endpoint.
>       To identify the local endpoint, the Exporting Process or
>       Collecting Process MUST use a certificate that contains either one
>       of the configured distinguished names in the subject field or at
>       least one of the configured fully qualified domain names in a
>       dNSName component of the subject alternative extension field or in
>       the most specific commonName component of the subject field.  If
>       none of the certificates installed on the Monitoring Device
>       fulfills the specified restrictions, the configuration MUST be
>       rejected with an error.
>       If any of the parameters localSubjectDN and localSubjectFQDN is
>       configured at the same time as the localCertificationAuthorityDN
>       parameter, certificates MUST also fulfill the specified
>       restrictions regarding the certification authority.
>       If localSubjectDN and localSubjectFQDN are not configured, the
>       choice of certificates identifying the local endpoint is not
>       restricted with respect to the subject's distinguished name or
>       fully qualified domain name.
> 
>    remoteCertificationAuthorityDN:  This parameter MAY appear one or
>       multiple times to restrict the authentication of remote endpoints
>       during the TLS/DTLS handshake to certificates issued by the
>       configured certification authorities.  Each occurrence of this
>       parameter contains the distinguished name of one certification
>       authority.
>       To authenticate the remote endpoint, the remote Exporting Process
>       or Collecting Process MUST provide a certificate issued by one of
>       the configured certification authority.  Certificates issued by
>       any other certification authority MUST be rejected during TLS/DTLS
>       handshake.
>       If the Monitoring Device is not able to validate certificates
>       issued by the configured certification authorities (e.g., because
>       of missing public keys), the configuration must be rejected with
>       an error.
> 
>       If remoteCertificationAuthorityDN is not configured, the
>       authorization of remote endpoints is not restricted with respect
>       to the issuing certification authority of the delivered
>       certificate.
> 
>    remoteSubjectDN, remoteSubjectFQDN:  Each of these parameters MAY
>       appear one or multiple times to restrict the authentication of
>       remote endpoints during the TLS/DTLS handshake to certificates
>       issued for specific subjects or for specific fully qualified
>       domain names.  Each occurrence of remoteSubjectDN contains a
>       distinguished name identifying a remote endpoint.  Each occurrence
>       of remoteSubjectFQDN contains a fully qualified domain name which
>       is assigned to a remote endpoint.
>       To authenticate a remote endpoint, the remote Exporting Process or
>       Collecting Process MUST provide a certificate that contains either
>       one of the configured distinguished names in the subject field or
>       at least one of the configured fully qualified domain names in a
>       dNSName component of the subject alternative extension field or in
>       the most specific commonName component of the subject field.
>       Certificates not fulfilling this condition MUST be rejected during
>       TLS/DTLS handshake.
>       If any of the parameters remoteSubjectDN and remoteSubjectFQDN is
>       configured at the same time as the remoteCertificationAuthorityDN
>       parameter, certificates MUST also fulfill the specified
>       restrictions regarding the certification authority in order to be
>       accepted.
>       If remoteSubjectDN and remoteSubjectFQDN are not configured, the
>       authorization of remote endpoints is not restricted with respect
>       to the subject's distinguished name or fully qualified domain name
>       of the delivered certificate.
> 
> 
> 4.7.  Transport Session Class
> 
>    +------------------------------------------------------+
>    | TransportSession                                     |
>    +------------------------------------------------------+
>    | exportMemberType {readOnly} {Exporting Process only} |<>----+ 0..*
>    | ipfixVersion {readOnly}                              |      |
>    | protocol {readOnly} {except File Reader/Writer}      | +----------+
>    | sourceAddress {readOnly} {except File Reader/Writer} | | Template |
>    | destinationAddress {readOnly}                        | +----------+
>    |                    {except File Reader/Writer}       |
>    | sourcePort {readOnly} {except File Reader/Writer}    |
>    | destinationPort {readOnly}                           |
>    |                 {except File Reader/Writer}          |
>    | sctpAssocId {readOnly} {SCTP only}                   |
>    | file {readOnly} {File Reader/Writer only}            |
>    | templateRefreshTimeout {readOnly} {UDP only}         |
>    | optionsTemplateRefreshTimeout {readOnly} {UDP only}  |
>    | templateRefreshPacket {readOnly} {UDP only}          |
>    | optionsTemplateRefreshPacket {readOnly} {UDP only}   |
>    | status {readOnly}                                    |
>    | rate {readOnly}                                      |
>    | packets {readOnly}                                   |
>    | bytes {readOnly}                                     |
>    | messages {readOnly}                                  |
>    | discardedMessages {readOnly}                         |
>    | records {readOnly}                                   |
>    | templates {readOnly}                                 |
>    | optionsTemplates {readOnly}                          |
>    | transportSessionDiscontinuityTime {readOnly}         |
>    +------------------------------------------------------+
> 
>                      Figure 21: TransportSession class
> 
>    The TransportSession class contains state data about Transport
>    Sessions originating from an Exporting Process or terminating at a
>    Collecting Process.  The names and semantics of the state parameters
>    correspond to the managed objects in the ipfixTransportSessionTable
>    and ipfixTransportSessionStatsTable of the IPFIX MIB module
>    [I-D.ietf-ipfix-mib].  Hence, if these state parameters are queried
>    from the Monitoring Device, the corresponding IPFIX MIB values can be

They can be queried from other management device.

>    returned without any further processing.  The MIB object
>    ipfixTransportSessionDeviceMode is not included in the
>    TransportSession class because its value can be derived from the
>    scope in which a TransportSession object appears: exporting(1) if it
>    belongs to an Exporting Process, collecting(2) if it belongs to a
>    Collecting Process.
> 
>    The state parameter exportMemberType is only available if the
>    TransportSession class is used within the ExportingProcess class.
>    exportMemberType then contains the value of the MIB object
>    ipfixExportMemberType of the ipfixExportTable of the IPFIX MIB
>    [I-D.ietf-ipfix-mib].
> 

The Destination already has exportMemberType. What is relation between
two object between the object in Destination class and one in this class?

>    The TransportSession class is also used for state data of File
>    Readers and File Writers.  In this case, the "file" parameter
>    specifies the name and location of the file as URI.  To avoid
>    ambiguities, the parameters "protocol", "sourceAddress",
>    "destinationAddress", "sourcePort", "destinationPort", and
>    "sctpAssocId" MUST NOT appear if the parameter "file" is present.
>    The parameter "file" MUST NOT appear if at least one of the
>    parameters "protocol", "sourceAddress", "destinationAddress",
>    "sourcePort", "destinationPort", and "sctpAssocId" is present.  Note
>    that the parameter "file" is currently not included in the IPFIX MIB.
> 

The above paragraph can be removed. Because you already have File
Reader and Writer class.

> 4.7.1.  Template Class
> 
>        +--------------------------------------+
>        | Template                             |
>        +--------------------------------------+
>        | observationDomainId {readOnly}       |<>---+ 0..*
>        | templateId {readOnly}                |     |
>        | setId {readOnly}                     |     |
>        | accessTime {readOnly}                |     |
>        | templateDataRecords {readOnly}       |     |
>        | templateDiscontinuityTime {readOnly} |     |
>        +--------------------------------------+     |
>                                                     |
>                                     +-------------------------------+
>                                     | Field                         |
>                                     +-------------------------------+
>                                     | ieId {readOnly}               |
>                                     | ieLength {readOnly}           |
>                                     | ieEnterpriseNumber {readOnly} |
>                                     | flags {readOnly}              |
>                                     +-------------------------------+
> 
>                          Figure 22: Template class
> 
>    The Template class contains state data about Templates used by an
>    Exporting Process or received by a Collecting Process in a specific
>    Transport Session.  The Field class defines one field of the
>    Template.  The names and semantics of the state parameters correspond
>    to the managed objects in the ipfixTemplateTable,
>    ipfixTemplateDefinitionTable, and ipfixTemplateStatsTable of the
>    IPFIX MIB module [I-D.ietf-ipfix-mib].  Hence, if these state
>    parameters are queried from the Monitoring Device, the corresponding
>    IPFIX MIB values can be returned without any further processing.
> 
> 
> 5.  Adaptation to Device Capabilities
> 
>    The configuration data model standardizes a superset of common IPFIX
>    and PSAMP configuration parameters.  A typical Monitoring Device
>    implementation will not support the entire range of possible
>    configurations.  Certain functions may not be supported, such as the
>    Collecting Process that does not exist on a Monitoring Device
>    conceived as Exporter only.  The configuration of other functions may
>    be subject to resource limitations.  For example, the Cache size is
>    typically limited according to the available memory on the device.
> 
>    YANG [I-D.ietf-netmod-yang] offers several possibilities to restrict
>    and adapt a configuration data model.  The current version of YANG
>    defines the concepts of "features" and "deviations".
> 
>    The feature concept allows the modeler to make proportions of the
>    model conditional in a manner that is controlled by the device.
>    Devices do not have to support these conditional parts to conform to
>    the model.  Those features that are supported by a device must be
>    announced in the <hello> message of the NETCONF protocol [RFC4741].
> 
>    The configuration data model for IPFIX and PSAMP covers the
>    configuration of Exporters, Collectors, and devices that may act as
>    both.  As Exporters and Collectors implement different functions, the
>    corresponding proportions of the model are conditional on the
>    following features:
> 
>    exporter:  If this feature is supported, Exporting Processes can be
>       configured.
> 
>    collector:  If this feature is supported, Collecting Processes can be
>       configured.
> 
>    Exporters do not necessarily implement any Selection Processes,
>    Caches, or even Observation Points in particular cases.  Therefore,
>    the corresponding proportions of the model are conditional on the
>    following feature:
> 
>    meter:  If this feature is supported, Observation Points, Selection
>       Processes, and Caches can be configured.
> 
>    Additional features refer to different PSAMP Sampling and Filtering
>    methods:
> 
>    psampSampCountBased:  If this feature is supported, Sampling method
>       sampCountBased can be configured.
> 
>    psampSampTimeBased:  If this feature is supported, Sampling method
>       sampTimeBased can be configured.
> 
>    psampSampRandOutOfN:  If this feature is supported, Sampling method
>       sampRandOutOfN can be configured.
> 
>    psampSampUniProb:  If this feature is supported, Sampling method
>       sampUniProb can be configured.
> 
>    psampFilterMatch:  If this feature is supported, Filtering method
>       filterMatch can be configured.
> 
>    psampFilterHash:  If this feature is supported, Filtering method
>       filterHash can be configured.
> 
>    The following features concern the support of UDP and TCP as
>    transport protocols and the support of File Readers and File Writers:
> 
>    udpTransport:  If this feature is supported, UDP can be used as
>       transport protocol by Exporting Processes and Collecting
>       Processes.
> 
>    tcpTransport:  If this feature is supported, TCP can be used as
>       transport protocol by Exporting Processes and Collecting
>       Processes.
> 
>    fileReader:  If this feature is supported, Collecting Processes can
>       be configured as File Readers.
> 
>    fileReader:  If this feature is supported, Exporting Processes can be
     ^^^^^^^^^^ fileWriter?

>       configured as File Writers.
> 
>    The deviation concept enables a device to announce deviations from
>    the standard model.  Deviations are typically used to specify
>    limitations due to resource constraints.  Deviations concern existing
>    parameters of the standard model and must not be confused with model
>    extensions that are realized with the YANG statement "augment".  Just
>    like features, deviations are announced in NETCONF's <hello> message.
>    A usage example of deviations is given in Section 7.5.
> 
> 

Regards,
Atsushi

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637