Packet Sampling (PSAMP) Protocol Specifications
RFC 5476
Yes
(Dan Romascanu)
No Objection
Lars Eggert
(Chris Newman)
(Cullen Jennings)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Sam Hartman)
(Tim Polk)
No Record
Note: This ballot was opened for revision 09 and is now closed.
Lars Eggert
No Objection
Dan Romascanu Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2008-01-10)
Unknown
Review by Christian Vogt: Draft-ietf-psamp-protocol-09 specifies how the IP Flow Information Export (IPFIX) protocol is used to communicate packet information between network measurement entities in a PSAMP architecture. The protocol was not originally designed for the PSAMP architecture. A few editorial/structural comments on how the understandability of the document could be improved for a non-expert reader. None of these comments is a technical show-stopper: (1) Section 3.2 in this document repeats many of the terminology definitions from section 3.1 in draft-ietf-psamp-sample-tech-10. This makes terminology updates and extensions unnecessarily cumbersome. I suggest moving all PSAMP-related terminology into a separate document, and citing that document where needed. (2) Section 3.3.1 does not compare PSAMP-related and IPFIX-related terminology, which it is supposed to do according to the introduction of section 3.3. Instead, section 3.3.1 simply describes PSAMP-related terms, and thus basically repeats parts of section 3.2. A comparison with the relevant IPFIX-related terminology should be added. (3) In section 3.3.2, the difference between a PSAMP Packet Report and a PSAMP Packet Interpretation remains unclear as both are equated to the same combination of IPFIX terms. Also, the term "Packet Interpretation" in section 3.3.2 should likely be replaced by "*Report* Interpretation" according to PSAMP terminology. (4) Section 4.2: Is the underlying architectural difference between PSAMP and IPFIX, which is relevant here, that aggregation may in IPFIX happen before data is exported, but not in PSAMP? If this is correct, then stating this explicitly would increase the clarity of this section.
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-01-08)
Unknown
I found Section 5's discussion of the requirements in [PSAMP-FMWK] hard to follow. I had to read section 4 of that document to sort out that the following paragraphs address subsections of the "Generic Requirements for PSAMP" referred to in the opening paragraph. The fact that the second paragraph focused on requirements that indirectly relate to the prtotocol contributes to the confusion. The opening paragraph of section 5 explicitly calls out "requirements that affect directly the PSAMP export protocol."
Magnus Westerlund Former IESG member
No Record
No Record
(2008-01-10)
Unknown
Section 6.4.1: For each selected packet, the Packet Report SHOULD contain the following information: - the observationTimeMicroseconds Information Element What is the purpose of this time? To enable determining exactly when the packet was sampled at the observation point? In that case I think it has insufficient resolution. I would recommend a time format that provides better than 10^-12 in resolution. We already today have link technology that serialize small packets in a small number of nano seconds.