I am the assigned Gen-ART reviewer for draft-ietf-ipfix-as-08.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please resolve these comments along with any other Last Call comments
you may receive.
---------------------------------------------------------------------
This document is almost ready for publishing as an Informational
RFC.
Below, I have listed several minor (mostly editorial) comments,
and about the same number of NITs, that I would like to see
addressed.
Comments/Observations/Questions:
===============================
In section 2.3 ("Traffic Engineering"), I am not sure that methods
you suggest will let an application determine "link utilization"
except for physical links associated with physical interfaces.
If you agree that this is a limitation, is it worth stating this
in this section?
---------------------------------------------------------------------
In section 2.4, 4th paragraph (2nd paragraph on page 9), a sudden
increase of flows from different sources to a specific destination
may also be an indication of a DDoS attack, or some specific event.
It might be worth mentioning at least the DDoS attack possibility.
You do - in the next paragraph - mention the "event" possibility.
Also, in this same paragraph, references to TCP-FIN/TCP-SYN and
Worm "signatures" are orders of magnitude more difficult to
recognize than simple changes in flow volumes. Perhaps these
should be discussed in more detail, or at least made into a
separate paragraph?
---------------------------------------------------------------------
In the second paragraph on page 10, what does the first sentence
mean? It says:
"Detecting security incidents in real-time often requires the
pre-processing of data already at the measurement device."
---------------------------------------------------------------------
In the last sentence (bullet under "Remarks") before section 2.5.2.2
- the characteristic (or property) "granularity" is not modifiable by
adjectives such as "higher" or "lower". If you want to say "finer
granularity" or "coarser granularity", then please say it that way.
The same comment applies to the 1st bullet on page 13.
A similar observation may apply to the use of "higher" as a modifier
to "threats" in the first paragraph of section 2.6 ("higher risks"
or "higher threat-levels" makes more sense - in this context - than
"higher threats").
---------------------------------------------------------------------
In section 2.5.2.2, you should mention (or refer to a document that
identifies concerns, or methods of addressing) the need to eliminate
or compensate for measured-time differences at multiple locations in
computing one-way delay.
Packet transport times are usually on a time-scale at which likely
differences in local times can be quite significant (especially if
you are expecting to obtain delay values accurate in nanoseconds).
---------------------------------------------------------------------
There are PSAMP reference in section 3.1, RMON references in section
3.2, AAA references in section 3.4 and RTFM in section 3.5 - but no
references for IPPM in section 3.3.
Can we add one or more references in this section, or are they all
implied by references in sections 2.5 and 2.7?
---------------------------------------------------------------------
Who is "They" in the second paragraph on page 17 (toward the middle
of the paragraph)? Is it the AAA functions, or the combination of
IPFIX collection and AAA functions?
---------------------------------------------------------------------
Are there really no plans, or work in progress, to define remote
configuration for IPFIX?
This is particularly irksome in light of the last paragraph in
section 4.3 -
"Whether [arrival of more records than the receiving application
can process] is a relevant drawback depends on the flexibility
of the IPFIX configuration and how IPFIX configuration rules are
implemented."
But this is just one issue with not defining (or at least planning
to define) a remote configuration standard for IPFIX. Another is
that - if it is necessary (or even just useful), and not defined as
a standard - then it will very likely have to be defined as vendor
proprietary several times.
---------------------------------------------------------------------
Section 5 ("Security Considerations") provides a severe example of
a minor misuse of the terms "framework" and "architecture" - it is
difficult to use IPFIX in combination with "other frameworks" as it
is not clear what it means to "use a framework."
I suggest replacing "framework" - at least - and maybe "architecture"
with "technology" (or "technologies") where it seems appropriate.
In this section, for example, the first sentence in the second
paragraph makes more sense as:
"Section 3 of this document describes how IPFIX can be used in
combination with other technologies."
Using IPFIX with another framework is somewhat between this and
using IPFIX in a different frame of reference - which is one of
the things covered in section 4.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
NITs:
====
** Second sentence in the introduction:
"It is intended to provide this information as input to various
applications."
Because the intent of this document is to define when/where IPFIX
might be useful, I would suggest rewording this sentence as:
"IP Flow information can be used as input to various applications."
--------------------------------------------------------------------
** Fourth sentence in the introduction:
"This document describes how typical applications that can use the
IPFIX protocol."
I assume you're trying to say this:
"This document describes how typical applications can use the IPFIX
protocol."
(That is what you say in a subsequent paragraph)
--------------------------------------------------------------------
** In section 2.1, after the second sentence:
I believe you meant the next sentence to start a new paragraph. This
seems to happen in several sections (sections 2.3, 2.5.1 and 3.2 are
other examples, where a 2nd paragraph is "bunched up" with the 1st -
although, in section 3.2, all of the paragraphs are "bunched up" and
this appears to be the case in section 3.5.1 as well).
In general, there are too many cases of paragraph "bunching" to list
them all in this review.
---------------------------------------------------------------------
** In section 2.1.1:
RFC 3330 is Informational; as such it does not "demand" or "require"
anything. The "Please note" at the beginning of section 2.1.1 should
be reworded similar to as follows:
"As noted in [RFC3330], the address block 192.0.2.0/24 may be used
for example addresses."
--------------------------------------------------------------------
** Bottom of page 5, top of page 6:
It is usually a good idea (for readability) to keep blocks like
this (template set) together.
--------------------------------------------------------------------
** Section 2.3, 2nd (or 3rd?) paragraph:
The parenthesized phrase "as usually the case" should be either
simply "usually the case" or "as is usually the case".
---------------------------------------------------------------------
** Next to last paragraph on page 9:
"IPIFX" should be "IPFIX".
(Same applies to the 2nd paragraph on page 10, the last one on page
11, and the 1st and 3rd paragraphs on page 15.)
---------------------------------------------------------------------
** Section 4.3, 3rd paragraph, 1st sentence:
The phrase "as certain thresholds are about to exceed" should be
something like "as certain thresholds are about to be exceeded."
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
