Subject: RE: [ipfix-data] Re: Information Model

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 6 Feb 2002 09:52:42 -0800

Hello Paul,

:-----Original Message-----
:From: [email-masked] [mailto:[email-masked]]
:Sent: Wednesday, February 06, 2002 8:11 AM
:To: Simon Leinen
:Cc: [email-masked]; data
:Subject: [ipfix-data] Re: Information Model
:
:
:
:Here is a first cut at the list of data elements to be reported.
:I of course hacked it out of the LFAP spec. 
:
:I think we need to begin with a couple of guidlines (which
:we should augment as we go). They are just guidelines.
:
:        1. Data element values should be defined in terms of
:           other specifications. Since we are only reporting
:           things in other protocols, there should be little
:           reason for us to define anything from scatch.

I agree with this.

:
:        2. Each element should be able to be interpreted on
:           it own. In other words, don't make me look though    
:           the rest of the message to figure out what this
:           value means. The drawback is this can lead to
:           data element explosion. We'll have to balance
:           the tradeoffs.

Sounds fair.

:
:        3. Others?....

Define a minimum set (common denominator) of elements, extensions should be
specificed on their own drafts and use capability negotiation to figure out
if the peers understand them or not.

I'm providing for the hability to negotiate extended flow type support in
the capability negotiation section. 

regards,

Reinaldo

---

From: [email-masked]
Date: Wed, 06 Feb 2002 13:49:06 -0500

Reinaldo Penno wrote:
> Define a minimum set (common denominator) of elements, extensions
> should be specificed on their own drafts and use capability
> negotiation to figure out if the peers understand them or not.
> 
> I'm providing for the hability to negotiate extended flow type support
> in the capability negotiation section.

	I agree but we need to list all the data elements we can.
	If we do not, the someone building a IPFIX server will
	need to go to each vendor to figure out what data they
	have an what it means.

	You can negotiate about what data elements you support
	as an exporter but the semantics of that data should
	already be defined.

--
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/