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

From: Gerhard Muenz <[email-masked]>
Date: Wed, 06 Jan 2010 13:11:39 +0100

Obviously, this mail did not make it to the ML.

-------- Original Message --------
Subject: Re: [IPFIX] WGLC comments on 
draft-ietf-ipfix-configuration-model-04
Date: Mon, 04 Jan 2010 12:59:13 +0100
From: Gerhard Muenz <[email-masked]>
To: Atsushi Kobayashi <[email-masked]>
CC: [email-masked]
References: <[email-masked]>

Hi Atsushi,

Thank you very much for you comments.

Please find my answers inline.

Regards,
Gerhard

Atsushi Kobayashi wrote:
> 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?

Fixed.

> 
>>    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.
>>
>>

[snip]

>> 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?

No.

"Mapping between the configuration data model and device-specific
configuration data" means that CDM parameters must correspond to
device-specific parameters.  If this is fulfilled, the CDM can be easily
converted into the device-specific data (CLI, XML, or whatever) and vice
versa.  On the other hand, if the device-specific parameters have a very
different meaning, a conversion is not possible (or at least difficult).

Side note: The conversion can be realized at different places, for example:
- in the management system
- on the device by running an agent

What shall we do with the last sentence "However,...."?
Remove it?

>>    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.
>>

[snip]

>> 2.  Terminology

[snip]

>>    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.

The only difference between a PSAMP Packet Report and an IPFIX Flow
Record is that the Packet Report always carries information about a
single packet while the Flow Record may contain information about
multiple packets.

The CDM always includes a Cache as part of the Metering Process, even if
Packet Reports are generated, because this is the place where the fields
contained in the record are defined.  The Cache Mode specifies the
expiration policy and thus whether one or multiple packets are included
in a record.

Is there a need to clarify the definition of Cache?

>>    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?

The whole paragraph will removed in the next version of the draft.

We had a discussion about this issue in the context of IPFIX MIB.  In
fact, there is no IPFIX document which says that packets observed at
different ODs must not enter the same MP.  Therefore, we did not add any
additional restriction on this in the IPFIX MIB, and we do not want to
do this here, either.

For clarification, I propose to add one sentence to the preceding paragraph:

NEW:
     ... 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 Observed Packet Stream at the input of a Selection
     Process is composed of packets from a single Observation Point. ...

Is this ok?

>>    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.

I do not understand your point.  If there is any inconsistency, please
explain it to me.

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

No.  This RFC will not cover IPFPIX 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.

I do not understand.  Why shall a Monitoring Device query state
information from another 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?

Fixed:
The remaining parameters have either a default value, the "{opt.}"
property, or a multiplicity indicator starting with zero.

>>    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.
>>

[snip]

>> 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.

All Selection Process are located in front of a Cache, not behind.

> 
>>       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.

NEW:

     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 an Observation Point.  Therefore, a
        SelectionProcess object MAY be referred to from a single
        ObservationPoint object.

        It is possible to cascade different Selection Processes.  In this
        case, the Selected Packet Stream at the output of a Selection
        Process is passed to the input of another Selection Process.
        Therefore, one SelectionProcess object may refer to other objects
        of the same class.  A configuration example is given below in
        Section 7.3.

        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.

        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.

This whole sentence will be removed.

>>
>>       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 |
>>                         +------------------+

NEW:

                          +------------------+
                          | ObservationPoint |
                          +------------------+
                               0..1 |
                                    |
                               0..* V
                          +------------------+
                          | SelectionProcess |
                          +------------------+<-+
                               0..* |  0..1 |   | 0..*
                                    |       +---+
                               0..* V
                          +------------------+
                          | Cache            |
                          +------------------+
                               0..* |
                                    |
                               0..* V
                          +------------------+
                          | ExportingProcess |
                          +------------------+

>>
>>              Figure 4: Class diagram of Exporter configuration
>>

[snip]

>> 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?

With respect to the CDM, there is no restriction.  Multiple
ObservationPoint objects belonging to different Observation Domain IDs
can have the same IfIndex value.

>>    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.

I do not understand.  SelectonProcess class corresponds to
ipfixSelectionProcessTable in the 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].
>>

[snip]

>> 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?

No.  The reason is that min/max fields are not specified in the Selector
Report Interpretation:
http://tools.ietf.org/html/rfc5476#section-6.5.2.5

In the case of FilterHash, we do min/max fields in the Selector Report
Interpretation:
http://tools.ietf.org/html/rfc5476#section-6.5.2.6

> And, I would like to specify its instruction, "match" or "unmatch".

This is not specified in the Selector Report Interpretation. Therefore,
we cannot allow configuring this.

>>    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?

There are various possibilities, such as dropping or early expiration of
Flows.  I do not think that we need to specify the behavior.

>>    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.

NEW:

     activeTimeout:  This parameter configures the time in milliseconds
        after which a Flow Record is expired even though packets matching
        this Flow are still received by the Cache.  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.  This parameter is only available for Cache Mode
        "timeout".

     inactiveTimeout:  This parameter configures the time in milliseconds
        after which a Flow Record is expired if no packets matching this
        Flow are received by the Cache.  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.  This parameter is only available for Cache Mode
        "timeout".

     exportInterval:  This parameter configures the interval for
        periodical export of Flow Records in milliseconds.  If not
        configured by the user, the Monitoring Device sets this parameter.
        It is only available for Cache Mode "permanent".

>>
>>    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].
>>

[snip]

>> 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.

We adopted this parameter because the Cisco CLI has it for UDP.  As far
as I understand, it is not used to specify the outgoing interface but
the (forged) source address in the IP header only.

How do you want to forge the IP address of a TCP endpoint?  It must
belong to the interface.

The parameter description remains unclear in the case of multiple
addresses assigned to a single interface.

I'm not sure what to do.
We can remove the parameter.
We can change to "...one of the addresses assigned to the outgoing
interface is used."
We can try to find a generic solution that defines the outgoing interface.

>>    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.
>>

[snip]

>> 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.

I do not understand.  Are you confusing "queried from" with "queried by"?

>>    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?

This is state data of a Transport Session, the other is configuration
data of an Exporting Process.

>>    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.

No.

All these state parameters may be interesting for File Writers/Readers:

     | status {readOnly}                                    |
     | rate {readOnly}                                      |
     | packets {readOnly}                                   |
     | bytes {readOnly}                                     |
     | messages {readOnly}                                  |
     | discardedMessages {readOnly}                         |
     | records {readOnly}                                   |
     | templates {readOnly}                                 |
     | optionsTemplates {readOnly}                          |
     | transportSessionDiscontinuityTime {readOnly}         |

Therefore, we have a Transport Session entry for File Readers/Writers.

>> 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?

Fixed.

> 
>>       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

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz