Subject: Re: [IPFIX] missing notes on exporting type...

From: <[email-masked]>
Date: Fri, 28 Mar 2008 19:20:00 +0100

Hi Brian,

The way the draft-ietf-ipfix-exporting-type defines types prevents adding new one in the future without updating the draft. There are already potential candidates: Enumerated, email, DNS, URL .... 

Adding these types to the IPFIX datamodel increases the scope of usage of IPFIX and interoperability. It permits the usage of standard IE for exporting specific information. It permits the collector to store this information in an efficient way. It encourage enterprises to use standard IE instead From [email-masked]  Fri Mar 28 11:21:03 2008
Content-class: urn:content-classes:message
Date: Fri, 28 Mar 2008 19:20:00 +0100
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [IPFIX] missing notes on exporting type...
Sender: [email-masked]

This is a multi-part message in MIME format.
Hi Brian,

The way the draft-ietf-ipfix-exporting-type defines types prevents adding new one in the future without updating the draft. There are already potential candidates: Enumerated, email, DNS, URL .... 

Adding these types to the IPFIX datamodel increases the scope of usage of IPFIX and interoperability. It permits the usage of standard IE for exporting specific information. It permits the collector to store this information in an efficient way. It encourage enterprises to use standard IE instead of enterprises specific ones. 

Therefore the draft has to define them as IEs and the IANA section have to request IANA to add them the IPFIX datamodel registry.

Regards
Emile

> -----Message d'origine-----
> De : Brian Trammell [mailto:[email-masked]]
> Envoyé : vendredi 28 mars 2008 02:11
> À : STEPHAN Emile RD-CORE-LAN
> Objet : missing notes on exporting type...
> 
> Emile,
> 
> As I recall, we had a conversation in Philadelphia about some specific
> aspect of draft-ietf-ipfix-exporting-type, and I had an answer for
> your question, and I was going to post a message to the list about
> that... but, I can't seem to find my note on the subject, and it's
> been a rather eventful couple of weeks, and I have consequently
> _completely_ forgotten it.
> 
> So.
> 
> Would you happen to remember what we were talking about, so we could
> perhaps start over on the subject?
> 
> Thanks,
> 
> Brian
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Fri, 28 Mar 2008 17:56:31 -0400

Emile,

Ah, yes. Thanks. I remember now. My short, short answer on this was  
"no, but..."

Here's why:

The data type and semantics registries are taken directly from RFC  
5102. This document doesn't seek to expand the types or semantics, it  
only seeks to create formal IANA registries for a list of types  
_already_ defined on the standards track. The reason behind creating  
those registries is to map the types themselves to numeric cFrom [email-masked]  Fri Mar 28 14:57:43 2008
From: Brian Trammell <[email-masked]>
To: <[email-masked]>
Date: Fri, 28 Mar 2008 17:56:31 -0400
Cc: [email-masked]
Subject: [IPFIX] expanding type and semantics registries (was Re: missing
	notes on exporting type...)
Sender: [email-masked]

Emile,

Ah, yes. Thanks. I remember now. My short, short answer on this was  
"no, but..."

Here's why:

The data type and semantics registries are taken directly from RFC  
5102. This document doesn't seek to expand the types or semantics, it  
only seeks to create formal IANA registries for a list of types  
_already_ defined on the standards track. The reason behind creating  
those registries is to map the types themselves to numeric codes used  
to represent them in the informationElementDataType and  
informationElementSemantics IEs. The reason behind declaring their  
modification to be subject to a Standards Action as per RFC 2434 is to  
ensure that

Adding a new data type to IPFIX is not simply a matter of sticking a  
new name and number into the data type registry -- specific  
information on the definition (as in section 3.1 of RFC 5102) and  
encoding (as in section 6.1 of RFC 5101) of the data type must be  
provided to allow the Exporting Process to properly encode and the  
Collecting Process to properly decode and recognize data of that type.  
Even if it's just a reference to an external standard (as 5101's  
sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types),  
it's still absolutely necessary to have some document extending the  
set of types for IPFIX to ensure interoperability of those new types.  
And that's out of scope for _this_ document, which, as chartered, only  
provides a _mechanism_ for describing the types already supported.

That said, you have a very good point.

There are quite a few types that could be immediately useful; and yes,  
additional network-identifiers such as URL, email, and FQDN are  
obvious first choices, which can only be implemented as Strings at the  
moment. Enumerations are another issue, and can already be partially  
implemented using the Reducing Redundancy mechanism.

My suggestion, however, would be a new document, to be considered for  
a future WG charter, to _explicitly_ extend the set of types supported  
by IPFIX, and adding those types to the registry created in exporting- 
type.

Cheers,

Brian

On Mar 28, 2008, at 2:20 PM, <[email-masked]> wrote:
> Hi Brian,
>
> The way the draft-ietf-ipfix-exporting-type defines types prevents  
> adding new one in the future without updating the draft. There are  
> already potential candidates: Enumerated, email, DNS, URL ....
>
> Adding these types to the IPFIX datamodel increases the scope of  
> usage of IPFIX and interoperability. It permits the usage of  
> standard IE for exporting specific information. It permits the  
> collector to store this information in an efficient way. It  
> encourage enterprises to use standard IE instead of enterprises  
> specific ones.
>
>
> Therefore the draft has to define them as IEs and the IANA section  
> have to request IANA to add them the IPFIX datamodel registry.
>
>
> Regards
>
> Emile
>
>

odes used  
to represent them in the informationElementDataType and  
informationElementSemantics IEs. The reason behind declaring their  
modification to be subject to a Standards Action as per RFC 2434 is to  
ensure that

Adding a new data type to IPFIX is not simply a matter of sticking a  
new name and number into the data type registry -- specific  
information on the definition (as in section 3.1 of RFC 5102) and  
encoding (as in section 6.1 of RFC 5101) of the data type must be  
provided to allow the Exporting Process to properly encode and the  
Collecting Process to properly decode and recognize data of that type.  
Even if it's just a reference to an external standard (as 5101's  
sections 6.1.3. and 6.1.4. do to IEEE 754 for floating point types),  
it's still absolutely necessary to have some document extending the  
set of types for IPFIX to ensure interoperability of those new types.  
And that's out of scope for _this_ document, which, as chartered, only  
provides a _mechanism_ for describing the types already supported.

That said, you have a very good point.

There are quite a few types that could be immediately useful; and yes,  
additional network-identifiers such as URL, email, and FQDN are  
obvious first choices, which can only be implemented as Strings at the  
moment. Enumerations are another issue, and can already be partially  
implemented using the Reducing Redundancy mechanism.

My suggestion, however, would be a new document, to be considered for  
a future WG charter, to _explicitly_ extend the set of types supported  
by IPFIX, and adding those types to the registry created in exporting- 
type.

Cheers,

Brian

On Mar 28, 2008, at 2:20 PM, <[email-masked]> wrote:
> Hi Brian,
>
> The way the draft-ietf-ipfix-exporting-type defines types prevents  
> adding new one in the future without updating the draft. There are  
> already potential candidates: Enumerated, email, DNS, URL ....
>
> Adding these types to the IPFIX datamodel increases the scope of  
> usage of IPFIX and interoperability. It permits the usage of  
> standard IE for exporting specific information. It permits the  
> collector to store this information in an efficient way. It  
> encourage enterprises to use standard IE instead of enterprises  
> specific ones.
>
>
> Therefore the draft has to define them as IEs and the IANA section  
> have to request IANA to add them the IPFIX datamodel registry.
>
>
> Regards
>
> Emile
>
>