RFC Errata
Found 17 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".
Status: Held for Document Update (6)
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: 2761
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-04-01
Held for Document Update by: ron bonica
Section 8 says:
If the measurement parameters change such that a new Template is required, the Template MUST be withdrawn (using a Template Withdraw Message
It should say:
If the measurement parameters change such that a new Template is required, the Template MUST be withdrawn (using a Template Withdrawal Message
Notes:
correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document.
Errata ID: 2762
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-04-01
Held for Document Update by: ron bonica
Section 8 says:
If the Metering Process restarts, the Exporting Process MUST either reuse the previously assigned Template ID for each Template, or it MUST withdraw the previously issued Template IDs by sending Template Withdraw Message(s) before reusing them.
It should say:
If the Metering Process restarts, the Exporting Process MUST either reuse the previously assigned Template ID for each Template, or it MUST withdraw the previously issued Template IDs by sending Template Withdrawal Message(s) before reusing them.
Notes:
Correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document.
Errata ID: 2763
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-04-01
Held for Document Update by: ron bonica
Section 9 says:
If the Collecting Process receives a Template Withdraw message
It should say:
If the Collecting Process receives a Template Withdrawal message
Notes:
Correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document.
Errata ID: 2764
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-04-01
Held for Document Update by: ron bonica
Section 10.3.6 says:
If UDP is selected as the transport protocol, the Template Withdraw Messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP.
It should say:
If UDP is selected as the transport protocol, the Template Withdrawal Messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP.
Notes:
Correct "Template Withdraw Message" to "Template Withdrawal Message" per figure T and the rest of the document.
Errata ID: 2852
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-07-03
Held for Document Update by: Dan Romascanu
Section Figure O says:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope N Field Length | Scope N Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Field Length | Option 1 Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Option 1 Enterprise Number | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope N Field Length | Scope N Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Field Length | Option 1 Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Option 1 Enterprise Number | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
Notice that the rows don't line up properly. I think this is because the ellipsis were supposed to overlap the edges. Compare with the diagram in A.4.3.
Perhaps the ellipsis in the figure in section A.4.2 could also be modified for consistency.
Errata ID: 2857
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-07-11
Held for Document Update by: Dan Romascanu
Section 6.2, 4th par says:
If reduced sizing is used,
It should say:
If reduced size encoding is used,
Notes:
s/reduced sizing/reduced size encoding/
Another instance also in this section: "Reduced sizing can also be used".