Subject: [IPFIX] semantics in structured-data: one of these things is not like the others

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

Hi,
I have a question on the "semantic" field in the structured-data draft.  I apologize if this has been brought up before.

ISTM the field is mixing-up/overloading two distinct types of information, or I'm not understanding it right.  One is list field *ordering* - whether the list's encoded order of members is significant or not (ie, the "ordered" semantic value).  The other is *applicability* - whether the lists members apply to the flow or not (noneOf, exactlyOneOf, oneOrMoreOf, and allOf).

So what is the *applicability* of an "ordered" list?  Presumably allOf, right?  In other words, if a list is marked "ordered", do all it's members apply to the flow?  

I ask because it's also possible for a list to have both a ordered and noneOf semantic, or to have a ordered with oneOrMoreOf semantic.  For example, if you report an access control list that did not apply to the flow, that's an ordered+noneOf.  Or if you report one that does match the flow, that would arguably be an ordered+oneOrMoreOf.  You might want to think about making "ordered" a bit-flag of the semantic field instead of one of the semantic enumerations. 

-hadriel

---

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

Hi Hadriel,

IPFIX is not only about Flow Records. We also have Options data which
needs to be exported.

Semantic "Ordered" will be very helpful to describe a chain of IPFIX
Mediators or a sequence of specific packet/flow treatments.

Regards,
Gerhard

Hadriel Kaplan wrote:
> Hi, I have a question on the "semantic" field in the structured-data
> draft.  I apologize if this has been brought up before.
> 
> ISTM the field is mixing-up/overloading two distinct types of
> information, or I'm not understanding it right.  One is list field
> *ordering* - whether the list's encoded order of members is
> significant or not (ie, the "ordered" semantic value).  The other is
> *applicability* - whether the lists members apply to the flow or not
> (noneOf, exactlyOneOf, oneOrMoreOf, and allOf).
> 
> So what is the *applicability* of an "ordered" list?  Presumably
> allOf, right?  In other words, if a list is marked "ordered", do all
> it's members apply to the flow?
> 
> I ask because it's also possible for a list to have both a ordered
> and noneOf semantic, or to have a ordered with oneOrMoreOf semantic.
> For example, if you report an access control list that did not apply
> to the flow, that's an ordered+noneOf.  Or if you report one that
> does match the flow, that would arguably be an ordered+oneOrMoreOf.
> You might want to think about making "ordered" a bit-flag of the
> semantic field instead of one of the semantic enumerations.
> 
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 12 Oct 2010 09:14:00 -0400

Hi Gerhard,
yes I'm not arguing against the need for "ordered" - I'm just saying it's a different type of semantic than the others, and it's not clear they're exclusive of each other.

-hadriel

On Oct 12, 2010, at 5:24 AM, Gerhard Muenz wrote:

> <smime.p7s><ATT00001..c>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 12 Oct 2010 15:21:56 +0200

Hi, Hadriel,

This came up in discussions a while ago. The tradeoff here was between the perfectly orthogonal situation - an infinite line of  n-ary decisions we can combine into a "semantics" vector, which we then hope to fit into an (odd) number of bytes (to fix the alignment poison we have to swallow when using varlen) i.e., an ordered flag, a set-negate flag, a how-many 2-bit field, etc, etc, which we could extend in the future - and something that would be relatively simple to cover the cases we could currently envision. As I recall, tacking ordered on here was a way to support an explicit ordering assertion with a minimum of complexity. Ordered implies allOf: ordered anyOf or oneOrMoreOf seem not to make sense except in really weird circumstances, and ordered noneOf not at all. Keep in mind that allOf is NOT necessary allOf unordered: allOf makes no ordering assertion at all, either way. Explicitly asserting non-ordering seems to be another one of those weird corner cases...

Cheers,

Brian

On Oct 12, 2010, at 3:14 PM, Hadriel Kaplan wrote:

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