RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search