Subject: Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...)

From: <[email-masked]>
Date: Wed, 2 Apr 2008 10:09:22 +0200

Hi Brian,

There is not doubt that the datamodel have to be extended in short term. 'enumerated' is the right example. It is missing in the datamodel and it is a ground truth storage datatype. 

In the current approach, the adding of 'enumerated' as an abstract datatype in the datamodel will require the update of draft-ietf-ipfix-exporting-type because this draft defines a static registry in the section "3.1.  informationElementDataType".

To avoid static pieces in the IPFIX datamodel in the future it is mandatory to define an IPFIX IE for each abstract data types defined in the IPFIX datamodel:
	octetArray          
	unsigned8           
	unsigned16          
	unsigned32          
	unsigned64          
	signed8             
	signed16            
	signed32            
	signed64            
	float32             
	float64             
	boolean             
	macAddress          
	string              
	dateTimeSeconds     
	dateTimeMilliseconds
	dateTimeMicroseconds
	dateTimeNanoseconds 
	ipv4Address         
	ipv6Address         

The WG has the opportunity to do that with draft-ietf-ipfix-exporting-type.

Regards
Emile

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

> -----Message d'origine-----
> De : Brian Trammell [mailto:[email-masked]]
> Envoyé : vendredi 28 mars 2008 22:57
> À : STEPHAN Emile RD-CORE-LAN
> Cc : [email-masked]
> Objet : expanding type and semantics registries (was Re: missing notes on
> exporting type...)
> 
> 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
> >
> >
> > > -----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
> >

Hi Brian,

There is not doubt that the datamodel have to be extended in short term. 'enumerated' is the right example. It is missing in the datamodel and it is a ground truth storage datatype. 

In the current approach, the adding of 'enumerated' as an abstract datatype in the datamodel will require the update of draft-ietf-ipfix-exporting-type because this draft defines a static registry in the section "3.1.  informationElementDataType".

To avoid static pieces in the IPFIX datamodel in the future it is mandatory to define an IPFIX IE for each abstract data types defined in the IPFIX datamodel:
	octetArray          
	unsigned8           
	unsigned16          
	unsigned32          
	unsignedONT SIZE=2 FACE="Courier New">And that's out of scope for _this_ document, which, as chartered, only</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">prov</FONT><FONT SIZE=2 FACE="Courier New">ides a _mechanism_ for describing the types already supported.</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt; </FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">That said, you have a very good point.</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt; </FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">There are quite a few types that could be immediately useful; and yes,</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">additional network-identifiers such as URL, email, and FQDN are</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">obvious first</FONT><FONT SIZE=2 FACE="Courier New"> choices, which can only be implemented as Strings at the</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">moment. Enumerations are another issue, and can already be partially</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">implemented using the Reducing Redundancy mechanism.</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt; </FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">My suggestion, however, would be a new document, to be considered for</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">a future WG charter, to _explicitly_ extend the set of types supported</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">by IPFIX, and adding those types to the registry created in exporting-</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">type.</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt; </FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">Cheers,</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt; </FONT></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt;</FONT></SPAN><SPAN LANG="en-us"> <FONT SIZE=2 FACE="Courier New">Brian</FONT></SPAN><SPAN LANG="en-us"></SPAN></P>

<P DIR=LTR><SPAN LANG="en-us"><FONT SIZE=2 FACE="Courier New">&gt; </FONT></SPAN></P>

<P DIR=LTR><SPA64          
	signed8             
	signed16            
	signed32            
	signed64            
	float32             
	float64             
	boolean             
	macAddress          
	string              
	dateTimeSeconds     
	dateTimeMilliseconds
	dateTimeMicroseconds
	dateTimeNanoseconds 
	ipv4Address         
	ipv6Address         

The WG has the opportunity to do that with draft-ietf-ipfix-exporting-type.

Regards
Emile

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

> -----Message d'origine-----
> De : Brian Trammell [mailto:[email-masked]]
> Envoyé : vendredi 28 mars 2008 22:57
> À : STEPHAN Emile RD-CORE-LAN
> Cc : [email-masked]
> Objet : expanding type and semantics registries (was Re: missing notes on
> exporting type...)
> 
> 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
> >
> >
> > > -----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: "Boschi, Elisa" <[email-masked]>
Date: Thu, 3 Apr 2008 15:10:15 +0100

Emile,

> There is not doubt that the datamodel have to be extended in short term. 
> 'enumerated' is the right example. It is missing in the datamodel and it 
> is a ground truth storage datatype.
>
> In the current approach, the adding of 'enumerated' as an abstract 
> datatype in the datamodel will require the update of 
> draft-ietf-ipfix-exporting-type because this draft defines a static 
> registry in the section "3.1.  informationElementDataType".
> 

maybe the data model will have to be extended, but this would be an information model extension (i.e. an update of RFC5102) and I don't think it belongs logically to a method description for exporting information model information on the wire. 
Of course changes in the information model are likely to affect this document too...

> To avoid static pieces in the IPFIX datamodel in the future it is 
> mandatory to define an IPFIX IE for each abstract data types defined in 
> the IPFIX datamodel:
> 
>       octetArray         
>       unsigned8          
>       unsigned16         
>       unsigned32         
>       unsigned64         
>       signed8            
>       signed16           
>       signed32           
>       signed64           
>       float32            
>       float64            
>       boolean            
>       macAddress         
>       string             
>       dateTimeSeconds    
>       dateTimeMilliseconds
>       dateTimeMicroseconds
>       dateTimeNanoseconds
>       ipv4Address        
>       ipv6Address        
> 

I understand your concern, but I think that this is out of scope for this document. If the working group wants to add this flexibility I suggest opening a separate thread on this to discuss how this issue should be addressed.

thanks,
Elisa

>>  > > perhaps start over on the subject?

************************************************************************************************** 
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://www.ietf.org/mailman/listinfo/ipfix