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

Note: This ballot was opened for revision 07 and is now closed.

(Ron Bonica; former steering group member) Yes

Yes ( for -07)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2012-07-19 for -09)
No email
send info
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 :-)

(Barry Leiba; former steering group member) No Objection

No Objection (2012-07-19 for -09)
No email
send info
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.

(Brian Haberman; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Martin Stiemerling; former steering group member) (was Discuss) No Objection

No Objection (2012-08-09)
No email
send info
Thank you for addressing my issue.

(Robert Sparks; former steering group member) (was Discuss) No Objection

No Objection ( for -09)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ( for -09)
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2012-06-05 for -08)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2012-05-21 for -07)
No email
send info
- 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?

(Stewart Bryant; former steering group member) (was Discuss) No Objection

No Objection (2012-07-17 for -09)
No email
send info
Thank you for addressing my concerns

(Wesley Eddy; former steering group member) (was No Record, Discuss) No Objection

No Objection (2012-07-18 for -09)
No email
send info
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.

(Benoît Claise; former steering group member) Recuse

Recuse ( for -07)
No email
send info