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

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        
> 
> The WG has the opportunity to do that with draft-ietf-ipfix-exporting-type.
> 

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

> 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

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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 3 Apr 2008 17:37:34 -0400

Elisa, Emile, all,

Replies inline.

> > registry in the section "3.1.  informationElementDataType".
Emile, it seems we're all talking past each other on representations  
of enumerated types, because I don't quite get what
you mean here. You seem to have a specific mechanism in mind for this.  
Could you describe it in more detail?
> 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.
>
Agreed. Not only that, but adding new types is, as previously noted,  
outside the item of the working group charter pertaining to this  
document.
> Of course changes in the information model are likely to affect this  
Absolutely, via the IANA registry this document creates. Changes to  
the information model that add data types to the protocol will also  
add them to the registry, assigning them a number, which can then be  
represented in informationElementDataType.
> > mandatory to define an IPFIX IE for each abstract data types  
<snip>

> 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.
>
Agreed, it's certainly not in scope, and again, doing such a thing is  
outside our charter for this document. I must admit I'm still not  
_precisely_ clear what defining these information elements gets us  
aside from the equivalent to another, different method for doing  
enterprise-specific information elements (with the benefit of  
typedness, which exporting-type achieves through an alternate  
mechanism) -- you can at least have the raw data type (as with  
exporting-type) but get no other display hints (name, units...) or  
semantic processing information.

Again, Also, I don't think it actually requires another document per  
se; the IANA registry for information elements can be amended subject  
only to Expert Review.

Cheers,

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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 3 Apr 2008 17:37:34 -0400

Elisa, Emile, all,

Replies inline.

<snip>

Cheers,

Brian

---

From: <[email-masked]>
Date: Mon, 14 Apr 2008 16:03:38 +0200

Hi Dan
 
Sorry for de delay.
 
Elisa said:

> 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.
     
To make it short:
We all agree that, without change, the RFC resulting of draft-ietf-ipfix-exporting-type will have to be updated each time a new datatype is defined.
 
My understanding of the current practice inside IETF is that numbering must be registered by IANA when the datamodel allows the definition of new datatypes in the future. So, if my view is correct, the numbering of the datatypes of the IPFIX datamodel (RFC5102) made in draft-ietf-ipfix-exporting-type has to be registered by IANA. 

Regards
Emile

________________________________

De : Boschi, Elisa [mailto:[email-masked]] 
Envoyé : jeudi 3 avril 2008 16:10
À : STEPHAN Emile RD-CORE-LAN
Cc : [email-masked]; [email-masked]
Objet : Re: [IPFIX] expanding type and semantics registries (was Re: missing notes on exporting type...)
 
Emile,

thanks,
Elisa

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

---

From: <[email-masked]>
Date: Mon, 14 Apr 2008 16:03:38 +0200

Hi Dan
 
Sorry for de delay.

     
To make it short:

Regards
Emile

 
Emile,

thanks,
Elisa

---

From: Brian Trammell <[email-masked]>
Date: Mon, 14 Apr 2008 14:43:40 -0400

Emile and all,

Replies inline.

Regards,

Brian

On Apr 14, 2008, at 10:03 AM, <[email-masked]> <[email-masked] 
 > wrote:
> Hi Dan
>
> Sorry for de delay.
>
> Elisa said:
>
> > 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
> We all agree that, without change, the RFC resulting of draft-ietf- 
> ipfix-exporting-type will have to be updated each time a new  
> datatype is defined.

No. This is not the case. The exporting-type RFC will not need to be  
updated whFrom [email-masked]  Mon Apr 14 11:44:48 2008
From: Brian Trammell <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Date: Mon, 14 Apr 2008 14:43:40 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [IPFIX] expanding type and semantics registries (was Re:
	missing notes on exporting type...)
Sender: [email-masked]

Emile and all,

Replies inline.

Regards,

Brian

On Apr 14, 2008, at 10:03 AM, <[email-masked]> <[email-masked] 
 > wrote:
> Hi Dan
>
> Sorry for de delay.
>
> Elisa said:
>
> > 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
> We all agree that, without change, the RFC resulting of draft-ietf- 
> ipfix-exporting-type will have to be updated each time a new  
> datatype is defined.

No. This is not the case. The exporting-type RFC will not need to be  
updated whenen data types are added to the protocol. The exporting-type  
draft says nothing about the data types available in IPFIX (that's the  
job of RFCs 5101/5102). It simply creates an IANA registry and  
populates it with the data types and semantics already defined within  
the protocol. It creates this registry solely so that datatypes can be  
mapped to numbers for the representation of type information inline.

> My understanding of the current practice inside IETF is that  
> numbering must be registered by IANA when the datamodel allows the  
> definition of new datatypes in the future. So, if my view is  
> correct, the numbering of the datatypes of the IPFIX datamodel  
> (RFC5102) made in draft-ietf-ipfix-exporting-type has to be  
> registered by IANA.

Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of  
exporting-type.

Note that, as the data type and semantics registries are defined to be  
updated by an RFC 2434 Standards Action only, an additional RFC _will_  
be necessary to add data types to the IPFIX protocol, but this RFC  
need not update the exporting-type RFC; nothing about new data types  
will change how metainformation about those types will be represented  
inline.

We selected Standards Action from RFC 2434 as the update policy for  
the created registries after discussion at one of the working group  
meetings (Vancouver, I think, but I may be remembering incorrectly),  
because there are potentially serious interoperability concerns raised  
by adding new datatypes to the protocol, specifically in how  
information of the new types is to be encoded on the wire.

> >>  -----Mess data types are added to the protocol. The exporting-type  
draft says nothing about the data types available in IPFIX (that's the  
job of RFCs 5101/5102). It simply creates an IANA registry and  
populates it with the data types and semantics already defined within  
the protocol. It creates this registry solely so that datatypes can be  
mapped to numbers for the representation of type information inline.

> My understanding of the current practice inside IETF is that  
> numbering must be registered by IANA when the datamodel allows the  
> definition of new datatypes in the future. So, if my view is  
> correct, the numbering of the datatypes of the IPFIX datamodel  
> (RFC5102) made in draft-ietf-ipfix-exporting-type has to be  
> registered by IANA.

Yes, exactly, as in sections 3.1, 3.6, and 5 of the -01 revision of  
exporting-type.

Note that, as the data type and semantics registries are defined to be  
updated by an RFC 2434 Standards Action only, an additional RFC _will_  
be necessary to add data types to the IPFIX protocol, but this RFC  
need not update the exporting-type RFC; nothing about new data types  
will change how metainformation about those types will be represented  
inline.

We selected Standards Action from RFC 2434 as the update policy for  
the created registries after discussion at one of the working group  
meetings (Vancouver, I think, but I may be remembering incorrectly),  
because there are potentially serious interoperability concerns raised  
by adding new datatypes to the protocol, specifically in how  
information of the new types is to be encoded on the wire.

> >>  -----Messagage d'origine-----
> >
> >>  > > De : Brian Trae d'origine-----
> >
> >>  > > De : Brian Trammmmell [mailto:[email-masked]]
> >
> >>  >
> >

ell [mailto:[email-masked]]

---

From: <[email-masked]>
Date: Wed, 16 Apr 2008 16:42:35 +0200

Hi Brain,

Thanks for the explanation. This framework limit's is reached when an enterprise has to export the type of an IE which abstract data type is not defined in the datamodel of the RFC5102. So the registry of the section 3 must not be limited to the exiting abstract data types. It must include any existing database datatypes to reach, at least, the initial goal of storing efficiently any proprietary IEs. 

Otherwise, for sure, enterprises will 'complete' the table of section 3.1 with their own abstract datatypes and tags. Then collectors will have to get these values (using their cristal ball) and to hardcode these values in a multidimensional table, then, later, the IPFIX WG will have to specify some solution to export proprietary abstract data types...

So, with real respect to the work done and to its need, this draft does not encourage the usage of standard IEs and the migration towards standard IEs. 

It should. Abstract data type IEs are really required in option templates to describe abstract contexts not relFrom [email-masked]  Wed Apr 16 07:42:16 2008
Content-class: urn:content-classes:message
Date: Wed, 16 Apr 2008 16:42:35 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [IPFIX] expanding type and semantics registries (was Re:
	missing notes on exporting type...)
Sender: [email-masked]

Hi Brain,

Thanks for the explanation. This framework limit's is reached when an enterprise has to export the type of an IE which abstract data type is not defined in the datamodel of the RFC5102. So the registry of the section 3 must not be limited to the exiting abstract data types. It must include any existing database datatypes to reach, at least, the initial goal of storing efficiently any proprietary IEs. 

Otherwise, for sure, enterprises will 'complete' the table of section 3.1 with their own abstract datatypes and tags. Then collectors will have to get these values (using their cristal ball) and to hardcode these values in a multidimensional table, then, later, the IPFIX WG will have to specify some solution to export proprietary abstract data types...

So, with real respect to the work done and to its need, this draft does not encourage the usage of standard IEs and the migration towards standard IEs. 

It should. Abstract data type IEs are really required in option templates to describe abstract contexts not rated per essence to a flow nor to the direction of a flow. This is an urgently needed to limit reasonably the number of proprietary IEs.

Regards
Emile
> Envoyé : lundi 14 avril 2008 20:44
> Cc : [email-masked]; [email-masked]; [email-masked]
> updated when data types are added to the protocol. The exporting-type
> > >>  moment. Enumelated per essence to a flow nor to the direction of a flow. This is an urgently needed to limit reasonably the number of proprietary IEs.

Regards
Emile
> Envoyé : lundi 14 avril 2008 20:44
> Cc : [email-masked]; [email-masked]; [email-masked]
> updated when data types are added to the protocol. The exporting-type
>erations are another issue, and can already be
> > partially
> > >

________________________ > information model information on the wire.
> > >>  moment. En_______________________
IPFIX mailing list
[email-masked]

umerations are another issue, and can already be
> > partially

---

From: Brian Trammell <[email-masked]>
Date: Wed, 16 Apr 2008 15:14:24 -0400

Emile,

Replies inline...

On Apr 16, 2008, at 10:42 AM, <[email-masked]> <[email-masked] 
 > wrote:
>
>
> Hi Brain,
>
> Thanks for the explanation. This framework limit's is reached when  
> an enterprise has to export the type of an IE which abstract data  
> type is not defined in the datamodel of the RFC5102. So the registry  
> of the section 3 must not be limited to the exiting abstract data  
> types. It must include any existing database datatypes to reach, at  
> least, the initial goal of storing efficiently any proprietary IEs.
>
> Otherwise, for sure, enterprises will 'complete' the table of  
> section 3.1 with their own abstract datatypes and tags. Then  
> collectors will have to get these values (using their cristal ball)  
> and to hardcode these values in a multidimensional table, then,  
> later, the IPFIX WG will have to specify some solution to export  
> proprietary abstract data types...

Enterprises can't "complete" the data type table without a standards  
action -- this is the point of restricting additions to that registry  
as exporting-type does currently. Without this, the best an enterprise  
can do for a new data type encoding is to represent it as an octet- 
array -- which is precisely as good as it can do without exporting- 
type. So, no loss here.

That said, I think we have different ideas as to what comprises a  
"data type".

The core data types supported by 5101/5102 are the basic primitive  
scalar types supported by most reasonably modern programming  
languages, plus specific subtypes of ordered octet arrays or special  
integer encodings corresponding to packet header (link-layer and  
network address) field types and collection infrastructure (timestamp)  
field types. It is unclear which scalar primitives we're missing.

You pointed out email addresses, FQDNs, and URIs as candidates for new  
abstract data types. All are already representable by Strings, and are  
all restricted subtypes of String. These make sense at first glance;  
however, on further reflection such would add a new error condition at  
the IPFIX Collecting Process side that would require protocol changes.

All the presently supported data types, save String, have the property  
that any sequence of bytes within the IE has a single valid decoding.  
This is trivially true for integer, address, and datetime types; IEEE  
754 states that all byte sequences are either numbers or valid NaNs  
(with the caveat that positive and negative zero may require special  
handling, but this is to be handled at a layer above IPFIX.) Strings  
are encoded in IPFIX using UTF-8 (see RFC 5101 section 6.1.6); while  
all byte sequences are not necessarily legal UTF-8, there are accepted  
methods for decoding or ignoring these illegal sequences (though these  
may themselves have security implications; see RFC 2279 section 6). We  
probably should have addressed this a bit more carefully in RFC 5101,  
but it's pretty clear that clarifying erroneous UTF-8 string decoding  
in exporting-type is _way_ out of scope.

This is not the case for URIs, or email addresses, or FQDNs. These  
"data types" are essentially encodings (UTF8 Strings) with a contract  
to keep the content conformant to some syntax. No other IPFIX data  
type has this property. Illegal UTF-8 sequences are corner cases;  
legal UTF-8 sequences that are not legal URIs comprise the majority of  
UTF-8 code space. What is a Collecting Process to do with such non- 
conformant byte sequences? What additional information does such a  
contract provide to the Collecting Process?

(Note that it is _precisely_ data type encoding complications such as  
this one that led us to restrict additions to the data type registry  
to standards actions.)

So, which scalar primitives are we missing?

Structured abstract data types and collection types are another story,  
but they'll require protocol changes and new template mechanisms, so  
they're also way, way out of scope for exporting-type.

> So, with real respect to the work done and to its need, this draft  
> does not encourage the usage of standard IEs and the migration  
> towards standard IEs.

I disagree. The mechanism here encourages standardization and  
transition of provisional enterprise-specific information elements to  
the degree possible without changing the protocol or the nature of the  
information model itself.

> It should. Abstract data type IEs are really required in option  
> templates to describe abstract contexts not related per essence to a  
> flow nor to the direction of a flow. This is an urgently needed to  
> limit reasonably the number of proprietary IEs.

No particular disagreement here (though this proposal still seems to  
me to be an alternate, typed, unlabeled enterprise-specific IE  
mechanism with potentially serious multiple-IE interpretation issues,  
and I'm still not 100% clear what you want them for). But once more,  
this is _not_ in scope for a draft which specifies a only a mechanism  
for inline type information encoding. It's also not something you need  
an RFC for; the IE registry is appendable subject only to expert (at  
this point, Nevil) review.

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Wed, 16 Apr 2008 15:14:24 -0400

Emile,

Replies inline...

Regards,

Brian

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 17 Apr 2008 11:07:53 +0200

Hi all,

I just want to say that Brian's rationales sound valid to me.

As done in RFC 5102, we need to distinguish between Abstract Data Types,
Data Type Semantics, and IEs.

The purpose of the draft is to explain/define enterprise-specific IEs by
their Abstract Data Type and their Data Type Semantic, plus a
human-readable description, information about the unit, and range of
valid values.

The draft is not about defining new Abstract Data Types or Data Type
Semantics. And I do not think it should be; otherwise, you would have to
explain the en/decoding to the collector, which can be very complicated.

With respect to the new types raised in the discussion, I currently do
not see the need to add new Abstract Data Types. As Brian said, an URL
can be encoded as a string. An enumeration can be encoded as an integer.
Only if someone found a much more efficient way to encode this kind of
information, it would be worth defining a new abstract data type.

However, new Data Type Semantics like "enumeration" or "url" might be
useful. Yet, as said above, this draft is not about new Data Type
Semantics.

Regards,
Gerhard

Brian Trammell wrote:
> Emile,
> 
> Replies inline...
> 
> On Apr 16, From [email-masked]  Thu Apr 17 02:07:31 2008
Date: Thu, 17 Apr 2008 11:07:53 +0200
From: Gerhard Muenz <[email-masked]>
To: Brian Trammell <[email-masked]>
Cc: [email-masked]
Subject: Re: [IPFIX] expanding type and semantics registries (was
 Re:	missing notes on exporting type...)
Sender: [email-masked]

Hi all,

I just want to say that Brian's rationales sound valid to me.

As done in RFC 5102, we need to distinguish between Abstract Data Types,
Data Type Semantics, and IEs.

The purpose of the draft is to explain/define enterprise-specific IEs by
their Abstract Data Type and their Data Type Semantic, plus a
human-readable description, information about the unit, and range of
valid values.

The draft is not about defining new Abstract Data Types or Data Type
Semantics. And I do not think it should be; otherwise, you would have to
explain the en/decoding to the collector, which can be very complicated.

With respect to the new types raised in the discussion, I currently do
not see the need to add new Abstract Data Types. As Brian said, an URL
can be encoded as a string. An enumeration can be encoded as an integer.
Only if someone found a much more efficient way to encode this kind of
information, it would be worth defining a new abstract data type.

However, new Data Type Semantics like "enumeration" or "url" might be
useful. Yet, as said above, this draft is not about new Data Type
Semantics.

Regards,
Gerhard

Brian Trammell wrote:
> Emile,
> 
> Replies inline...
> 
> On Apr 16, 202008, at 10:42 AM, <[email-masked]> <[email-masked] 
>  > wrote:
>>
>> Hi Brain,
>>
> Structured abstract data types and collection types08, at 10:42 AM, <[email-masked]> <[email-masked] 
>  > wrote:
>>
>> Hi Brain,
>>
> Structured abstract data types and collection types a are another story,  
>>> We selected Standards Action from RFC 2434 as the update polre another story,  
>>> We selected Standards Action from RFC 2434 as the update policicy for
>>>>>> informay for
>>>>>> informatition on the definition (as in section 3.1 of RFC 5102) and
>>> *********************************************on on the definition (as in section 3.1 of RFC 5102) and

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

*****************************
>>> ************************

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Thu, 17 Apr 2008 11:47:29 -0400

Gerhard,

Hmm, interesting... you're right, of course, that the restricted  
String "types" (email, url, etc..) are _semantics_ (hadn't thought of  
that, actually; I was considering only types and their encoding in  
this discussion so far)...

And yes, new semantics, like new types, are not in scope for this  
draft. They probably _should_ be addressed in a new individual draft  
for consideration for adoption as a WG standards-track item for a  
subsequent charter; exporting-type _does_ provide guidelines such a  
draft should follow for noting which semantics are valid for which  
types (section 3.10, paragraph 3 in -01), but that, I think, is the  
proper extent of exporting-typeFrom [email-masked]  Thu Apr 17 08:47:26 2008
From: Brian Trammell <[email-masked]>
To: Gerhard Muenz <[email-masked]>
Date: Thu, 17 Apr 2008 11:47:29 -0400
Cc: [email-masked]
Subject: Re: [IPFIX] expanding type and semantics registries (was
	Re:	missing notes on exporting type...)
Sender: [email-masked]

Gerhard,

Hmm, interesting... you're right, of course, that the restricted  
String "types" (email, url, etc..) are _semantics_ (hadn't thought of  
that, actually; I was considering only types and their encoding in  
this discussion so far)...

And yes, new semantics, like new types, are not in scope for this  
draft. They probably _should_ be addressed in a new individual draft  
for consideration for adoption as a WG standards-track item for a  
subsequent charter; exporting-type _does_ provide guidelines such a  
draft should follow for noting which semantics are valid for which  
types (section 3.10, paragraph 3 in -01), but that, I think, is the  
proper extent of exporting-ty's involvement in adding semantics.

Cheers,

Brian

On Apr 17, 2008, at 5:07 AM, Gerhard Muenz wrote:
>> are encodepe's involvement in adding semantics.

Cheers,

Brian

On Apr 17, 2008, at 5:07 AM, Gerhard Muenz wrote:
>> are encod in IPFIX using UTF-8 (see RFC 5101 section 6.1.6); while
>>>> Objet : Re: [IPFIX] expanding type and semantics registries (was  
>>>> Re:
>>>> updated wded in IPFIX using UTF-8 (see RFC 5101 section 6.1.6); while
>>>> Objet : Re: [IPFIX] expanding type and semantics registries (was  
>>>> Re:
>>>> updatedhen data types are added to the protocol. The exporting- 
>>>> type
>>>>> Objet : Re: [IPFIX] expanding type and semantics registries (was  
>>>>> Re:
>>>>>> There is not doubt that the datamodel have to be extended in  
>>>>>> short
>>>>> term.
>>>>> an
>>>>> Of course changes in the information model are likely to affect  
>>>>> this
>>>>> document too...
>>>>>
>>>>>
>>>>> suggest opening a separate thread on this to discuss how t when data types are added to the protocol. The exporting- 
>>>> type
>>>>> Objet : Re: [IPFIX] expanding type and semantics registries (was  
>>>>> Re:
>>>>>> There is not doubt that the datamodel have to be extended in  
>>>>>> short
>>>>> term.
>>>>> an
>>>>> Of course changes in the information model are likely to affect  
>>>>> this
>>>>> document too...
>>>>>
>>>>>
>>>>> suggest opening a separate thread on this to discuss howhis  
>>>>> issue
>>>>> should be addressed.
>>>>>
>>>>> thanks,
>>>>> Elisa
>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Emile
>>>>>>
>>>> this  
>>>>> issue
>>>>> Hitachi checks outgoing e-mail messages for the presence of  
>>>>> computer
>>>>> viruses.
>>>>>

>>>>> Hitachi checks outgoing e-mail messages for the presence of  
>>>>> computer
>>>>> viruses.
>>>>>