Subject: Re: [IPFIX] new work item candidate #4: extended types

From: "Boschi, Elisa" <[email-masked]>
Date: Thu, 26 Jul 2007 22:51:21 +0100

Gerhard,

> 
> On the one hand, it's a nice idea to have some IEs which allow
> describing the type and semantic of other IEs. On the other hand, my
> impression is that the usefulness is very restricted and not as broad as
> claimed in the introduction of the draft:
> 
>    ... Having to do some sort of tool-specific
>    configuration (or code modification) on every tool just to tell which
>    type each used Information Element has is a huge amount of work for
>    users and implementors of enterprise-specific Information Elements.
>    Many tools in fact only need to know the field's data type to work on
>    them. ...
>

One of the use cases we have in mind here would be a collaborative measurement infrastructure where each exporter is implemented by a different vendor and exports slightly different enterprise IEs. In that case, having type information in the message stream allows ad-hoc preliminary analysis of the enterprise specific data. 

Our claim that many tools only need to know the field's data types to work on them applies...so the usefulness of the draft is not too "restricted" 
 
> In my opinion, any deeper analysis and processing of metering data
> requires knowledge about the semantic. Just knowing the data type may be
> enough to display values correctly. Considering
> informationElementSemanticType, you might also know if the calculation
> of statistical properties (max, min, mean, variance etc.) makes sense or
> not. But any further analysis would probably require more semantical
> knowledge. That's why I assume that, in practice, analyzing and
> processing enterprise-specific data will mostly be performed with
> specialized analysis tools that have been implemented for this specific
> purpose. And for these tools, there is no need to export the IE information.
> 

...but those ad hoc tools won't be reusable, unless tool specific configuration or code modification are done for any used Enterprise Specific IE. And what about if the tools are not updated? 

A real life example that this draft would solve is mentioned in:
http://www1.ietf.org/mail-archive/web/ipfix/current/msg03040.html

...which also contains the motivation for this draft.

Regards,
Elisa

> 
> Juergen Quittek wrote:
>> Dear all,
>>
>> Candidates #4 to become a new IPFIX work item is described by
>> draft draft-boschi-ipfix-extended-type-00.txt.
>>
>>> 4. Extended Types (Elisa Boschi)
>>>    Needed for IPFIX files, most useful for Enterprise IEs; need to
>>>    specify what operations make sense for an IE.
>>>    Support shown for this as a WG item, as for File Format.
>>>    Milestones:  WG LC after IETF 70, to IESG before IETF  71.
>> It is a method for assigning data types to unknown IPFIX information
>> elements by using option records that map data types to element identifiers.
>>
>> It can be applied in cases where an IPFIX collector does not know the
>> data type of received information elements. This may in particular happen
>> if enterprise specific elements are used. Without this information the
>> collector would treat these elements as if they were of type octet array.
>> With this information it may be able to treat them more appropriately.
>>
>> The current version of the IPFIX file format draft recommends using this
>> method when IPFIX records are stored.
>>
>> Do you think this is a useful extension of the IPFIX protocol?
>> Do you think we should accept this as an IPFIX work item?
>> Please have a look at the draft and send your comments.
>>
>> Thanks,
>>
>>     Juergen
>>
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipfix
> 

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

This email 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. 

Please note that Hitachi checks outgoing e-mail messages for the presence of computer viruses. 
**************************************************************************************************
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix