Subject: [IPFIX] WG last call on IPFIX MIB

From: Juergen Quittek <[email-masked]>
Date: Wed, 05 Dec 2007 23:09:44 +0100

Dear all,

At our session yesterday we concluded that the IPFIX MIB module
has solved all open issues.  A new version has been posted today.

Now, it is time for working group last call on
draft-ietf-ipfix-mib-02.

The call will last until Friday December 21st.
This gives us a bit more than two weeks.

Please read the draft!
Please send your comments to this mailing list!
Please also send a message if you are fine with the draft as it is!

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 4342-115
NEC Europe Limited,    Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 17 Dec 2007 18:32:16 +0100

Dear Jürgen, all,

Here is my review for draft-ietf-ipfix-mib-02.txt.

Regards,
Gerhard

Editing:
Verify thoroughly the  usage of IPFIX terms with capital letters. I
found various versions (with and without capital) of the following terms:
Exporter
Collector
Transport Session
IPFIX protocol
record (not sure if this should be capitalized or not)
Data Record
Template Record

> Abstract
> 
>    This document defines managed objects for IP Flow Information Export
>    (IPFIX).  These objects provide information for monitoring IPFIX
>    Exporters and IPFIX Collectors including some minor configuration
>    information.

What is "some minor configuration information"?

> 1.  Introduction
> 
>    This document defines MIB modules for monitoring IP Flow Information

How many MIB modules are defined in the document?

>    Export (IPFIX) Devices including Exporters and Collectors.  The full
>    configuration of the IPFIX Metering Process is out of the scope this
>    MIB.  However, some configuration of the Exporting Process is
>    specified in this document.

What is "some configuration"?
Which parameters can be configured with the MIB module? Make a clearer
statement here.

> 2.  IPFIX Documents Overview

>    It is assumed that Flow metering, export and collection is performed
>    according to the IPFIX architecture defined in
>    [I-D.ietf-ipfix-architecture].  Configuration of the export and
>    collection of Flow Information Templates and Records is modeled
>    according to [I-D.ietf-ipfix-protocol].  Packet selection and

"Flow Information Templates" is no standardized term
=> no capital letters
In which sense is "configuration" meant here? Do you refer to monitoring
the current configuration parameters of the device (read)? Or to
changing the configuration (write)?

>    filtering methods that may be optionally used by the IPFIX Metering
>    Process are not considered in this MIB module.  They are defined in
>    the Packet Sampling (PSAMP) framework [I-D.ietf-psamp-framework] and
>    sampling techniques [I-D.ietf-psamp-sample-tech] documents.
>    Nevertheless the entry point for those methods [I-D.ietf-psamp-mib]
>    is given within this MIB module since PSAMP export protocol
>    [I-D.ietf-psamp-protocol] is based on the IPFIX protocol.
> 5.  Structure of the IPFIX MIB
> 
>    The IPFIX MIB consists of four main tables, the Transport Session
>    table, the Observation Domain table, the Template table and the
>    Template Definition table.  Since the IPFIX architecture
>    [I-D.ietf-ipfix-architecture] foresees the possibility of using
>    filtering and/or sampling functions to reduce the data volume the MIB
>    provides the basic objects for theses functions with the Selector

these

>    Table and a subtree for hooking standard filtering and sampling
>    functions.
> 
>    All remaining objects contain statistical values for the different
>    tables contained in the MIB.  Finally an entry point for extensions
>    of the IPFIX MIB is given that can be used e.g. for the PSAMP MIB
>    [I-D.ietf-psamp-mib].
> 
>    The following subsections describe all tables in the IPFIX MIB
>    module.
> 
> 5.1.  The Transport Session Table
> 
>    The Transport Session is the basic concept in the MIB.  The Transport

I do not understand "basic concept" in this context.

>    Session table (ipfixTransportSessionTable) contains all Transport
>    Sessions between Exporter and Collector.  The table specifies the
>    layer 4 protocol of the Transport Session and, depending on the
>    protocol, further parameters for the Transport Session.  In case of
>    UDP and TCP these are the source and destination address as well as
>    the source and destination port.  For SCTP the table contains the
>    SCTP Assoc Id which is the index for the SCTP association in the SCTP
>    MIB [RFC3873].  Finally a status of the Transport Session is given in
>    the table.
> 
> 5.1.1.  The Transport Session Group Table
> 
>    On Exporters, the Transport Session Group table
>    (ipfixTransportSessionGroupTable)can be used to achieve features like

Other verb for "achieve"? Maybe support?

>    failover, load-balancing, duplicate export to several Collectors etc.
>    The member type for each group member describes its functionality.

>    The notion of Transport Session Grouping is only available on
>    Exporters.  Nevertheless the Transport Session Group table exists on
>    Exporters and Collectors, for consistency reasons.  Each Transport
>    Session Group on a Collector consists of a single entry with a

"consists of a single Transport Session entry"?

>    Transport Session.  The member type for this entry MUST be set to
>    unused.  If the Transport Session Grouping is not supported on an
>    Exporter the same conditions as described above for Collectors apply.
> 
>    To illustrate the use of the the above tables lets assume the

remove one "the"
let's

>    following scenario: We have an exporter on IP address 192.0.2.22 and
>    a collector on IP address 192.0.2.37.  They use TCP.  Then we would

Replace "They use TCP." by a better description of what is happening.

>    have the following Transport Session Table on the exporter:
> 
>      ipfixTransportSessionTable (2)
>      |
>      +- ipfixTransportSessionEntry (1)
>         |
>         +- index (5)
>            +- ipfixTrasportSessionIndex (1) = 5
>            +- ipfixTransportSessionProtocol (2) = 6 (TCP)
>            +- ipfixTransportSessionAddressType (3) = 1 (ipv4)
>            +- ipfixTransportSessionSourceAddress (4) = 192.0.2.22
>            +- ipfixTransportSessionDestinationAddress (5) = 192.0.2.37
>            +- ipfixTransportSessionSourcePort (6) = 7653
>            +- ipfixTransportSessionDestinationPort (7) = 4739
>            +- ipfixTransportSessionSctpAssocId (8) = 0
>            +- ipfixTransportSessionTemplateRefreshTimeout (9) = 0
>            +- ipfixTransportSessionOptionTemplateRefreshTimeout (10) = 0
>            +- ipfixTransportSessionTemplateRefreshPacket (11) = 0
>            +- ipfixTransportSessionOptionTemplateRefreshPacket (12) = 0
>            +- ipfixTransportSessionStatus (13) = 2 (active)
> 
>    The values in brackets are the OID numbers.  The collector would then
>    have e.g. the following table:

The collector table seems to be identical except the index. If this is
true, do not repeat it as it is confusing the reader looking for hidden
differences.

>    We further asume that the exporter uses the above connection as the
>    primary export for a session protected by a secondary backup
>    connection with a ipfixTransportSessionIndex of 28.  Both, exporter

an

>    and collector, also need to have a Transport Session Group Table.
>    For the export this may look like the following table:

>    Since the collector does not know which Transport Sessions belong
>    together he has one Transport Session Group Table entry per Transport

he -> it

>    Session.  So the entry for the given example is the following:

> 5.3.  The Template Table
> 
>    The Template table lists all Templates (including Option Templates)
>    that are sent (by an Exporter) or received (by a Collector).  The
>    Templates are unique per Transport Session Group and Observation
>    Domain, thus the table is indexed by the Transport Session Index and
>    the Observation Domain Id from the previous two tables.  It contains
>    the Set Id and an Access Time denoting the time when the Template was
>    last sent or received.  In addition it contains an inactive timeout
>    to terminate Flows that are inactive for a certain amount of time and
>    an active timeout to expire Flows that are still active to get#

remove #

>    intermediate Flow Records for these long-living Flows.

> 5.4.  The Template Definition Table

>    To resume the above example the exporter may want to export the
>    octets received and dropped at the Observation Point since the last
>    export of these values.  In addition it exports the start and end
>    time of the flow relative to the timestamp contained in the IPFIX

You talk about relative timestamps, but the example shows absolute ones.
(150, 151 are absolute timestamps!)

>    header.  The active timeout is set to 0 i.e., long-living Flows do
>    not generate intermediate exports.  The inactive timeout is set to
>    300 seconds i.e., a Flow is exported after 5 minutes of inactivity.
>    This leads to the following Template Table defining Template and
>    Option Template:
> 
>     ipfixTemplateTable (5)
>     |
>     +- ipfixTemplateEntry (1)
>        |
>        +- index (11)
>           |
>           +- index (3)
>              |
>              + index (257)
>              | +- ipfixTemplateId (1) = 257
>              | +- ipfixTemplateSetId (2) = 3

Set id is 2 for Template.

>              | +- ipfixTemplateAccessTime (3) = 2007-7-9,12:49:11.2,+2:0
>              | +- ipfixTemplateActiveTimeout (4) = 0
>              | +- ipfixTemplateInactiveTimeout (5) = 500
>              |
>              + index (264)
>                +- ipfixTemplateId (1) = 264
>                +- ipfixTemplateSetId (2) = 4

Set id is 3 for Option Template.

>                +- ipfixTemplateAccessTime (3) = 2007-7-9,12:47:04.8,+2:0
>                +- ipfixTemplateActiveTimeout (4) = 0
>                +- ipfixTemplateInactiveTimeout (5) = 0

> 5.5.  The Selector Table
> 
>    This table supports the usage of filtering and sampling functions as
>    described in [I-D.ietf-ipfix-architecture].  The implementation and
>    use of this table is optional.  If implemented it contains lists of
>    functions per Template, thus it takes the same indexes as the
>    Template Field table.  The Selector Index indicates the order of the

Template Definition table?

>    functions i.e, the order in that the functions are applied to the
>    packets observed at the Observation Point.  The functions are
>    referred by object identifiers pointing to the function with its
> 
> 
> 
> Dietz, et al.          draft-ietf-ipfix-mib-02.txt             [Page 12]
> 
> Internet-Draft                  IPFIX MIB                  December 2007
> 
> 
>    parameters.  If the table is implemented and no filtering or sampling
>    is used for a Template then an entry for the Template should be
>    created pointing to the Select All function (ipfixFuncSelectAll).
> 
> 5.6.  The Selector Functions
> 
>    The subtree ipfixSelectorFunctions is a placeholder where all
>    standard filtering and sampling functions should be located (if any)
>    and is mainly build for extensibility in future versions.  It

built

>    currently contains the Select All functions (ipfixFuncSelectAll).

> 5.6.1.  Textual Convention IpfixFunctionAvailabilty
> 
>    In conjunction with the Selector Functions the textual convention
>    IpfixFunctionAvailabilty is defined in the MIB.  It MUST be used
>    within all Selector Functions to indicate if a standard function is
>    currently available at the Device or not.  The previous mentioned

previously

>    Select All function is always available.

> 6.  MIB Definitions

>    ipfixTransportSessionTemplateRefreshTimeout OBJECT-TYPE
>        SYNTAX      Unsigned32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "On Exporters this object contains the time in seconds
>            after which IPFIX Templates MUST be resend by the

resent (this error is repeated in the following objects descriptions).

>            Exporter.

>    ipfixTransportSessionStatus OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        unknown(0),
>                        inactive(1),
>                        active(2)
>                    }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The status of a transport session. This object can have the
>            following values:
> 
>            unknown(0)
>                This value muse be used if the status of the
>                connection cannot be detected by the equipment. This
>                value should be avoided as far as possible.
> 
>            inactive(1)
>                This value MUST be used for transport sessions that
>                are specified in the system but not currently connected.
>                The value can be used e.g. for transport sessions that
>                are backup (secondary) sessions in a transport session
>                group.

Does backup secondary mean that the SCTP/TCP handshake only takes place
after the export to the primary destination failed? Or does this depend
on the implementation/configuration?

>            active(2)
>                This value MUST be used for transport sessions that are
>                currently connected and transmitting or receiving data."
>        ::= { ipfixTransportSessionEntry 13 }
> 
>    --------------------------------------------------------------------
>    -- 1.3: Transport Session Group Table
>    --------------------------------------------------------------------
>    ipfixTransportSessionGroupTable  OBJECT-TYPE
>        SYNTAX      SEQUENCE OF IpfixTransportSessionGroupEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists groups of transport sessions to
>            achieve features like automatic failover, load
>            balancing, parallel export etc.
> 
>            On Exporters this table can group one ore more transport

or

>            sessions to achieve a special functionality like failover

>    ipfixTransportSessionGroupMemberType OBJECT-TYPE
>        SYNTAX      INTEGER {
>                        unknown(0),
>                        primary(1),
>                        secondary(2),
>                        parallel(3),
>                        loadBalancing(4),
>                        unused(5)
>                    }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The type of a member transport session in its transport
>            session group (identified by the value of
>            ipfixTransportSessionGroupIndex). The following values are
>            valid:
> 
>            unknown(0)
>                This value muse be used if the status of the group

must

>                membership cannot be detected by the equipment. This
>                value should be avoided as far as possible.
> 
>            primary(1)
>                This value is used for a group member that is used as
>                the primary target of an Exporter. Other group members
>                (with the same ipfixTransportSessionGroupIndex) MUST
>                NOT have the value primary(1) but MUST have the value
>                secondary(2).
> 
>            secondary(2)
>                This value is used for a group member that is used as a
>                secondary target of an Exporter. The Exporter will use
>                one of the targets specified as secondary(2) within the
>                same transport session group when the primary target is
>                not reachable.
> 
>            duplicate(3)
>                This value is used for a group member that is used for
>                duplicate exporting i.e., all group members identified
>                by the ipfixTransportSessionGroupIndex are exporting
>                the same Records in parallel. This implies that all
>                group members MUST have the the same membertype
>                duplicate(3).
> 
>            loadBalancing(4)
>                This value is used for a group member that is used as
>                as one target for load-balancing. This means that a
>                Record is send to one of the group members in this

sent

>                group identified by ipfixTransportSessionGroupIndex.
>                This implies that all group members MUST have the same
>                membertype load-balancing(4)
> 
> 
> 
> 
> Dietz, et al.          draft-ietf-ipfix-mib-02.txt             [Page 23]
> 
> Internet-Draft                  IPFIX MIB                  December 2007
> 
> 
>            unused(5)
>                This value MUST be specified if the Exporter does not
>                support transport session grouping. It is the default
>                value for Collectors since the Collector cannot decide
>                if the received transport session uses transport
>                session grouping or not. In this case the group MUST
>                contain only one transport session."
>        ::= { ipfixTransportSessionGroupEntry 2 }
> 
>    --------------------------------------------------------------------
>    -- 1.4: Observation Domain Table
>    --------------------------------------------------------------------
>    ipfixObservationDomainTable  OBJECT-TYPE
>        SYNTAX      SEQUENCE OF IpfixObservationDomainEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists Observation Domains used by the Metering
>            Process, the Exporting Process or the Collecting Process.

remove Metering Process?

>            On Exporters the index ipfixTransportSessionGroupIndex MUST
>            always be zero (0) because the Observation Domain Id is
>            unique on the Exporter and can be used by any Transport
>            Session.
> 
>            On Collectors the index ipfixTransportSessionGroupIndex MUST
>            NOT be zero (0) because the Collector could receive Records
>            from different Transport Sessions which use the same
>            Observation Domain Ids."
>        ::= { ipfixObjects 4 }

>    ipfixObservationDomainId OBJECT-TYPE
>        SYNTAX      Integer32 (0..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "Locally arbitrary, but unique identifier of an entry in the
>            ipfixObservationDomainTable. The value is expected to remain
>            constant from a re-initialization of the entity's network
>            management system to the next re-initialization.
> 
>            The special value of 0 MUST NOT be used within this table
>            but is reserved for the usage in the ipfixTemplateTable
>            and the ipfixTemplateDefinitionTable. An index of 0 for the
>            ipfixObservationDomainId index in those tables indicates
>            that a Template or Option Template cannot be applied to a
>            single Observation Domain."

This has been specified in IPFIX protocol, so add a reference here.

>        ::= { ipfixObservationDomainEntry 1 }

>    ipfixTemplateTable  OBJECT-TYPE
>        SYNTAX      SEQUENCE OF IpfixTemplateEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table lists the Templates and Option Templates that
>            are transmitted or received by the Exporting or Collecting
>            Process.
> 
>            On an Exporter the table contains the Templates and Option
>            Templates that are used for exporting data for a given
>            Transport Session group and Observation Domain.
> 
>            On an Collector the table contains Templates and Option

a

>            Templates that are received in the given Transport Session
>            group per Observation Domain.
> 
>            If a value of zero (0) is specified for the
>            ipfixObservationDomainId then the Template or Option
>            Template cannot be applied to a single Observation Domain."
>        ::= { ipfixObjects 5 }

>    ipfixTemplateSetId OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This number indicates the set id of the Template. This
>            object allows to easily retrieve the Template type.
> 
>            Currently there are two values defined. The value 3 is
>            used for Sets containing Template definitions. The value 4

Values are 2 and 3.

>            is used for Sets containing Option Template definitions. A
>            value greater than 255 is used for Sets containing Data
>            Records for the (Option) Template Id given by the Set Id."
>        ::= { ipfixTemplateEntry 2 }
> 
>    ipfixTemplateAccessTime OBJECT-TYPE
>        SYNTAX      DateAndTime
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The time when the Template was last sent or received.
> 
>            On the Exporter this object contains the time when this
>            (Option) Template was last sent to the Collector(s). This
>            time is used if the transport protocol is UDP to know when a
>            retransmission of the (Option) Template is needed.
>            On the Collector this object contains the time when this
>            (Option) Template was last received from the Exporter. This
>            time is used if the transport protocol is UDP to know when
>            this (Option) Template times out and thus is no longer
>            valid."

What happens to Templates that are no longer valid? Do they remain in
the table? Do they have to be removed?

>        ::= { ipfixTemplateEntry 3 }

>    ipfixTemplateInactiveTimeout OBJECT-TYPE
>        SYNTAX      Unsigned32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The time in seconds after which an inactive Flow is
>            expired.
> 
>            On the exporter this object contains the time after which a
>            (and a data record for the template is sent) when no packets

syntax error

>            matching this Flow are received by the Metering Process for
>            the given number of seconds. If this value is 0 the Flow is
>            timed out immediately i.e., a data record is sent for every
>            packet received by the Metering Process.
> 
>            On the Collector as well as for Option Templates this object
>            is not valid and should be set to 0 (see
>            [I-D.ietf-ipfix-architecture], Section 5.1.1, Point 1)."
>        ::= { ipfixTemplateEntry 5 }

>    ipfixTemplateDefinitionIndex OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The ipfixTemplateDefinitionIndex specifies the order in
>            which the Information Elements are used in the (Option)
>            Template Record if an order MUST be applied.

I think the ipfixTemplateDefinitionIndex is mandatory (as index of the
entry) so remove the condition "if an order MUST be applied".

>            For more information on the order of Information Elements
>            see [I-D.ietf-ipfix-protocol]."
>        ::= { ipfixTemplateDefinitionEntry 1 }
> 
>    ipfixTemplateDefinitionIeId OBJECT-TYPE
>        SYNTAX      Integer32 (1..2147483647)

>    ipfixTemplateDefinitionFlags OBJECT-TYPE
>        SYNTAX      BITS {
>                        scope(0),
>                        flowKey(1)
>                    }
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "This bitmask indicates special attributes for the
>            Information Element:
> 
>            scope(0)
>                This Information Element is used for scope.
> 
>            flowKey(1)
>                This Information Element is a Flow key.
> 
>            Thus we get the following values for an Information Element:
> 
>            0
>                The Information Element contains Record values.

Actually, scope and flow key fields are record values as well. Find a
better definition.

>            1 (scope)
>                The Information Element is used for scoping.
> 
> 
> 
> Dietz, et al.          draft-ietf-ipfix-mib-02.txt             [Page 30]
> 
> Internet-Draft                  IPFIX MIB                  December 2007
> 
> 
>            2 (flowKey)
>                The Information Element is used as Flow Key.
>            3 (scope | flowKey)
>                This combination is not allowed."
>        DEFVAL      { { } }
>        ::= { ipfixTemplateDefinitionEntry 4 }

>    ipfixTransportSessionInactiveFlows OBJECT-TYPE
>        SYNTAX      Integer32
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The number of Flows that are currently inactive. I.e. the
>            number of Flows that are currently not monitored because
>            there is no traffice matching the Flow Keys."

traffic

How can I count flows that do not exist?

>        ::= { ipfixTransportSessionStatsEntry 8 }

>    ipfixSelectorTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF IpfixSelectorEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "This table contains Selector Functions connected to a
>            Template by the indexes ipfixTransportSessionIndex,
>            ipfixObservationDomainId and ipfixTemplateId. The Selector
>            Functions are applied to the packets observed at the
>            given Observation Domain in the order implied by the
>            ipfixSelectorIndex. The resulting Flow Records are then
>            exported by using the connected Template.
> 
>            Since IPFIX does not define any Selector Function (except
>            selecting every packet) this is a placeholder for future
>            use and a guideline for implementing enterprise specific
>            Selector Function objects.
> 
>            The following object tree should visualize how the Selector
>            Function objects should be implemented:
> 
>            ipfixSelectorFunctions
>            |
>            +- ipfixFuncSelectAll
>            |  |
>            |  +- ipfixFuncSelectAllAvail (is the function available?)
>            |
>            +- ipfixFuncF2
>            |  |
>            |  +- ipfixFuncF2Avail (is the function F2 available)
>            |  |
>            |  +- ipfixFuncF2Parameters (a table with parameters)
>            ...
>            |
>            +- ipfixFunFn...
> 
>            If a Selector Function takes parameters the MIB should
>            table with an entry for each set of parameters used at the
>            Exporter."

broken sentence?

>        ::= { ipfixObjects 10 }

>    ipfixCollectorCompliance MODULE-COMPLIANCE
>        STATUS      current
>        DESCRIPTION
>            "An implementation that implements an IPFIX Collector Device

remove "Device"

>            that complies to this module MUST implement the objects
>            defined in the mandatory group ipfixCommonGroup.

Is it possible to rephrase with smaller number of "implement" in one
sentence? (repeated in ipfixExporterCompliance)

> 
>            The implementation of all objects in the other groups is
>            optional and depends on the corresponding functionality
>            implemented in the equipment."
>        MODULE  -- this module
>        MANDATORY-GROUPS {
>            ipfixCommonGroup
>        }

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 17 Dec 2007 18:32:16 +0100

Dear Jürgen, all,

Regards,
Gerhard

Editing:

these

remove one "the"
let's

an

he -> it

remove #

built

previously

or

must

sent

remove Metering Process?

a

Values are 2 and 3.

syntax error

traffic

broken sentence?

remove "Device"