[sip-clf] is doing ascii doing both? (was: Defining Pros and Cons of ASCII/IPFIX)

[Hadriel Kaplan <[e-mail]>]

When Peter first proposed it I was basically thinking the same thing.  In a way, that's true in that if we go define IANA numbers for putting the field in IPFIX, then obviously one could then write the IPFIX message with such fields into a file.  But that'll be true no matter what we do, unless you're suggesting no protocol ever be allowed to encode the fields.  For example someone might submit an I-D to create IANA-defined DIAMETER AVPs for these fields; and someone may submit an I-D someday to write DIAMETER messages to a file.  How can we prevent that?  Why should we?

Having said all that, the more I'm thinking about it the more I'm thinking it's not _really_ "doing both".  Because I think Eric's right.  Those of us that need an exporting mechanism will do IPFIX, if there's some advantage to doing that for exporting such stuff.  I personally think there is, but that's really a separate topic.  But for literal local *file* format, I have no doubt Eric is right and ascii will dominate.  It's trivial to implement, and easy to read. (or will be if we get rid of the indexes)

So when you go to the Cisco marketing folks, you can tell them to use the single, ascii format we publish an RFC for. (whatever format that will be)

-hadriel

On Nov 9, 2010, at 11:22 PM, Cullen Jennings wrote:

>> The proposal Peter suggested was to pick Ascii.  Are you ok with that?
> 
> I'm fine with pick either but that was not the proposal. The proposal was effectively to pick both.