Subject: [ipfix] AD review for: draft-ietf-ipfix-architecture-09.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 13 Mar 2006 12:20:28 +0100

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

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/