Subject: [IPFIX] How to add new abstract data types in the information model

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Jan 2009 11:28:54 +0100

RFC5102 mentions in section 3.1 "Abstract Data Types"

   This section describes the set of valid abstract data types of the
   IPFIX information model.  Note that further abstract data types may
   be specified by future extensions of the IPFIX information model.

However, neither the IANA section from RFC5102 nor the one from RFC5101 
mentions how to do that?
Do we have to go through the full process of having an internet draft, 
accepted in the charter, then in the RFC-editor queue, for IANA to 
create a abstract data types registry for IPFIX eventually?

Regards, Benoit.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Thu, 22 Jan 2009 12:46:31 +0100

Exporting-type already creates the Information Element Data Type  
subregistry, as we noticed this same issue (Abstract Data Types as in  
5101 and 5102 were not registered anywhere, and additions to the set  
were designated to be "by future extension"). Since we _did_ need a  
registry to represent types with numbers in IPFIX Options, we read the  
language in 5102 as requiring a standards action. exporting-type-02  
section 5 currently states:

IANA has created an Information Element Data Type subregistry for the  
values defined for the informationElementSemantics Information  
Element. Entries may be added to this subregistry subject to a  
Standards Action [RFC2434].

We specified this subregistry in this way because it was our intention  
to follow what we thought was the spirit of 5102 -- exporting-type  
allows the export of existing type information, not the extension of  
the type system's primitives. However, if it is the sense of the  
Working Group that it should be easier to add new ADTs, then we should  
discuss this in the scope of changes to section 5 of exporting-type.

I would caution against making it _too_ easy to add new ADTs, as each  
new ADT requires significant implementation at each protocol endpoint,  
and there are serious interoperability risks to supporting too many.  
The set that exists is a reasonably complete universal set of  
primitives as applicable to network traffic measurement, and there  
does exist a catchall ADT (0x00 octetArray) which can represent any  
other ADT (though with reduced flexibility).

Do you have an ADT in mind that's missing from the present set in 5102?

Best regards,

Brian

On Jan 22, 2009, at 11:28 AM, Benoit Claise wrote:

> IPFIX chairs,
> However, neither the IANA section from RFC5102 nor the one from  
> RFC5101 mentions how to do that?
> Do we have to go through the full process of having an internet  
> draft, accepted in the charter, then in the RFC-editor queue, for  
> IANA to create a abstract data types registry for IPFIX eventually?
>
> Regards, Benoit.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 22 Jan 2009 12:46:31 +0100

Best regards,

Brian

---

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Jan 2009 14:24:15 +0100

Great. I overlooked the IANA section of your draft.

Regards, Benoit.
> Greetings, Benoit, all,

---

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Jan 2009 14:24:15 +0100

Regards, Benoit.