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

(Dan Romascanu) (was No Objection, Discuss, Yes) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) No Objection

In Section 8.2.4 and 8.2.5, data type should probably be "unsigned32" 
(or some other integer/float type), not dateTimeMicroseconds?

The spec uses "quantity" semantics for many information elements that
don't look like quantities (where e.g. adding two values doesn't
make sense), such as digestHashValue, hashDigestOutput, 
hashInitialiservalue, ipHeaderPacketSection,
ipPayloadPacketSection, mplsLabelStackSection, and
mplsPayloadPacketSection,

Appendix A says "The use of Namespaces as an extension mechanism
implies that an IANA registered Namespace URI should be available and
that directory names below this base URI be assigned for relevant IETF
specifications.  The authors are not aware of this mechanism today."
IANA does register namespace URIs; see RFC 3688 for more information .

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

Section 8 states:
   The Information Elements specified by the IPFIX information model
   [RFC5102] are used by the PSAMP protocol where applicable.

The document does not provide any guidance on the subset of RFC5106
that is applicable to the psamp information model.  Are implementations
expected to support the entire IPFIX information model?

(Mark Townsley) No Objection

(David Ward) (was Discuss) No Objection

The RFC Editor note clears my discuss.

Magnus Westerlund No Objection