Subject: RE: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architect ure-00.txt

From: "Reinaldo Penno"<[email-masked]>
Date: Mon, 11 Feb 2002 17:30:21 -0800

:-----Original Message-----
:From: Sebastian Zander [mailto:[email-masked]]
:Sent: Monday, February 11, 2002 4:41 AM
:To: [email-masked]
:Subject: [ipfix-arch] Comments/questions on
:draft-ietf-ipfix-architecture-00.txt
:
:
:The draft is in a very early state but nevertheless i have 
:some comments/questions:
:
:section 2: 
:
:"* Describes the required mechanisms  to interoperate with 
:other protocol/architecture 
:this may includes AAA or Diameter or Intrusion Detection system.
:* Identifies a minimal set of applications for IPFIX."
:
:I don't understand why this is part of the architecture 
:document. It's fine to list
:a set of applications but describing these and the interaction 
:with IPFIX is IMHO
:out of scope of the draft.
:
:
:"* May perform appropriate middle-box functions to translate 
:the flow information." 
:
:I would suggest deleting or rewording this to something like: 
:May add middle-box 
:information to flow record but the exporter certainly does not 
:perform middlebox 
:functions.

okay, agrred. The exporter itself as a self-contained entity does not
perform middlebox functions, but middlebox functions change how the exporter
see the flows. 
:
:Am I right that the exporter does the packet to flow 
:classification and statistics 
:calculation?
:
:section 4.3: The text totally confuses me. Why is reliability 
:and security now a function
:of the IPFIX protocol? The reqirements are already in the 
:requirement draft and the protocol 
:spec. will be in some future protocol draft I guess. Probably 
:a wording issue which
:can be solved by omitting the word protocol.
:
:section 4.4:
:
:Why does the collector need to maintain a repository of IP 
:flow statistics? Can't the
:application do that?
:
:section 5:
:
:Out of scope of this draft IMHO. There should be either an 
:application draft or maybe
:different application drafts.
:
:
:It is possible that several protocols (e.g. LFAP, CRANE, 
:Netflow, Diameter) meet the 
:IPFIX requirements.  In this case, this capability is used to 
:negotiate which protocol 
:the end points will use. 
:
:Does this sections tells me that there is no single IPFIX 
:protocol but instead there
:are a couple of protcols? So in the end we have a couple of 
:protocols and each vendor
:implements a different. ;-) I think there should be a 
:standardized protocol.
:
We might omit this part from the capability negotiation since this would be
another parameter. It would be up to vendor to include in the capability
negotiation its protocol as a vendor-extension. So, I'll reword this section

:section 6.6.2.6:
:
:What is the exact definition of overlapping flows?
:

I'll add that. It's when a flow is reported twice without the exporter or
collector knowing about it.

thanks,

Reinaldo