Subject: [IPFIX] review: draft-muenz-ipfix-configuration-04.txt

From: Paul Aitken <[email-masked]>
Date: Tue, 11 Mar 2008 23:01:00 +0000

Gerhard, From [email-masked]  Tue Mar 11 16:03:25 2008
Date: Tue, 11 Mar 2008 23:01:00 +0000
From: Paul Aitken <[email-masked]>
To: Gerhard Muenz <[email-masked]>,
	Benoit Claise <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [IPFIX] review: draft-muenz-ipfix-configuration-04.txt
Sender: [email-masked]

Gerhard, Benoit,

Here with a review of draft-muenz-ipfix-configuration-04.txt

Overall, it's a very strong draft which I'd like to see adopted as a WG 
item.

Cheers,
P.

2.  Introduction, 2nd paragraph:

>    The purpose of this document is the specification of a device-
>    independent configuration data model that covers the commonly
>    available configuration parameters of IPFIX Metering Processes, 
                                            ^^^^^
>    Exporting Processes, and Collecting Processes. 

2.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 [I-D.ietf-ipfix-architecture], per
>    the requirements defined in [RFC3917], which 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.  Finally,
>                                                             ^
>    [I-D.ietf-ipfix-as] 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.

4.  Structure of the Configuration Data Model

>    The IPFIX reference model in [I-D.ietf-ipfix-architecture] specifies
>    the role and function of IPFIX Metering Processes, Exporting
                               ^^^^^
>    Processes, and Collecting Processes. In [I-D.ietf-psamp-framework], the
>    corresponding information is specified for the PSAMP architecture.
>    IPFIX and PSAMP compliant monitoring device implementations usually
>    maintain the separation of Metering Processes, Exporting Processes,
>    and Collecting Processes (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].  The configuration data model enables the setting
>    of commonly available configuration parameters for IPFIX Metering
                                                         ^^^^^
>    Processes, Exporting Processes, and Collecting Processes.

>    In
>    addition, it allows specifying the composition of Metering Processes,
>    Exporting Processes, and Collecting Processes within a monitoring
>    device configuration.

This implies that an Exporting Process and Collecting Process will exist 
within the same device?

Instead, consider:

    In addition, it allows specifying the composition of Metering
    Processes and Exporting Processes within a monitoring device,
    and the associated Collecting Processes.

>    In the following, we use Unified Modeling Language (UML) class
>    diagrams

Could you cite a reference for this please?

>    Figure 1 below shows the main classes in the configuration data model. 
               ^^^^^                        ^^-- or "of"?

>    o  The ObservationPoint class specifies an Observation Point (e.g.
>       interface) of the monitoring device which is used for traffic
>       monitoring.  Furthermore, it configures Metering Processes that
>       process the observed packets.

- it might configure which MP's process the observed packets, but should 
not configure those MPs themselves.

- consider "specifies an *IPFIX* Observation Point".

>    o  The MeteringProcess class represents a Metering Process.  A

- consider "an IPFIX Metering Process".

>       Metering Process requires a record cache which is represented by

- depends on the definition of "record". Most likely the cache contents 
will be related to the data records which appear from the exporting 
process, but we shouldn't assume or imply that the MP cache contains 
exactly those records.

>       an instance of the Cache class.  In order to enable the usage of
>       the same record cache in multiple Metering Processes, the

- please first explain why multiple MP would want to use a single cache? 
And conversely, whether a single MP may use multiple caches, and if so, 
briefly mention why it may wish to do so?

>       MeteringProcess class contains only a reference to an instance of
>       the Cache class.  Note that the usage of the same cache implies
>       that the Template defining the record format is identical for the
>       corresponding Metering Processes.  Additionally, the

Agreed, the cache definitions will be the same. However, I don't like 
using "Template" to describe this, since it implies the Exporting 
Process Template, which may be quite different even for the same cache. 
For clarity, I'd much prefer the cache "template" to have its own name 
(eg, cache definition, cache layout) even if it's essentially a template.

>    o  The SelectionProcess class contains the configuration parameters
>       of a Selection Process, which is a Primitive Selector (i.e.,
>       sampler or filter).  An instance of the SelectionProcess class can
>       be referred to from multiple Metering Processes, which allows the
                     ^^

>    o  The Cache class contains configuration parameters of a cache which
>       stores the Flow Records in the monitoring device.  Configuration
                    ^^^^^^

- because RFC 5101 says "The Metering Process generates Flow Records."

>       parameters of the Cache class specify the record format
>       (Template), expiration parameters, and cache size.  In addition,

Again, even though the cache contents may conveniently expressed as a 
template, IPFIX Templates belong to the Exporting Process, and one cache 
may be exported using many different IPFIX Templates. So for clarity I'd 
prefer to express the cache record format using a different name.

>       references to one or multiple Exporting Processes can be included.
>       An instance of the Cache class can be referred from multiple
>       Metering Processes, enabling the shared usage of the same record
>       cache in different Metering Processes.  As the Template is defined

As above, I'd like to see a small note indicating why this might be 
useful - not as a justification, but simply to clarify the intention to 
the reader.

>       in the Cache class, using the same record cache implies that the
>       record format is identical.  Also, the same Exporting Processes
>       will be used, as these are linked to the record cache.

If the Template is defined in the Cache, aren't you constraining the 
Exporting Process to always export the same cache in the same way? So 
what if two EPs want to export the same fields in different orders, or 
if we want to export a sub-set of fields from the cache? Now different 
export templates are required that don't match the cache template - 
which is why I want to be clear that these "templates" are distinct from 
one another.

>    o  The ExportingProcess class contains configuration parameters of an
>       Exporting Process.  It defines the export parameters and
>       destinations.  An instance of the ExportingProcess class can be
>       referred from multiple instances of the Cache class.

Presumably multiple EPs can be referenced from a single cache, as Figure 
1 seems to show?

>    As can be seen in Figure 1, the MeteringProcess class defines
>    references to instances of the SelectionProcess class and the Cache
>    class.  It acts as an envelope element specifying a series of
>    Selection Processes, forming a Selection Sequence, and a record
>    cache.

>    The order in which the user specifies Selection Processes in
>    the XML document corresponds to the order in which they are applied.
>    Hence, by using UML associations instead of aggregation
>    relationships, the same Selection Processes and record caches can be
>    deployed in different Metering Processes.  An example is given in
>    Section 7.1.

>    The MeteringProcess class itself is not instantiated,
>    but specified as part of the ObservationPoint class.  Using the same
>    Metering Process with different Observation Points is achieved by
>    referring to the same instances of the SelectionProcess class and the
>    Cache class.  Considering Selection Processes and Cache Parameters as
>    instances (and not the complete Metering Process) corresponds to the
>    common practice to implement Selection Processes and record caches as
>    independent modules.

This is a lot of text. Consider breaking it up as shown.

5.1.  ObservationPoint Class

>    The ObservationPoint class identifies an Observation Point of the
>    monitoring device, which is either an interface or a linecard. 

For "post" elements, the OP may be considered to be a process inside the 
box.

RFC 5101 says:

       An Observation Point is a location in the network where IP packets
       can be observed.  Examples include: a line to which a probe is
       attached, a shared medium, such as an Ethernet-based LAN, a single
       port of a router, or a set of interfaces (physical or logical) of
       a router.

- so some grouping of interfaces / linecards may be desirable too.

Also, recall that IPFIX allows an OP to be composed of set of OPs:

       Note that every Observation Point is associated with an
       Observation Domain (defined below), and that one Observation Point
       may be a superset of several other Observation Points.

5.2.  MeteringProcess Class

>    The MeteringProcess class represents a Metering Process.  It refers
>    to one instance of the Cache class that specifies a record cache in
>    the monitoring device.  In addition, the MeteringProcess class may
>    refer to one or multiple instances of the SelectionProcess class
>    which specify sampling and filtering methods applied to the packets
>    before entering the record cache.  The order of the Selection
>    Processes references in the XML document corresponds to the sequence
>    in which they are applied.  If no SelectionProcess is specified, all
>    observed packets are selected. 

Is it possible to disable a MP? ie, to have MPs configured but inactive? 
This may be useful during configuration - so the config can be loaded, 
then activated. It may also be useful to have configs standing by - eg 
day/night monitoring, or weekday/weekend. Or normal / attack scenario.

The same is true for EP too - it may be desirable to have an EP standing 
bye, configured and ready to leap into action at a moment's notice :-)

5.3.  SelectionProcess Class

The configuration parameters seems to be related to the PSAMP 
selectorAlgorithm (even if not quite 1:1?) which is an IANA-controlled 
registry. Do you envisage the configuration model encompassing additions 
to the selectorAlgorithm?

5.4.  Cache Class

>    o  cacheSize: maximum number of records in the cache.

This could be mistaken for the number of bytes the cache consumes. 
Consider eg "maxRecords" ?

>    o  activeTimeout: timeout after which an active Flow is timed out
>       anyway even if there is still a continuous flow of packets.
>    o  idleTimeout: A Flow is considered to be timed out if no packets
>       belonging to the Flow have been observed for the amount of time
>       specified by this parameter.

In what units are these timeouts expressed? What ranges do they have?

5.4.1.  Template Class

Is it likely (or even allowed) that a cache (and thus, the template) 
will contain enterprise specific IEs from different enterprises?

If not, then the field definition need not contain the enterpriseNumber. 
Rather, I expect this would be a property of the Monitoring Process 
(since the MP may be connected to a different vendor's EP).

Presumably the ieID would suffice to indicate that it's an 
enterprise-specific ID by having its top bit set?

>    o  templateId: This is an optional parameter which allows specifying
>       a Template ID value for the Template.  As specified in the IPFIX
>       protocol [RFC5101], the Template ID must be locally unique per
>       Observation Domain and Transport Session,

Oh dear, no! This concerns the Exporting Process, which is nothing to do 
with the Monitoring Process, which is what owns the cache. How do you 
propose to communicate the IDs between the processes?

>    o  isFlowKey: If present, this field is a Flow Key.

It may be more convenient to have a boolean - so, if present and set, 
then the field is a key field.

>    The order of the fields in the XML document corresponds to the order
>    in the Template.

Are implementations free to store the fields in whatever order they 
like? eg, put all the key fields adjacent to one another? Or according 
to draft-irino-ipfix-ie-order ?

5.5.2.  Export Parameters Classes

>    o  sourceIpAddress: In the case of UdpExport, this optional parameter
>       may appear once to set the source IP address.  If this parameter
>       is omitted, the address assigned to the outgoing interface is
>       used.

If the exporring device is a router then it can selects the output 
interface itself, according to its own routing table. But what if it's 
not a router? How would it determine the correct outgoing interface?

>       In the case of SctpExport, 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.

Really? Even if those addresses are assigned to interfaces in different 
networks? :-o

>    o  uri: file name and location encoded as URI if the measurement data
>       is exported to a file.

So the file can be local or even remote?

5.5.3.  Option Class

The list is difficult to read. A little whitespace would improve it 
greatly :-)

> The Option Template can be specified manually, using the
> OptionTemplate class.

Consider adding this as an "or, ..." at the bottom of the list.

> The timeout parameter specifies the reporting interval.

Consider also having a packet interval - because it may be more 
appropriate to export the option (and templates, BTW) more frequently in 
proportion to the amount of data that's exported.

5.5.4.  OptionTemplate Class

Again, the same questions about enterpriseNumber.

> If the parameter isScope is present, the field is a scope field.

Same point about isFlowKey: a boolean may be more useful.

5.6.  CollectingProcess Class and Receiver Class

>    o  ipAddress, transportPort: IP address and port number of the
>       receiving port.  If ipAddress is omitted, the Collecting Process
>       receives data sent to any local IP address.

If there are multiple collecting processes running in the same server, 
would/should they all receive data from the same port(s)? (ie, data 
duplication).

6.  YANG Module of the IPFIX/PSAMP Configuration Data Model

I'm not familiar with YANG, so I didn't review this.

Thanks.
-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

Benoit,

Here with a review of draft-muenz-ipfix-configuration-04.txt

Overall, it's a very strong draft which I'd like to see adopted as a WG 
item.

Cheers,
P.

2.  Introduction, 2nd paragraph:

>    The purpose of this document is the specification of a device-
>    independent configuration data model that covers the commonly
>    available configuration parameters of IPFIX Metering Processes, 
                                            ^^^^^
>    Exporting Processes, and Collecting Processes. 

2.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 [I-D.ietf-ipfix-architecture], per
>    the requirements defined in [RFC3917], which 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.  Finally,
>                                                             ^
>    [I-D.ietf-ipfix-as] 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.

4.  Structure of the Configuration Data Model

>    The IPFIX reference model in [I-D.ietf-ipfix-architecture] specifies
>    the role and function of IPFIX Metering Processes, Exporting
                               ^^^^^
>    Processes, and Collecting Processes. In [I-D.ietf-psamp-framework], the
>    corresponding information is specified for the PSAMP architecture.
>    IPFIX and PSAMP compliant monitoring device implementations usually
>    maintain the separation of Metering Processes, Exporting Processes,
>    and Collecting Processes (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].  The configuration data model enables the setting
>    of commonly available configuration parameters for IPFIX Metering
                                                         ^^^^^
>    Processes, Exporting Processes, and Collecting Processes.

>    In
>    addition, it allows specifying the composition of Metering Processes,
>    Exporting Processes, and Collecting Processes within a monitoring
>    device configuration.

This implies that an Exporting Process and Collecting Process will exist 
within the same device?

Instead, consider:

    In addition, it allows specifying the composition of Metering
    Processes and Exporting Processes within a monitoring device,
    and the associated Collecting Processes.

>    In the following, we use Unified Modeling Language (UML) class
>    diagrams

Could you cite a reference for this please?

>    Figure 1 below shows the main classes in the configuration data model. 
               ^^^^^                        ^^-- or "of"?

>    o  The ObservationPoint class specifies an Observation Point (e.g.
>       interface) of the monitoring device which is used for traffic
>       monitoring.  Furthermore, it configures Metering Processes that
>       process the observed packets.

- it might configure which MP's process the observed packets, but should 
not configure those MPs themselves.

- consider "specifies an *IPFIX* Observation Point".

>    o  The MeteringProcess class represents a Metering Process.  A

- consider "an IPFIX Metering Process".

>       Metering Process requires a record cache which is represented by

- depends on the definition of "record". Most likely the cache contents 
will be related to the data records which appear from the exporting 
process, but we shouldn't assume or imply that the MP cache contains 
exactly those records.

>       an instance of the Cache class.  In order to enable the usage of
>       the same record cache in multiple Metering Processes, the

- please first explain why multiple MP would want to use a single cache? 
And conversely, whether a single MP may use multiple caches, and if so, 
briefly mention why it may wish to do so?

>       MeteringProcess class contains only a reference to an instance of
>       the Cache class.  Note that the usage of the same cache implies
>       that the Template defining the record format is identical for the
>       corresponding Metering Processes.  Additionally, the

Agreed, the cache definitions will be the same. However, I don't like 
using "Template" to describe this, since it implies the Exporting 
Process Template, which may be quite different even for the same cache. 
For clarity, I'd much prefer the cache "template" to have its own name 
(eg, cache definition, cache layout) even if it's essentially a template.

>    o  The SelectionProcess class contains the configuration parameters
>       of a Selection Process, which is a Primitive Selector (i.e.,
>       sampler or filter).  An instance of the SelectionProcess class can
>       be referred to from multiple Metering Processes, which allows the
                     ^^

>    o  The Cache class contains configuration parameters of a cache which
>       stores the Flow Records in the monitoring device.  Configuration
                    ^^^^^^

- because RFC 5101 says "The Metering Process generates Flow Records."

>       parameters of the Cache class specify the record format
>       (Template), expiration parameters, and cache size.  In addition,

Again, even though the cache contents may conveniently expressed as a 
template, IPFIX Templates belong to the Exporting Process, and one cache 
may be exported using many different IPFIX Templates. So for clarity I'd 
prefer to express the cache record format using a different name.

>       references to one or multiple Exporting Processes can be included.
>       An instance of the Cache class can be referred from multiple
>       Metering Processes, enabling the shared usage of the same record
>       cache in different Metering Processes.  As the Template is defined

As above, I'd like to see a small note indicating why this might be 
useful - not as a justification, but simply to clarify the intention to 
the reader.

>       in the Cache class, using the same record cache implies that the
>       record format is identical.  Also, the same Exporting Processes
>       will be used, as these are linked to the record cache.

If the Template is defined in the Cache, aren't you constraining the 
Exporting Process to always export the same cache in the same way? So 
what if two EPs want to export the same fields in different orders, or 
if we want to export a sub-set of fields from the cache? Now different 
export templates are required that don't match the cache template - 
which is why I want to be clear that these "templates" are distinct from 
one another.

>    o  The ExportingProcess class contains configuration parameters of an
>       Exporting Process.  It defines the export parameters and
>       destinations.  An instance of the ExportingProcess class can be
>       referred from multiple instances of the Cache class.

Presumably multiple EPs can be referenced from a single cache, as Figure 
1 seems to show?

>    As can be seen in Figure 1, the MeteringProcess class defines
>    references to instances of the SelectionProcess class and the Cache
>    class.  It acts as an envelope element specifying a series of
>    Selection Processes, forming a Selection Sequence, and a record
>    cache.

>    The order in which the user specifies Selection Processes in
>    the XML document corresponds to the order in which they are applied.
>    Hence, by using UML associations instead of aggregation
>    relationships, the same Selection Processes and record caches can be
>    deployed in different Metering Processes.  An example is given in
>    Section 7.1.

>    The MeteringProcess class itself is not instantiated,
>    but specified as part of the ObservationPoint class.  Using the same
>    Metering Process with different Observation Points is achieved by
>    referring to the same instances of the SelectionProcess class and the
>    Cache class.  Considering Selection Processes and Cache Parameters as
>    instances (and not the complete Metering Process) corresponds to the
>    common practice to implement Selection Processes and record caches as
>    independent modules.

This is a lot of text. Consider breaking it up as shown.

5.1.  ObservationPoint Class

>    The ObservationPoint class identifies an Observation Point of the
>    monitoring device, which is either an interface or a linecard. 

For "post" elements, the OP may be considered to be a process inside the 
box.

RFC 5101 says:

       An Observation Point is a location in the network where IP packets
       can be observed.  Examples include: a line to which a probe is
       attached, a shared medium, such as an Ethernet-based LAN, a single
       port of a router, or a set of interfaces (physical or logical) of
       a router.

- so some grouping of interfaces / linecards may be desirable too.

Also, recall that IPFIX allows an OP to be composed of set of OPs:

       Note that every Observation Point is associated with an
       Observation Domain (defined below), and that one Observation Point
       may be a superset of several other Observation Points.

5.2.  MeteringProcess Class

>    The MeteringProcess class represents a Metering Process.  It refers
>    to one instance of the Cache class that specifies a record cache in
>    the monitoring device.  In addition, the MeteringProcess class may
>    refer to one or multiple instances of the SelectionProcess class
>    which specify sampling and filtering methods applied to the packets
>    before entering the record cache.  The order of the Selection
>    Processes references in the XML document corresponds to the sequence
>    in which they are applied.  If no SelectionProcess is specified, all
>    observed packets are selected. 

Is it possible to disable a MP? ie, to have MPs configured but inactive? 
This may be useful during configuration - so the config can be loaded, 
then activated. It may also be useful to have configs standing by - eg 
day/night monitoring, or weekday/weekend. Or normal / attack scenario.

The same is true for EP too - it may be desirable to have an EP standing 
bye, configured and ready to leap into action at a moment's notice :-)

5.3.  SelectionProcess Class

The configuration parameters seems to be related to the PSAMP 
selectorAlgorithm (even if not quite 1:1?) which is an IANA-controlled 
registry. Do you envisage the configuration model encompassing additions 
to the selectorAlgorithm?

5.4.  Cache Class

>    o  cacheSize: maximum number of records in the cache.

This could be mistaken for the number of bytes the cache consumes. 
Consider eg "maxRecords" ?

>    o  activeTimeout: timeout after which an active Flow is timed out
>       anyway even if there is still a continuous flow of packets.
>    o  idleTimeout: A Flow is considered to be timed out if no packets
>       belonging to the Flow have been observed for the amount of time
>       specified by this parameter.

In what units are these timeouts expressed? What ranges do they have?

5.4.1.  Template Class

Is it likely (or even allowed) that a cache (and thus, the template) 
will contain enterprise specific IEs from different enterprises?

If not, then the field definition need not contain the enterpriseNumber. 
Rather, I expect this would be a property of the Monitoring Process 
(since the MP may be connected to a different vendor's EP).

Presumably the ieID would suffice to indicate that it's an 
enterprise-specific ID by having its top bit set?

>    o  templateId: This is an optional parameter which allows specifying
>       a Template ID value for the Template.  As specified in the IPFIX
>       protocol [RFC5101], the Template ID must be locally unique per
>       Observation Domain and Transport Session,

Oh dear, no! This concerns the Exporting Process, which is nothing to do 
with the Monitoring Process, which is what owns the cache. How do you 
propose to communicate the IDs between the processes?

>    o  isFlowKey: If present, this field is a Flow Key.

It may be more convenient to have a boolean - so, if present and set, 
then the field is a key field.

>    The order of the fields in the XML document corresponds to the order
>    in the Template.

Are implementations free to store the fields in whatever order they 
like? eg, put all the key fields adjacent to one another? Or according 
to draft-irino-ipfix-ie-order ?

5.5.2.  Export Parameters Classes

>    o  sourceIpAddress: In the case of UdpExport, this optional parameter
>       may appear once to set the source IP address.  If this parameter
>       is omitted, the address assigned to the outgoing interface is
>       used.

If the exporring device is a router then it can selects the output 
interface itself, according to its own routing table. But what if it's 
not a router? How would it determine the correct outgoing interface?

>       In the case of SctpExport, 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.

Really? Even if those addresses are assigned to interfaces in different 
networks? :-o

>    o  uri: file name and location encoded as URI if the measurement data
>       is exported to a file.

So the file can be local or even remote?

5.5.3.  Option Class

The list is difficult to read. A little whitespace would improve it 
greatly :-)

> The Option Template can be specified manually, using the
> OptionTemplate class.

Consider adding this as an "or, ..." at the bottom of the list.

> The timeout parameter specifies the reporting interval.

Consider also having a packet interval - because it may be more 
appropriate to export the option (and templates, BTW) more frequently in 
proportion to the amount of data that's exported.

5.5.4.  OptionTemplate Class

Again, the same questions about enterpriseNumber.

> If the parameter isScope is present, the field is a scope field.

Same point about isFlowKey: a boolean may be more useful.

5.6.  CollectingProcess Class and Receiver Class

>    o  ipAddress, transportPort: IP address and port number of the
>       receiving port.  If ipAddress is omitted, the Collecting Process
>       receives data sent to any local IP address.

If there are multiple collecting processes running in the same server, 
would/should they all receive data from the same port(s)? (ie, data 
duplication).

6.  YANG Module of the IPFIX/PSAMP Configuration Data Model

I'm not familiar with YANG, so I didn't review this.

Thanks.
-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix