Skip to main content

Packet Sampling (PSAMP) Protocol Specifications
draft-ietf-psamp-protocol-09

Yes

(Dan Romascanu)

No Objection

(Chris Newman)
(Cullen Jennings)
(David Ward)
(Jon Peterson)
(Lars Eggert)
(Lisa Dusseault)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Sam Hartman)

No Record


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

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

                            
Lars Eggert 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.