RFC Errata
Found 11 records.
Status: Verified (11)
RFC 5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", January 2008
Note: This RFC has been obsoleted by RFC 7011
Source of RFC: ipfix (ops)
Errata ID: 1655
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2009-01-20
Verifier Name: Dan Romascanu
Date Verified: 2009-02-18
Section A.4.4. says:
Line Card ID | IPFIX Message | Exported Flow Records ------------------------------------------------------------------- Line Card 1 (lineCardId=1) | 345 | 10201 Line Card 2 (lineCardId=2) | 690 | 20402
It should say:
Enterprise field 123 | exportedPacketCount | exportedFlowCount ------------------------------------------------------------------- 1 | 345 | 10201 2 | 690 | 20402
Notes:
The example in A.4.4 uses set ID 260 which is defined in the template in A.4.3.
Therefore the fields used in A.4.4 must be those defined in A.4.3.
Fortunately the field lengths are correct, so no other change is required.
Errata ID: 2791
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2011-04-28
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section 7 says:
If the length of the Information Element is greater than or equal to 255 octets, the length is encoded into 3 octets before the Information Element. The first octet is 255, and the length is carried in the second and third octets, as shown in Figure S.
It should say:
The length may also be encoded into 3 octets before the Information element allowing the length of the Information Element to be greater than or equal to 255 octets. In this case, first octet of the Lenght field MUST be 255, and the length is carried in the second and third octets, as shown in Figure S.
Notes:
The original text is ambiguous as to whether it is possible to carry a length of less than 255 encoded in a 3 octet Length field. The quoted text seems to say it is not allowed, but Figure S says that the 2nd and 3rd octets may be set to "Length (0 to 65535)".
Since there is absolutely no harm (except a little inefficiency) in using a 3 octet Length field to encode a small length, the document should be clarified to remove the ambiguity.
Errata ID: 2814
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Brian Trammell
Date Reported: 2011-05-24
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section 4.1 says:
exportedFlowTotalCount
The total number of Flow Records that the
Exporting Process successfully sent to the
Collecting Process since the Exporting
Process re-initialization.
It should say:
exportedFlowRecordTotalCount
The total number of Flow Records that the
Exporting Process successfully sent to the
Collecting Process since the Exporting
Process re-initialization.
Notes:
The exportedFlowRecordTotalCount Information Element (42) is incorrectly referenced in the text in this section as exportedFlowTotalCount.
Errata ID: 1818
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benoit Claise
Date Reported: 2009-07-26
Verifier Name: Dan Romascanu
Date Verified: 2009-08-02
Section All says:
Notes:
Throughout the document, all instances of "Option Template" must be replaced by "Options Template"
Errata ID: 2792
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2011-04-28
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section A.5.2 says:
A.5.2. Example of Variable-Length Information Element with Length 255
to 65535 Octets
It should say:
A.5.2. Example of Variable-Length Information Element with 3 Octet
Length Encoding
Notes:
Per Erratum 2791, this section header should be changed to reflect that the 3 octet Lenght encoding supports lengths of less than 255 as well as greater than or equal to 255.
Note that there is a corresponding change in the Table of Contents
Errata ID: 2888
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section 6.1.7 says:
6.1.7. dateTimeSeconds The data type dateTimeseconds represents a time value in units of seconds normalized to the GMT timezone. It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1, 1970. The 32-bit integer allows the time encoding up to 136 years.
It should say:
6.1.7. dateTimeSeconds The data type dateTimeSeconds represents a time value in units of seconds normalized to the GMT timezone. It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1, 1970. The 32-bit integer allows the time encoding up to 136 years.
Notes:
s/dateTimeseconds/dateTimeSeconds/
- per the section title, the definition in IANA's IPFIX registry, and usage in other IPFIX RFCs.
Errata ID: 2889
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section multiple says:
exportedFlowCount
It should say:
exportedFlowRecordTotalCount
Notes:
s/exportedFlowCount/exportedFlowRecordTotalCount/ (four times)
- in sections A.4.1 (+figure), and A.4.3 (+figure).
The definition in [RFC5102] and IANA's IPFIX registry is "exportedFlowRecordTotalCount" (as correctly used elsewhere in this RFC).
Errata ID: 2890
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section multiple says:
exportedPacketCount
It should say:
exportedMessageTotalCount
Notes:
s/exportedPacketCount/exportedMessageTotalCount/ (six times)
- in sections A.4.1 (+figure), A.4.2 (+figure), and A.4.3 (+figure).
[RFC5102] defines exportedMessageTotalCount, exportedOctetTotalCount, and exportedFlowRecordTotalCount - but no "exportedPacketCount".
Presumably "exportedMessageTotalCount" is the name that's intended here.
Errata ID: 2891
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section multiple says:
inOctetDeltaCount
It should say:
octetDeltaCount
Notes:
s/inOctetDeltaCount/octetDeltaCount/ (four times)
- in sections A.2.1 (+figure) and A.2.2 (+figure)
Per [RFC5102] and IANA's IPFIX registry, the correct name is "octetDeltaCount".
Errata ID: 2892
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section multiple says:
inPacketDeltaCount
It should say:
packetDeltaCount
Notes:
s/inPacketDeltaCount/packetDeltaCount/ (four times)
- in sections A.2.1 (+figure) and A.2.2 (+figure)
Per [RFC5102] and IANA's IPFIX registry, the correct name is "packetDeltaCount".
Errata ID: 2903
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Verifier Name: Dan Romascanu
Date Verified: 2011-08-02
Section 6.1.6 says:
6.1.6. string and octetarray The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an Information Element of fixed or variable length. The length of the Information Element specifies the length of the octetarray.
It should say:
6.1.6. string and octetArray The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an Information Element of fixed or variable length. The length of the Information Element specifies the length of the octetArray.
Notes:
s/octetarray/octetArray/ (twice).
Also in section 6.2:
"Information Elements containing integer, string, float, and
octetarray types in the information model ..."
Per RFC5102 and IANA's IPFIX registry, the correct name is "octetArray".