Subject: Re: [IPFIX] Semantic and structured data

From: Benoit Claise <[email-masked]>
Date: Mon, 15 Mar 2010 14:18:54 +0100

Dear all,

We've been thinking about this one, and we see 3 solutions. We believe 
that the solution 3 is the way to go, as we show below.

_Solution 1. _
Consider that the semantic is out of scope for this document.
This is the easiest solution.  However, we understand it's not right: we 
would not do a complete job wrt to IPFIX structured data
As Gerhard was expressing, the collector has not clue how to treat the 
example of a BasicList of egress interfaces in a Flow Record.
     - Has every counted packet been sent on every egress interface?
       => multicast case, AND semantic
     - Has every counted packet been sent on any one of the egress 
interfaces?
      => load balancing case, OR semantic

_Soltution 2_
We could focus on the logical AND and OR semantics only , by defining 
semantic lists, such as andBasicList, andSubTemplateList, 
andSubTemplateMultiList, orBasicList, orSubTemplateList, and 
orSubTemplateMultiList
So 6 I.E.s in total, describing AND and OR semantics.
While it's solved the router and most mediation function needs today, we 
understand that this is not a complete solution.
Gerhard, in one of his old draft, draft-sommer-ipfix-mediator-ext-01, 
proposed ADTs for orderedList, orderedPair, and portRanges which allow 
the definition new IEs for port ranges etc.
Even if this solution 2 is extensible, in the long term, will lead to an 
explosion of IEs: 3 list types * the semantic type, where the semantic 
can be (and, or, orderedList, orderedPair, portRanges, random, etc...)

_Soltution 3
_We propose to add a semantic field in the 3 list types.
Something such as:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|               Field ID    |       Element Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Semantic  |             BasicList Content ...                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ...                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This semantic field would be a new IANA registry, we could be populated 
initially with NONE, OR, AND, ORDERED, etc... Up to discussion.
The advantage of this solution is that it's extensible, and it doesn't 
need new IEs for each semantic.
If ever required (mainly in a mediation function), we can model  very 
complex semantic, eg, "(eth1 OR eth2) AND (NOT (eth3 OR eth4)) OR 
linecard2", which could be the new observation point from a aggregated 
Flow Record

_Conclusion:_
After much debate internally, we believe that we should do the effort to 
include this semantic now, and not postpone the problem, which will lead 
to an explosion of IEs in the future.
Personally, I was initially against the solution 3 ... mostly due to the 
effort required to modify the complete specs.
We're now ready to modify the specifications in the IPFIX structured 
data, but we would like to get your feedback and agreement in advance as 
this is not a small piece of work.

Please comment.

Regards, Paul, Stan, Gowri, and Benoit.
> hi Benoit, Gerhard,
>
> In this case I'm strongly in favor of leaving semantics out of 
> structured data. Structured data defines containers. The semantics of 
> the containers as a whole and the elements change based upon the 
> information elements within the container and within the record 
> containing it. Wedging semantics into the structured data elements 1. 
> risks further proliferation of (potentially non-interoperable) ways to 
> represent the same thing, 2. gives us more ways to represent 
> nonsensical things (an OR basicList of MPLS stack 
> entries...means...what?), and 3. risks defining an inadequate semantic 
> representation mechanism (what about semantics for records not using 
> structured data? what about ordered versus unordered sets? what about 
> OR basicList vs AND basicList vs nested AND and OR basicLists vs just 
> three identical IEs?). If we really want an unambiguous semantic 
> framework for IPFIX (and here I'm not convinced either way) that's 
> best done on its own, addressing things at the information element and 
> record level. Doing it here confuses the issue.
>
> Regards,
>
> Brian
>
> On Nov 10, 2009, at 6:26 AM, Benoit Claise wrote:
>
>> Gerhard,
>>
>> Thanks for your email.
>> I have no strong feelings about the two solutions you proposed.
>>
>> From a pure router point of view,  I don't see any use cases for 
>> logical OR in exporting flow records.
>> However, from a IPFIX Mediator point of view, I see some use cases.
>> I mean that it requires an Intermediate Aggregation Process or 
>> Intermediate Correlation Process to express: I've seen this flow 
>> record OR that flow record.
>> Now, it's true that even routers will have mediation functions...
>>
>> I'm inclined to add orBasicList, orSubTemplateList, 
>> orSubTempalteMultiList to the draft (This is a small addition after 
>> all) and to express that, by default, a logical AND is assumed... 
>> specifically if the structured data is used in the IPFIX Mediation 
>> Protocol.
>>
>> I'm not convinced by the NOT in the context of structured data, as we 
>> don't even have a concept of NOT for a single information element!
>>
>> I would like to get some more feedback from others.
>>
>> Regards, Benoit.
>>
>>> Dear all,
>>>
>>> Regarding draft-ietf-ipfix-structured-data, I see the risk that the
>>> semantic of the exported structured data is not clear.
>>>
>>> How do you interpret the manifold occurrence of the same Information
>>> Element (basicList) or the same group of Information Elements
>>> (subTemplateList) in one record?
>>>
>>> What does it mean if basicList, subTemplateList, or 
>>> subTemplateMultiList
>>> is used for a Flow Key field? Or non-key field?
>>>
>>> Some Examples:
>>>
>>> - BasicList of egress interfaces in a Flow Record
>>>  How should a Flow Record be interpreted which contains a list of
>>>  egress interfaces and a packet counter?
>>>  Has every counted packet been sent on every egress interface?
>>>    => multicast case, AND semantic (see example in section 8.1)
>>>  Has every counted packet been sent on any one of the egress
>>>  interfaces?
>>>    => load balancing case, OR semantic
>>>  Can it be used as a Flow Key or not?
>>>
>>> - BasicList of destination ports in a Flow Record
>>>  As every packet has only one destination port, the only reasonable
>>>  interpretation is that the Flow contains packets having one of
>>>  the reported port numbers.
>>>    => OR semantic
>>>  This would be a non-key field.
>>>
>>>
>>> I think there are two solutions:
>>>
>>> 1. We decide that the semantic of list content is out of scope of
>>>   draft-ietf-ipfix-structured-data. We add a note to the draft that
>>>   the semantic must be clear from the context or the definition of the
>>>   Information Elements used within the lists.
>>>
>>> 2. We define semantic lists, such as
>>>   - andBasicList, andSubTemplateList, andSubTemplateMultiList
>>>   - orBasicList, orSubTemplateList, orSubTempalteMultiList
>>>   describing AND and OR semantic of the contained IEs/Templates,
>>>   respectively.
>>>
>>>
>>> As I wrote in an earlier mail, I see a good use case for 
>>> orBasicList. It
>>> could be used in the Selector Report Interpretation of Property Match
>>> Filtering to report a filter like "port 80 or port 443".
>>> http://www.ietf.org/mail-archive/web/ipfix/current/msg04856.html
>>> At the moment, the Selector Report Interpretation is limited to AND.
>>> However, if we also want to express a NOT, we still need another 
>>> solution...
>>>
>>> Regards,
>>> Gerhard
>>>
>>> _______________________________________________
>>> IPFIX mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Mon, 15 Mar 2010 11:01:28 -0700

hi, Benoit, all...

Agreed that we should do something about this (i.e., that solution 1 is no solution.); that said, a few comments in no particular order:

1. In considering adding explicit semantics to structured data, we as a WG are taking on the task of defining semantics for IPFIX as a whole. Semantics, as I understand them, are in IPFIX largely contextual and template dependent, but in almost all cases I can think of it seems like these are implicitly "AND" semnantics (this flow has source IP A _AND_ destination IP B _AND_...). We will need to make an explicit statement on this. We will need to determine whether these implicit semantics are a property of the protocol (in which case Structured Data is really a protocol-level extension), or a property of each information element (in which case all 5103 IEs have implicit AND semantics; question 2: will we need to add semantics to the IANA registry in this case?). We will need to be quite careful about this. It's not as simple as defining semantics within structured data then calling it done.

2. I don't consider draft-sommer-ipfix-mediator-ext-01 a valid argument against Solution 2, as it's trying to solve a somewhat different and more limited problem than structured data. Solution 2 _might_ cause a problem for this draft, but certainly not the other way around (unless we as a WG want to subsume that work into this draft, which would probably require rechartering...). Also, I don't think we need semantics for all of the list types, just basicList (Illustrative question: How do I meaningfully interpret two "or" subTemplateMultiLists with disjoint IE sets? Two "and" subTemplateMultiLists? Nestings thereof?)... So, we don't really have an explosion to deal with if we do Solution 2 correctly: andBasicList, orBasicList, xorBasicList, notBasicList; Four IEs, nestable, done. What can't we do with those four IEs? In this case, we could even step back and say that semantics outside these four are within the protocol explicitly _undefined_, and to be interpreted within the context of each Template.

3. If we really _do_ want ranges and so on (which, again, we'd need to get WG consensus on; this is explicitly out of scope in my reading of the present charter), then we could do them in the scope of Solution 3. However, this seems a little not-quite-fleshed-out-enough for me to say whether I like it or not. Could you present an example of how you would use the proposed Semantic field to model your example? "(eth1 OR eth2) AND (NOT (eth3 OR eth4)) OR linecard2"

(FWIW, I would do this with my proposal to Solution 2 as follows:)

(orBasicList (andBasicList (orBasicList ingressInterface eth1 eth2) (notBasicList (orBasicList ingressInterface eth3 eth4)) (andBasicList lineCardID 2))

Best regards,

Brian

On Mar 15, 2010, at 6:18 AM, Benoit Claise wrote:

> Dear all,
> 
> We've been thinking about this one, and we see 3 solutions. We believe that the solution 3 is the way to go, as we show below.
> 
> Solution 1. 
> This is the easiest solution.  However, we understand it's not right: we would not do a complete job wrt to IPFIX structured data
> As Gerhard was expressing, the collector has not clue how to treat the example of a BasicList of egress interfaces in a Flow Record. 
>     - Has every counted packet been sent on any one of the egress interfaces?
> Soltution 2
> We could focus on the logical AND and OR semantics only , by defining semantic lists, such as andBasicList, andSubTemplateList, andSubTemplateMultiList, orBasicList, orSubTemplateList, and orSubTemplateMultiList
> While it's solved the router and most mediation function needs today, we understand that this is not a complete solution.
> Gerhard, in one of his old draft, draft-sommer-ipfix-mediator-ext-01, proposed ADTs for orderedList, orderedPair, and portRanges which allow the definition new IEs for port ranges etc.
> Even if this solution 2 is extensible, in the long term, will lead to an explosion of IEs: 3 list types * the semantic type, where the semantic can be (and, or, orderedList, orderedPair, portRanges, random, etc...)
> 
> Soltution 3
> We propose to add a semantic field in the 3 list types.
> Something such as:
> 
> This semantic field would be a new IANA registry, we could be populated initially with NONE, OR, AND, ORDERED, etc... Up to discussion.
> The advantage of this solution is that it's extensible, and it doesn't need new IEs for each semantic.
> If ever required (mainly in a mediation function), we can model  very complex semantic, eg, "(eth1 OR eth2) AND (NOT (eth3 OR eth4)) OR linecard2", which could be the new observation point from a aggregated Flow Record
> 
> 
> 
> Conclusion:
> After much debate internally, we believe that we should do the effort to include this semantic now, and not postpone the problem, which will lead to an explosion of IEs in the future.
> Personally, I was initially against the solution 3 ... mostly due to the effort required to modify the complete specs.  
> We're now ready to modify the specifications in the IPFIX structured data, but we would like to get your feedback and agreement in advance as this is not a small piece of work.
> 
> Please comment.
> 
>> In this case I'm strongly in favor of leaving semantics out of structured data. Structured data defines containers. The semantics of the containers as a whole and the elements change based upon the information elements within the container and within the record containing it. Wedging semantics into the structured data elements 1. risks further proliferation of (potentially non-interoperable) ways to represent the same thing, 2. gives us more ways to represent nonsensical things (an OR basicList of MPLS stack entries...means...what?), and 3. risks defining an inadequate semantic representation mechanism (what about semantics for records not using structured data? what about ordered versus unordered sets? what about OR basicList vs AND basicList vs nested AND and OR basicLists vs just three identical IEs?). If we really want an unambiguous semantic framework for IPFIX (and here I'm not convinced either way) that's best done on its own, addressing things at the information element and record level. Doing it here confuses the issue. 
>> 
>> Regards, 
>> 
>> Brian 
>> 
>>> >From a pure router point of view,  I don't see any use cases for logical OR in exporting flow records. 
>>> I mean that it requires an Intermediate Aggregation Process or Intermediate Correlation Process to express: I've seen this flow record OR that flow record. 
>>> I'm inclined to add orBasicList, orSubTemplateList, orSubTempalteMultiList to the draft (This is a small addition after all) and to express that, by default, a logical AND is assumed... specifically if the structured data is used in the IPFIX Mediation Protocol. 
>>> 
>>> I'm not convinced by the NOT in the context of structured data, as we don't even have a concept of NOT for a single information element! 
>>> 
>>>> What does it mean if basicList, subTemplateList, or subTemplateMultiList 
>>>> As I wrote in an earlier mail, I see a good use case for orBasicList. It 
>>>> However, if we also want to express a NOT, we still need another solution... 
>>>> 
>>>> Regards, 
>>>> Gerhard 
>>>>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 16 Mar 2010 10:40:30 +0100

Hi Brian,

Thanks for your feedback.
> 1. In considering adding explicit semantics to structured data, we as a WG are taking on the task of defining semantics for IPFIX as a whole. Semantics, as I understand them, are in IPFIX largely contextual and template dependent, but in almost all cases I can think of it seems like these are implicitly "AND" semnantics (this flow has source IP A _AND_ destination IP B _AND_...).
Agreed.
> We will need to make an explicit statement on this.
Not sure why.
> We will need to determine whether these implicit semantics are a property of the protocol (in which case Structured Data is really a protocol-level extension), or a property of each information element (in which case all 5103 IEs have implicit AND semantics; question 2: will we need to add semantics to the IANA registry in this case?). We will need to be quite careful about this. It's not as simple as defining semantics within structured data then calling it done.
>    
I'm not sure why each individual IE should have a semantic ... in the 
IANA registry.
As you wrote, "in almost all cases I can think of it seems like these 
are implicitly "AND" semnantics", so the case we try to solve is when 
there are multiple instances of a single IE. We know that RFC 5101 
foresaw that case " The Collector MUST support the use of Templates 
containing multiple occurrences of the similar Information Elements", 
but the idea is not to change RFC5101.  If we put some semantic in the 
IPFIX structured data, that would solve the vast majority of our cases. 
Also, we could say: if you want some semantic when exporting multiple 
IEs, then you SHOULD use IPFIX structured data.

Also, the default value for the semantic field in the IPFIX structured 
data SHOULD be "NONE", to express that flow record doesn't include any 
semantic.... like in RFC5101. You might draw your own conclusion, maybe 
because you know your network, maybe because you have configured the 
exporter, but then it's your decision.
The way I see the proposed solution is: in IPFIX structured data, you 
MAY use the semantic field as a way to express the relationship between 
IEs within the structure.
> 2. I don't consider draft-sommer-ipfix-mediator-ext-01 a valid argument against Solution 2, as it's trying to solve a somewhat different and more limited problem than structured data. Solution 2 _m…
If I translate some more what I wrote "While it's solved the router and 
most mediation function needs today", this would be "Me, myself, and I 
don't need more that OR and AND _now _;-)".
However, who am I to tell that others don't need it now... and that the 
logical solution is to use the IPFIX structured data
Furthermore, if we think a little bit longer term, the next big step in 
IPFIX is the mediation function. In my company, every features want to 
export his own data with NetFlow/IPFIX... up to the point where a CPE 
would not have enough bandwidth across the WAN to export all the 
"management" information. So we'll need more and more of aggregated flow 
records (both in time and space) even in the router. Again, the logical 
solution will be to use the IPFIX structured data. At this point, we 
will most probably need something else than OR and AND, i.e. RANGE, 
ORDERRED, etc...

An example of subTemplateMultiLists with disjoint IE sets, let's imagine 
that you have to export an aggregated observation point, composed of 
multiple template records
     template 1: exporterIPaddress
     template 2: exporterIPaddress, basicList of interfaces
     template 3: exporterIPaddress, LC

> 3. If we really _do_ want ranges and so on (which, again, we'd need to get WG consensus on; this is explicitly out of scope in my reading of the present charter), then we could do them in the scope of Solution 3.
Btw, acknowledging that one day we will have to solve this is good 
enough for solution 3. I mean, we don't have to populate the semantic 
IANA now... even if that would be more efficient.
> However, this seems a little not-quite-fleshed-out-enough for me to say whether I like it or not. Could you present an example of how you would use the proposed Semantic field to model your example? "(eth1 OR eth2) AND (NOT (eth3 OR eth4)) OR linecard2"
>
(BasicList, OR, (basicList, AND, (basicList, OR, eth1, eth2), (basicList, NOR, eth3, eth4)), (basicList, NONE, linecard2)))

Thanks for your valuable feedback, as always.

Regards, Benoit.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 16 Mar 2010 09:48:28 -0700

Hi, Benoit,

Replies inline...

On Mar 16, 2010, at 2:40 AM, Benoit Claise wrote:

> I'm not sure why each individual IE should have a semantic ... in the IANA registry.

I'm not either. On reflection it seems like overkill. I'm just saying that if we, as a WG, are moving from stating that semantics are explicitly out of scope to defining them as in-scope, we need to have a consistent approach, and answers to all the questions that arise when we consider moving the protocol from a simple framing mechanism to a framing mechanism with some logic behind it, so we answer them once, so that all future efforts having to do with semantics are consistent. This, I acknowledge, is an argument in favor of solution 3...)

One very simple new question that arises here, to illustrate my point: Is it legal to export a record that has sourceIPAddress X AND NOT sourceIPAddress X? 

> As you wrote, "in almost all cases I can think of it seems like these are implicitly "AND" semnantics", so the case we try to solve is when there are multiple instances of a single IE. We know that RFC 5101 foresaw that case " The Collector MUST support the use of Templates containing multiple occurrences of the similar Information Elements", but the idea is not to change RFC5101.  If we put some semantic in the IPFIX structured data, that would solve the vast majority of our cases. Also, we could say: if you want some semantic when exporting multiple IEs, then you SHOULD use IPFIX structured data.
> 
> Also, the default value for the semantic field in the IPFIX structured data SHOULD be "NONE", to express that flow record doesn't include any semantic.... like in RFC5101. You might draw your own conclusion, maybe because you know your network, maybe because you have configured the exporter, but then it's your decision. 
> The way I see the proposed solution is: in IPFIX structured data, you MAY use the semantic field as a way to express the relationship between IEs within the structure. 
> If I translate some more what I wrote "While it's solved the router and most mediation function needs today", this would be "Me, myself, and I don't need more that OR and AND now ;-)".
> However, who am I to tell that others don't need it now... and that the logical solution is to use the IPFIX structured data
> Furthermore, if we think a little bit longer term, the next big step in IPFIX is the mediation function. In my company, every features want to export his own data with NetFlow/IPFIX... up to the point where a CPE would not have enough bandwidth across the WAN to export all the "management" information. So we'll need more and more of aggregated flow records (both in time and space) even in the router. Again, the logical solution will be to use the IPFIX structured data. At this point, we will most probably need something else than OR and AND, i.e. RANGE, ORDERRED, etc...
> 
> An example of subTemplateMultiLists with disjoint IE sets, let's imagine that you have to export an aggregated observation point, composed of multiple template records

and then you'd want to OR these... Okay, makes sense...

> Btw, acknowledging that one day we will have to solve this is good enough for solution 3. I mean, we don't have to populate the semantic IANA now... even if that would be more efficient.

Hm. Okay. This makes sense. A couple of questions then, about solution 3:

1. Would we want to try and bitfield this, to define the semantics we _know_ we have, then leave the rest of it reserved? Something like:

MSb                      LSb
+---+------+---------------+
| ! | multi| reserved      |
+---+------+---------------+

! = negate sense of semantics if 1 (this is the NOT flag)
multi (multiplicity) = 00: undefined, 01: or/oneOrMore, 10: xor/exactlyOne, 11: and/exactlyAll
reserved = place for adding other bells and whistles like RANGE and so on in the future.

2. Are we sure we want to do this in one byte? If we do bitfielding as above this gives us 32 possible extensions, which seems like _way_ more than enough, but does stick another odd offset in there, which slows things down on machines that need aligned access. Probably one byte is okay and we let the implementation use paddingOctets and set padding to fix this...

3. Would it make sense maybe to have two sets of structured data elements, one with the semantics byte, and one without (which is then explicitly undefined)? Then exporters who don't need it don't have to bother sticking an extra odd-aligned zero in the stream for every list.

I'm sure I'l have more questions, but none come to mind now... But it seems like we're converging on the least-unnecessarily-complex solution here, which is good. :)

Best regards,

Brian

>>>> In this case I'm strongly in favor of leaving semantics out of structured data. Structured data defines containers. The semantics of the containers as a whole and the elements change based upon the information elements within the container and within the record containing it. Wedging semantics into the structured data elements 1. risks further proliferation of (potentially non-interoperable) ways to represent the same thing, 2. gives us more ways to represent nonsensical things (an OR basicList of MPLS stack entries...means...what?), and 3. risks defining an inadequate semantic representation mechanism (what about semantics for records not using structured data? what about ordered versus unordered sets? what about OR basicList vs AND basicList vs nested AND and OR basicLists vs just three identical IEs?). If we really want an unambiguous semantic framework for IPFIX (and here I'm not convinced either way) that's best done on its own, addressing things at the information elem
>>>> ent and record level. Doing it here confuses the issue. 
>>>> 
>>>> Regards, 
>>>> 
>>>> Brian 
>>>>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Mar 2010 12:52:13 +0100

Hi Brian,
> One very simple new question that arises here, to illustrate my point: Is it legal to export a record that has sourceIPAddress X AND NOT sourceIPAddress X?
 From a protocol point of view, yes
 From a semantic point of view, I don't see a use case for that.
Now, this question is not different that: with RFC5101,  is it legal to 
export a record that has two instances of sourceIPAddress?
> 1. Would we want to try and bitfield this, to define the semantics we _know_ we have, then leave the rest of it reserved? Something like:
Maybe we want to start by asking the question: which semantic do we need 
now?
Is a need for NONE, OR, AND, ORDERED for now. Anything else?
> 2. Are we sure we want to do this in one byte? If we do bitfielding as above this gives us 32 possible extensions, which seems like _way_ more than enough, but does stick another odd offset in ther…
With structured data, is the alignment still important? When I look at 
the examples throughout the draft... As you wrote, paddingOctets might 
be the solution in this case.
> I'm sure I'l have more questions, but none come to mind now... But it seems like we're converging on the least-unnecessarily-complex solution here, which is good. :)
Happy about that. ;-)
Note: I was envisioning even something more simpler: one byte, 
containing all the semantic possibilities, administered by IANA.  So no 
reserved, no !

Regards, Benoit.

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 17 Mar 2010 13:56:23 +0100

Hi all,

Some general thoughts from my side:

- I appreciate that you want to add a basic notion of semantic to the
   structured data.

- Up to now, semantic was not in the protocol but in the info model.

   Can't we encode Semantic in an IE?
   Then, we could do without a new IANA registry.
   And: This IE could be used for other purposes (e.g., in Templates)

- I'm not sure whether the bitvector encoding has an advantage over an
   enumeration type.

Unfortunately, I do not have the time to participate in a deep 
discussion - I'm busy with IPFIX-CONFIG and other stuff.

Regards,
Gerhard

Benoit Claise wrote:
>>>> 2. I don't consider draft-sommer-ipfix-mediator-ext-01 a valid argument against Solution 2, as it's trying to solve a somewhat different and more limited problem than structured data. Solution 2 _might_ cause a problem for this draft, but certainly not the other way around (unless we as a WG want to subsume that work into this draft, which would probably require rechartering...). Also, I don't think we need semantics for all of the list types, just basicList (Illustrative question: How do I meaningfully interpret two "or" subTemplateMultiLists with disjoint IE sets? Two "and" subTemplateMultiLists? Nestings thereof?)... So, we don't really have an explosion to deal with if we do Solution 2 correctly: andBasicList, orBasicList, xorBasicList, notBasicList; Four IEs, nestable, done. What can't we do with those four IEs? In this case, we could even step back and say that semantics outside these four are within the protocol explicitly _undefined_, and to be interpreted withi
n the
>>>>   context of each Template.
>>>>
>>>>
>>>>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Mar 2010 14:10:35 +0100

Thanks Gerhard for your feedback.
See inline.
> - I appreciate that you want to add a basic notion of semantic to the
Great.
> - Up to now, semantic was not in the protocol but in the info model.
We thought about this one. However, one of the IPFIX principle is that 
the semantic of one IE can't depend on the value or position of some 
other IEs.
One example of this is the (MPLS label position, MPLS label). Way before 
structured data, our initial implementation contained: MPLS label 
position, MPLS label.
So the collector had to look first at the MPLS label position value in 
order to correctly understand the following  MPLS label.
Somehow, with these conventions, we were having an information model on 
the top of the IE. This was wrong.
Also it was not obvious for a collector, i.e. without hardcoding the 
information.
Finally, what if the IE order changed within the flow record?
Conclusion: we had to change back our implementation mplslabelposition1, 
mplslabelposition2, etc... Like we did in IPIFX ;-)

> discussion - I'm busy with IPFIX-CONFIG and other stuff.
Thanks and regards, Benoit.
>>>>> Agreed that we should do something about this (i.e., that solution 
>>>>> 1 is no solution.); that said, a few comments in no particular order:
>>>>>
>>>>> 1. In considering adding explicit semantics to structured data, we 
>>>>> as a WG are taking on the task of defining semantics for IPFIX as 
>>>>> a whole. Semantics, as I understand them, are in IPFIX largely 
>>>>> contextual and template dependent, but in almost all cases I can 
>>>>> think of it seems like these are implicitly "AND" semnantics (this 
>>>>> flow has source IP A _AND_ destination IP B _AND_...).
>>>>>
>>>> Agreed.
>>>>> We will need to determine whether these implicit semantics are a 
>>>>> property of the protocol (in which case Structured Data is really 
>>>>> a protocol-level extension), or a property of each information 
>>>>> element (in which case all 5103 IEs have implicit AND semantics; 
>>>>> question 2: will we need to add semantics to the IANA registry in 
>>>>> this case?). We will need to be quite careful about this. It's not 
>>>>> as simple as defining semantics within structured data then 
>>>>> calling it done.
>>>>>
>>>>>
>>> I'm not either. On reflection it seems like overkill. I'm just 
>>> saying that if we, as a WG, are moving from stating that semantics 
>>> are explicitly out of scope to defining them as in-scope, we need to 
>>> have a consistent approach, and answers to all the questions that 
>>> arise when we consider moving the protocol from a simple framing 
>>> mechanism to a framing mechanism with some logic behind it, so we 
>>> answer them once, so that all future efforts having to do with 
>>> semantics are consistent. This, I acknowledge, is an argument in 
>>> favor of solution 3...)
>>>
>>> One very simple new question that arises here, to illustrate my 
>>> point: Is it legal to export a record that has sourceIPAddress X AND 
>>> NOT sourceIPAddress X?
>> Now, this question is not different that: with RFC5101,  is it legal 
>> to export a record that has two instances of sourceIPAddress?
>>>> As you wrote, "in almost all cases I can think of it seems like 
>>>> these are implicitly "AND" semnantics", so the case we try to solve 
>>>> is when there are multiple instances of a single IE. We know that 
>>>> RFC 5101 foresaw that case " The Collector MUST support the use of 
>>>> Templates containing multiple occurrences of the similar 
>>>> Information Elements", but the idea is not to change RFC5101.  If 
>>>> we put some semantic in the IPFIX structured data, that would solve 
>>>> the vast majority of our cases. Also, we could say: if you want 
>>>> some semantic when exporting multiple IEs, then you SHOULD use 
>>>> IPFIX structured data.
>>>>
>>>> Also, the default value for the semantic field in the IPFIX 
>>>> structured data SHOULD be "NONE", to express that flow record 
>>>> doesn't include any semantic.... like in RFC5101. You might draw 
>>>> your own conclusion, maybe because you know your network, maybe 
>>>> because you have configured the exporter, but then it's your decision.
>>>> The way I see the proposed solution is: in IPFIX structured data, 
>>>> you MAY use the semantic field as a way to express the relationship 
>>>> between IEs within the structure.
>>>>> 2. I don't consider draft-sommer-ipfix-mediator-ext-01 a valid 
>>>>> argument against Solution 2, as it's trying to solve a somewhat 
>>>>> different and more limited problem than structured data. Solution 
>>>>> 2 _might_ cause a problem for this draft, but certainly not the 
>>>>> other way around (unless we as a WG want to subsume that work into 
>>>>> this draft, which would probably require rechartering...). Also, I 
>>>>> don't think we need semantics for all of the list types, just 
>>>>> basicList (Illustrative question: How do I meaningfully interpret 
>>>>> two "or" subTemplateMultiLists with disjoint IE sets? Two "and" 
>>>>> subTemplateMultiLists? Nestings thereof?)... So, we don't really 
>>>>> have an explosion to deal with if we do Solution 2 correctly: 
>>>>> andBasicList, orBasicList, xorBasicList, notBasicList; Four IEs, 
>>>>> nestable, done. What can't we do with those four IEs? In this 
>>>>> case, we could even step back and say that semantics outside these 
>>>>> four are within the protocol explicitly _undefined_, and to be 
>>>>> interpreted withi
> n the
>>>> If I translate some more what I wrote "While it's solved the router 
>>>> and most mediation function needs today", this would be "Me, 
>>>> myself, and I don't need more that OR and AND now ;-)".
>>>> However, who am I to tell that others don't need it now... and that 
>>>> the logical solution is to use the IPFIX structured data
>>>> Furthermore, if we think a little bit longer term, the next big 
>>>> step in IPFIX is the mediation function. In my company, every 
>>>> features want to export his own data with NetFlow/IPFIX... up to 
>>>> the point where a CPE would not have enough bandwidth across the 
>>>> WAN to export all the "management" information. So we'll need more 
>>>> and more of aggregated flow records (both in time and space) even 
>>>> in the router. Again, the logical solution will be to use the IPFIX 
>>>> structured data. At this point, we will most probably need 
>>>> something else than OR and AND, i.e. RANGE, ORDERRED, etc...
>>>>
>>>> An example of subTemplateMultiLists with disjoint IE sets, let's 
>>>> imagine that you have to export an aggregated observation point, 
>>>> composed of multiple template records
>>>>> 3. If we really _do_ want ranges and so on (which, again, we'd 
>>>>> need to get WG consensus on; this is explicitly out of scope in my 
>>>>> reading of the present charter), then we could do them in the 
>>>>> scope of Solution 3.
>>>> enough for solution 3. I mean, we don't have to populate the 
>>>> semantic IANA now... even if that would be more efficient.
>>>>> However, this seems a little not-quite-fleshed-out-enough for me 
>>>>> to say whether I like it or not. Could you present an example of 
>>>>> how you would use the proposed Semantic field to model your 
>>>>> example? "(eth1 OR eth2) AND (NOT (eth3 OR eth4)) OR linecard2"
>>>>>
>>>>> (orBasicList (andBasicList (orBasicList ingressInterface eth1 
>>>>> eth2) (notBasicList (orBasicList ingressInterface eth3 eth4)) 
>>>>> (andBasicList lineCardID 2))
>>>>>
>>>>>
>>>> (BasicList, OR, (basicList, AND, (basicList, OR, eth1, eth2), 
>>>> (basicList, NOR, eth3, eth4)), (basicList, NONE, linecard2)))
>>> 1. Would we want to try and bitfield this, to define the semantics 
>>> we _know_ we have, then leave the rest of it reserved? Something like:
>>>
>>> MSb                      LSb
>> Maybe we want to start by asking the question: which semantic do we 
>> need now?
>>> 2. Are we sure we want to do this in one byte? If we do bitfielding 
>>> as above this gives us 32 possible extensions, which seems like 
>>> _way_ more than enough, but does stick another odd offset in there, 
>>> which slows things down on machines that need aligned access. 
>>> Probably one byte is okay and we let the implementation use 
>>> paddingOctets and set padding to fix this...
>> With structured data, is the alignment still important? When I look 
>> at the examples throughout the draft... As you wrote, paddingOctets 
>> might be the solution in this case.
>>> 3. Would it make sense maybe to have two sets of structured data 
>>> elements, one with the semantics byte, and one without (which is 
>>> then explicitly undefined)? Then exporters who don't need it don't 
>>> have to bother sticking an extra odd-aligned zero in the stream for 
>>> every list.
>>>
>>> I'm sure I'l have more questions, but none come to mind now... But 
>>> it seems like we're converging on the least-unnecessarily-complex 
>>> solution here, which is good. :)
>> Happy about that. ;-)
>> containing all the semantic possibilities, administered by IANA.  So 
>> no reserved, no !
>>
>> Regards, Benoit.
>

---

From: Paul Aitken <[email-masked]>
Date: Wed, 17 Mar 2010 13:19:32 +0000

Gerhard,

> - Up to now, semantic was not in the protocol but in the info model.

We'd still need a (sub)registry to allow the IE to be extensible.
eg, see the "MPLS label type" registry.

>   And: This IE could be used for other purposes (e.g., in Templates)

How do you see that being used?

> - I'm not sure whether the bitvector encoding has an advantage over an

A bitvector would allow multiple semantics where most combinations would 
not be useful. eg, "AND OR". Only "NOT" + "second semantic" seems useful.

> discussion - I'm busy with IPFIX-CONFIG and other stuff.

Thanks for taking the time.

P.

>>>>> as a WG are taking on the task of defining semantics for IPFIX as a 
>>>>> whole. Semantics, as I understand them, are in IPFIX largely 
>>>>> property of the protocol (in which case Structured Data is really a 
>>>>> protocol-level extension), or a property of each information 
>>>>> as simple as defining semantics within structured data then calling 
>>>>> it done.
>>>>>
>>>>>
>>>>>        
>>> I'm not either. On reflection it seems like overkill. I'm just saying 
>>> that if we, as a WG, are moving from stating that semantics are 
>>> explicitly out of scope to defining them as in-scope, we need to have 
>>> a consistent approach, and answers to all the questions that arise 
>>> when we consider moving the protocol from a simple framing mechanism 
>>> to a framing mechanism with some logic behind it, so we answer them 
>>> once, so that all future efforts having to do with semantics are 
>>> consistent. This, I acknowledge, is an argument in favor of solution 
>>> 3...)
>>>
>>>> Templates containing multiple occurrences of the similar Information 
>>>> Elements", but the idea is not to change RFC5101.  If we put some 
>>>> semantic in the IPFIX structured data, that would solve the vast 
>>>> majority of our cases. Also, we could say: if you want some semantic 
>>>> when exporting multiple IEs, then you SHOULD use IPFIX structured data.
>>>>
>>>>> different and more limited problem than structured data. Solution 2 
>>>>> _might_ cause a problem for this draft, but certainly not the other 
>>>>> way around (unless we as a WG want to subsume that work into this 
>>>>> draft, which would probably require rechartering...). Also, I don't 
>>>>> think we need semantics for all of the list types, just basicList 
>>>>> (Illustrative question: How do I meaningfully interpret two "or" 
>>>>> subTemplateMultiLists with disjoint IE sets? Two "and" 
>>>>> nestable, done. What can't we do with those four IEs? In this case, 
>>>>> we could even step back and say that semantics outside these four 
>>>>> are within the protocol explicitly _undefined_, and to be 
>>>>> interpreted withi
> n the
>>>> and most mediation function needs today", this would be "Me, myself, 
>>>> and I don't need more that OR and AND now ;-)".
>>>> Furthermore, if we think a little bit longer term, the next big step 
>>>> in IPFIX is the mediation function. In my company, every features 
>>>> want to export his own data with NetFlow/IPFIX... up to the point 
>>>> where a CPE would not have enough bandwidth across the WAN to export 
>>>> all the "management" information. So we'll need more and more of 
>>>> aggregated flow records (both in time and space) even in the router. 
>>>> Again, the logical solution will be to use the IPFIX structured 
>>>> data. At this point, we will most probably need something else than 
>>>> OR and AND, i.e. RANGE, ORDERRED, etc...
>>>>
>>>>> 3. If we really _do_ want ranges and so on (which, again, we'd need 
>>>>> to get WG consensus on; this is explicitly out of scope in my 
>>>>> reading of the present charter), then we could do them in the scope 
>>>>> of Solution 3.
>>>>>        
>>>>> However, this seems a little not-quite-fleshed-out-enough for me to 
>>>>> say whether I like it or not. Could you present an example of how 
>>>>> you would use the proposed Semantic field to model your example? 
>>>>> "(eth1 OR eth2) AND (NOT (eth3 OR eth4)) OR linecard2"
>>>>>
>>>>> (orBasicList (andBasicList (orBasicList ingressInterface eth1 eth2) 
>>>>> (notBasicList (orBasicList ingressInterface eth3 eth4)) 
>>> 1. Would we want to try and bitfield this, to define the semantics we 
>>> _know_ we have, then leave the rest of it reserved? Something like:
>>>
>>> MSb                      LSb
>>> as above this gives us 32 possible extensions, which seems like _way_ 
>>> more than enough, but does stick another odd offset in there, which 
>>> slows things down on machines that need aligned access. Probably one 
>>> byte is okay and we let the implementation use paddingOctets and set 
>>> padding to fix this...
>>>    
>>> elements, one with the semantics byte, and one without (which is then 
>>> explicitly undefined)? Then exporters who don't need it don't have to 
>>> bother sticking an extra odd-aligned zero in the stream for every list.
>>>
>>> I'm sure I'l have more questions, but none come to mind now... But it 
>>> seems like we're converging on the least-unnecessarily-complex 
> ------------------------------------------------------------------------
> 

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Brian Trammell <[email-masked]>
Date: Wed, 17 Mar 2010 07:44:03 -0700

Hi, Benoit,

As always... inline.

>>>> We will need to make an explicit statement on this.

Because if we're adding semantics to the protocol in any way (which we have so far left out of scope), anything we say in structured data (standards track) may be taken to apply to 5101 without structured data. So a statement that says "semantic interpretations of recieved Data Records at or beyond the CP remain explicitly undefined, unless that data is transmitted using this extension with explicit semantic information" (or something like it) reduces the scope for confusion. 

> Now, this question is not different that: with RFC5101,  is it legal to export a record that has two instances of sourceIPAddress?

Point. Okay, yes, it is legal. So in Structured Data we should have a statement as well that semantically meaningless combinations are legal, and up to the CP to interpret.

> Maybe we want to start by asking the question: which semantic do we need now?

What's ORDERED for? It seems like we're getting multiplicities confused with other things here... Is this an AND/allOf with additional stipulation that the ordering is important?

> With structured data, is the alignment still important? When I look at the examples throughout the draft... As you wrote, paddingOctets might be the solution in this case.
> Note: I was envisioning even something more simpler: one byte, containing all the semantic possibilities, administered by IANA.  So no reserved, no !

Okay, then... by "reserved" I meant, "future stuff (IANA) goes here"... but yes, that's more complicated than the rest of the subregistries for the protocol. So, agreed.

On reflection, I would suggest defining these in terms of multiplicities (as we're dealing with N-element lists) as opposed to logical operations. So I'd propose the following:

0x00: undefined (default) (CP may assume allOf)
0x01: allOf
0x02: oneOrMoreOf
0x03: exactlyOneOf
0x04: noneOf

If I understand what you mean by ORDERED, add:
0x05: allInOrder

If we really want to do ranges:
0x06: inclusiveRanges (MUST have even number of elements, and elements MUST be numeric; this is then equivalent to inclusive allOf [e_0,e_1], [e_2,e_3], ... , [e_n-1]..[e_n]); 

Still unanswered is whether we want to force all basicList/subTemplateList/subTemplateMultiList instances to state semantics, or whether we want "semanticless" versions as well...

Best regards,

Brian

---

From: Atsushi Kobayashi <[email-masked]>
Date: Thu, 18 Mar 2010 06:40:40 +0900

Hi Benoit, and all,

I agree solution3 rather than new semantic IE. 
As Benoit mentioned, semantic IE seems to increase the difficulty to
interpret them.

As Brian mentioned, I think it should avoid to have unnecessary
complexity. But, I am not sure what type, e.g., NONE, OR, AND, NOR,
RANGE, and ORDERRED, is needed. I would like to avoid that one data
structure is represented in multiple ways. To examine it, we needs more
practical examples in addition to: Selector Report
Interpretation and interface lists on aggregated Flow Records.

How about BGP AS Path, Community? Anything else?

When I have the following BGP AS Path mixing as-sequence and as-set, how
to present it?

10 20 30 40 {50,60}

(basicList, ORDERED, (basicList, ORDERED, AS10,AS20,AS30,AS40),
(basicList, OR, AS50, AS60))

Is it correct?

Regards,
Atsushi

On Wed, 17 Mar 2010 14:10:35 +0100

> >> containing all the semantic possibilities, administered by IANA.  So 

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: Benoit Claise <[email-masked]>
Date: Thu, 18 Mar 2010 09:31:00 +0100

> Because if we're adding semantics to the protocol in any way (which we have so far left out of scope), anything we say in structured data (standards track) may be taken to apply to 5101 without str…
Ok with the sentence.
I thought you wanted to add a sentence such as "RFC 5101 = implicit 
AND", which I would not agree with.
> Point. Okay, yes, it is legal. So in Structured Data we should have a statement as well that semantically meaningless combinations are legal, and up to the CP to interpret.
Right.
However, we should try to minimize this likelihood.
> What's ORDERED for? It seems like we're getting multiplicities confused with other things here... Is this an AND/allOf with additional stipulation that the ordering is important?
An example, as discussed by Kobayashi-san is the AS-PATH.
> 0x00: undefined (default) (CP may assume allOf)
This corresponds to NONE
> 0x01: allOf
This corresponds to AND
> 0x02: oneOrMoreOf
This corresponds to OR
> 0x03: exactlyOneOf
Not sure what it corresponds to. At first glance, I don't see a use case 
for it.
> 0x04: noneOf
This corresponds to NOT
> If I understand what you mean by ORDERED, add:
This corresponds to ORDERED
> 0x06: inclusiveRanges (MUST have even number of elements, and elements MUST be numeric; this is then equivalent to inclusive allOf [e_0,e_1], [e_2,e_3], ... , [e_n-1]..[e_n]);
This corresponds to RANGE

What is required? NONE, AND, OR, potentially NOT, ORDERED

> Still unanswered is whether we want to force all basicList/subTemplateList/subTemplateMultiList instances to state semantics, or whether we want "semanticless" versions as well...
No strong feeling about this one.
Maybe it would be better to have additional semanticBasicList, 
semanticSubTemplateList, semanticSubTemplateMultiList

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 18 Mar 2010 09:52:20 +0100

Kobayashi-san,
> structure is represented in multiple ways.
So do I.
 From this, I conclude that a simple enumeration type is better compared 
to the bitvector encoding.
If we include a bitvector with one bit for NOT, we end up in this situation.

    NOT OR = NOR
    NOT AND = NAND
    NOT ORDERED = UNORDERED (*)
    NOT UNORDERED = ORDERED (*)
    NOT NONE => doesn't make sense  (**)
    NOT RANGE => doesn't make sense  (**)
    NOT NOT => doesn't make sense  (**)

(*) implies that we can represent the same semantic different ways. Now, 
we can argue that we don't need UNORDERED
(**) add non possible and confusing semantics
> To examine it, we needs more
Exactly, which implies that the ORDER semantic is required for this use 
case.

Regards, Benoit.
> Benoit Claise<[email-masked]>  wrote:
>
>    
> Atsushi KOBAYASHI<[email-masked]>

---

From: Paul Aitken <[email-masked]>
Date: Thu, 18 Mar 2010 11:21:57 +0000

Benoit, Brian,

>> On reflection, I would suggest defining these in terms of 
>> multiplicities (as we're dealing with N-element lists) as opposed to 
>> logical operations. So I'd propose the following:

>> 0x03: exactlyOneOf
>    
> Not sure what it corresponds to. At first glance, I don't see a use case for it.

0x02 and 0x03 are two different kinds of OR: "at least one of" as 
opposed to "just one of".

> This corresponds to NOT

- which introduces the idea of NOT as a semantic in its own right, 
rather than simply as a modifier for other semantics.

However, "noneOf (x, y, z)" could be "NOT-AND (x, y, z)". Or possibly 
"NOT-OR (x, y, z)", though the distinction is subtle.

So NOT may still be considered as a modifier, rather than a distinct and 
separate semantic.

>> 0x06: inclusiveRanges (MUST have even number of elements, and elements 
>> MUST be numeric; this is then equivalent to inclusive allOf [e_0,e_1], 
>> [e_2,e_3], ... , [e_n-1]..[e_n]);
>    

And RANGE.

>> Still unanswered is whether we want to force all 
>> basicList/subTemplateList/subTemplateMultiList instances to state 
>> semantics, or whether we want "semanticless" versions as well...
>>    

Then there's no need for semantics = NONE.

I think it's more straightforward not to have "semanticless" versions.

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 18 Mar 2010 07:56:56 -0700

>>> 0x00: undefined (default) (CP may assume allOf)

Ahhh..... okay. This is confusing, though. I'd _definitely_ call this "undefined", because "none" could be interpreted as "not".

> 0x02 and 0x03 are two different kinds of OR: "at least one of" as opposed to "just one of".

With two elements in the list, it corresponds to XOR; exactlyOneOf is the multiplicity extension of this (which lends itself nicely to clarity for lists of more than two).

The use case is when you want to express uncertainty within a certain set: for example, say a mediator knows that a flow was observed on one of a set of interfaces at a MP on an original exporter (by virtue of having come from that exporter), but that the flow ONLY traversed one of them (say, because the exporter is only looking at ingress interfaces at the network border, and the routing configuration precludes balancing across those interfaces). With oneOrMoreOf ("OR"), the mediator cannot exclude the possibility it was seen on both. It's also one of the basic multiplicities {0, 1, 1..n, n}, so should be included for completeness in any case.

> 
>>> 0x04: noneOf
>> 
>> This corresponds to NOT
> 
> - which introduces the idea of NOT as a semantic in its own right, rather than simply as a modifier for other semantics.
> 
> However, "noneOf (x, y, z)" could be "NOT-AND (x, y, z)". Or possibly "NOT-OR (x, y, z)", though the distinction is subtle.
> 
> So NOT may still be considered as a modifier, rather than a distinct and separate semantic.

I think the argument for the flag goes away if you treat these as multiplicities. I'd treat the flag as a set negation: NOT AND = allOf (set) (negated) = noneOf: the represented value set can contain zero or more elements in the universe that do not appear in the list. 

Here, NOT OR = oneOrMoreOf (set) (negated) = notAllOf, meaning, the represented value set can contain zero or more elements in the universe but not in the list, as well as up to n-1 elements in the list, but not all n elements of the list; at least one (unspecified) value in the list must be absent from the set of represented values. It is not clear to me that this is useful...

NOT XOR = exactlyOneOf (set) (negated) seems even less useful.

>> What is required? NONE, AND, OR, potentially NOT, ORDERED

The case for this one's not clear to me. I see the use case, but I'm undecided on whether it's in scope for this draft...

>> Maybe it would be better to have additional semanticBasicList, semanticSubTemplateList, semanticSubTemplateMultiList
> 

arguments for "semanticless" versions: clean representation and no waste of a byte per list (okay, minor considering how big lists are likely to be, but maybe annoying for alignment purposes) for the (majority of?) applications that don't care about semantics. Arguments against: we need an undefined (again, "NONE" might lead to confusion) semantic flag anyway so now we have two legal ways to represent the same thing, which makes the collector's life harder... plus it doesn't look as clean in the IE registry. 

No super strong opinion here either way...

Best regards,

Brian

---

From: Benoit Claise <[email-masked]>
Date: Sat, 20 Mar 2010 13:48:31 +0100

Brian,
> Ahhh..... okay. This is confusing, though. I'd _definitely_ call this "undefined", because "none" could be interpreted as "not".
"undefined" is a better term, you're right.
> The use case is when you want to express uncertainty within a certain set: for example, say a mediator knows that a flow was observed on one of a set of interfaces at a MP on an original exporter (…
Point taken.
I now see the need for exactlyOneOf versus oneOrMoreOf

We're slowly but surely converging. Great.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Sat, 20 Mar 2010 19:07:36 +0100

Paul,
> I think it's more straightforward not to have "semanticless" versions.

Ok,. let's shoot for that one.

Regards, Benoit.

---

From: Atsushi Kobayashi <[email-masked]>
Date: Sun, 21 Mar 2010 14:25:12 +0900

Hi Benoit,

On Thu, 18 Mar 2010 09:52:20 +0100

> we can argue that we don't need UNORDERED

If using "UNORDERED", we can use "AND" or "OR" alternatively.
In my conclusion, we can remove it.

> > Interpretation and interface lists on aggregated Flow Records.

That make sense.

> Exactly, which implies that the ORDER semantic is required for this use 

We needs more other examples.

Regards,
Atsushi

-- 
Atsushi Kobayashi <[email-masked]>