Subject: [IPFIX] questions about structured-data draft

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 9 Oct 2010 12:17:30 -0400

Hi,
I have some questions on the structured-data draft:
1) The structured-data draft defines three new abstract data types: basicList, subTemplateList, and subTemplateMultiList.  Are these allowed/expected to be used by a new IANA-assigned IE as its abstract data type?  Clearly the draft revolves around using them for the new IEs of the same name, but I don't see any text that the new abstract types are unusable as types for a new IE.  Although one would think it would provide no advantage to do so, since the specific IE type of the list members has to be encoded inside the list anyway, it may improve interop to do so.  For example, specifying new IEs for bgpPathList, bgpSequenceList and bgpSetList, of abstract types and semantics basicList/ordered, basicList/ordered, and basicList/exactlyOneOf respectively.  That way ipfix readers can recognize it as a BGP Path/Seq/Set more easily.

2) Along that same line of thought, encoding the structures as done in this draft seems to lose the type information of the list itself.  It has to be inferred, which is failure-prone.  For example, suppose you report a list of the ACL the flow matches, as well as a list of the packet's source IP headers (it could be a list if it's IP-in-IP or IPsec tunnel mode).  The ACL may be just a basicList of sourceIPv4Address, as would the IP-in-IP list.  How does the ipfix collector/reader know which is which?  What if vendor X records the ACL first and the IP-in-IP second, while vendor Y does the opposite?  Or vendor X may only report ACLs while vendor Y only reports IP-in-IP, but their reports look identical.  Or for another example, the draft talks about a multicast list being a list of egressInterfaces.  But how does the ipfix reader know that a list of egress interfaces is a "multicast" list and not a list of aggregated interfaces, or span ports?  The problem is these lists have no type.  They're just lists of types.  Anytime two lists of different purposes happen to use the same member types there's a collision.  Or am I missing something? (could easily be)

3) If I define a Template, and I want to include multiple lists, like 3 basicLists which are unrelated other than they all apply to the same flow, can I do that by just specifying the basicList IE 3 times in my Template?  Or should I instead create a single list of lists?

4) This is just an observation, but it seems funny to me that a "basicList" actually takes more bytes to encode than a subTemplateList, so that a basicList of basicLists is even more expensive than a subTemplateList of subTemplateLists.  For example take the BGP Path example encoding AS1, AS2, AS3, {AS4, AS5}: 

I would encode the following using basicList:
Template: ID=256
	sourceIPv4Address, destinationIPv4Address, basicList

Set: TemplateID=256
	Data-Record: 1.1.1.1, 2.2.2.2, {(length=XXX, ordered) IE=basicList IElength=65535: {(length=YYY, ordered) IE=bgpAS IElength=2: AS1, AS2, AS3}, {(length=ZZZ, exactlyOneOf) IE=bgpAS IElength=2: AS4, AS5}}

But the following using subTemplateList:
Template: ID=256
	sourceIPv4Address, destinationIPv4Address, subTemplateList

Template: ID=257
	subTemplateList

Template: ID=258
	bgpAS

Set: TemplateID=256
	Data-Record: 1.1.1.1, 2.2.2.2, {(length=XXX, ordered) TID=257: {(ordered) TID=258: AS1, AS2, AS3}, {(exactlyOneOf) TID=258: AS4, AS5}}

-hadriel

---

From: Paul Aitken <[email-masked]>
Date: Sat, 09 Oct 2010 22:51:56 +0100

Hadriel,

> I have some questions on the structured-data draft:

We appreciate you reviewing the draft, thanks!

> 1) The structured-data draft defines three new abstract data types: basicList, subTemplateList, and subTemplateMultiList.  Are these allowed/expected to be used by a new IANA-assigned IE as its abs…

The new data types may be used by new IANA or Enterprise specific 
information elements as required. The new elements you propose sound 
useful and can be registered through the usual IANA process if required 
once this draft reaches RFC status.

> 2) Along that same line of thought, encoding the structures as done in this draft seems to lose the type information of the list itself.  It has to be inferred, which is failure-prone.  For example, suppose you report a list of the ACL the flow matches, as well as a list of the packet's source IP headers (it could be a list if it's IP-in-IP or IPsec tunnel mode).  The ACL may be just a basicList of sourceIPv4Address, as would the IP-in-IP list.  How does the ipfix collector/reader know which is which?  What if vendor X records the ACL first and the IP-in-IP second, while vendor Y does the opposite?  Or vendor X may only report ACLs while vendor Y only reports IP-in-IP, but their reports look identical.  Or for another example, the draft talks about a multicast list being a list of egressInterfaces.  But how does the ipfix reader know that a list of egress interfaces is a "multicast" list and not a list of aggregated interfaces, or span ports?  The problem is these lists hav
e
>   no type.  They're just lists of types.  Anytime two lists of different purposes happen to use the same member types there's a collision.  Or am I missing something? (could easily be)

New Information Elements should be defined for the ACL matches and 
source IP headers, allowing the lists to be distinguished from one 
another and from anything else. Per sections 4.3.x of the draft, the 
list elements we define in the draft are explicitly generic elements.

eg, "A basicList specifies a generic Information Element..."

> 3) If I define a Template, and I want to include multiple lists, like 3 basicLists which are unrelated other than they all apply to the same flow, can I do that by just specifying the basicList IE…

We recommend creating three separate basicList elements inside the 
template, because a list of lists includes a top level semantic which 
incurs an extra overhead and implies a relationship between the lists.

> 4) This is just an observation, but it seems funny to me that a "basicList" actually takes more bytes to encode than a subTemplateList, so that a basicList of basicLists is even more expensive than…

Not so, because the subTemplateList requires that a template also be 
defined so that the template ID can be specified in the list.

This exact situation is discussed in section 5.4 :

   A subTemplateList can represent the same simple list of single-value
   Information Elements as a basicList, if the Template referenced by
   the subTemplateList contains only one single-valued Information
   Element.  Although the encoding is more compact than a basicList by
   two bytes, using a subTemplateList in this case requires a new
   Template per Information Element.  The basicList requires no
   additional Template and is therefore RECOMMENDED in this case.

Thanks,
Gowri, Benoit and Paul.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 9 Oct 2010 23:06:39 -0400

Hi Paul,
comments inline...
(and sorry if these questions/comments are naive - I'm relatively new to ipfix)

> once this draft reaches RFC status.

Ahhh.  That clears up a lot for me.  I was utterly confused how a record with arbitrary collection of data types would have any meaning to an ipfix reader.  I think the draft should say something in section 4.1 along the lines of:
"Since this document defines the three new abstract data types below, new Information Elements can be created as these data types, just as they could have been for unsigned8, ipv4Address, and so on.  A Template Record containing such an IE would therefore indicate the new IE as a field in the Template and not the new IEs described in section 4.3, but its instance structure within a Data Record would follow those described for the new IEs in section 5."

> eg, "A basicList specifies a generic Information Element..."

OK, but for someone who doesn't live and breathe IPFIX but just reads the specs so he can encode some info to export (like me), the draft reads like all I have to do if I need a structure is to use one of these new IE types and any of the IANA-defined IEs, and if ipfix readers want to decode it for OAM reporting purposes they can.  But really they can't, if some other vendor does the same thing using the same IE types but for a different reason.  There is no XML/whatever dictionary I can give to the reader to distinguish my structure's purpose from the other vendor's structure, because we both happened to use the same IE types for our list members.  

In fact, I still don't understand what purpose the new IEs serve.  I mean really these are new *data types*, just as an unsigned8 or octetArray is.  What would be the point of having an IANA defined IE named "unsigned8"?  It has no meaning between two different parties.  It's like a PEN, but without the Enterprise number.  Or to put it in C programming terms, it's like defining a new data type named "struct", instead of using a struct to define a new data type.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 9 Oct 2010 23:52:55 -0400

> defined so that the template ID can be specified in the list.

Sure, but the Templates get sent/recorded once; and for the exporter, are probably in a static form they can just send as a blob, and save the bytes from then on for that session/file.

>   additional Template and is therefore RECOMMENDED in this case.

This has probably been suggested and dismissed already, but have you thought of encoding a basicList as just a list of the data with the length/semantic fields, and encoding the member IE type/length in the Template instead?  For example, reserve an IANA Enterprise Number such as 123456, and in the template encode the IANA-defined IE basicList using the IANA-define IE number but with that reserved PEN.  The reserved PEN 123456 means the IE is a list of that IE, following the structure of a basicList.

So for example, if you wanted to record multiple egressInterfaces (type 14), the encoding would look like:
Template: ID=256
	sourceIPv4Address=8 length=4, destinationIPv4Address=12 length=4, listOf(egressInterface)=(pen:14/123456) length=65535

Set: TemplateID=256
	Data-Record: 1.1.1.1, 2.2.2.2, {(length=12, allOf) intf-1, intf-2, intf-3}

And if you wanted to have a basicList of subTemplateList or subTemplateMultiList, it would be the PEN 123456 with their respective IEs. 

The advantages of this scheme are:
1) Follows the previous IPFIX model of encoding data types in Templates and data values in records. (instead of encoding types in data records)
2) Makes it imminently clear that a basicList of IE type X is exactly the same meaning of IE type X individually.
3) Allows an ipfix reader to know the position relativity of lists for different types from Templates in advance of Data Records (ie, that a list of egressInterfaces will come before a list of foobar)
4) Saves 4 bytes per basicList.
5) Automatically allocates a basicList type for every current (and future) IANA-defined IE, but we can put into IANA if it makes sense for a given one or not.

The one thing this does not allow is a real PEN IE to be used as a basicList member.  But doing so makes no sense anyway - a PEN's content is effectively opaque data, so knowing something is a list of opaque data isn't useful.  Note this doesn't mean you can't encode a PEN IE who's content happens to be a list; you just record your real PEN IE in the Template and encode its data in the Data Record following the same list structure format (as you can already do today).  And we would still define a "basicList" abstract data type so that if the real PEN IE is described using RFC 5610 or XML or whatever, it works and you can decode it all.

-hadriel

---

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Oct 2010 18:17:36 +0200

Hadriel,
> (and sorry if these questions/comments are naive - I'm relatively new to ipfix)
Don't worry, we welcome new readers.
> "Since this document defines the three new abstract data types below, new Information Elements can be created as these data types, just as they could have been for unsigned8, ipv4Address, and so on…
We have to pay attention to one thing. Your basicList examples (such as 
bgpPathList) make perfect sense and could be easily specified in IPFIX IANA.
However, we will have to decide how far we want to go in defining new 
IEs based on subTemplateList and subTemplateMultiList...
> In fact, I still don't understand what purpose the new IEs serve.  I mean really these are new *data types*, just as an unsigned8 or octetArray is.  What would be the point of having an IANA define…
You're right.
The goal of this draft is not defined an information model on the top of 
IEs. For example, we will not tell you that a list of IP address pairs 
represent:
- 4 IP address of GRE tunnel
- versus IP accounting data
- versus an ACL

The goal of this draft, as you pointed out is to have new data types.

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

---

From: "Gowri Dhandapani (gowri)" <[email-masked]>
Date: Mon, 11 Oct 2010 10:16:14 -0700

Hi Hadriel,
Thanks for your review, please see responses inline marked by ###.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Saturday, October 09, 2010 11:53 PM
To: Paul Aitken (paitken)
Cc: IETF IPFIX Working Group
Subject: Re: [IPFIX] questions about structured-data draft

On Oct 9, 2010, at 5:51 PM, Paul Aitken wrote:

> 
>> 4) This is just an observation, but it seems funny to me that a
"basicList" actually takes more bytes to encode than a subTemplateList,
so that a basicList of basicLists is even more expensive than a
subTemplateList of subTemplateLists.  For example take the BGP Path
> defined so that the template ID can be specified in the list.

Sure, but the Templates get sent/recorded once; and for the exporter,
are probably in a static form they can just send as a blob, and save the
bytes from then on for that session/file.

### Yes, the Templates are sent only once, the concern isn't the
bandwidth. The overhead is defining and maintaining the template when
there is no need for one. 

>   additional Template and is therefore RECOMMENDED in this case.

This has probably been suggested and dismissed already, but have you
thought of encoding a basicList as just a list of the data with the
length/semantic fields, and encoding the member IE type/length in the
Template instead?  For example, reserve an IANA Enterprise Number such
as 123456, and in the template encode the IANA-defined IE basicList
using the IANA-define IE number but with that reserved PEN.  The
reserved PEN 123456 means the IE is a list of that IE, following the
structure of a basicList.

So for example, if you wanted to record multiple egressInterfaces (type
14), the encoding would look like:
Template: ID=256
	sourceIPv4Address=8 length=4, destinationIPv4Address=12
length=4, listOf(egressInterface)=(pen:14/123456) length=65535

Set: TemplateID=256
	Data-Record: 1.1.1.1, 2.2.2.2, {(length=12, allOf) intf-1,
intf-2, intf-3}

And if you wanted to have a basicList of subTemplateList or
subTemplateMultiList, it would be the PEN 123456 with their respective
IEs. 

### If I recall correctly, I believe we may have considered this in the
past, but was dropped due to consistency sake - all of the three
structured data IEs would look similar to any individual IEs in the
Template (anything specific to the list would be included in the Data
Record), this is also important for backward compatibility for
collectors who don't understand structured data. 

Thanks.

The advantages of this scheme are:
1) Follows the previous IPFIX model of encoding data types in Templates
and data values in records. (instead of encoding types in data records)
2) Makes it imminently clear that a basicList of IE type X is exactly
the same meaning of IE type X individually.
3) Allows an ipfix reader to know the position relativity of lists for
different types from Templates in advance of Data Records (ie, that a
list of egressInterfaces will come before a list of foobar)
4) Saves 4 bytes per basicList.
5) Automatically allocates a basicList type for every current (and
future) IANA-defined IE, but we can put into IANA if it makes sense for
a given one or not.

The one thing this does not allow is a real PEN IE to be used as a
basicList member.  But doing so makes no sense anyway - a PEN's content
is effectively opaque data, so knowing something is a list of opaque
data isn't useful.  Note this doesn't mean you can't encode a PEN IE
who's content happens to be a list; you just record your real PEN IE in
the Template and encode its data in the Data Record following the same
list structure format (as you can already do today).  And we would still
define a "basicList" abstract data type so that if the real PEN IE is
described using RFC 5610 or XML or whatever, it works and you can decode
it all.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 11 Oct 2010 14:11:03 -0400

> IEs based on subTemplateList and subTemplateMultiList...

Yeah I can't grok how that would work. 

So maybe I should describe the problem I'm trying to solve and see if structured-data is the solution or not.  (sorry about the email length)

We have this SIP-CLF proposal, where we export/record info about the SIP Message. (as you well know :)
All the current mandatory fields we wish to export are either already existing IEs, such as sourceIPv4Address, or proposed new ones specific to SIP like sipToURI.  None of them can appear more than once in a SIP Message, so we don't have to deal with lists.

We want to make it extensible, by letting vendors export additional info in the record.  We could do that with vendor-specific PENs (and undoubtedly people will), but I was going to submit a draft for registering IEs for things we expect to be somewhat popular to add, or at least that someone might want to add and having a defined IE for already would be useful.  For example, stuff from a SIP Contact, P-Asserted-Identity, or P-Preferred-Identity headers.  

Some SIP header types can appear multiple times, some cannot.  So having a basicList for the ones that can solves that.  

The tricky thing about SIP headers, though, is that their contents are not just a single "value".  They are really composed of distinct fields.  There's a list of zero or more header parameters, a header value, and within that header value there could be a URI, display-name, or some other combination of discrete fields.  For reporting purposes, one generally wants to segregate out such fields if possible, so that the collector/reader does not need to understand SIP ABNF rules and do that work itself.  But for some headers recording the whole field makes sense.

So as I was writing up the stuff people may want to record, it became obvious that creating a unique IE for each and every field, of each and every SIP header, is untenable.  It would mean, for example, that you'd have a sipContactURI, sipContactDisplayName, sipContactParamName, sipContactParamValue, as well as a sipPAssertedIdURI, sipPAssertedIdDisplayName, sipPAssertedIdParamName, sipPAssertedIdParamValue, as well as sipPPreferredIdURI, sipPPreferredIdDisplayName, sipPPreferredIdParamName, and sipPPreferredIdParamValue.  And that's only the tip of iceberg.  There are currently *106* SIP headers registered in IANA, and a half-dozen more in drafts at various stages.  Not all of them follow the pattern of having a URI and optional display name (most don't, but many do); but even if you created a "<headerName>HeaderValue" and "<headerName>ParamName" and "<headerName>ParamValue" IE type for each, that's a lot. (and you'd exhaust your IE number space if you did this for other protocols like H.323 and HTTP and RTSP)

What you'd really want is to create a few new abstract data types of "sipGenericHeader", "sipUriHeader" and "sipParam" in IANA, which would be a composite of the pieces, and then define a sip<name>Header IE for each of the 106 header types, based on their specific abstract data type.  For example a sipPAssertedIdHeader IE, which is of abstract type sipUriHeader, with a URI, display-name, and a basicList of sipParam (and sipParam would be a name/value pair).  

Essentially, what this calls for is the ability to take *generic* data types, such as URI or paramValue (both of which are based on string), and build upon them to form more complex (and unique) data types to eventually yield a sipContactHeader IE.  It's not clear to me if the structured-data draft is actually meant to accomplish that, or if it's just meant to take *specific* data type IEs and let them appear multiple times in a structure, but without changing their meaning. 

In other words, you can't record an ACL list as just a basicList of sourceIPv4Address, because "sourceIPv4Address" has the meaning of being the source IPv4 address of the flow's actual *packet*, not an access control it may or may not match to.  You'd have to create an IE for aclSourceIPv4Address and put it in a basicList.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 11 Oct 2010 14:16:25 -0400

Hi Gowri,
it would be backwards-compatible, because as far as a legacy reader knows the Template just told it there was going to be a PEN IE in that position, as either a variable length or a fixed length (note that the length in the Template would apply to the whole basicList, not the length of the specific IE in the list).

But anyway yeah the idea suffers from being different from the other list type syntaxes, and can't have a basicList of basicList, which is bad.  So cancel that idea. :)

-hadriel

On Oct 11, 2010, at 1:16 PM, Gowri Dhandapani (gowri) wrote:

Hi Hadriel,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Saturday, October 09, 2010 11:53 PM
To: Paul Aitken (paitken)
Cc: IETF IPFIX Working Group
Subject: Re: [IPFIX] questions about structured-data draft

On Oct 9, 2010, at 5:51 PM, Paul Aitken wrote:

### Yes, the Templates are sent only once, the concern isn’t the bandwidth. The overhead is defining and maintaining the template when there is no need for one.

Template: ID=256

Set: TemplateID=256

### If I recall correctly, I believe we may have considered this in the past, but was dropped due to consistency sake – all of the three structured data IEs would look similar to any individual IEs in the Template (anything specific to the list would be included in the Data Record), this is also important for backward compatibility for collectors who don’t understand structured data.

Thanks.

-hadriel

IPFIX mailing list

[email-masked]<mailto:[email-masked]>

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 12 Oct 2010 11:38:09 +0200

Hi Hadriel,

Hadriel Kaplan wrote:
> 2) Along that same line of thought, encoding the structures as done
> in this draft seems to lose the type information of the list itself.
> It has to be inferred, which is failure-prone.  For example, suppose
> you report a list of the ACL the flow matches, as well as a list of
> the packet's source IP headers (it could be a list if it's IP-in-IP
> or IPsec tunnel mode).  The ACL may be just a basicList of
> sourceIPv4Address, as would the IP-in-IP list.  How does the ipfix
> collector/reader know which is which?  What if vendor X records the
> ACL first and the IP-in-IP second, while vendor Y does the opposite?
> Or vendor X may only report ACLs while vendor Y only reports
> IP-in-IP, but their reports look identical.  Or for another example,
> the draft talks about a multicast list being a list of
> egressInterfaces.  But how does the ipfix reader know that a list of
> egress interfaces is a "multicast" list and not a list of aggregated
> interfaces, or span ports?  The problem is these lists have no type.
> They're just lists of types.  Anytime two lists of different purposes
> happen to use the same member types there's a collision.  Or am I
> missing something? (could easily be)

Without any context information, the Collector will never know how to
interpret a Data Record.

For example, even if it looks like a Flow Record, it might be an PSAMP
Packet Report (unless a counter fields exists indicating that there is
more than one packet).

To some extend, context information can be exported in a standardized
way using Options, e.g. to describe the Metering Process. But there are
limitations.

My understanding is that IPFIX does not aim at exporting all kinds
context information because IPFIX will be implemented in environments
where you know what kind of device the Exporter is. So, you can assume
that a certain context is given so that the Collector is able to
interpret the exported data.

> "basicList" actually takes more bytes to encode than a
> subTemplateList, so that a basicList of basicLists is even more
> expensive than a subTemplateList of subTemplateLists.  For example
> take the BGP Path example encoding AS1, AS2, AS3, {AS4, AS5}:
> 
> I would encode the following using basicList: Template: ID=256 
> Set: TemplateID=256 Data-Record: 1.1.1.1, 2.2.2.2, {(length=XXX,
> ordered) IE=basicList IElength=65535: {(length=YYY, ordered) IE=bgpAS
> IElength=2: AS1, AS2, AS3}, {(length=ZZZ, exactlyOneOf) IE=bgpAS
> IElength=2: AS4, AS5}}
> 
> But the following using subTemplateList: Template: ID=256 
> Template: ID=257 subTemplateList
> 
> Template: ID=258 bgpAS
> 
> Set: TemplateID=256 Data-Record: 1.1.1.1, 2.2.2.2, {(length=XXX,
> ordered) TID=257: {(ordered) TID=258: AS1, AS2, AS3}, {(exactlyOneOf)
> TID=258: AS4, AS5}}

Just a note: This is a good use-case where the IE representation
proposed in the IE doctors draft would be useful :) I think I would have
less problems to understand your example.

Regards,

Gerhard

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 12 Oct 2010 12:10:07 -0400

Hi Gerhard,
with regards to the below, yes I gathered the context of the Data Record has to be known in advance (or rather, the ipfix-reader needs to generally know what's going on), but that wasn't my point.  

Let's assume all the exporters in a given deployment are purely flow information exporters, reporting on IP flows.  But it's a mix of vendors.  Vendor X reports multicast information as shown/described in the current structured-draft, using a basicList of egressInterface.  Vendor Y reports that the flow is egressing an ATM IMA bundle, by using a basicList of egressInterface.  Vendor Z reports that the flow is being mirrored on one or more span ports, by using a basicList of egressInterface.  To the collector, all the reports look the same.

I think the rationale for this is that the structured data is not changing or adding to the meaning of the individual IEs within the structure - it's not making a new data type out of the collection of IEs within it.  In other words, the draft should NOT describe a basicList of egressInterface as "multicast" info, because it's not "multicast" - it's just a list of egressInterface.  No additional information is conveyed beyond that.  On the other hand, if we go create a new IE named "multicastEgressList" of type basicList, then that conveys it.

I know that sounds kinda nit-picky, but when I read the draft I really got the impression I could create/report new info by using the generic structured data.

-hadriel

---

From: Benoit Claise <[email-masked]>
Date: Tue, 26 Oct 2010 14:08:31 +0200

Hadriel,

Let me come back to this one, now that the IETF deadlines are over.
> We want to make it extensible, by letting vendors export additional info in the record.  We could do that with vendor-specific PENs (and undoubtedly people will), but I was going to submit a draft…
make sense.
> Some SIP header types can appear multiple times, some cannot.  So having a basicList for the ones that can solves that.
make sense.
> Essentially, what this calls for is the ability to take *generic* data types, such as URI or paramValue (both of which are based on string), and build upon them to form more complex (and unique) da…
Initially, the structured data was not meant to accomplish this: it was 
simply to give some semantic about the existing IEs
However, there is nothing that prevents us to do for the coming for new, 
more complex IE definitions.
Even with a few new abstract complex data types such "sipGenericHeader", 
we would still need the definition of the 106 header fields, as we don't 
want to export a opaque field.
> In other words, you can't record an ACL list as just a basicList of sourceIPv4Address, because "sourceIPv4Address" has the meaning of being the source IPv4 address of the flow's actual *packet*, no…
Yes.

Regards, Benoit.