Subject: [IPFIX] [Fwd: I-D ACTION:draft-boschi-ipfix-exporting-type-00.txt]

From: "Boschi, Elisa" <[email-masked]>
Date: Wed, 29 Aug 2007 10:07:27 +0100

All,

A new version of the "extended type" draft has been published. We changed the draft title to "Exporting Type Information for IPFIX Information Elements" in order to reduce confusion on the draft's content. 

This is a more clearly and completely expressed instance of the original idea: encoding an IPFIX Information Model or part thereof in an IPFIX Message. The main application of this is improved interoperability of enterprise specific IEs.

Comments are welcome,
Elisa

-------- Original Message --------
Subject: I-D ACTION:draft-boschi-ipfix-exporting-type-00.txt
Date: Tue, 28 Aug 2007 15:15:01 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Exporting Type Information for IPFIX Information Elements
	Author(s)	: E. Boschi, et al.
	Filename	: draft-boschi-ipfix-exporting-type-00.txt
	Pages		: 17
	Date		: 2007-8-28
	
   This document describes an extension to IPFIX to allow the encoding
   of IPFIX Information Model properties within an IPFIX Message stream,
   to allow the export of extended type information for enterprise-
   specific Information Elements.  This format is designed to facilitate
   interoperability and reusability among a wide variety of applications
   and tools.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boschi-ipfix-exporting-type-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-boschi-ipfix-exporting-type-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-boschi-ipfix-exporting-type-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

************************************************************************************************** 
E-mail Confidentiality Notice and Disclaimer. 

This e-mail and any files transmitted with it are confidential and are intended solely for the use 
of the individual or entity to which they are addressed. Access to this e-mail by anyone else is 
unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited. E-mail messages are not 
necessarily secure. Hitachi does not accept responsibility for any changes made to this message 
after it was sent. 
Hitachi checks outgoing e-mail messages for the presence of computer viruses. 
**************************************************************************************************
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Thu, 30 Aug 2007 11:37:22 -0400

Paul,

Thanks for the comments... I have a couple of points on the specifics  
of the Exporting Type information elements, inline below...

Cheers,

Brian

On Aug 29, 2007, at 10:42 AM, Paul Aitken wrote:

> 3.4.  informationElementRangeBegin
> 3.5.  informationElementRangeEnd
>
> - Rather than unsigned64, the type of these IEs should be identical  
> to the type of IE they're representing. ie, if I have a timestamp,  
> these may be of type dateTimeSeconds, while I have a float, they  
> may be of type float32.
>

hmmm... In the general case, this means we'd need two IEs for each  
defined type, which seems excessive. However, I do believe you're  
right, we need a way to express negative range ends. We may also need  
a way to express range ends on floating point numbers not expressible  
in an integer type (float32 or float64 with a magnitude > 2^63-1).  
I'm less convinced of the need to express absolute timestamps as  
ranges (what would this mean? a timestamp that's only good until a  
week from next Wednesday?) but this is mainly because I can't think  
of an example. Also, if we're worried about floating point range  
ends, would we also need nanosecond timestamp ends? What about  
address ranges? String ranges? Do we need a locale to define sort  
order of strings if we have string ranges? This gets messy quickly.

Doing the least restrictive possible thing here is probably  
prohibitively complex, with limited real applicability. I see a few  
possibilities here...

1. Redefine the range begin and range end as signed64. This makes it  
possible to express negative range beginnings or ends, but does not  
allow range ends outside -2^63 - 2^63-1, or non-integer range ends.  
It retains the ability to define range ends using reduced length  
encoding. I think I prefer this solution.

2. Redefine the range begin and range end as float64. This makes it  
possible to express any numeric range end, with a possible loss of  
precision for some values. It does not allow reduced-length encoding,  
because reduced-length encoding is not possible with IEEE floats.

3. Define signed64 _and_ float64 range begin and range end. Use  
signed64 for integer types with reduced-length encoding as  
appropriate, and float64 for floating point types.

For the record, the following are the presently defined ranges in the  
information model:

sourceIPv4PrefixLength 0-32
sourceIPv6PrefixLength 0-128
destinationIPv4PrefixLength 0-32
destinationIPv6PrefixLength 0-128
ipDiffServCodePoint 0-64
ipPrecedence 0-7

The lack of any negative (or even non-zero) range beginnings here is  
why we didn't consider signed ranges to be important, initially.  
Indeed, if the aim of this document is to express information from  
the information model inline (which it is), and the definition of  
"range" is implicitly taken from the information model (which it is),  
then we could even assume that all range beginnings are zero, and  
have only an unsigned64 informationElementRangeEnd IE. I do think  
that the flexibility of two signed64 range IEs is worth it (as above).

>
> 3.8.  privateEnterpriseNumber
>
>       If the Enterprise ID bit of the
>       corresponding Information Element is cleared (has the value 0),
>       this IE should be set to 0.
>
> No; it shouldn't exist since an IE that's set to zero isn't the  
> same as an IE that's not there - unless the IE is specifically  
> defined to use zero as an out-of-band not-applicable or unknown  
> indication.

Actually, I think the right thing to do here is to define the type  
options template to not include the privateEnterpriseNumber if the  
Enterprise ID bit is not set.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 30 Aug 2007 11:37:22 -0400

Paul,

Cheers,

Brian