Re: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-00

[Hadriel Kaplan <[e-mail]>]

Hi Brian,
comments inline...

On Oct 8, 2010, at 2:39 AM, Brian Trammell wrote:

> Hi, Hadriel,
> 
> Thanks for the feedback.
> 
> The primary design goal of the IESpec format is human readability in the expression of information model extensions and templates, while maintaining simple machine readability. The idea is implementors can read an Internet Draft about an IPFIX application with example templates in IESpec form, copy and paste the example templates out of it into an implementation supporting IEspec, fill in the fields and go.

At the end of the day what we're talking about is a form of a "dictionary" file, similar to those used for other protocols, like for SNMP, DIAMETER, RADIUS, etc.  Right?  Like not just for putting into a RFC, but more importantly for importing into a reader so it can decode and understand the IEs, right?

Again, I'm not a big fan of XML, but there are a ton of XML parser libraries available, and the importing of that into a reader so it can understand the new IEs is done rarely, and with a CPU (not an FPGA or network processor).  Libraries exist to not only read them, but verify their correctness using a schema.  Further, they support comments and text descriptions, which are useful for an IPFIX reader importing them.  An IPFIX reader can use those to display in a GUI as additional help, and a human can use them to understand stuff when he/she reads the XML.  

For example, suppose vendor BigCorp wants to give out such a "dictionary" file for some PEN IEs its BigBox generates, so that IPFIX Readers can decode them.  One of those PEN IEs is for a "camFlowId".  In IESpec, it might be:
camFlowId(35566/123)<unsigned32>[4]

That doesn't tell the human nor the IPFIX collector/reader much info.  In XML it's a lot longer text, but it can include some more info like this:
       <description>
         <paragraph>
           An identifier of a single Content Addressable Memory index allocated for the flow.  Two CAM entries are allocated, for each direction, unless the system is provisioned otherwise.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See BigCorp User Manual chapter titled "Hardware Resources" for more information.
         </paragraph>
       </reference>

And the file can even have a "<-- BigCorp dictionary file for BigCorp BigBox 10000 System, version 1.2.3. Created 2-10-2010 -->" comment at the top.



> For readability and compactness, it's intended to address shortcomings both in the XML format(s) already defined for IPFIX IEs

What shortcomings?  There're some fields I think it should have that it doesn't, and the structure of it is weird, but  I'm a nitpicker.  Is there something fatally wrong with it?


> and in the traditional 32-bit-wide box-and-line diagrams, which make it difficult to fit a nontrivial template onto a single page, and require some manual work to turn into an implementation.

This is one of the things I was worried about - that we would be saying this would avoid showing things in 32-bit-wide box-and-line diagrams.  I find those drawings are really, really useful.  For example, I couldn't make heads or tails of the structured-data draft until I saw those examples.  

Fitting them on a page is not a serious issue really, is it?  I mean if it crosses pages, people can deal.  I know it takes more work to draw them, but you're writing an RFC for others to be able to interop with you, so that's life.  If a nontrivial template is difficult to draw, maybe that will encourage people to not make complicated templates. :)  I'm half joking, but my point is the work to write the RFC is really moot compared to helping people reading the RFC implementing it right.  


> The XML format in 5102 has been partially superceded by the one used by IANA internally (I'm not sure the extent to which the one uses the elements from the other, it's been a while), and is specifically targeted only for defining Informatio
n Elements to be added to the registry. (If you need to put IE metadata on the wire, e.g. to define enterprise-specific IEs in long-term storage, 5610 covers that.)

Right, I know 5610 puts the meta-data on the wire, and IESpec looks to me like basically just a text transformation of that.  But I see 5610 as a limited functionality, last-resort solution, in case the reader/collector has no real dictionary file available. (it seems odd to me that there's really a use-case for that in practice, but that's just me)  The point is because it's on-the-wire it has to be terse and limited, but a real dictionary file shouldn't be.

-hadriel