RFC Errata
Found 18 records.
Status: Verified (5)
RFC 5655, "Specification of the IP Flow Information Export (IPFIX) File Format", October 2009
Source of RFC: ipfix (ops)
Errata ID: 3559
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2013-03-20
Verifier Name: Benoit Claise
Date Verified: 2013-03-24
Section 8.2.1 says:
(none)
It should say:
Units: milliseconds
Notes:
collectionTimeMilliseconds requires units of milliseconds.
Compare with sections 8.2.7 and 8.2.14 in the same document.
IANA's IPFIX IE registry requires the corresponding update.
Errata ID: 3560
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2013-03-20
Verifier Name: Benoit Claise
Date Verified: 2013-07-26
Section 8.2.11 + .18 says:
(none)
It should say:
Range: The valid range is 0-0.
Notes:
8.2.11 messageScope requires a value of 0 ("The value of this Information Element MUST be written as 0") but no range is given. The range should say "0-0". (Compare with text in RFC 5102).
Similarly for 8.2.18 sessionScope.
Note to IANA: the changes are already done in the IPFIX registry, via the IE doctors (draft-ietf-ipfix-ie-doctors-07 procedure)
Errata ID: 1988
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Verifier Name: Dan Romascanu
Date Verified: 2010-05-11
Section 9.1.3, pg.39 says:
signedAttrs: an optional set of attributes that are signed along
with the content.
| digestAlgorithm: identifies the digital signature algorithm and
associated parameters used to generate the signature.
signature: the digital signature of the associated file.
unsignedAttrs: an optional set of attributes that are not signed.
It should say:
signedAttrs: an optional set of attributes that are signed along
with the content.
| signatureAlgorithm: identifies the digital signature algorithm and
associated parameters used to generate the signature.
signature: the digital signature of the associated file.
unsignedAttrs: an optional set of attributes that are not signed.
Notes:
Rationale:
Same SEQUENCE element name listed twice, for two different explanations.
Further Note (keep for update!):
In Section 9.1, in the ASN.1 on page 37, for a better approximation
to ASN.1, all pairs of curly braces, "{" ... "}", should better be
preceded by the keyword "SEQUENCE".
Errata ID: 4306
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Wayne Tackabury
Date Reported: 2015-03-19
Verifier Name: Benoit Claise
Date Verified: 2015-03-19
Section A.5 says:
224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E
[ message checksum record ^ -->
240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00
256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01
It should say:
224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 16 00 3E
[ message checksum record ^ -->
240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00
256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01
Notes:
First of all, note that per erratum #2030, the offsets in this whole section are wrong, it should begin (I think) at 192. I shall use the published (incorrect) offset for illuminating this point:
I believe the byte at #237 should be 0x16 and not 0x18. I suspect this checksum was copy-pasted from a prior instance in the example, where there were three pad bytes added to the data record for #259 (0x103). In this instance, there is only one pad byte at #255, hence the offset here should be two less (22 or 0x16 and not 24 or 0x18):
2 bytes set ID
2 bytes length
1 byte option data
16 bytes checksum data
1 byte pad (at #255)
...totalling 22. Thanks!
Errata ID: 2906
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 B.1.1 says:
Observation Domain ID: Similarly, the NetFlow V9 sourceID has
become the IPFIX Observation Domain ID.
It should say:
Observation Domain ID: Similarly, the NetFlow V9 Source ID has
become the IPFIX Observation Domain ID.
Notes:
s/sourceID/Source ID/
Per consistent usage in RFC3954, the correct term is "Source ID".
Status: Held for Document Update (11)
RFC 5655, "Specification of the IP Flow Information Export (IPFIX) File Format", October 2009
Source of RFC: ipfix (ops)
Errata ID: 2030
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrei Rohau
Date Reported: 2010-02-01
Held for Document Update by: Dan Romascanu
Section A.5, pg.56 says:
Bringing together the examples above and adding message headers as
appropriate, a hex dump of the first 317 bytes of the example File
constructed above would appear as in the annotated Figure 10 below.
...
144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00
176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01
[^ second message header (length 80 bytes) -->
192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02
[^ time window rec -> [ session detail rec ^ -->
208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84
224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E
[ message checksum record ^ -->
240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00
256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01
[^ third message header (length 1296 bytes) -->
272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03
[^ set hdr ][^ first data rec -->
288: 80 02 00 50 06 00 00 46 50 00 00 00 41
It should say:
Bringing together the examples above and adding message headers as
appropriate, a hex dump of the first 285 bytes of the example File
constructed above would appear as in the annotated Figure 10 below.
...
144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00
160:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01
[^ second message header (length 80 bytes) -->
176:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02
[^ time window rec -> [ session detail rec ^ -->
192: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84
208: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E
[ message checksum record ^ -->
224: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00
240:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01
[^ third message header (length 1296 bytes) -->
256:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03
[^ set hdr ][^ first data rec -->
272: 80 02 00 50 06 00 00 46 50 00 00 00 41
Notes:
Should be pretty obvious as total size of the hex dump is only 285 bytes.
Please note that the whole Figure 10 is supposed to contain 317 bytes!
Errata ID: 1984
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu
Section 5.8, pg.13 says:
Certain use cases for archival flow storage require the storage of collection infrastructure details alongside the data itself. These details include information about how and when data was received, and where it was received from. They are useful for auditing as well as | for the replaying received data for testing purposes.
It should say:
Certain use cases for archival flow storage require the storage of collection infrastructure details alongside the data itself. These details include information about how and when data was received, and where it was received from. They are useful for auditing as well as | for replaying received data for testing purposes.
Notes:
Alternative for last line:
| for the replay of received data for testing purposes.
Additional editorial remark (keep for update!):
In Section 1.1, there's an unexpected blank line inserted into
the first paragraph on page 5.
Errata ID: 1985
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu
Section 7.1, pg.16 says:
... third bullet, at the bottom of page 16:
o resolve any conflict between a resent definition and a previous
definition by assuming that the new Template replaces the old, as
| consistent with Template expiration and ID reuse when using UDP at
the IPFIX transport protocol; and
It should say:
o resolve any conflict between a resent definition and a previous
definition by assuming that the new Template replaces the old, as
| consistent with Template expiration and ID reuse when using UDP as
the IPFIX transport protocol; and
Notes:
Rationale: typo; s/at/as/ .
Errata ID: 1986
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu
Section 8.1.4, pg.26 says:
... first paragraph:
[...]. This Options Template
| also allows the storage of the export session metadata provided the
Export Session Details Options Template, for storing information from
multiple Transport Sessions in the same IPFIX File.
It should say:
[...]. This Options Template
| also allows the storage of the export session metadata provided by
the Export Session Details Options Template, for storing information
from multiple Transport Sessions in the same IPFIX File.
Notes:
Rationale: missing word, "by".
Errata ID: 1987
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu
Section 9, 1st para says:
In order to ensure the integrity of IPFIX Files and the identity of IPFIX File Writers, File Writers and File Readers SHOULD provide for an interoperable and easily implemented method for signing IPFIX | Files, and verifying those signatures. This section specifies method | via CMS detached signatures.
It should say:
In order to ensure the integrity of IPFIX Files and the identity of IPFIX File Writers, File Writers and File Readers SHOULD provide for an interoperable and easily implemented method for signing IPFIX | Files, and verifying those signatures. This section specifies one | such method via CMS detached signatures.
Notes:
Rationale: missing word(s); suggest inserting "one such".
Errata ID: 1990
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu
Section 12, pg.42 says:
[...]. However, aside
from merely applying CMS for signatures, there are several security
| issues which much be considered in certain circumstances; these are
covered in the subsections below.
It should say:
[...]. However, aside
from merely applying CMS for signatures, there are several security
| issues that must be considered in certain circumstances; these are
covered in the subsections below.
Notes:
Rationale: broken grammar; s/which much/that must/ .
Errata ID: 1991
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Dan Romascanu
Section 12.2, pg.43 says:
... first paragraph:
[...]. The channel
| between the Exporting Process to Collecting Process using IPFIX is
signed by the Exporting Process key and protected via TLS and DTLS,
while the File is signed by the File Writer key and protected via
CMS. [...]
It should say:
[...]. The channel
| from the Exporting Process to the Collecting Process using IPFIX is
signed by the Exporting Process key and protected via TLS and DTLS,
while the File is signed by the File Writer key and protected via
CMS. [...]
Notes:
Rationale:
"channel between xxx to yyy" does not make sense. Either
"channel _from_ xxx to yyy" or "channel between xxx _and_ yyy"
should be written.
The Corrected Text above suggests the first alternative (based
on the essential unidirectionality of the information flow) and
balances the use of articles.
Errata ID: 1992
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Held for Document Update by: Ron Bonica
Throughout the document, when it says:
Section 15.1 contains the outdated Normative Reference: | [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", | RFC 3852, July 2004. "[RFC3852]" is used in Sections 5.6, 9.1, 9.1.1, and 12.
It should say:
At the time of publication of RFC 5655, the replacement RFC already had been published six weeks ago and should have been referred to, due to the essential corrections it incorporates: | [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", | RFC 5652, September 2009.
Errata ID: 2881
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2011-08-01
Held for Document Update by: Dan Romascanu
Section B.2 says:
6. Copy each FlowSet from the Netflow V9 packet to the IPFIX Message
after the header. Replace Set ID 0 with Set ID 2 for Template
Sets, and Set ID 1 with Set ID 3 for Options Template Sets.
It should say:
6. Copy each FlowSet from the NetFlow V9 packet to the IPFIX Message
after the header. Replace Set ID 0 with Set ID 2 for Template
Sets, and Set ID 1 with Set ID 3 for Options Template Sets.
Notes:
s/Netflow/NetFlow/
Per RFC 3954 and searches of cisco.com and google, the correct term is "NetFlow".
Errata ID: 3687
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2013-07-26
Held for Document Update by: Benoit Claise
Date Held: 2013-07-26
Section 8.1.4 says:
| messageScope [scope] | A marker denoting this Option | | | applies to the whole IPFIX message; | | | content is ignored.
It should say:
| messageScope [scope] | A marker denoting this Option | | | applies to the whole IPFIX Message; | | | content is ignored.
Notes:
s/IPFIX message/IPFIX Message/
- because that's the technical term defined in RFC5101 to which this draft refers
Errata ID: 3688
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2013-07-26
Held for Document Update by: Benoit Claise
Date Held: 2013-07-26
Section B.1.1 says:
Export Time: Aside from being called UNIX Secs in the NetFlow V9
packet header specification, the export time in seconds since 1
January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX
message headers.
It should say:
Export Time: Aside from being called UNIX Secs in the NetFlow V9
packet header specification, the export time in seconds since 1
January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX
Message headers.
Notes:
s/IPFIX message/IPFIX Message/
- because that's the technical term defined in RFC5101 to which this draft refers
Status: Rejected (2)
RFC 5655, "Specification of the IP Flow Information Export (IPFIX) File Format", October 2009
Source of RFC: ipfix (ops)
Errata ID: 1989
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-12-28
Rejected by: Dan Romascanu
Date Rejected: 2010-05-11
Section 10, pg. 39 says:
[...] | IPFIX Templates tend to increase the information content per record by not requiring the export of irrelevant or non-present fields in records, and the technique described in [RFC5473] also reduces the export of redundant information. [...]
It should say:
[...] | IPFIX Templates tend to decrease the information content per record by not requiring the export of irrelevant or non-present fields in records, and the technique described in [RFC5473] also reduces the export of redundant information. [...]
Notes:
Rationale: arguably s/increase/decrease/ .
--VERIFIER NOTES--
The text seems to be correct. Usage of templates increases efficiency by increasing the amount of information carried by a record.
Errata ID: 4308
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Aitken
Date Reported: 2015-03-19
Rejected by: Benoit Claise
Date Rejected: 2015-04-21
Section A.5 says:
A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 317 bytes of the example File constructed above would appear as in the annotated Figure 10 below.
It should say:
A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 285 bytes of the example File constructed above would appear as in the annotated Figure 10 below.
Notes:
s/317/285/
Figure 10 shows 18 lines of 16 octets each, less three octets in the final row.
(18 x 16 - 3) = 285 octets.
This can also be confirmed by the revised numbering in errata 2030 - though note that the dump is numbered from octet zero:
272: 80 02 00 50 06 00 00 46 50 00 00 00 41
Since the offset of the final octet ("41") is 284, the overall length must be 285.
--VERIFIER NOTES--
The errata 2030 has been updated to reflect this, as proposed by Paul Aitken.