Brian Trammell | 6 Jan 2010 11:57
Picon
Picon

Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1984)

Agreed, on first correction.

On Dec 28, 2009, at 7:22 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5655,
> "Specification of the IP Flow Information Export (IPFIX) File Format".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=1984
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <ah <at> TR-Sys.de>
> 
> Section: 5.8, pg.13
> 
> Original Text
> -------------
>   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.
> 
> 
> 
> Corrected Text
> --------------
(Continue reading)

Brian Trammell | 6 Jan 2010 11:57
Picon
Picon

Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1985)

Agreed.

On Dec 28, 2009, at 7:25 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5655,
> "Specification of the IP Flow Information Export (IPFIX) File Format".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=1985
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <ah <at> TR-Sys.de>
> 
> Section: 7.1, pg.16
> 
> Original Text
> -------------
> ... 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
> 
> 
> Corrected Text
> --------------
(Continue reading)

Brian Trammell | 6 Jan 2010 11:58
Picon
Picon

Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1986)

Agreed.

On Dec 28, 2009, at 7:28 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5655,
> "Specification of the IP Flow Information Export (IPFIX) File Format".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=1986
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <ah <at> TR-Sys.de>
> 
> Section: 8.1.4, pg.26
> 
> Original Text
> -------------
> ... 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.
> 
> 
> Corrected Text
> --------------
(Continue reading)

Brian Trammell | 6 Jan 2010 11:58
Picon
Picon

Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1989)

No. Information content here refers to the amount of the record devoted to information, as opposed to
record structure. If there is a general agreement that the wording here is confusing (on rereading, it
isn't IMO) and tends to lead to misunderstanding, then I would suggest fixing by a complete reformulation
of the sentence in question.

On Dec 28, 2009, at 7:42 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5655,
> "Specification of the IP Flow Information Export (IPFIX) File Format".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=1989
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <ah <at> TR-Sys.de>
> 
> Section: 10, pg. 39
> 
> Original Text
> -------------
>   [...]
> |  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.  [...]
> 
> Corrected Text
(Continue reading)

Brian Trammell | 6 Jan 2010 11:58
Picon
Picon

Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1987)

Agreed.

On Dec 28, 2009, at 7:31 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5655,
> "Specification of the IP Flow Information Export (IPFIX) File Format".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=1987
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <ah <at> TR-Sys.de>
> 
> Section: 9, 1st para
> 
> Original Text
> -------------
>   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.
> 
> 
> Corrected Text
> --------------
>   In order to ensure the integrity of IPFIX Files and the identity of
(Continue reading)

Gerhard Muenz | 6 Jan 2010 13:11
Picon
Favicon

[IPFIX] [Fwd: Re: WGLC comments on draft-ietf-ipfix-configuration-model-04]


Obviously, this mail did not make it to the ML.


-------- Original Message --------
Subject: Re: [IPFIX] WGLC comments on 
draft-ietf-ipfix-configuration-model-04
Date: Mon, 04 Jan 2010 12:59:13 +0100
From: Gerhard Muenz <muenz <at> net.in.tum.de>
To: Atsushi Kobayashi <akoba <at> nttv6.net>
CC: ipfix <at> ietf.org
References: <20091210164010.8C60.17391CF2 <at> nttv6.net>


Hi Atsushi,

Thank you very much for you comments.

Please find my answers inline.

Regards,
Gerhard


Atsushi Kobayashi wrote:
> Dear Gerhard, Benoit, and Paul,
> 
> I would like to show the respect for your great effort for writing this
> document. This document contains all of parameters and statistics with
> regard to IPFIX and PSAMP specification. Thus, it needs hard review even
(Continue reading)

Brian Trammell | 6 Jan 2010 13:24
Picon
Picon

Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1991)

Agreed, on first alternative.

On Dec 28, 2009, at 7:52 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5655,
> "Specification of the IP Flow Information Export (IPFIX) File Format".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=1991
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <ah <at> TR-Sys.de>
> 
> Section: 12.2, pg.43
> 
> Original Text
> -------------
> ...  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.  [...]
> 
> Corrected Text
> --------------
(Continue reading)

Brian Trammell | 6 Jan 2010 13:25
Picon
Picon

Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1992)

Agreed; however, I would note that as 5652 obsoletes 3852, the risk of misreading is minimal.

On Dec 28, 2009, at 8:01 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5655,
> "Specification of the IP Flow Information Export (IPFIX) File Format".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=1992
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <ah <at> TR-Sys.de>
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> 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.
> 
> Corrected Text
> --------------
> At the time of publication of RFC 5655, the replacement RFC already
(Continue reading)

Brian Trammell | 6 Jan 2010 13:25
Picon
Picon

Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1990)

Completely agreed on the typographical error here (s/much/must/). I suppose the which/that change is
acceptable as well.

On Dec 28, 2009, at 7:45 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5655,
> "Specification of the IP Flow Information Export (IPFIX) File Format".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=1990
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <ah <at> TR-Sys.de>
> 
> Section: 12, pg.42
> 
> Original Text
> -------------
>                                                 [...].  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.
> 
> 
> Corrected Text
> --------------
>                                                 [...].  However, aside
(Continue reading)

Brian Trammell | 6 Jan 2010 13:29
Picon
Picon

Re: [IPFIX] [Technical Errata Reported] RFC5655 (1988)

Agreed; this was a copy/paste typo. SEQUENCE would increase clarity, as well, I suppose; note that the
summary in 9.1 was taken pretty much directly from RFC5485 section 3, in which SEQUENCE does not appear.

On Dec 28, 2009, at 7:40 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC5655,
> "Specification of the IP Flow Information Export (IPFIX) File Format".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=1988
> 
> --------------------------------------
> Type: Technical
> Reported by: Alfred Hoenes <ah <at> TR-Sys.de>
> 
> Section: 9.1.3, pg.39
> 
> Original Text
> -------------
>   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.
(Continue reading)


Gmane