Subject: [IPFIX] draft-claise-export-application-info-in-ipfix-05

From: Chris Inacio <[email-masked]>
Date: Wed, 28 Mar 2012 06:48:47 -0400

http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-05

ClassEngineID + SelectorID - shouldn't this be 32-bits and possible to be shortened using reduced size encoding?  I'm not sure there is any advantage to saying you won't know until you see the Engine ID; and seriously, from an implementation point of view; building the decoder, I'm not going to care while parsing the information.  I will only care when doing the human display level - when I have to do the lookups.  For the protocol, (on the wire,) I prefer a 32-bit field.

I think the reference to the Cisco L7 registry should be removed from the main body text; and if possible added to some type of appendix.

Is defaulting to TCP for protocol conflicts the best answer?  Why not just make it relevant to the transport contained in another IE?

Aren't the IEEE standards you reference, well standards: e.g. normative, not informative?

Can we add the definition of how to get an online registry into the document, and the XML definition of the registry?  We have all those possible registry entries - why not define the interchange (lightweight) to get registry of app labels, and an options record to to be to specify its address.

e.g.

Name: applicationRegistry
      Description:
        Specifies a URN where section 8.x well formed application registry information may be retrieved.
      Abstract Data Type: string
      Data Type Semantics: URN
      ElementId: <to be assigned>
      Status:

<xml…>
	<registry ID major="1" minor="0">
		<provider>Cisco</provider>
		<release>_date_</release>
	        <major>VER</major>
  		<minor>VER</minor>
	</registry>
	<app_labels>
		<label>
			<id>80</id>
			<name>HTTP</name>
			<description>Primarily designed for transferring web pages, but extended to transfer *everything* on the net, because it is the only open port.</description>
			<category></category>
			<subCat></subCat>
			.
			.
			.
		</label>
		<label>
			.
			.
			.
		</label>
		.
		.
		.
	</app_labels>
</xml>

Then the Cisco specific references within the document above can be moved into the section related to how to get specific registries.

What missing:

I need data extracted from fields as well; with a big question on how to efficiently index into it.  I see two possibilities:

(1)  We have a general registry of useful fields (I have no idea how to build this even close to comprehensively):
	1 - user
	2 - organization
	3 - command
	4- command path
	5 - …

and then using structured data, under an application level, you can have something like application id:
	+--------------+---------------------------------------+
	|    1              | (string) inacio                            |
        +--------------+---------------------------------------+
        |    2              | (string) CERT                            |
        +--------------+---------------------------------------+

for something like an X.509 certificate.

(2) define the fields specifically to the application protocols, which means extending the registry type information from above:

X.509.user = inacio
X.509.org = CERT

for example.  But that leads to IE explosion.

Lastly, also, why all the reserved registry numbers?  We're inventing something new, aren't we?  ;)

Chris