Information Model for Packet Sampling Exports
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.