From bclaise@cisco.com Mon Jan 16 08:41:47 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5F421F868C for ; Mon, 16 Jan 2012 08:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40-UrR38IngQ for ; Mon, 16 Jan 2012 08:41:46 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8585121F8627 for ; Mon, 16 Jan 2012 08:41:46 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0GGfiXF021083 for ; Mon, 16 Jan 2012 17:41:44 +0100 (CET) Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0GGfhl7023898; Mon, 16 Jan 2012 17:41:44 +0100 (CET) Message-ID: <4F145347.3010205@cisco.com> Date: Mon, 16 Jan 2012 17:41:43 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Aitken References: <4EF0A13E.40401@cisco.com> In-Reply-To: <4EF0A13E.40401@cisco.com> Content-Type: multipart/alternative; boundary="------------030306080409050601090405" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] two issues for RFC5102bis X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 16:41:47 -0000 This is a multi-part message in MIME format. --------------030306080409050601090405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul, Thanks for your email. These two open issues are related. See my reply in line. > Dear IPFIX experts, > > Two issues for RFC5102bis: > > > Firstly, can we recognise that unsigned8, unsigned16, unsigned32, and > unsigned64 aren't different types; they're simply different lengths of > the same type. Accordingly, we should use a single "unsigned" type. > > Similarly for signed. > > Else, when using reduced size encoding to export unsigned64, the > implication is that the _type_ changes? Clearly this isn't the case. > > The encoding of float32 and float64 differs, so these should remain as > different types. Andrew Johnson reminded me that RFC 5101 states that you can RLE a float64 down to a float32 So no distinction between unsigned and float is required in this discussion. I'm thinking about the implications of such a change, i.e, unsigned8, unsigned16, unsigned32, and unsigned64 become unsigned signed8, signed16, signed32, and signed64 become signed float 32, float34 become float What about the backward compatibility? It means that we have to obsolete all IEs in IPFIX IANA whose type is unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, signed64, float32 or float64, right? And then reassigned those to unsigned, signed, or float. Is this realistic? Trying to evaluate the gain now ... I'm not convinced. Yes it's cleaner from a protocol point of view but is it enough? Somehow, I like it to see ipClassOfService = unsigned8. Without it, I would need to rely on the description to discover (or read) this information. "For IPv4 packets, this is the value of the TOS field in the IPv4 packet header. For IPv6 packets, this is the value of the Traffic Class field in the IPv6 packet header." > > > Secondly, the info model should not specify the field size since sizes > are specified in the template. > > There was one argument that the maximum length must be specified for > collector database design. Yes, that was discussed in the past. > This is only an issue if differently-sized fields are stored in the > same database - eg, the database field is only 8 bits wide, and is > suddenly required to store a 16- or 32-bit wide field. This may only > be an issue in an IPFIX aggregator. Why? I see this as a generic problem for any collector. Example: a big fat router, with only one line card. You could encode in the ingress interface as unsigned8, as optimized by the Exporting Process. The collector receives the first template record, and designs its database with an key of size 8. Then you add more line cards, while the router is still exporting, suddenly the Exporting Process must export an ingress interface= unsigned16 Then you add virtual interfaces, and you need ingress interface = unsigned32 > > If this is a real issue, then the infomodel should specify the maximum > length for each field, rather than confusing this with the field type. Maybe, it should have been cleaner if we had done this from day one for all types, but isn't it a little bit too late? Note the max length is specify in the description (even if I found one or two entries where it's not done) for octetArray and string: mplsVpnRouteDistinguisher, octetArray -> "The maximum length of this Information Element is 256 octets" messageMD5Checksum, octetArray -> "This Information Element has a fixed length of 16 octets." wlanSSID, string, "the SSID is encoded into a string of up to 32 characters." ... Note for the IE-doctors: always specify the IE max length, for the collector database design. Regards, Benoit. > > > Thanks, > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > --------------030306080409050601090405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Paul,

Thanks for your email.
These two open issues are related.
See my reply in line.
Dear IPFIX experts,

Two issues for RFC5102bis:


Firstly, can we recognise that unsigned8, unsigned16, unsigned32, and unsigned64 aren't different types; they're simply different lengths of the same type. Accordingly, we should use a single "unsigned" type.

Similarly for signed.

Else, when using reduced size encoding to export unsigned64, the implication is that the _type_ changes? Clearly this isn't the case.

The encoding of float32 and float64 differs, so these should remain as different types.
Andrew Johnson reminded me that RFC 5101 states that you can RLE a float64 down to a float32
So no distinction between unsigned and float is required in this discussion.

I'm thinking about the implications of such a change, i.e,
    unsigned8, unsigned16, unsigned32, and unsigned64 become unsigned
    signed8, signed16, signed32, and signed64 become signed
    float 32, float34 become float
What about the backward compatibility?
It means that we have to obsolete all IEs in IPFIX IANA whose type is unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, signed64, float32 or float64, right? And then reassigned those to unsigned, signed, or float.
Is this realistic?

Trying to evaluate the gain now ... I'm not convinced. Yes it's cleaner from a protocol point of view but is it enough?
Somehow, I like it to see ipClassOfService = unsigned8. Without it, I would need to rely on the description to discover (or read) this information.
"For IPv4 packets, this is the value of the TOS field in
the IPv4 packet header.  For IPv6 packets, this is the
value of the Traffic Class field in the IPv6 packet header."
        


Secondly, the info model should not specify the field size since sizes are specified in the template.

There was one argument that the maximum length must be specified for collector database design.
Yes, that was discussed in the past.
This is only an issue if differently-sized fields are stored in the same database - eg, the database field is only 8 bits wide, and is suddenly required to store a 16- or 32-bit wide field. This may only be an issue in an IPFIX aggregator.
Why? I see this as a generic problem for any collector.
Example: a big fat router, with only one line card. You could encode in the ingress interface as unsigned8, as optimized by the Exporting Process.
The collector receives the first template record, and designs its database with an key of size 8.
Then you add more line cards, while the router is still exporting, suddenly the Exporting Process must export an ingress interface= unsigned16
Then you add virtual interfaces, and you need ingress interface = unsigned32

If this is a real issue, then the infomodel should specify the maximum length for each field, rather than confusing this with the field type.
Maybe, it should have been cleaner if we had done this from day one for all types, but isn't it a little bit too late?

Note the max length is specify in the description  (even if I found one or two entries where it's not done) for octetArray and string:
    mplsVpnRouteDistinguisher, octetArray  -> "The maximum length of this Information Element is 256 octets"
    messageMD5Checksum, octetArray -> "This Information Element has a fixed length of 16 octets."
    wlanSSID, string, "the SSID is encoded into a string of up to 32 characters."
    ...

Note for the IE-doctors: always specify the IE max length, for the collector database design.

Regards, Benoit.


Thanks,
P.
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix



--------------030306080409050601090405-- From paitken@cisco.com Mon Jan 16 14:34:29 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C0D21F86D7 for ; Mon, 16 Jan 2012 14:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.228 X-Spam-Level: X-Spam-Status: No, score=-9.228 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ7mSokvW5yz for ; Mon, 16 Jan 2012 14:34:27 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4615821F86C6 for ; Mon, 16 Jan 2012 14:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=10785; q=dns/txt; s=iport; t=1326753267; x=1327962867; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Ww5siEK4heYDfzgsYa05v/nTWjPjJ/o5PvMW+PjunNU=; b=Z4Cud+ttj8flvKtWeuKiGTT48AnGL3KfmltI4ySIOaajx+sn8LUhHxR/ 569V58mrrvyrl6qtt/0Bo/4mnzCBUMIbkXsZEHO8Jv6pATTEFmzQk7hiM JEcoEt72pbZFasRJl5w3IJzvEqgVbbsP1nY9C+5gQFZJSqvH0Vhk/9R4v 4=; X-IronPort-AV: E=Sophos;i="4.71,520,1320624000"; d="scan'208,217";a="63775176" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 16 Jan 2012 22:34:25 +0000 Received: from [10.61.88.244] (ams3-vpn-dhcp6389.cisco.com [10.61.88.244]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0GMYOfb005000; Mon, 16 Jan 2012 22:34:24 GMT Message-ID: <4F14A5F0.9070506@cisco.com> Date: Mon, 16 Jan 2012 22:34:24 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: Benoit Claise References: <4EF0A13E.40401@cisco.com> <4F145347.3010205@cisco.com> In-Reply-To: <4F145347.3010205@cisco.com> Content-Type: multipart/alternative; boundary="------------050709010607070901090608" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] two issues for RFC5102bis X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 22:34:29 -0000 This is a multi-part message in MIME format. --------------050709010607070901090608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benoit, Perhaps you're right; it's already too late. Thanks, P. On 16/01/12 16:41, Benoit Claise wrote: > Paul, > > Thanks for your email. > These two open issues are related. > See my reply in line. >> Dear IPFIX experts, >> >> Two issues for RFC5102bis: >> >> >> Firstly, can we recognise that unsigned8, unsigned16, unsigned32, and >> unsigned64 aren't different types; they're simply different lengths >> of the same type. Accordingly, we should use a single "unsigned" type. >> >> Similarly for signed. >> >> Else, when using reduced size encoding to export unsigned64, the >> implication is that the _type_ changes? Clearly this isn't the case. >> >> The encoding of float32 and float64 differs, so these should remain >> as different types. > Andrew Johnson reminded me that RFC 5101 states that you can RLE a > float64 down to a float32 > So no distinction between unsigned and float is required in this > discussion. > > I'm thinking about the implications of such a change, i.e, > unsigned8, unsigned16, unsigned32, and unsigned64 become unsigned > signed8, signed16, signed32, and signed64 become signed > float 32, float34 become float > What about the backward compatibility? > It means that we have to obsolete all IEs in IPFIX IANA whose type is > unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, > signed32, signed64, float32 or float64, right? And then reassigned > those to unsigned, signed, or float. > Is this realistic? > > Trying to evaluate the gain now ... I'm not convinced. Yes it's > cleaner from a protocol point of view but is it enough? > Somehow, I like it to see ipClassOfService = unsigned8. Without it, I > would need to rely on the description to discover (or read) this > information. > > "For IPv4 packets, this is the value of the TOS field in > the IPv4 packet header. For IPv6 packets, this is the > value of the Traffic Class field in the IPv6 packet header." > >> >> >> Secondly, the info model should not specify the field size since >> sizes are specified in the template. >> >> There was one argument that the maximum length must be specified for >> collector database design. > Yes, that was discussed in the past. >> This is only an issue if differently-sized fields are stored in the >> same database - eg, the database field is only 8 bits wide, and is >> suddenly required to store a 16- or 32-bit wide field. This may only >> be an issue in an IPFIX aggregator. > Why? I see this as a generic problem for any collector. > Example: a big fat router, with only one line card. You could encode > in the ingress interface as unsigned8, as optimized by the Exporting > Process. > The collector receives the first template record, and designs its > database with an key of size 8. > Then you add more line cards, while the router is still exporting, > suddenly the Exporting Process must export an ingress interface= > unsigned16 > Then you add virtual interfaces, and you need ingress interface = > unsigned32 >> >> If this is a real issue, then the infomodel should specify the >> maximum length for each field, rather than confusing this with the >> field type. > Maybe, it should have been cleaner if we had done this from day one > for all types, but isn't it a little bit too late? > > Note the max length is specify in the description (even if I found > one or two entries where it's not done) for octetArray and string: > mplsVpnRouteDistinguisher, octetArray -> "The maximum length of > this Information Element is 256 octets" > messageMD5Checksum, octetArray -> "This Information Element has a > fixed length of 16 octets." > wlanSSID, string, "the SSID is encoded into a string of up to 32 > characters." > ... > > Note for the IE-doctors: always specify the IE max length, for the > collector database design. > > Regards, Benoit. >> >> >> Thanks, >> P. >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> >> > --------------050709010607070901090608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Benoit,

Perhaps you're right; it's already too late.

Thanks,
P.


On 16/01/12 16:41, Benoit Claise wrote:
Paul,

Thanks for your email.
These two open issues are related.
See my reply in line.
Dear IPFIX experts,

Two issues for RFC5102bis:


Firstly, can we recognise that unsigned8, unsigned16, unsigned32, and unsigned64 aren't different types; they're simply different lengths of the same type. Accordingly, we should use a single "unsigned" type.

Similarly for signed.

Else, when using reduced size encoding to export unsigned64, the implication is that the _type_ changes? Clearly this isn't the case.

The encoding of float32 and float64 differs, so these should remain as different types.
Andrew Johnson reminded me that RFC 5101 states that you can RLE a float64 down to a float32
So no distinction between unsigned and float is required in this discussion.

I'm thinking about the implications of such a change, i.e,
    unsigned8, unsigned16, unsigned32, and unsigned64 become unsigned
    signed8, signed16, signed32, and signed64 become signed
    float 32, float34 become float
What about the backward compatibility?
It means that we have to obsolete all IEs in IPFIX IANA whose type is unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, signed64, float32 or float64, right? And then reassigned those to unsigned, signed, or float.
Is this realistic?

Trying to evaluate the gain now ... I'm not convinced. Yes it's cleaner from a protocol point of view but is it enough?
Somehow, I like it to see ipClassOfService = unsigned8. Without it, I would need to rely on the description to discover (or read) this information.
"For IPv4 packets, this is the value of the TOS field in
the IPv4 packet header.  For IPv6 packets, this is the
value of the Traffic Class field in the IPv6 packet header."
        


Secondly, the info model should not specify the field size since sizes are specified in the template.

There was one argument that the maximum length must be specified for collector database design.
Yes, that was discussed in the past.
This is only an issue if differently-sized fields are stored in the same database - eg, the database field is only 8 bits wide, and is suddenly required to store a 16- or 32-bit wide field. This may only be an issue in an IPFIX aggregator.
Why? I see this as a generic problem for any collector.
Example: a big fat router, with only one line card. You could encode in the ingress interface as unsigned8, as optimized by the Exporting Process.
The collector receives the first template record, and designs its database with an key of size 8.
Then you add more line cards, while the router is still exporting, suddenly the Exporting Process must export an ingress interface= unsigned16
Then you add virtual interfaces, and you need ingress interface = unsigned32

If this is a real issue, then the infomodel should specify the maximum length for each field, rather than confusing this with the field type.
Maybe, it should have been cleaner if we had done this from day one for all types, but isn't it a little bit too late?

Note the max length is specify in the description  (even if I found one or two entries where it's not done) for octetArray and string:
    mplsVpnRouteDistinguisher, octetArray  -> "The maximum length of this Information Element is 256 octets"
    messageMD5Checksum, octetArray -> "This Information Element has a fixed length of 16 octets."
    wlanSSID, string, "the SSID is encoded into a string of up to 32 characters."
    ...

Note for the IE-doctors: always specify the IE max length, for the collector database design.

Regards, Benoit.


Thanks,
P.
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix




--------------050709010607070901090608-- From muenz@net.in.tum.de Wed Jan 18 14:21:15 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D369121F8574 for ; Wed, 18 Jan 2012 14:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoeY6uMsVN73 for ; Wed, 18 Jan 2012 14:21:15 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id C18B821F8572 for ; Wed, 18 Jan 2012 14:21:10 -0800 (PST) Received: from [192.168.2.26] (e181137161.adsl.alicedsl.de [85.181.137.161]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 33936205779C; Wed, 18 Jan 2012 23:21:09 +0100 (CET) Message-ID: <4F1745CA.60500@net.in.tum.de> Date: Wed, 18 Jan 2012 23:20:58 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Benoit Claise References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> In-Reply-To: <4E78A0EC.9030003@cisco.com> Content-Type: multipart/alternative; boundary="------------030307090105090803050108" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 22:21:15 -0000 This is a multi-part message in MIME format. --------------030307090105090803050108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Benoit, Getting back to this issue: On 20.09.2011 16:19, Benoit Claise wrote: > Thirdly, the section 4.2 doesn't take into account a metering process > id. Indeed, what if we have multiple caches on the exporter? Having another look at RFC5101, I see that this situation is already covered in RFC5101! See the following paragraph which appears in sections 4.1 and 4.2: Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field. If you now want to make meteringProcessId mandatory, you need to remove these paragraphs at least. Gerhard > > Here is a proposal for 4.2 and 4.3. The underlined parts are new > > > 4.2. The Metering Process Reliability Statistics Option Template > > > > The Metering Process Reliability Option Template specifies the > structure of a Data Record for reporting lack of reliability in the > Metering Process. It SHOULD contain the following Information > Elements that are defined in [RFC5102 ]: > > observationDomainId > An identifier of an Observation Domain that > is locally unique to the Exporting Process. > This Information Element MUST be defined as a > Scope Field. > > > _ meteringProcessId (*) > The identifier of the Metering Process for > which lack of reliability is reported. There > This Information Element MUST be defined as a > Scope Field._ > > ignoredPacketTotalCount > The total number of IP packets that the > Metering Process did not process. > > ignoredOctetTotalCount > The total number of octets in observed IP > packets that the Metering Process did not > process. > > time first_packet_ignored > The timestamp of the first IP packet that was > ignored by the Metering Process. For this > timestamp, any of the "flowStart" timestamp > Information Elements flowStartMilliseconds, > flowStartMicroseconds, flowStartNanoseconds, > and flowStartDeltaMicroseconds can be used. > > time last_packet_ignored > The timestamp of the last IP packet that was > ignored by the Metering Process. For this > timestamp, any of the "flowEnd" timestamp > Information Elements flowEndMilliseconds, > flowEndMicroseconds, flowEndNanoseconds, and > flowEndDeltaMicroseconds can be used. > > --------------030307090105090803050108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Benoit,

Getting back to this issue:

On 20.09.2011 16:19, Benoit Claise wrote:
Thirdly, the section 4.2 doesn't take into account a metering process id. Indeed, what if we have multiple caches on the exporter?

Having another look at RFC5101, I see that this situation is already covered in RFC5101!
See the following paragraph which appears in sections 4.1 and 4.2:

   Note that if several Metering Processes are available on the Exporter
   Observation Domain, the Information Element meteringProcessId MUST be
   specified as an additional Scope Field.
If you now want to make meteringProcessId mandatory, you need to remove these paragraphs at least.

Gerhard


Here is a proposal for 4.2 and 4.3. The underlined parts are new

4.2.  The Metering Process Reliability Statistics Option Template


   The Metering Process Reliability Option Template specifies the
   structure of a Data Record for reporting lack of reliability in the
   Metering Process.  It SHOULD contain the following Information
   Elements that are defined in [RFC5102]:

   observationDomainId
                           An identifier of an Observation Domain that
                           is locally unique to the Exporting Process.
                           This Information Element MUST be defined as a
                           Scope Field.

    
   meteringProcessId (*)
                           The identifier of the Metering Process for
                           which lack of reliability is reported.  There
                           This Information Element MUST be defined as a 
                           Scope Field.

   ignoredPacketTotalCount
                           The total number of IP packets that the
                           Metering Process did not process.

   ignoredOctetTotalCount
                           The total number of octets in observed IP
                           packets that the Metering Process did not
                           process.

   time first packet ignored
                           The timestamp of the first IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowStart" timestamp
                           Information Elements flowStartMilliseconds,
                           flowStartMicroseconds, flowStartNanoseconds,
                           and flowStartDeltaMicroseconds can be used.

   time last packet ignored
                           The timestamp of the last IP packet that was
                           ignored by the Metering Process.  For this
                           timestamp, any of the "flowEnd" timestamp
                           Information Elements flowEndMilliseconds,
                           flowEndMicroseconds, flowEndNanoseconds, and
                           flowEndDeltaMicroseconds can be used.
--------------030307090105090803050108-- From muenz@net.in.tum.de Thu Jan 19 12:25:59 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3463F21F86E1 for ; Thu, 19 Jan 2012 12:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-SGNjUP4ThE for ; Thu, 19 Jan 2012 12:25:58 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id A060221F86D1 for ; Thu, 19 Jan 2012 12:25:58 -0800 (PST) Received: from [192.168.2.26] (g231049240.adsl.alicedsl.de [92.231.49.240]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 57B342022EA8 for ; Thu, 19 Jan 2012 21:25:57 +0100 (CET) Message-ID: <4F187C59.60401@net.in.tum.de> Date: Thu, 19 Jan 2012 21:26:01 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E78F855.3070800@cisco.com> <4E7A3F0A.102@net.in.tum.de> In-Reply-To: <4E7A3F0A.102@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] [Sender: ipfix-bounces@ietf.org] RFC5101: time first flow dropped and time last flow dropped X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 20:25:59 -0000 Dear all, On 21.09.2011 21:46, Gerhard Muenz wrote: [...] > We do not have selectorId, exportingProcessId, and meteringProcessId in > the configuration data model. If we think about adding > meteringProcessId, it may be worth thinking about the other IDs as well. > > I do not see a problem if these are defined as state parameters (e.g. > read-only). > > selectorId is a bit different because the scope is OD, not IPFIX device. > Therefore, the same ID value may appear for different Selectors of the > same device. I found that we had an internal discussion about selectorId back in 2010. The conclusion was twofold: 1) It is not possible to simply add a single selectorId parameter per Selector because Selector ID is only unique per Observation Domain and not per PSAMP Device. Similarly to selectionSequenceId, only a list of tuples (observationDomainId,selectorId) would make sense in the configuration model. 2) selectorId is actually not needed in the configuration model because we already have the tuples (observationDomainId,selectionSequenceId) which allow associating "Selection Sequence Report Interpretation" and "Selection Sequence Statistics Report Interpretation" with the corresponding Selection Process in the configuration model. So, I will only add exportingProcessId and meteringProcessId. If somebody thinks of writing an RFC5476bis, I suggest to broaden the scope of selectorId and selectionSequenceId from Observation Domain to PSAMP Device in order to be consistent with meteringProcessId and exportingProcessId. Gerhard From paitken@cisco.com Thu Jan 19 14:13:17 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B3321F86DF for ; Thu, 19 Jan 2012 14:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwGbYBR8vBG2 for ; Thu, 19 Jan 2012 14:13:16 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F2F9A21F86EA for ; Thu, 19 Jan 2012 14:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=361; q=dns/txt; s=iport; t=1327011196; x=1328220796; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=WTJ3JBH04rORgwydvUr07rF/zLlrY50kLotbJ6/2WeA=; b=Xq2/Zn6J03ieK9C+A5bzbHMiAYmUfknDzHmI0CsTywQnSCgGcMn80xxc qJFibcrHovkJ1eRbu00SetvDjdmqixmfsLEstlF1m3J7uQKO4tLXM7C4h 5M5V3r959gn87iP9C2Cc4u7ALX1WwqwSy29xbmIu87t4U0yeUWWD1xdYm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGAOKUGE+Q/khM/2dsb2JhbAAqGoMNqWqBAIEFggsBJTYKATwWGAMCAQIBSw0BBwEBBRmHYiSaLAGeNYkUFwEMAQEFAwQNBQsEAgQBBQgFBBEFAQYBAQYBBQclAQIBAQIBAgECAQEBAQIWFQMBBgwHAgIDHQMBBgkCAQ0BAQMLAgsCCwMBAQmBMQEBBQIDBwEBAQIBAQEBDQ4VA4NaBJUXhVWMdWw X-IronPort-AV: E=Sophos;i="4.71,538,1320624000"; d="scan'208";a="127042562" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2012 22:13:14 +0000 Received: from [10.55.89.90] (dhcp-10-55-89-90.cisco.com [10.55.89.90]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0JMDEQA026549; Thu, 19 Jan 2012 22:13:14 GMT Message-ID: <4F18957A.6010809@cisco.com> Date: Thu, 19 Jan 2012 22:13:14 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Benoit Claise Subject: [IPFIX] errata 2052 : IPFIX selectorID X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 22:13:17 -0000 Dear all, Since errata 2052 has been verified for > 1 year, I've asked IANA to make the change in the IPFIX registry. http://www.rfc-editor.org/errata_search.php?eid=2052 This changes selectorID from 16 bits to 64 bits per discussion on the IPFIX mailing list: http://www.ietf.org/mail-archive/web/ipfix/current/msg05133.html P. From paitken@cisco.com Thu Jan 19 14:23:11 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458A421F857A for ; Thu, 19 Jan 2012 14:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBl1H0kSRuNY for ; Thu, 19 Jan 2012 14:23:10 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7123021F8573 for ; Thu, 19 Jan 2012 14:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=281; q=dns/txt; s=iport; t=1327011790; x=1328221390; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=k3TlG6d3hHoz2mR+U9G8Tan8miIVWzN5wPUjpIbWxBg=; b=BZVHGf7vN6nXsaWS71PlQqwoHI4S+adhQKk0S47P+fvJsY17mKkw48sS RZ0UDfB+cLb4xKKLGE9Y/h3p33HvX+G+8sOj0JY81VJoFI8VjYcYyhyyl P+E4nty4HUru/sPwVQ/pQuemtFLTcKhlTlqBXrH4wTDSRwcsFdzJ5OF4Z o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUGADGXGE+Q/khR/2dsb2JhbABEgw2paoEAgQWBcgEBAQMBEgElQAEFCwshFg8JAwIBAgFFBg0BBwEBHodaml0BnjaJOAEBBQMEDQULBAIEAQUIBQQRBQEGAQEGAQUHJQECAQECAQIBAgEBAQECFhUDAQYMBwICAx0DAQYJAgENAQEDCwILAgsDAQEJgTEBAQUCAwcBAQECAQEBAQsJAQECEAECAwEGAwIDBAEEg0cElReFVYx1 X-IronPort-AV: E=Sophos;i="4.71,538,1320624000"; d="scan'208";a="127043042" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2012 22:23:09 +0000 Received: from [10.55.89.90] (dhcp-10-55-89-90.cisco.com [10.55.89.90]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0JMN9BL032342; Thu, 19 Jan 2012 22:23:09 GMT Message-ID: <4F1897CC.1080806@cisco.com> Date: Thu, 19 Jan 2012 22:23:08 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: Gerhard Muenz References: <4A8015DF.6040903@cisco.com> <4E78A0EC.9030003@cisco.com> <4E78F855.3070800@cisco.com> <4E7A3F0A.102@net.in.tum.de> <4F187C59.60401@net.in.tum.de> In-Reply-To: <4F187C59.60401@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] RFC5101: time first flow dropped and time last flow dropped X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 22:23:11 -0000 Gerhard, > If somebody thinks of writing an RFC5476bis, I suggest to broaden the > scope of selectorId and selectionSequenceId from Observation Domain to > PSAMP Device in order to be consistent with meteringProcessId and > exportingProcessId. Well volunteered! P. From internet-drafts@ietf.org Fri Jan 20 03:34:24 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1491621F8687; Fri, 20 Jan 2012 03:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-6GhHCX+Q+y; Fri, 20 Jan 2012 03:34:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C6521F864F; Fri, 20 Jan 2012 03:34:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120120113404.6140.84246.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2012 03:34:04 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-rfc5815bis-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 11:34:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Gr= oup of the IETF. Title : Definitions of Managed Objects for IP Flow Information E= xport Author(s) : Thomas Dietz Atsushi Kobayashi Benoit Claise Gerhard Muenz Filename : draft-ietf-ipfix-rfc5815bis-01.txt Pages : 68 Date : 2012-01-20 This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-rfc5815bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-rfc5815bis-01.txt From Thomas.Dietz@neclab.eu Fri Jan 20 03:38:51 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EC821F85AC for ; Fri, 20 Jan 2012 03:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u1wAEIh88-k for ; Fri, 20 Jan 2012 03:38:50 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6A19A21F85AA for ; Fri, 20 Jan 2012 03:38:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5CBF62800020A for ; Fri, 20 Jan 2012 12:38:49 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M5pdleduSGg for ; Fri, 20 Jan 2012 12:38:49 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 39B1228000085 for ; Fri, 20 Jan 2012 12:38:44 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.103]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 20 Jan 2012 12:38:23 +0100 From: Thomas Dietz To: "ipfix@ietf.org" Thread-Topic: [IPFIX] I-D Action: draft-ietf-ipfix-rfc5815bis-01.txt Thread-Index: AQHM12eC6H01MuPTDkCkRiFNcV9TFpYVIN0Q Date: Fri, 20 Jan 2012 11:38:23 +0000 Message-ID: <75581E268A48F849916117B977D76D3734CBF479@PALLENE.office.hd> References: <20120120113404.6140.84246.idtracker@ietfa.amsl.com> In-Reply-To: <20120120113404.6140.84246.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.137] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03A3_01CCD770.6574E390" MIME-Version: 1.0 Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-rfc5815bis-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 11:38:51 -0000 ------=_NextPart_000_03A3_01CCD770.6574E390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I just updated the rfc5815bis draft now addressing all pending errata of RFC 5815 and taking into account Paul's review of the document. Best Regards, Thomas -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, January 20, 2012 12:34 PM > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org > Subject: [IPFIX] I-D Action: draft-ietf-ipfix-rfc5815bis-01.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 : Definitions of Managed Objects for IP Flow > Information Export > Author(s) : Thomas Dietz > Atsushi Kobayashi > Benoit Claise > Gerhard Muenz > Filename : draft-ietf-ipfix-rfc5815bis-01.txt > Pages : 68 > Date : 2012-01-20 > > This document defines managed objects for IP Flow Information eXport > (IPFIX). These objects provide information for monitoring IPFIX > Exporters and IPFIX Collectors including the basic configuration > information. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-rfc5815bis-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-rfc5815bis-01.txt > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix ------=_NextPart_000_03A3_01CCD770.6574E390 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQsMIIEKAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICZzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAxMjAxMTM4MjJaMCMGCSqGSIb3 DQEJBDEWBBT7iVPgGruMRN8gG3Bxx4cGY7yWsDCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCG SAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzANBgkqhkiG9w0BAQEFAASCAQBG yhC1hA2x4K1n7jAHBLk7IbW3SBIAHLNiK7lWx3uNsKNs6d2uYz9wrfI+/WTHEOzLfemLKzYzpfHh 1rDNPKTrxqxjAcdlSxbBDD8KwVNvgt9Umsag1V9md1w4vvebtJRUqFuxaUuoIlPGHNBjEv9fxTqB jGZqAEUl1gx+Aj9aFvrrjLcdWwFTeSo6dn3O1SnB1ElZwX0MksZw46ewOaKpJUwJwMQa09TZnHIl SEG5CQNImZHSKuOr7/84PKu6pnljH3UGgjqfz5gl04V+3wrWpjxHl4dvYa3Mar8MIPBO/nxlp7Fx 3DJDhjiDzCEpvLG1TJEtsb0qf9nztL3fWfKoAAAAAAAA ------=_NextPart_000_03A3_01CCD770.6574E390-- From internet-drafts@ietf.org Tue Jan 24 10:37:30 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D3111E80AD; Tue, 24 Jan 2012 10:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa9jTiBz0lQ5; Tue, 24 Jan 2012 10:37:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914BF11E8079; Tue, 24 Jan 2012 10:37:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120124183729.8210.66865.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2012 10:37:29 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 18:37:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Gr= oup of the IETF. Title : Information Model for IP Flow Information eXport (IPFIX) Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-information-model-rfc5102bis-00.txt Pages : 30 Date : 2012-01-24 This memo defines an overview of the information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-information-model-rfc5= 102bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-information-model-rfc51= 02bis-00.txt From bclaise@cisco.com Tue Jan 24 11:14:21 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FBF11E8085 for ; Tue, 24 Jan 2012 11:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRLh9uCr6kFa for ; Tue, 24 Jan 2012 11:14:21 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E961D11E8072 for ; Tue, 24 Jan 2012 11:14:20 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0OJEJWb029148 for ; Tue, 24 Jan 2012 20:14:20 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0OJEJL0022694 for ; Tue, 24 Jan 2012 20:14:19 +0100 (CET) Message-ID: <4F1F030A.8060508@cisco.com> Date: Tue, 24 Jan 2012 20:14:18 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4F1F0046.4060205@cisco.com> In-Reply-To: <4F1F0046.4060205@cisco.com> X-Forwarded-Message-Id: <4F1F0046.4060205@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Fwd: Re: New Version Notification for draft-ietf-ipfix-information-model-rfc5102bis-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 19:14:21 -0000 Dear all, Here is the WG document, for the next level of standardization of RFC5102 (based on the individual draft draft-claise-ipfix-information-model-rfc5102bis-01) Please review this new draft for mistakes. Also, please review the list of open issues, to make sure that we haven't missed any. See http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-00 Regards, Benoit. > A new version of I-D, draft-ietf-ipfix-information-model-rfc5102bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. > > Filename: draft-ietf-ipfix-information-model-rfc5102bis > Revision: 00 > Title: Information Model for IP Flow Information eXport (IPFIX) > Creation date: 2012-01-24 > WG ID: ipfix > Number of pages: 30 > > Abstract: > This memo defines an overview of the information model for the IP Flow > Information eXport (IPFIX) protocol. It is used by the IPFIX protocol > for encoding measured traffic information and information related to the > traffic Observation Point, the traffic Metering Process, and the > Exporting Process. Although developed for the IPFIX protocol, the model > is defined in an open way that easily allows using it in other > protocols, interfaces, and applications. This document obsoletes RFC > 5102. > > > > > The IETF Secretariat > > From paitken@cisco.com Mon Jan 30 12:17:34 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72F721F84FF for ; Mon, 30 Jan 2012 12:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.32 X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PGta7-F15pL for ; Mon, 30 Jan 2012 12:17:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E319721F84C9 for ; Mon, 30 Jan 2012 12:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=290; q=dns/txt; s=iport; t=1327954654; x=1329164254; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=PrZwSFbtfh/lxLVsf1oQAYsCbP168BYSseq5wd/Nsts=; b=SZcw7WTv3TT+e5+X4+Saudni1aTIu8s9y8ydpGj+VLTmyOHyoMJWkGh1 lGNCqj8D34rgKNX3FCf+Z4dqBNdnzvymmVMaxSTWc7fCSpTPFX6PupEzE i0+p08vUJKrXWglikIMv1cBNw+yU5RHWwTb4/2gE1UAhg8E2yl2OJjFOk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI75Jk+Q/khL/2dsb2JhbABDrlaBBYILASVAPRYYAwIBAgFLDQgBAR6gToEnAZ46iD0BAwICBAoCAQwEAwQLAQgBBQkGAwQXAQIBgnEZBAIKAg0HAVsMAgQDg1YElRqFVox7 X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="128036932" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2012 20:17:32 +0000 Received: from [10.55.90.231] (dhcp-10-55-90-231.cisco.com [10.55.90.231]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0UKHW3k004060 for ; Mon, 30 Jan 2012 20:17:32 GMT Message-ID: <4F26FADF.8070900@cisco.com> Date: Mon, 30 Jan 2012 20:17:35 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] RFC 5101bis - UDP checksum X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 20:17:35 -0000 Dear all, Per RFC 768 and RFC 1122, UDP checksums are not mandatory. Since the IPv4 checksum is only calculated over the header (not the data) and there is no IPv6 checksum, 5101bis should include a line recommending that UDP checksums are enabled when exporting over UDP. P. From wwwrun@rfc-editor.org Tue Jan 31 15:29:35 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B23521F84D1 for ; Tue, 31 Jan 2012 15:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRg88cOMy6nw for ; Tue, 31 Jan 2012 15:29:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id F420021F84CF for ; Tue, 31 Jan 2012 15:29:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C162B72F1D0; Tue, 31 Jan 2012 15:25:42 -0800 (PST) To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20120131232542.C162B72F1D0@rfc-editor.org> Date: Tue, 31 Jan 2012 15:25:42 -0800 (PST) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5102 (3101) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 23:29:35 -0000 The following errata report has been submitted for RFC5102, "Information Model for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=3101 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 5.9. Original Text ------------- Timestamps flowStartSysUpTime and flowEndSysUpTime are relative timestamps indicating the time relative to the last (re- )initialization of the IPFIX Device. For reporting the time of the last (re-)initialization, systemInitTimeMilliseconds can be reported, for example, in Data Records defined by Option Templates. Corrected Text -------------- Timestamps flowStartSysUpTime and flowEndSysUpTime are relative timestamps indicating the time relative to the last (re-)initialization of the IPFIX Device. For reporting the time of the last (re-)initialization, systemInitTimeMilliseconds can be reported, for example, in Data Records defined by Option Templates. Notes ----- Poor formatting of "(re-)initialization" in the 3rd paragraph of section 5.9 Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5102 (draft-ietf-ipfix-info-15) -------------------------------------- Title : Information Model for IP Flow Information Export Publication Date : January 2008 Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG