Subject: Re: [ipfix-info] simple editorial changes for the information model draft

From: Juergen Quittek <[email-masked]>
Date: Sat, 11 Jun 2005 15:34:21 +0200

Benoit,

Thanks for the comments.  Please see replies in line.

--On 6/7/2005 11:45 PM +0200 Benoit Claise wrote:

> Juergen,
>
>
> I reviewed the information model draft one last time.
>
> For everybody interest, we discussed with Juergen a list of new I.E.
> to be added.
> However, as we wanted to make the date of June 1st for the last-call,
> and as these new I.E. can be considered as editorial changes, these new
> I.E.s were not inserted in the current draft version.
> These I.E. will be the subject of a separate email.
>
>
> Here is a list of simple editorial changes.
>  - http://ietf.levkowetz.com/drafts/ipfix/info/draft-ietf-ipfix-info-07.nits.txt

Fixed.

> - Section 4, Information Element Identifiers
>    "Enterprise-specific identifiers can be chosen by an enterprise
>    arbitrarily within the range of 1-32767.  The same identifier may be
>    assigned by other enterprises for different purposes."
>
> 	->
>    "Enterprise-specific Information Elements identifiers can be chosen
>    by an enterprise arbitrarily within the range of 1-32767.  The same
>    identifier may be assigned by other enterprises for different purposes."

Fixed (removed the trailing 's' from "Elements").

> - Section 4, Information Element Identifiers
>
>    "The following list gives an overview of the Information Element
>    identifiers that are specified in section 5 and are not compatible
>    with field types used by NetFlow version 9 [RFC3954]"
>
> 	->
>    "The following list gives an overview of the Information Element
>    identifiers that are specified in section 5 and are compatible
>    with Information Elements used by NetFlow version 9 [RFC3954]"

Fixed.

> - Section 5.  Information Elements
>
>    "The Information Elements that are derived from fields of packets or
>    from packet treatment, such as the Information Elements in groups
>    3.-6., can serve as Flow Keys used for mapping packets to flows.  But
>    they also may contain values that are not constant for a single flow.
>    For example a flow using a certain source IPv4 address as flow key
>    has sourceIPv4Address as constant property but may have
>    destinationIPv4Address as a property that changes from packet to
>    packet."
>
> I don't understand the sentence starting with "But".
> Either this is a flow key, and then this I.E. is constant in a flow.
> Or it's not a flow key and it's not worth mentioning!
> I mean... by definition a flow is defined by his flow keys.
> So the following sentence is wrong
> "But they (I understand by "they", the I.E.s that serve as Flow Keys"
> also may contain values that are not constant for a single flow."

This is a lost editorial edit.  I fixed this already, but here we have
the old version.  I'll post the improved version to the list when I am
back in the office and can retrieve it from the CVS server.

> - Section 5.  Information Elements
>
>    For such Information Elements that are derived from fields of packets
>    or from packet treatment, the IPFIX information model makes the
>    general assumption that their value is determined by the first packet
>    observed for the corresponding Flow, unless the description of the
>    Information Element explicitly specifies a different semantics.
>
> 	semantics -> semantic

No, 'semantics' is correct.  Strange English language: 'semantic' is an
attribute, 'semantics' is the singular form of the corresponding noun.

> - Section 5.2.5  exportedFlowTotalCount
>
>    Description:
>       The total number of Flows Records reported that the Exporting
>       Process successfully sent as Data Records since the Exporting
>       Process (re-)initialization to the Collecting Process receiving a
>       report that contains this Information Element.
>
>    What does "reported" mean? Can't we simply delete it?

Yes. Done.

> - Section 5.2.6  observedFlowTotalCount
>
>    Description:
>       The total number of Flows observed in the Observation Domain since
>       the Metering Process (re-)initialization for this Observation
>       Point.
>    ElementId: 3
>
> We should be in line with the RFC 3954 that explains something
> different: Number of Flows that were aggregated;

Fine to be in line.  But what means RFC 3954 with "Flows that were aggregated"?
The common definition of flow aggregation is merging individual flow records
of different flows into a single one.  This is in line with the last paragraph
on page 4 of RFC 3954.  But this is not what I understood so far as the
semantics of Information Element #3 "observedFlowTotalCount".

> - Section 5.7  Min/Max Flow Properties
>
>    Information Elements in this section are results of minimum or
>    maximum operations over all packets of a flow.
>
> TCP flags and ipv6OptionHeaders don't fall into this description.
> New proposal:
>
> "Information Elements in this section are results of minimum or
> maximum operations over all packets of a flow.Information Elements
> in this section are the results of minimum, a maximum, or a logical
> operations over all packets of a flow."

The logical operation you are referring to is the bit-wise maximum operation.

> - 5.7.5  ipv6OptionHeaders
>
>  New proposal:
> Description:
>      IPv6 extension headers observed in packets of this flow.  The
>      information is encoded in a set of bit fields.  For each IPv6
>      option header there is a bit in this set.  The bit is set to 1 if
>      any observed packet of this flow contains the corresponding IPv6
>      extension header.  Otherwise, if no observed packet of this flow
>      contained the resepective IPv6 extension header, the value of the
>      corresponding bit is 0.
>
>               0     1     2     3     4     5     6     7
>           +-----+-----+-----+-----+-----+-----+-----+-----+
>           | Res | FRA1| ROU | FRA0| UNK | Res | HOP | DST |  ...
>           +-----+-----+-----+-----+-----+-----+-----+-----+
>
>               8     9    10    11    12    13    14    15
>           +-----+-----+-----+-----+-----+-----+-----+-----+
>       ... | PAY | AUT | ENC |         Reserved            | ...
>           +-----+-----+-----+-----+-----+-----+-----+-----+
>
>              16    17    18    19    20    21    22    23
>           +-----+-----+-----+-----+-----+-----+-----+-----+
>       ... |                  Reserved                     | ...
>           +-----+-----+-----+-----+-----+-----+-----+-----+
>
>              24    25    26    27    28    29    30    31
>           +-----+-----+-----+-----+-----+-----+-----+-----+
>       ... |                  Reserved                     |
>           +-----+-----+-----+-----+-----+-----+-----+-----+
>
>       Bit     IPv6 Option   Description
>
>        0, Res               Reserved
>        1, FRA1     44       Fragmentation header - not first fragment
>        2, ROU      43       Routing header
>        3, FRA0     44       Fragment header - first fragment
>        4, UNK               Unknown Layer 4 header
>                            (compressed, encrypted, not supported)
>        5, Res               Reserved
>        6, HOP       0       Hop-by-hop option header
>        7, DST      60       Destination option header
>        8, PAY     108       Payload compression header
>        9, AUT      51       Authentication Header
>       10, ENC     50        Encrypted security payload
>       11 to 31              Reserved

Done.  I hope you don't mind that I capitalized all occurrences of
the term 'flow' in your proposal :-)

> - Capitalization
>     A lot of instances where "IPFIX message" is not capitalized.
>     A couple of instances where "IPFIX device" is not capitalized
>     "flow" sometimes is in lower case, should be "Flow"

Done.

> - Section 5.10.3 flowEndReason
>
>    Description:
>       The reason for flow termination.  The range of values includes
>    Abstract Data Type: octet
>    Data Type Semantics: identifier
>    ElementId: 136
>    Status: current
> The description is incomplete.  The person who requested it should
> complete the description

This was my fault.  I used the wrong XML tag and the list of reasons
disappeared.  It is

   0x01: idle timeout
   0x02: active timeout
   0x03: end of Flow detected (e.g. TCP FIN)
   0x04: forced end
   0x05: cache full

> - Section 6.  Extending the Information Model
>
>    Extension is done by defining new Information Elements.  Each new
>    information item MUST be assigned a unique Information Element
>    identifier as part of its definition.
>     ->
>
>    Extension is done by defining new Information Elements.  Each new
>    Information Element MUST be assigned a unique Information Element
>    identifier as part of its definition.

Fixed.

> Regards, Benoit.

Thanks,

    Juergen

--
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: Benoit Claise <[email-masked]>
Date: Mon, 13 Jun 2005 16:06:41 +0200

Juergen,

> semantics of Information Element #3 "observedFlowTotalCount".

It's because the ElementId 3 name and description changed along the 
different versions.

flowCount (version 3) -> totalFlowCount (version 6) -> observedFlowTotalCount (version 7)

I guess you want:
- Element Id 3 to be in line with RFC3954
- A new I.E. for observedFlowTotalCount, if you have a need for it

>   0x03: end of Flow detected (e.g. TCP FIN)

What does the force end mean?

Regards, Benoit.