Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)
draft-claise-export-application-info-in-ipfix-10

To the AD:

Could you update the ballot and approval notes to reflect the new
name of the document, please.

--- 

To the Authors

The first section could really do with having text that explains (per
the title and Abstract - but in a little more detail) that this is a
Cisco-proprietary extension to IPFIX.

I found a very skimpy sentence in Section 2 (which made me recall that
I like it when the first section of a document is the Introduction :-)

I agree with the comments that the boilerplate for this sort of document is odd.  I think we need to look at the choices we have for what to say at the beginnings of documents, and make sure there's a good, standard option for "this is not a consensus document; we're just putting it out for information."  Or maybe this says that this should have gone through the ISE.

In any case, I have no objection to publishing this, so here we go.

Thank you for addressing my issue.

- The reference to http://www.cisco.com/ seems wonderfully
vague, but unfortunately useless. What are the "Cisco
systems assigned numbers"? (I agree with this bit of
Stewart's discuss)

- 2.1: I don't think I buy the congestion control use
case. (While I don't like the security use case, I do
agree others might like it.)

- 4.1: is this encouraging folks to guess what IANA might
allocate for IANA to act? Seems like a bad idea.o

- 4.2: PANA-L* - I don't get how this works.  How can you
assign selector lengths for the PANA-L* in 4.2?

- section 7: I don't get how some ElementId's are assigned
here already but are marked as reserved in the IANA
registry.

- AppA: How is section 7 of an informative document
normative?

Thank you for addressing my concerns

As with similar "Company X's FooBar" documents, I think it is bizarre to let the boilerplate say that the IETF has consensus that this is what Cisco does.

Though I am opposed to IETF work on DPI and supporting technologies like this as they are clearly hopeless and fundamentally harmful to the Internet, I have no technical arguments with this document and no objection to publishing what Cisco is doing in this regard.