Architecture for IP Flow Information Export
draft-ietf-ipfix-architecture-12

[Ballot discuss]
Section 10.1.2 should encourage the use of ESP with a null encryption
  algorithm to provide authentication-only security services.  I suggest
  adding the following before the bullet for AH:
 
    o  Encapsulating Security Payload (with a null encryption algorithm)

  TLS also offers some ciphersuites with null encryption algorithms.
  If the use of TLS in this manner is also useful, then also add:

    o  Transport Layer Security (with a null encryption algorithm)

[Ballot discuss]
I am holding a DISCUSS for draft-ietf-ipfix-architecture in order to make sure that its content is synchronized with the content of draft-ietf-ipfix-proto. The editors and WG chairs agreed to produce new versions of the two documents, which are closely related, although not part of the same ballot package.

I recommend at the same occasion that the editors consider all COMMENTs made during the ballot process and produce text fixes accordingly.

[Ballot discuss]
I am holding a DISCUSS for draft-ietf-ipfix-architecture in order to make sure that its content is synchronized with the content of draft-ietf-ipfix-proto. The editors and WG chairs agreed to produce new versions of the two documents, which are closely related, although not part of the same ballot package.

I recommend at the same occasion that the editors consider all COMMENTs made during the ballot process and produce text fixes accordingly.

[Ballot comment]
Reference 5 is obsolete. RFC 1889 was replaced with RFC 3550 which is STD 64.

Section 5.2.3:

  Example: Mask/Match of the fields that define a filter.  A filter
  might be defined as {Protocol == TCP, Destination Port between 80 and
  120}.

Shouldn't it be "or" between 80 and 120? Otherwise it implies that there are two destination ports in the packet that is being matched.

Section 8.1:

The WG could have considered using DCCP for the transport if one is interested in unreliable transport while still have it congestion controlled and connection oriented transport which seems to suite the application pretty well.

[Ballot comment]
Section 2., paragraph 6:

>      An Observation Domain is the largest set of Observation Points for
>      which Flow information can be aggregated by a Metering Process.
>      For example, a router line card may be an observation domain if it
>      is composed of several interfaces, each of which is an Observation
>      Point.  Each Observation Domain presents itself to the Collecting
>      Process using an Observation Domain ID to identify the IPFIX
>      Messages it generates.  Every Observation Point is associated with
>      an Observation Domain.  It is RECOMMENDED that Observation Domain
>      IDs are also unique per IPFIX Device.

  s/RECOMMENDED/recommended/ or need to include RFC2119 boilerplate and
  cite it


Section 8.2., paragraph 2:

>    Once connected, an IPFIX Collector receives Control Information and
>    uses that information to interpret Flow Records.  The IPFIX Device
>    should set a keepalive (e.g. the keepalive timeout in the case of
>    TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently
>    low value so that it can quickly detect a Collector failure.

  It may be worth pointing out that extremely short keepalive intervals
  can incorrectly abort the connection during transient periods of
  congestion. They can also cause some level of additional network load
  during otherwise idle periods.


Section 11.1., paragraph 0:

11.1.  Numbers used in the Protocol

  I think this section should be removed, because IPFIX-PROTO [3]
  already defines the IANA considerations for these fields.


Section 11.2., paragraph 0:

11.2.  Numbers used in the Information Model

  Ditto, because IPFIX-INFO [2] defines IANA considerations for those.

IANA Last Call Comments:

In section 11.1, the registration procedures describing the Version numbers and Set IDS is
not identical to how they are described in draft-ietf-ipfix-protocol-21.txt. A correction
is needed to one of the documents so that the language matches. Should the instructions
even be there at all as they are already described in the registry creating document?

Does this document create the new registry for field types?
If so, should the field type registry be placed with the version numbers and set id
registries?

We understand the registration procedures for field types to be the following:
Expert review as described in section 11.2. There should be at least 1 appointed expert to
communicate expert decisions to the IANA as it appears there will be a group of experts.

Expert designation by the IESG will be needed.

AD review posted to WG list:

----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Wijnen, Bert (Bert)
Sent: Monday, March 13, 2006 12:20
To: 'Ipfix Wg' (E-mail) (E-mail)
Cc: Dan Romascanu (E-mail); David Kessens (E-mail)
Subject: [ipfix] AD review for: draft-ietf-ipfix-architecture-09.txt


Appologies that it took so long.

As far as I am concerned, you could ask for IETF last Call
now and consider the below as initial IETF Last Call comments.
At the other hand, if you can quickly spin a new rev (during
IETF week?), then it might be better to try and address the
below first, before asking your AD to request IETF LC.

- sect 2, under bullet observation domain
  it speaks a bout a "unique ID".
  Is that administratively unique?
  or globally unique?

- sect 5.4 last line
  s/Source ID/Domain ID/ ??
  Or should the section title be somthing about "Soutrce" ??
  I am getting a bit confused about DOmain and Source ID I guess?
  Protocol doc does indeed speak about SOurce ID.

- sect 6.4 2nd para.
  How can a IPfix device count the p[ackets losts in all
  the possible problem scenarios?
  Maybe the solution is to say that it should try to count
  them and if it can, then it should report. Of it cannot count
  them, then maybe give a indication of the time period that
  packets could not be handled/seen?

- sect 8.1 last para
  I think it would be good to add a few more words on how operators
  can avoid congestion. Just keeping it in their own domain helps
  to not impact other networks, but if it is a live network with
  normal user data, then it is still problemantic. Maybe you mean that
  they should use a dedicated network for it?
  Anyway, best to elaborate somewhat I think.

- I suspect that the Security Considerations section will be considered
  weak by the security ADs. You may want to check with them for early
  review/comment. Early meaning right before or in parallel with IETF LC.
  For example, I am not sure that just MD5 is sufficient anymore.

- It seems to me that sect 11 is also Security COnsideratons, no?
  So should they be subsections of Sect 10?

- Sect 12.1
  I think you rather want Standards Action for approval of a new IPfix
  version or template, no?

- page 30: INtellectual Property
  the last para can be removed. We normally do not add such a statement
  because such claims can be filed any time, even after RFC publication.

 
admin/nites/spelling

- refernces/citation issues:
  !! Missing Reference for citation: [IPFIX-INFO]
  P008 L037:      The IPFIX information model [IPFIX-INFO] defines the base set of

- In the abstract you should not use a citation

- sect 1.2 last para
  I would assume that config is done by network ops staff,
  regardless if it can be done remote or local or whatever
  the tools are.

- sect 2, middle of page 5
  s/vvery/very/

- page 6, 1st line: s/field/fields/
  3rd line add closing parethesis
  one but last line: remove 1 open parenthesis

- page 8: s/sender Exporter/sending Exporter/ ??

- page 9
  In exmaples you should use IP addresses 192.0.2.x/24
  as per RFC3330

- last sentence on page 10.
  I do not see the difference between "<-->" and "<-->"
  I know my eyes are getting worse, but this time I suspect
  it is not caused by my eyes ;-)

- sect 5.1.2 last sentence
  s/Metering Process/Exporting Process/ ??

- sect 5.3.1. 2nd line
  s/is/are/

- sect 5.5
  Pls use RFC3330 IP addresses in example IP addresses

- Sect 6.3 speaks about "ID". Is that the "Domain ID" ??

- sect 10: s/IPSEC/IPsec/

Bert

--