Packet Delay Variation Applicability Statement
draft-ietf-ippm-delay-var-as-02

[Ballot comment]
In the Gen-ART Review by Christian Vogt, two suggestions were made:

  Section 1.1, 3rd paragraph:  "Lost and delayed packets are separated
  by a waiting time threshold." -- Since the waiting time threshold
  does not only apply to those packets that are lost or delayed, this
  sentence should be rephrased to:  "Packets for which one-way loss or
  delay is measured are...".

  Section 3.2, 4th-to-last paragraph:  "The error in the alignment
  process can be accounted for by a factor, A." -- A is an offset
  (addend) here, not a factor.

[Ballot comment]
In section 4.4:
  Note that the IPDV histogram will change
  if the sequence of delays is modified, but the PDV histogram will
  stay the same.

Should this be if the *order* of the sequence of delays is modified?  I believe if the sequence of delays were modified by changing the values, PDV histogram could change. 

On reading more of the document, I believe this wording is intentional; it seems that sequence is used as a synonym for order elsewhere in the doc.  For the record, I usually treat "sequence" as a synonym for "an ordered set" rather than "an order", but usage may differ in other communities.

[Ballot comment]
Good work. One small issue: I found this confusing:

  range(b) = b_max - b_min = D_max - D_min + A

Is "b" here a variable or does it represent buffering as earlier?
b_min does not appear elsewhere in the document, did you mean B_min?

[Ballot comment]
Good work. A couple of small issues: I found this confusing:

  range(b) = b_max - b_min = D_max - D_min + A

Is "b" here a variable or does it represent buffering as earlier?
b_min does not appear elsewhere in the document, did you mean B_min?

[Ballot comment]
The document was unexpectedly easy to understand (even to someone who
doesn't have much background knowledge about this kind of metrics
and measurements) -- good work!

[Ballot comment]
The Summary of Comparisons table in section 7.3 would be more legible if there was
a blank line or a line of dashes separating each row.

[Ballot discuss]
This is a two part discuss:

Part 1 is really a question, not a request for any change at this time.  Part 2 is the usual
request for more information in the security considerations section.

Part 1: The Security Considerations don't address any inherent differences between PDV
and IPDV.  Is this because they have the same security considerations?

For example, are there inherent differences in the quantity or types of traffic that must be
injected to support IPDV and DPV calculations?  Since high levels of added traffic constitute
a DoS attack of sorts, this would be an important security differentiator.  It would be nice to
note that either way...

Part 2: The security considerations should probably point to RFC 2679 for generic
considerations, and to 3393 for specific considerations for that technique.  I would retain
the reference to 4656 as well.

>    (1.a) Who is the Document Shepherd for this document? Has the
>          Document Shepherd personally reviewed this version of the
>          document and, in particular, does he or she believe this
>          version is ready for forwarding to the IESG for publication?
>
> The document shepherd is Henk Uijterwaal .  I have 
> personally
> reviewed
> this document and would not have bothered to write this not if I 
> didn't feel it
> was ready for the IESG.
>
>    (1.b) Has the document had adequate review both from key WG 
> members
>          and from key non-WG members? Does the Document Shepherd have
>          any concerns about the depth or breadth of the reviews that
>          have been performed?
>
> I believe the document has received sufficent review from key WG 
> members (see
> acknowledgements
> for names).  I don't believe there are key non-WG members that need 
> to review
> the document.
> I have no concerns about the depth or breadth of reivews for this 
> document.
>
>    (1.c) Does the Document Shepherd have concerns that the document
>          needs more review from a particular or broader perspective,
>          e.g., security, operational complexity, someone familiar 
> with
>          AAA, internationalization or XML?
>
> No.
>
>    (1.d) Does the Document Shepherd have any specific concerns or
>          issues with this document that the Responsible Area Director
>          and/or the IESG should be aware of?
>
> None.
>
>          Has an IPR disclosure related to this document been filed?
>
> No.
>
>    (1.e) How solid is the WG consensus behind this document? Does it
>          represent the strong concurrence of a few individuals, with
>          others being silent, or does the WG as a whole understand 
> and
>          agree with it?
>
> The WG asked for this document after a talk from Roman Krasnowski at 
> IETF-65,
> the authors then voluntered to write it.  It has been presented at a 
> couple
> of meetings, received support and the authors have been thanked for 
> writing
> the document as it is needed in day to day operations.  The document 
> has been
> reviewed in dept by about 5 members of the group.  I have no 
> indication that
> the majority of the WG members does not understand what this 
> document is about.
>
>
>    (1.f) Has anyone threatened an appeal or otherwise indicated 
> extreme
>          discontent?
>
> No.
>
>    (1.g) Has the Document Shepherd personally verified that the
>          document satisfies all ID nits?
>
> There are currently 4 nits:
>
>  == It looks like you're using RFC 3978 boilerplate.  You should 
> update
>      this, as the boilerplate described in the IETF Trust License 
> Policy
>      document (see http://trustee.ietf.org/license-info) is accepted 
> from 10
>      November 2008, and will soon be required.  Version 1.34 of 
> xml2rfc can
>      (when released) be used to produce documents with boilerplate 
> according
>      to the mentioned Trust License Policy document.
>
>      I believe that this is a timing issue, the document was 
> finished before the
>      new boilerplate was.
>
>  == The document doesn't use any RFC 2119 keywords, yet seems to 
> have RFC
>      2119 boilerplate text.
>
>      This reference can be removed by the editor.
>
>  == Outdated reference: A later version (-07) exists of
>      draft-ietf-ippm-framework-compagg-06
>  == Outdated reference: A later version (-07) exists of
>      draft-ietf-ippm-spatial-composition-06
>
>      These are again timing issues.
>
>          Has the document met all formal review criteria it needs 
> to, such as
> the MIB
>          Doctor, media type and URI type reviews?
>
> None of these are necessary.
>
>    (1.h) Has the document split its references into normative and
>          informative?
>
> Yes.
>
>          Are there normative references to documents that
>          are not ready for advancement or are otherwise in an unclear
>          state?
>
> No.
>
>    (1.i) Has the Document Shepherd verified that the document IANA
>          consideration section exists and is consistent with the body
>          of the document?
>
> There is an IANA considerations section.  It is empty as the 
> document doesn't
> require anything from the IANA.
>
>    (1.j) Has the Document Shepherd verified that sections of the
>          document that are written in a formal language, such as XML
>          code, BNF rules, MIB definitions, etc., validate correctly 
> in
>          an automated checker?
>
> Not applicable.
>
>    (1.k) The IESG approval announcement includes a Document
>          Announcement Write-Up. Please provide such a Document
>          Announcement Write-Up? Recent examples can be found in the
>          "Action" announcements for approved documents. The approval
>          announcement contains the following sections:
>
>          Technical Summary
>    Packet delay variation metrics appear in many different standards
>    documents.  The metric definition in RFC 3393 has considerable
>    flexibility, and it allows multiple formulations of delay variation
>    through the specification of different packet selection functions.
>
>    Although flexibility provides wide coverage and room for new ideas,
>    it can make comparisons of independent implementations more
>    difficult.  Two different formulations of delay variation have come
>    into wide use in the context of active measurements.  This memo
>    examines a range of circumstances for active measurements of delay
>    variation and their uses, and recommends which of the two forms is
>    best matched to particular conditions and tasks.
>
>
>          Working Group Summary
>              Was there anything in WG process that is worth noting? 
> For
>              example, was there controversy about particular points or
>              were there decisions where the consensus was particularly
>              rough?
>
> This document was suggested after a talk on this topic at IETF-65. 
> There
> was no controversy in the WG process.  Consensus was smooth.
>
>          Document Quality
>              Are there existing implementations of the protocol?
>
> This document does not describe a new protocal.
>
>