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

Hi Chris,

Thanks for your review.
> 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.
See the answer I just sent to the IPFIX mailing list.
>
> 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.
This issue is that this is a list that keeps updating all the time. So a 
reference is actually required.
>
> Is defaulting to TCP for protocol conflicts the best answer?  Why not just make it relevant to the transport contained in another IE?
Because we would break the following rule: the semantic of one IE would 
depend on the value of a different one.
>
> Aren't the IEEE standards you reference, well standards: e.g. normative, not informative?
Good catch. Corrected.
>
> 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.
That makes a lot of sense, and we should/will do it. This will take a 
little bit of time to make it right.
However, the proposal for this draft is to put on paper the 
specifications of what has been implemented.
Copying Ron Bonica, the new AD sponsored for this draft (transferred 
from Dan Romascanu)
>
> 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:
Sure ;-)
Many of us need this. This would be a second building block...
>
> (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?  ;)
We started this project years ago, so let's say a few beginner mistakes.
On top of that, we might need some more registries for custom protocols ...

Regards, Benoit (as a contributor)

>
> Chris
>
>
>

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