Re: [IPFIX] unobserved fields

Hi, Paul, Andrew,

I'm not sure I understand the proposed mechanism here...

Observed/unobserved is a per-field/per-record attribute, while extended field specifiers modify IEs per-column: every instance of a given IE in a Template is "decorated" with its extension.

As I understand the requirements for -unobserved-fields, we want a way to distinguish, from an MP: "I am capable of observing this attribute, but it was not present in the observation" versus "I am not capable of observing this attribute". We have the second already: simply leave the IE out of the template. And, indeed, you can also use leaving things out of the template to signify the first: the presence of a field in some templates from an EP/MP combination implies that it's observable, its absence in the other implies it's not observed. FWIW, YAF does this for those things that haven't moved behind the 6313 curtain: no reverse elements if it's not a biflow, for instance.

Given that, how would you use a per-IE specifier to signal a per-record attribute? What am I missing?

Cheers,

Brian

On 7 Dec 2012, at 20:01, Paul Aitken <paitken@cisco.com> wrote:

> Andrew,
> 
>> My earlier email about Extended Field Specifiers reminded me of an other draft (draft-aitken-ipfix-unobserved-fields) that doesn't seem to have gone anywhere, but that I would love to move forward. Having a standard way to know if  field is unobserved/NULL for a given flow would be very valuable.
> 
> It's not that this draft didn't go anywhere. Rather, I've written all I can for now, yet the WG isn't in a position to adopt the work. However it's a real issue that needs to be solved -in fact, we're already using some of the techniques in this document - so in my mind it's only "on hold" until I think of something to add and/or the WG can adopt it.
> 
> You're right, Extended Field Specifiers would allow us to tag each field with an "Observed" attribute with advantages:
> 
>    - we wouldn't need to change fields to varlen just to report length = 0.
> 
>    - we could have a many-valued reason rather than a boolean.
>        ie, we can report why the value is not available or not applicable.
> 
> P.
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix