[IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Flow Information Export Working Group of the IETF.

	Title           : IPFIX Mediation: Problem Statement
	Author(s)       : A. Kobayashi, et al.
	Filename        : draft-ietf-ipfix-mediators-problem-statement-02.txt
	Pages           : 26
	Date            : 2009-02-04

Flow-based measurement is a popular method for various network
monitoring usages.  The sharing of flow-based information for
monitoring applications having different requirements raises some
open issues in terms of scalability, reliability, and flexibility
that IPFIX Mediation may help resolve.  IPFIX Mediation covers two
classes of mediation: context mediation for traffic data and
transport mediation for transport protocols.  This document describes
the problems that network administrators have been facing and the
applicability of IPFIX Mediation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: [IPFIX] IPFIX Mediator - Term Definition

Gerhard and Benoit,

I submitted new version problem statement draft just now. It took more
long time than I have expected.

I tried to merge Benoit's idea and Gerhard's idea regarding terminology
section. I propose that IPFIX Mediation indicates the generic term of
some capabilities, and IPFIX Concentrator, Proxy and Masquerading Proxy
indicate specific capability of IPFIX Mediation.

Please see section 2, and let me know your comments.

http://tools.ietf.org/html/draft-ietf-ipfix-mediators-problem-statement-02#section-2

Thanks,
Atsushi Kobayashi

On Fri, 21 Nov 2008 12:29:15 +0100
Gerhard Muenz <muenz <at> net.in.tum.de> wrote:

> 
> Benoit,
> 
> Benoit Claise wrote:
> >  Christoph, All,
> > 
> > I agree there is some confusion with regards to the terminology.
> > Here is a proposal
> > 

Re: [IPFIX] Mediator Problem Statement: Review

Gerhard and all,

I improve the problem statement draft according to following your
suggestion. I added new section "Problem Statement" showing the problems
that network operators have been facing. 

http://tools.ietf.org/html/draft-ietf-ipfix-mediators-problem-statement-02#section-4

And I added "implementation analysis" in each applicable examples. It
includes several implementation examples other than IPFIX Mediation.

I think the next version meets your suggestion. I would appreciate it if
you put your comments in mail list.

Thanks,
Atsushi Kobayashi

On Wed, 19 Nov 2008 20:28:49 +0100
Gerhard Muenz <muenz <at> net.in.tum.de> wrote:

> I think it is ok to discuss what is possible without Mediation and to
> show the limits of "state-of-the-art" IPFIX.
> So, you could
> - present a problem,
> - show how the problem could be solved without mediation  (if possible),
> - argue why this solution is not optimal, and
> - present how mediation enables a better solution.

--- 

[IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Flow Information Export Working Group of the IETF.

	Title           : IPFIX Mediation: Framework
	Author(s)       : A. Kobayashi, et al.
	Filename        : draft-ietf-ipfix-mediators-framework-02.txt
	Pages           : 24
	Date            : 2009-02-10

This document describes a framework for IPFIX Mediation.  This
framework details the IPFIX Mediation reference model and the
components of an IPFIX Mediator.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

[IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Re: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification

Hi Benoit, all,

Hm, that's still kind of confusing. First off, there's no "reliable  
mode" in PR-SCTP. SCTP is modeless, reliability is per-message. PR- 
SCTP can provide "fully reliable" transport. But this terminology  
seems to be overloaded:

"If the path from the Exporting Process to the Collecting Process is  
full reliable"

What does this mean, precisely? My assumption is that it means "if the  
link between the Exporting Process and the Collecting Process has low  
loss and reordering characteristics..." However, the guidance doesn't  
actually change depending on the loss characteristics of the lower  
layer: RR prefers reliable transport for Common Properties, full stop.  
I'd suggest (as usual...) removing any mention of UDP as recommended:

NEW:
The proposed method is most effective using a reliable transport  
protocol for the transfer of the Common Properties. Therefore the use  
of PR-SCTP with the full reliability or TCP is recommended for the  
transmission of IPFIX Messages containing Common Properties.

Cheers,

Brian

On Feb 11, 2009, at 4:40 PM, Benoit Claise wrote:

> Dear all,
>
> We received the following remark from Sven regarding http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt
>> 8.1.  Transport Protocol Choice
>>
>>   The proposed method is most effective using a reliable transport
>>   protocol for the transfer of the Common Properties.  Therefore the
>>   use of PR-SCTP with the reliable mode or TCP is recommended.
>>   However, if the path from the Exporting Process to the Collecting
>>   Process is not fully reliable, the SCTP or TCP retransmission might
>>   reduce the benefits of this specification.  If the path from the
>>   Exporting Process to the Collecting Process is full reliable, the  
>> use
>>   of UDP is less effective because the Common Properties have to be  
>> re-
>>   sent regularly.
>
> Do I understand that section correctly: If the path is reliable, you  
> should use a reliable transport, and if the path is unreliable you  
> should use unreliable UDP? Isn't that upside down? If the path is  
> reliable, you can use UDP _without_ retransmission, no need for a  
> reliable transport protocol then.
> We proposed the following text, removing the confusing sentence.
> NEW:
>
>    The proposed method is most effective using a reliable transport
>    protocol for the transfer of the Common Properties.  Therefore the
>    use of PR-SCTP with the reliable mode or TCP is recommended.
>    If the path from the Exporting Process to the Collecting Process is
>    full reliable, the use of UDP is less effective because the Common
>    Properties have to be re-sent regularly.
>
> Any objections?
> Pending on nobody objecting in a couple of work days,  this  
> editorial disambiguation will be applied.
>
> Regards, Benoit.
> _______________________________________________
> IPFIX mailing list
> IPFIX <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Re: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification

Brian,

First of all, I would like to have Sven's feedback, as he was the one 
asking for this change.
Then, see inline.
> Hi Benoit, all,
>
> Hm, that's still kind of confusing. First off, there's no "reliable 
> mode" in PR-SCTP. SCTP is modeless, reliability is per-message. 
> PR-SCTP can provide "fully reliable" transport. But this terminology 
> seems to be overloaded:
>
> "If the path from the Exporting Process to the Collecting Process is 
> full reliable"
>
> What does this mean, precisely? My assumption is that it means "if the 
> link between the Exporting Process and the Collecting Process has low 
> loss and reordering characteristics..." However, the guidance doesn't 
> actually change depending on the loss characteristics of the lower 
> layer: RR prefers reliable transport for Common Properties, full stop. 
> I'd suggest (as usual...) removing any mention of UDP as recommended:
The recommendation doesn't change, agreed.
But the sentence is a warning/clarification against the use of UDP, even 
if the path is fully reliable.
So my preference is to keep this sentence (slightly modified, see 
below)... however, this is a minor point IMHO.
What are the others thinking?

>
> NEW:
> The proposed method is most effective using a reliable transport 
> protocol for the transfer of the Common Properties. Therefore the use 
> of PR-SCTP with the full reliability or TCP is recommended for the 
> transmission of IPFIX Messages containing Common Properties.
NEW:
    The proposed method is most effective using a reliable transport 
protocol for the transfer
    of the Common Properties. Therefore the use of PR-SCTP with the full 
reliability or TCP
    is recommended for the transmission of IPFIX Messages containing 
Common Properties.
    If the path from the Exporting Process to the Collecting Process is 
fully reliable (i.e., no loss),
    the use of UDP is less effective because the Common Properties have 
to be re-sent regularly.

Regards, Benoit.
>
> Cheers,
>
> Brian
>
> On Feb 11, 2009, at 4:40 PM, Benoit Claise wrote:
>
>> Dear all,
>>
>> We received the following remark from Sven regarding 
>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt 
>>
>>> 8.1.  Transport Protocol Choice
>>>
>>>   The proposed method is most effective using a reliable transport
>>>   protocol for the transfer of the Common Properties.  Therefore the
>>>   use of PR-SCTP with the reliable mode or TCP is recommended.
>>>   However, if the path from the Exporting Process to the Collecting
>>>   Process is not fully reliable, the SCTP or TCP retransmission might
>>>   reduce the benefits of this specification.  If the path from the
>>>   Exporting Process to the Collecting Process is full reliable, the use
>>>   of UDP is less effective because the Common Properties have to be re-
>>>   sent regularly.
>>
>> Do I understand that section correctly: If the path is reliable, you 
>> should use a reliable transport, and if the path is unreliable you 
>> should use unreliable UDP? Isn't that upside down? If the path is 
>> reliable, you can use UDP _without_ retransmission, no need for a 
>> reliable transport protocol then.
>> We proposed the following text, removing the confusing sentence.
>> NEW:
>>
>>    The proposed method is most effective using a reliable transport
>>    protocol for the transfer of the Common Properties.  Therefore the
>>    use of PR-SCTP with the reliable mode or TCP is recommended.
>>    If the path from the Exporting Process to the Collecting Process is
>>    full reliable, the use of UDP is less effective because the Common
>>    Properties have to be re-sent regularly.
>>
>> Any objections?
>> Pending on nobody objecting in a couple of work days,  this editorial 
>> disambiguation will be applied.
>>
>> Regards, Benoit.
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Re: [IPFIX] draft-ietf-ipfix-reducing-redundancy-04.txt: text clarification

Hi, Benoit,

Two minor points:

1. Change "...the use of PR-SCTP with the full reliability..." to  
"...the use of PR-SCTP with full reliability..." (no need for the  
article). Oops, sorry about that.

2. This proposed change is much, much clearer. However, I'm still not  
convinced that
    (a) the recommendation against UDP is _really_ dependent on the  
loss characteristics of the lower layer; or that
    (b) on a second reading, this should really be a recommendation  
against UDP, but rather a caveat given that UDP has already been  
chosen (after all, if you're using UDP, you're doing NetFlow  
replacement, you've presumably already read Section 6.2 of RFC5153 and  
know all the caveats, and you're going to use UDP anyway). So I think  
the recommendation here would be clearer and more internally  
consistent if it restated the caveats in Section 4.2, instead:

So, I'd suggest:

NEW:

   The proposed method is most effective using a reliable transport  
protocol for the transfer
   of the Common Properties. Therefore the use of PR-SCTP with full  
reliability or TCP
   is recommended for the transmission of IPFIX Messages containing  
Common Properties.
   Note that this method loses some of its effectiveness if  UDP is  
used for the transmission
   of IPFIX Messages containing Common Properties, since the Common  
Properties MUST then,
   like Templates, be re-sent at regular intervals as in Section 4.2.

Cheers,

Brian

On Feb 12, 2009, at 9:38 AM, Benoit Claise wrote:

> Brian,
>
> First of all, I would like to have Sven's feedback, as he was the  
> one asking for this change.
> Then, see inline.
>> Hi Benoit, all,
>>
>> Hm, that's still kind of confusing. First off, there's no "reliable  
>> mode" in PR-SCTP. SCTP is modeless, reliability is per-message. PR- 
>> SCTP can provide "fully reliable" transport. But this terminology  
>> seems to be overloaded:
>>
>> "If the path from the Exporting Process to the Collecting Process  
>> is full reliable"
>>
>> What does this mean, precisely? My assumption is that it means "if  
>> the link between the Exporting Process and the Collecting Process  
>> has low loss and reordering characteristics..." However, the  
>> guidance doesn't actually change depending on the loss  
>> characteristics of the lower layer: RR prefers reliable transport  
>> for Common Properties, full stop. I'd suggest (as usual...)  
>> removing any mention of UDP as recommended:
> The recommendation doesn't change, agreed.
> But the sentence is a warning/clarification against the use of UDP,  
> even if the path is fully reliable.
> So my preference is to keep this sentence (slightly modified, see  
> below)... however, this is a minor point IMHO.
> What are the others thinking?
>
>
>>
>> NEW:
>> The proposed method is most effective using a reliable transport  
>> protocol for the transfer of the Common Properties. Therefore the  
>> use of PR-SCTP with the full reliability or TCP is recommended for  
>> the transmission of IPFIX Messages containing Common Properties.
> NEW:
>   The proposed method is most effective using a reliable transport  
> protocol for the transfer
>   of the Common Properties. Therefore the use of PR-SCTP with the  
> full reliability or TCP
>   is recommended for the transmission of IPFIX Messages containing  
> Common Properties.
>   If the path from the Exporting Process to the Collecting Process  
> is fully reliable (i.e., no loss),
>   the use of UDP is less effective because the Common Properties  
> have to be re-sent regularly.
>
>
> Regards, Benoit.
>>
>> Cheers,
>>
>> Brian
>>
>> On Feb 11, 2009, at 4:40 PM, Benoit Claise wrote:
>>
>>> Dear all,
>>>
>>> We received the following remark from Sven regarding http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reducing-redundancy-04.txt
>>>> 8.1.  Transport Protocol Choice
>>>>
>>>>  The proposed method is most effective using a reliable transport
>>>>  protocol for the transfer of the Common Properties.  Therefore the
>>>>  use of PR-SCTP with the reliable mode or TCP is recommended.
>>>>  However, if the path from the Exporting Process to the Collecting
>>>>  Process is not fully reliable, the SCTP or TCP retransmission  
>>>> might
>>>>  reduce the benefits of this specification.  If the path from the
>>>>  Exporting Process to the Collecting Process is full reliable,  
>>>> the use
>>>>  of UDP is less effective because the Common Properties have to  
>>>> be re-
>>>>  sent regularly.
>>>
>>> Do I understand that section correctly: If the path is reliable,  
>>> you should use a reliable transport, and if the path is unreliable  
>>> you should use unreliable UDP? Isn't that upside down? If the path  
>>> is reliable, you can use UDP _without_ retransmission, no need for  
>>> a reliable transport protocol then.
>>> We proposed the following text, removing the confusing sentence.
>>> NEW:
>>>
>>>   The proposed method is most effective using a reliable transport
>>>   protocol for the transfer of the Common Properties.  Therefore the
>>>   use of PR-SCTP with the reliable mode or TCP is recommended.
>>>   If the path from the Exporting Process to the Collecting Process  
>>> is
>>>   full reliable, the use of UDP is less effective because the Common
>>>   Properties have to be re-sent regularly.
>>>
>>> Any objections?
>>> Pending on nobody objecting in a couple of work days,  this  
>>> editorial disambiguation will be applied.
>>>
>>> Regards, Benoit.
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

[IPFIX] Maji - an open source IPFIX meter implementation

Hi all,

I'm pleased to announce that maji, an open source implementation of an 
IPFIX meter developed at the University of Waikato, has finally been 
released.

Some of the major features include:
    * Read packets from a variety of sources including PCAP interfaces, 
trace files and DAG capture cards
    * Support for over 50 different standard information elements 
defined in RFC 5101
    * Define your own data and option templates, rather than being 
limited to fixed templates
    * Export IPFIX messages via SCTP, TCP or UDP, or export IPFIX flow 
records directly to an SQLite database

One of the design goals for maji was to create a framework that could be 
utilised by researchers to test new concepts and ideas for IPFIX without 
having to implement the entire protocol themselves. To this end, maji 
can be easily extended to include new information elements, export 
formats or special templates. A series of developer notes are included 
as part of the documentation that should aid anyone looking to build 
upon our code.

Further details and a link to download maji can be found at 
http://research.wand.net.nz/software/maji.php

We appreciate any feedback you might have about maji. Please direct any 
questions, comments or bug reports to myself or feel free to file a 
ticket in our bug tracker at http://www.wand.net.nz/trac/traceflow_ipfix

Shane Alcock
Research Assistant
WAND Network Research Group
University of Waikato
Hamilton, New Zealand
Email: salcock <at> cs.waikato.ac.nz

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

[IPFIX] AD review of draft-ietf-ipfix-mib-05.txt

Please find below the AD (and MIB doctor) review of
draft-ietf-ipfix-mib-05.txt. This I-D is not ready yet for IETF Last
Call. Please address the issues below and issue a new I-D. 

Part of the comments were contributed by Bert Wijnen. 

I have divided the comments into Technical and Editorial. 

Thanks and Regards,

Dan

T1. INET-ADDRESS-MIB is IMPORT-ed from RFC 4001and not from RFC 3291

T2. There is no real justification for defining a new TC for
IpfixFunctionAvailability. As per RFC 4181, use TruthValue instead. 

T3. The top level structure of the MIB does not follow the
recommendation in Appendix D of RFC 4181 concerning the OID layout: 

  xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)

T4. The object iffixTransportSessionProtocol uses only 3 out of the 255
possible values in the range (6, 17, 132). A better SYNTAX would be just
INTEGER and then enumerate the three values in the MODULE-COMPLIANCE
clause. This would allow future changes by just another
MODULE-COMPLIANCE if there is a need to add a new protocol. If you
believe that another transport will be never added the appropriate
SYNTAX would be INTEGER (6|17|132). Also provide
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
as REFERENCE.

T5. There is only one InetAddressType object for both source and
destination addresses. Does this mean that an IPFIX session is only IPv4
to IPv4 or IPv6 to IPv6? This is a question, I apologize if it is a
layman one. In any case, it would be good to write an explanation, as
users of the RFC 4001 addresses TCs are used to always encounter pairs
of type-address objects. 

T6. Why are the address type and addresses objects only valid for UDP
and TCP, and not for SCTP? Are not STCP session also conducted between
IP hosts that can be described by IP addresses? 

T7. What does 'this object is only valid' mean for the address type and
addresses objects? What is returned by the agent in this case on a Get
operation on these objects? 

T8. The InetPort TC IMPORT-ed from RFC 4001 looks like a more
appropriate SYNTAX for the ipfixTransportSessionSourcePort and
ipfixTransportSessionDestinationPort objects

T9. I cannot figure out what is the role of all the DEFVAL clauses in
this MIB module. All the MIB is read-only and there is no dynamic row
creation. Why are they needed? 

T10. Many of the objects in the MIB modules - especially counters and
gauges - would benefit from defining UNITS clauses. In some places they
are mentioned in the DESCRIPTION clauses, but using explicit UNITS
clauses wherever possible is better. 

T11. Some object names in table do not respect the naming conventions
that recommends that table names and objects have an identical suffix -
ipfixObservationDomainId,  ipfixObservationPointGroupReference,
ipfixPhysicalEntity, ipfixPhysicalEntityDirection

T12. Some objects are completely missing REFERENCE clauses - especially
in the first tables o the MIB. Some other clauses could benefit from
more exact referencing, saying just [RFC5101] without mentioning the
exact section is not very useful. 

T13. Why is the range of ipfixTemplateDefinitionLength 1..2147483547)?
According to RFC 5101, section 7, page 31 it looks like it should be
(0..65535)

T14. Give http://www.iana.org/assignments/enterprise-numbers/ as
REFERENCE for ipfixTemplateDefinitionEnterprise

T15. Use hex notations for describing values in the DESCRIPTION clause
of ipfixTemplateDefintionFlags - the decimal values do not correspond to
the bits positions

T16. ipfixExportEntry leads to a warning in the smicng compilation 

W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a
consistent indexing scheme - index items from current table must come
after index items from other tables

T17. A couple of enumerated objects start to value 0 which is not
recommended unless special cases. Are there special cases here for
ipfixExportMemberType and ipfixPhysicalEntityDirection

T18. Unsigned32 seems to be a better SYNTAX than Integer32 (see RFC
4181) for the following objects: ipfixMeteringProcessId,
ipfixObservationPointGroupReference, ipfixObservationPointIndex,
ipfixTransportSessionRate

T19. I cannot understand what useful information carries
ipfixmeteringProcessId - it is not an index and its value is
implementation dependent. 

T20. Does it make sense for the ipfixSelectorFunction to point to a
function that is not available? 

T21. I assume that selection functions will be added in the future. If I
am wrong please delete all mention of extensibility and take out the
ipfixSelectorFunctions group. If I am right, I suggest to put
ipfixSelectorFunctions in a separate MIB module that will be IANA
maintained, so that new functions can be added in the future without the
need to revise the MIB module and the RFC. The separate MIB module will
become the initial version of the IANA maintained module, and new
selector functions will be added using for example Expert Review policy.

T22. it looks like Gauge32 would be a better SYNTAX for the following
objects: ipfixTransportSessionRate,
ipfixMeteringProcessCacheActiveFlows, ipfixMetering
ProcessCacheInactiveFlows

T23. How is ipfixTransportSessionRate computed? Every second? Every T
seconds? T=?

T24. I am wondering whether more counters in this MIB module need to be
Counter64 rather than Counter32 - especially the bytes and packets
counters

T25. There is no definition of the discontinuity behavior of all the
counter objects or definition of discontinuity objects.  

T26. It looks like Counter32 (or Counter64) with the appropriate
discontinuity objects are better SYNTAX for
ipfixSelectorStatsPacketsObserved and ipfixSelectorStatspacketsDropped. 

T27. Some of the DESCRIPTION clauses of the OBJECT-GROUPs contain
statements about the mandatory or optional characteristics of the
objects. This is inappropriate, such statements must be made in
MODULE-COMPLIANCE definitions, not in OBJECT-GROUP. 

T.28. Security Consideration sections - The description of the
vulnerability of objects in the tables should be more precise than
'contains configuration data that might be sensitive'. 

E1. Section 5.1 s/is defined in the MIB/is defined in the MIB module/

E2. The language in the sub-section of section 5 may be polished - for
example in section 5.3 and 5.4 s/may want to export/is configured to
export/

E3. Section 5.6 s/consists of a set of function/consists of a set of
functions/

E4. Section 5.6 - 'the Metering Process table (ipfixMetering
ProcessTable) is grouped by maintained by ...' - this phrase needs to be
fixed. 

E5. Section 6.1 - s/they should also implement the ENTITY MIB/they
SHOULD also implement the ENTITY MIB/

E6. Section 6.1 s/all entries in the Observation Point Table contain an
ipfixPhysicalEntity of zero(0)/all values of the ipfixPhysicalEntity
columns in the ipfixObservationPointTable are 0 and the values of the
ipfixPhysicalEntityDirection columns are none(0). 

E7. The DESCRIPTION clause and the name of the object
ipfixTransportSessionMode seem mis-leading. I think that this object
describes the device role in a session, not the mode of the session in
other words it's an attribute of the device that runs the agent and not
of the session. 

E8. The DESCRIPTION clause of the ipfixTemplateAccessTime object is
confusing. The second and third paragraph seem to duplicate the content
of the first paragraph. The last phrase of the clause seems to belong
rather in the DESCRIPTION clause of the table than here. 

E9. DESCRIPTION clause of ipfixObservationPointIndex - is this
'management system' or rather 'management agent'? 

E10. DESCRIPTION clause of ipfixPhysicalEntity s/the object contains
0/the value of the object is 0/

E11. What does 'a direction is not applicable' mean in the DESCRIPTION
clause of ipfixPhysicalEntityDirection? 

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix