Subject: Re: [ipfix] AD review for: draft-ietf-ipfix-info-11.txt

From: Juergen Quittek <[email-masked]>
Date: Tue, 18 Apr 2006 21:39:28 +0200

Hi Bert,

Many thanks for the detailed comments.
Please find replies inline.

Dear all,

Please check my replies and please speak up quickly
if you have problems with what I suggested.

Most issues should be closed by the replies.

The following ones definitely need further work.
I will address them in a follow-up message:

  - INFO-AD#1: Do reported statistics include or exclude the
    reporting IPFIX message?  Affected IEs are
        #40 exportedOctetTotalCount
        #41 exportedMessageTotalCount
        #42 exportedFlowTotalCount

  - INFO-AD#2: Does IE #42 exportedFlowTotalCount
    report the number of flows or the number of flow records?

  - INFO-AD#3: Is it OK to change dataty of IEs
        #16 bgpSourceAsNumber
        #17 bgpDestinationAsNumber
    from unsiogned16 to unsigned32?

  - INFO-AD#4: How to add new label types to the definition of
    IE #46 mplsTopLabelType?

  - INFO-AD#5: Explain in the capabilities and limitations of the
    different dateTimeXX data types.

  - INFO-AD#6:
    Review last paragraph of section 7.

  - INFO-AD#7:
    Elaborate security considerations

Thanks,

    Juergen

> - sect 5.5.x
>   Would it be useful to add a line of text to explain how long
>   (how many minutes, months, years) each granularity allows
>   based on the underlying datatype?

I will work on a text suggestion.

--On 17.03.2006 17:42 Uhr +0100 Wijnen, Bert (Bert) wrote:

> Sorry that it took so long (if I say it 4 times, i.e.
> for each doc I have reviewed, will you please forgive me).
>
> Seems that a new rev might be in order ??
>
> Bert
>
> - bottom of page 8. enterpriseId -
>   it speaks about "Information Element Identifier described above"
>   I do not see where "above" it is described. In fact, I think the
>   Identifier is described in sect 4, no?

Oooops, the Element Id is a mandatory element and not listed above.
This was a problem of the code generating this section from the schema.
Now, the list of mandatory IE properties contains in addition between
'name' and 'description' the following property:

  "elementId - A numeric identifier of the Information Element.  If this
      identifier is used without an enterprise identifier (see below),
      then it is globally unique and the list of allowed values is
      administered by IANA.  It is used for compact identification of an
      Information Element when encoding templates in the protocol."

> - In the 3 paragraphs of sect 3 and 3.1, I would insert the word "abstract"
>   in from of each occurrence of "data type(s)".
>   Also the title of sect 3.1 probably reads better as "Abstract Data Types".

done.

> - sect 3.1.9
>   "it is expected that strings will be encoded in UTF-8"
>   That does not make it interoperable, does it?
>   Would it not be better to say "strings MUST be encoded..."
>   And I would add a citation and reference to RFC3629.

done.
added RFC3629 as normative reference.

> - sect 3.2
>   s/future protocol extensions/future information model extensions/ ??

fixed, and also in section 3.1.

> - page 16
>   What are ID 211 and 212 ?? blank ?? reserved?? something else?
>   I see the explanation on page 17. I'd suggest to make them RESERVED
>   or OBSOLLETE or DEPRECATEd or give them some name with the note
>   that they are not part of the standard.

I used RESERVED. Maybe we can solve the issues of these two elements
before submitting the next version.

> - section 5 1st sentence
>   s/Flow attributes/Information Elements/ ??

fixed.

> - sections 5.1.3, 5.1.4., 5.1.5 and 5.1.6
>   I worry about referential integrety when the ifIndex gets stored
>   in offline/archive storage. On a reboot, many devices renumber the
>   ifIndex for various interfaces.
>   Is this not a problem? I'd think it is at least something to
>   mention/discuss/warn for.

added

       "Please note that ifIndex
        values are not assigned statically to an interface.
        Interfaces may be renumbered every time the device is
        rebooted."

to the description of 5.1.3 and 5.1.4.

added

       "Please note that
        process identifiers are typically assigned dynamically.
        After a reboot, a system failure, a crash of the Metering
        Process, etc. the Metering Process may be re-started
        with a different ID.

to the description of 5.1.5 and 5.1.6.  For 5.1.6 "Metering"
was replaced with "Exporting".

> - sect 5.2.3
>   Is the message that contains this Information Element included in the
>   count?? May want to make that clear for better interoperability.
>   Same for some of the other exportXXXCounters

INFO-AD#1:
These IEs are specified to be compatible with NetFlow v9.
I'm checking with my co-authors from Cisco which alternative
was chosen for NF v9.

When I have this information, I will remove the ambiguity
from the descriptions of IEs
    #40 exportedOctetTotalCount
    #41 exportedMessageTotalCount
    #42 exportedFlowTotalCount

> - sect 5.2.5
>   Text says: number of flow records
>   But in Units it says: flows
>   So what is it?
>   Same for sect 5.2.9

INFO-AD#2:
This is another NF v9 compatible IE.  As above, I will check
and make sure that description and units are consistent.

> - sect 5.2.8
>   Does the count include header octets?

added clarification:

OLD
   Description:
      The total number of octets in observed IP packets that the
      Metering Process did not process since the (re-)initialization of
      the Metering Process.
NEW
   Description:
      The total number of octets in observed IP packets (including the
      IP header) that the Metering Process did not process since the
      (re-)initialization of the Metering Process.

> - sect 5.2.12
>   It is not clear/sopecific as to which bit is bit zero, bit one etc.

I am not sure what is the problem here, but I tried to clarify
the description:

OLD
   Description:
      This set of bit fields is used for marking the Information
      Elements of a Data Record that serve as Flow Key. Each bit
      represents an Information Element in the Data Record with the n-th
      bit representing the n-th Information Element.  A set bit with
      value 1 indicates that the corresponding Information element is a
      Flow Key of the reported Flow.  A value of 0 indicates that this
      is not the case.  ...
NEW
   Description:
      This set of bit fields is used for marking the Information
      Elements of a Data Record that serve as Flow Key. Each bit
      represents an Information Element in the Data Record with the n-th
      bit representing the n-th Information Element.  A bit set to value
      1 indicates that the corresponding Information element is a Flow
      Key of the reported Flow.  A bit set to value 0 indicates that
      this is not the case.

> - Sect 5.2.3 and 5.2.5
>   Is it best to speak about Mask?
>   Or would speaking of (and naming it) PrefixLength be better?

renamed sourceIPv4Mask to sourceIPv4PrefixLength
and sourceIPv6Mask to sourceIPv6PrefixLength

> - Sect 5.6.3
>   I worry about the fact that there is discussion already about AS numbers
>   of 32-bit length. So are we future proof here?
>   In the MIB/SMI world we have made it a 32bit unsigned, see
>   InetAutonomousSystemNumber in RFC4001.

INFO-AD#3:
change data type of
    #16  bgpSourceAsNumber
    #17  bgpDestinationAsNumber
    #128 bgpNextAdjacentAsNumber
    #129 bgpPrevAdjacentAsNumber
from unsigned16 to unsigned32.

> - sect 5.6.9
>   How are new values of Labeltypes be added in the future?
>   last line in this section, remove "and IP addresses" ??

INFO-AD#4:
I have no good answer on this comment. Does anyone else have?

> - sect 5.8
>   Just for my understanding, why do you need all 4 levels
>   of granularity here (i.e. sec, milisec, microsec and nanosec)??

For efficient reporting from probes with different precisions and for
applications with different precision requirements.

> - sect 5.5.x
>   Would it be useful to add a line of text to explain how long
>   (how many minutes, months, years) each granularity allows
>   based on the underlying datatype?

INFO-AD#5:
I will work on a text suggestion.  We avoid duplication if we put
this text to the data type descriptions in section 3.1.

> - sect 5.9.11 to 5.9.14
>   I wondered if it makes sense to say some thing more about
>   "packet treatment". Like what sort of treatment? Any
>   reference to an RFC?

We discussed this issue several times in the past, but did not
find a good solution for it.

> - sect 5.10.2 speaks about flowInactiveTimeout while sect 5.10.3
>   speaks about idle timeout. Should you have flowIdleTimeout
>   instead of flowInactievTimeout for consistency?

renamed flowInactiveTimeout to flowIdleTimeout.

> - sect 5.10.11
>   Make it clear that the value is hex 00 (0 could be read
>   as decimal zero)

OLD
5.11.1.  paddingOctets

   Description:
      The value of this Information Element is always 0.
NEW
5.11.1.  paddingOctets

   Description:
      The value of this Information Element is always a sequence of 0x00
      values.

> - sect 6, page 69
>   I think I would make it MUST instead of SHOULD in 2nd
>   and 3rd para.

These paragraphs are

  "Names of new Information Elements SHOULD be chosen according to the
   naming conventions given in section 2.3.

   For extensions, the type space defined in section 3 can be used.  If
   required, new data types can be added.  New data types SHOULD be
   defined in IETF standards track documents."

For IE naming I think that a SHOULD is OK, because fully consistent IE
naming appears to be very difficult.  There might be situations where
deviations from a fixed scheme improve the readability and intuitive
understanding of IE semantics.  For example we inconsistently use "IPv4"
instead of "IpV4" in IE names, because several people did not like "IpV4".

For new data types I agree.  Changed SHOULD to MUST.

> - sect 7
>   first para, pls add a ptr to the list of Information
>   Element Identifiers that need to be recorded as the
>   initially assigned values for this registry.
>   I guess you need to point them to sect 4.
>   I doubt it is clear to IANA though what exactly to record
>   from that section. You can check directly with iana to
>   ask if things are clear or not and if not to work out
>   text with them that they understand.

I tried to address this comment:
OLD
7.  IANA Considerations

   This documents defines an initial set of IPFIX Information Elements.
   For extending them in the future, IANA needs to create a new registry
   for IPFIX Information Element identifiers.

   New assignments for IPFIX Information Elements will be administered
   by IANA, on a First Come First Served basis [RFC2434], subject to
   Expert Review [RFC2434], i.e. review by one of a group of experts
   designated by an IETF Operations and Management Area Director.  The
   group of experts must double check the Information Elements
   definitions with already defined Information Elements for
   completeness, accuracy, redundancy, and correct naming following the
   naming conventions in section 2.3.  Those experts will initially be
   drawn from the Working Group Chairs and document editors of the IPFIX
   and PSAMP Working Groups.

   Appendix B defines an XML schema which may be used to create
   consistent machine readable extensions to the IPFIX information
   model.  This schema introduces a new namespace, which will be
   assigned by IANA according to RFC 3688.  Currently the name space for
   this schema is identified as http://www.ietf.org/ipfix.
NEW
7.  IANA Considerations

   This document specifies an initial set of IPFIX Information Elements.
   The list of these Information Elements with their identifiers is
   given in section 4.  IANA needs to create a new registry for IPFIX
   Information Element identifiers and fill it with the initial list in
   section 4.

   New assignments for IPFIX Information Elements will be administered
   by IANA, on a First Come First Served basis [RFC2434], subject to
   Expert Review [RFC2434], i.e. review by one of a group of experts
   designated by an IETF Operations and Management Area Director.  The
   group of experts must double check the Information Elements
   definitions with already defined Information Elements for
   completeness, accuracy, redundancy, and correct naming following the
   naming conventions in section 2.3.  The specification of new IPFIX
   Information Elements MUST use the template specified in section 2.1
   and MUST be published using a well established and persistent
   publication medium.  The experts will initially be drawn from the
   Working Group Chairs and document editors of the IPFIX and PSAMP
   Working Groups.

   Appendix B defines an XML schema which may be used to create
   consistent machine readable extensions to the IPFIX information

>   I wonder if it would not be much better to have new
>   Information Elements require a Standards Track action.
>   I think that ensure much better review and evaluation
>   and certainly ensure well-documented registrations.

We discussed the issue several times and concluded that this
procedure would be too time consuming and too slow.

>   In any event, if you do do FCFS with expert review,
>   then I would
>   - require proper documentation to be publicly available
>   - maybe setup some sort of template that MUST be filled
>     out and approved to request registration.

I added these two requirements to the new version of section 7
that you find above.

>   You speak about an Appendix B as having a schema/example
>   on how to extend. It is however (I think) the Schema
>   for the currently assigned values.

INFO-AD#6:
Yes, but it should also be used for extensions.  However, I
still need to investigate the XML schema issues that you posted
in a different email.  I will come back to this issue, when
the XML schema issue is closed.

> - Sect 8.
>   I am pretty sure that the Security ADs will want to see
>   more detail here. They probably want to understand which
>   Information Elements contain sensitive data (and why it
>   is sensitive) or privacy sensitive data (and why so).
>   Probably similar to why they want to see that a MIB
>   document lists the objects that are sensitive and
>   why so and what the risks are if the data gets
>   intercepted.

INFO-AD#7:
Let's come back to this after the security AD review.

> - Appendix A and B
>   I am a bit confused when I read as title
>   "Formal Specification..." and then in the first para
>   I read that it is informational and not normative.
>
>   If it is a "formal machine readable spec.." is it then not
>   intended as input to tools, code-generators, data-structure
>   generators and such? In that case I would be very worried
>   if no this schema but the text earlier in the document
>   is normative and authoritative.

It is not a formal specification. But it is machine readable
and intended as input to tools.  In one of the many passed
IPFIX sessions and on the mailing list we discussed the issue
and concluded that the text in section 5, which is generated
from the appendix with a tool would be normative, because this
is human readable.

>   Anyway, I asked an APPS AD if he could check the "formal"
>   machine readable schema, but he does not recognize it as
>   a schema that can be checked by any of his tools. So
>   what is it? How can we (or anyone) check it for correctness?

We got this review in a separate email.
Issues raised will be addressed in a reply to it.

> administrative/bureaucracy/nits/spelling:
>
> - sect 5.10.4
>
>   "bewtween in time" in first sentence ??

fixed.

>   same in sect 5.10.5

fixed.

> - 3rd para in sect 1. I suspect that the ptrs to the various sections
>   do not completely match with the actual content claimed to be
>   in those sections. Specifically, the ptrs to 4 and 5 should probably
>   be 5 and 6 ??

fixed.

> - I see that you use MUST (i.e. rfc2119 type) language and
>   so there MUST be a normative citation/reference to RFC2119.

added.

> - problems with references/citations.
>   Note that my tool may give false warnings, so just check
>   them.

In most of the cases below we cited "see RFC XXXX" in the
reference section.  I replaced all these references with
"see RFC XXXX [RFCXXXX]".

>   !! Missing citation for Informative reference:
>   P071 L006:    [IEEE.802-11.1999]
>
>   !! Missing citation for Informative reference:
>   P071 L015:    [IEEE.802-3.2002]
>
>   !! Missing citation for Informative reference:
>   P071 L023:    [IEEE.P802-1Q.2003]
>
>   !! Missing citation for Informative reference:
>   P072 L026:    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
>
>   !! Missing citation for Informative reference:
>   P072 L029:    [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
>
>   !! Missing citation for Informative reference:
>   P072 L033:    [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
>
>   !! Missing citation for Informative reference:
>   P072 L036:    [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
>
>   !! Missing citation for Informative reference:
>   P072 L039:    [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
>
>   !! Missing citation for Informative reference:
>   P072 L042:    [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
>
>   !! Missing citation for Informative reference:
>   P072 L047:    [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
>
>   !! Missing citation for Informative reference:
>   P072 L050:    [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
>
>   !! Missing citation for Informative reference:
>   P073 L006:    [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
>
>   !! Missing citation for Informative reference:
>   P073 L012:    [RFC3260]  Grossman, D., "New Terminology and Clarifications for

The three references below are not cited. removed them.

>   !! Missing citation for Informative reference:
>   P073 L015:    [RFC3667]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
>
>   !! Missing citation for Informative reference:
>   P073 L018:    [RFC3668]  Bradner, S., "Intellectual Property Rights in IETF
>
>   !! Missing citation for Informative reference:
>   P073 L021:    [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
>
> --
> Help        mailto:[email-masked] and say "help" in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Brian Trammell <[email-masked]>
Date: Tue, 18 Apr 2006 17:20:59 -0400

Juergen,

A couple of brief questions and suggestions, inline...

> and sourceIPv6Mask to sourceIPv6PrefixLength

what about the destinationIPv(4,6)Mask IEs?

> applications with different precision requirements.

It may additionally be worth noting that by using NTP (RFC1305)  
encoding for microseconds and nanoseconds (see protocol-19 6.1.7,  
6.1.8), the only real difference between the microsecond and  
nanosecond information elements is an estimation of precision. Since  
NTP timestamps have a resolution of about 200 picoseconds, Collecting  
Processes SHOULD ignore differences smaller than 1ns for nanosecond  
IEs and 1us for microsecond IEs.

Also, while checking up on references for this suggestion, I noticed  
that the only reference to the actual encoding of the microsecond and  
nanosecond IEs is in the data type definition in the protocol  
document. Should the encoding not also appear in the data type  
definition in the information model, adding a normative reference to  
RFC1305 in the information model?

Also also, while I'm talking timestamps, I would like to point out  
once more section 5.5 of the -01 rev of the implementation  
guidelines: the capitalization of the timestamp information element  
names are inconsistent with the SI time unit names in English - e.g.  
"flowStartMicroSeconds" implies a word break that does not exist  
("microseconds", not "micro seconds") - and should be corrected while  
we have the chance.

> renamed flowInactiveTimeout to flowIdleTimeout.

Another capitalization: we have flowIdleTimeout, and  
flowActiveTimeOut; the latter should be changed to flowActiveTimeout.

Regards,

Brian

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 19 Apr 2006 01:54:37 +0200

Brian,

Thank you for your suggestions.
Please find replies inline.

> what about the destinationIPv(4,6)Mask IEs?

Right. I missed them.  Fixed it by changing also the destination
masks to destination prefix lengths.

> nanosecond information elements is an estimation of
> precision. Since  NTP timestamps have a resolution of about 200
> picoseconds, Collecting Processes SHOULD ignore differences smaller
> than 1ns for nanosecond  IEs and 1us for microsecond IEs.

I think this is an issue for the protocol document.

> RFC1305 in the information model?

No, the information model does not request a specific encoding for time
stamps.  It should be possible to use it with different time stamp formats.

> names are inconsistent with the SI time unit names in
> English - e.g.  "flowStartMicroSeconds" implies a word break that does not exist

You are right.  I changed it.  To be consistent, I also had to
change the data types dateTimeXXXXSeconds to dateTimeXXXXseconds.
To be consistent, we also need to apply this change in the protocol
document.

> Another capitalization: we have flowIdleTimeout, and  flowActiveTimeOut;
> the latter should be changed to flowActiveTimeout.

fixed.

Thanks,

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Wed, 19 Apr 2006 15:47:59 +0100

Juergen,

> To be consistent, I also had to change the data types 
> dateTimeXXXXSeconds to dateTimeXXXXseconds.

There is also some inconsistency concerning where IP, IPv4 and IPv6 are 
placed in the IE names: IP usually prefixes the name, while IPv4 and 
IPv6 are usually in the middle of the name, or suffixes - with the 
notable exceptions of "ipv4Options" and "ipv6ExtensionHeaders".

It's particularly clear here:

   |   5 | classOfServiceIPv4        |
   |  55 | postClassOfServiceIPv4    |
   | 137 | classOfServiceIPv6        |
   | 138 | postClassOfServiceIPv6    |

   | 194 | ipClassOfService          |
   | 195 | ipDiffServCodePoint       |

 From a readability perspective, the address family (if any) should 
always be first in the name. However, from a technology perspective it 
may be more sensible as a suffix.

Whichever, we should chose a consistent naming convention and stick to it.

Cheers.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 19 Apr 2006 17:00:56 +0200

Hi Paul,

--On 19.04.2006 15:47 Uhr +0100 Paul Aitken wrote:

> There is also some inconsistency concerning where IP, IPv4 and IPv6 are placed in the IE names: IP usually prefixes the name, while IPv4 and IPv6 are usually in the middle of the name, or suffixes - with the notable exceptions of "ipv4Options" and
> "ipv6ExtensionHeaders".
>

We also have IPvX in the middle

     |  44 | sourceIPv4Prefix          |
     |  45 | destinationIPv4Prefix     |

and two IPs in one name:

     |  62 | ipNextHopIPv6Address      |

I am open to a consistent suggestion for ALL IEs containing IP, IPv4 or IPv6.

>    | 195 | ipDiffServCodePoint       |

What about removing "ip" from these two IE names?

Thanks,

    Juergen

>  From a readability perspective, the address family (if any) should always be first in the name. However, from a technology perspective it may be more sensible as a suffix.
>

---

From: Paul Aitken <[email-masked]>
Date: Wed, 19 Apr 2006 16:44:55 +0100

Juergen,

>> There is also some inconsistency concerning where IP, IPv4 and IPv6 
>> are placed in the IE names: IP usually prefixes the name, while IPv4 
>> and IPv6 are usually in the middle of the name, or suffixes - with 
>> the notable exceptions of "ipv4Options" and
>> "ipv6ExtensionHeaders".
>>

It's clearly a confusing naming convention.

> What about removing "ip" from these two IE names?

If we consistently put { IP | IPv4 | IPv6 } at the start of the names, 
then when listing elements alphabetically, all the elements for the same 
address family will be listed together. Also, the names read well. 
However, it's difficult to relate similar IE's for different address 
families.

However, if we only specify IPv4 or IPv6 at the end of each name, then 
when the elements are listed alphabetically, elements with the same 
functionality - but for different address families - will be adjacent to 
one another. Unfortunately the names don't read so well.

Question is whether the names are only useful tags for human readers, or 
whether we might expect a machine to understand that classOfServiceIP, 
classOfServiceIPv4 and classOfServiceIPv6 are all related?

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 19 Apr 2006 18:30:57 +0200

Hi Paul,

> It's clearly a confusing naming convention.

The question is: which is a non-confusing one
that also works well for ipNextHopIPv6Address?

> However, it's difficult to relate similar IE's for different address families.
>
> However, if we only specify IPv4 or IPv6 at the end of each name, then when
> the elements are listed alphabetically, elements with the same functionality
> - but for different address families - will be adjacent to one another.
> Unfortunately the names don't read so well.
>
> Question is whether the names are only useful tags for human readers,
> or whether we might expect a machine to understand that classOfServiceIP,

I do not think machine interpretation of names is a relevant criteria.

Thanks,

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Apr 2006 14:01:53 +0200

Juergen, Brian,
> To be consistent, we also need to apply this change in the protocol
Done. 
I now have in [IPFIX-PROTO]:

flowStartMilliseconds,
flowStartMicroseconds, 
flowStartNanoseconds,
flowStartDeltaMicroseconds

flowEndMilliseconds,
flowEndMicroseconds, 
flowEndNanoseconds, 
flowEndDeltaMicroseconds

flowStartDeltaMicroseconds,
flowEndDeltaMicroseconds

        dateTimeseconds,
        dateTimeMilliseconds,
        dateTimeNanoseconds
        dateTimeMicroseconds

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Apr 2006 14:40:49 +0200

> flowStartDeltaMicroseconds,
Oops. dateTimeSeconds

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Apr 2006 23:44:10 +0200

Hi Juergen,
>        #42 exportedFlowTotalCount
All of the counters exclude the reporting IPFIX Message
>    from unsiogned16 to unsigned32?
RFC 3954 specifies already 32 bits

                                           Source BGP autonomous
   SRC_AS                       16   N     system number where N could
                                           be 2 or 4. By default N is
                                           2

                                           Destination BGP autonomous
   DST_AS                       17   N     system number where N could
                                           be 2 or 4. By default N is
                                           2

Anyway, we've got the reduced size encoding, so unsigned32 makes sense.
>  - INFO-AD#4: How to add new label types to the definition of
The references from RFC 3954 have been assigned by the NetFlow 
development team

   MPLS_TOP_LABEL_TYPE          46   1     MPLS Top Label Type:
                                           0x00 UNKNOWN
                                           0x01 TE-MIDPT
                                           0x02 ATOM
                                           0x03 VPN
                                           0x04 BGP
                                           0x05 LDP

I could not find any IANA registry for that.
So I guess we have only one choice, i.e. assign a new registry for it in 
IANA.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Apr 2006 23:56:15 +0200

Juergen,

>    report the number of flows or the number of flow records?
= the number of flow records that have been exported.
Example: for a long lived flow (longer than the active timeout value), 
we have multiple flow records

Regards, Benoit.