Loss Episode Metrics for IP Performance Metrics (IPPM)
draft-ietf-ippm-loss-episode-metrics-04

[Ballot comment]
Ari Keränen's review:

2.4.  Metric Definition
        [...] Src sent the first bit of a Type-P
        packet to Dst at wire-time T1 and the first bit of a Type-P
        packet to Dst a wire-time T2>T1 [...]

The text says twice "first bit of a Type-P packet"; should it rather say
on the second occasion "first bit of the next Type-P packet" or
something? And the same issue repeats in the following definitions.


3.5.  Discussion

    which to select a substream from it for the purposes of loss episode

s/which/wish/ ?

[Ballot comment]
It may be obvious, but I believe that some of the Metric Units section should aboid ambiguity about the numbers in the definition of the metrics.

Section 6.1.3:

s/A number in the interval [0,1]/A decimal number in the interval [0,1]/

Section 6.2.3:

s/A non-negative number of seconds./A non-negative integer number of seconds./

[Ballot comment]
Please s/draft/document/

---

In the definition of Type-P-One-way-Bi-Packet-Loss-Stream I was
surprised that there is no statement that the packet pairs are
contiguous. That is, that there is no other packet transmission between
the second packet in the first pair and the first packet in the second
pair. Given the term "stream" I expected this to be the case, but the
text is silent and the definitions apply only to the time of
transmission in a way that allows interspersion.

Could you consider clarifying (either way) to be sure to state your
intentions.

---

Section 10 would be clearer if it said "This document requests no
actions from IANA."

[Ballot comment]
The Gen-ART Review by Peter McCann on 19-Nov-2011 raised several
  editorial suggestions.  Please consider them.  The review can be
  found here:

  http://www.ietf.org/mail-archive/web/gen-art/current/msg06942.html

[Ballot comment]
- 1.1, 2nd para refers to "by Gilbert and...by Elliot" but
doesn't give references. Those would be good to include.

- Is section 8 appropriate to include? If so, it'd be more
useful if "some of the material" could be more tightly
scoped I guess.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Loss Episode Metrics for IPPM) to Proposed Standard


The IESG has received a request from the IP Performance Metrics WG (ippm)
to consider the following document:
- 'Loss Episode Metrics for IPPM'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IETF has developed a one way packet loss metric that measures the
  loss rate on a Poisson probe stream between two hosts.  However, the
  impact of packet loss on applications is in general sensitive not
  just to the average loss rate, but also to the way in which packet
  losses are distributed in loss episodes (i.e., maximal sets of
  consecutively lost probe packets).  This draft defines one-way packet
  loss episode metrics, specifically the frequency and average duration
  of loss episodes, and a probing methodology under which the loss
  episode metrics are to be measured.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ippm-loss-episode-metrics/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ippm-loss-episode-metrics/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1354/

The responsible AD (me) erroneously placed this on the agenda and issued the ballot; it has been removed from the agenda and put back into the correct state.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
In section 1.2, "represent have" should just be "have".

In section 2.3, the last sentence shouldn't have "for" in it.

Section 3.6, 3.7, and 3.8 are empty.  I would think these need to be at least minimally filled in with the relevant description or references to other sections, as applicable.

Section 8 (IPR Considerations) is helpful, however note that the tracker only shows a link to IPR ID #1354, and this section mentions #1009, #1010, and #1126; does this need to be explained somehow or more links added?

(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?

Document sheperd is Henk Uijterwaal.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?

Yes, the document was reviewed by some members of the working group.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,

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?

There is an IPR claim for the document. However, this is an optional
element in the IPPM metrics suite. If one doesn't like the IPR then one simply
doesn't implement.

(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?

Good, the topic has been under discussion for a long time and there is
general consensus on the document. Besides the people contributing and
reviewing, the topic is well understood in the WG.


(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?

== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?

I couldn't quite figure out what is wrong here, but this is something the editor
can fix.

No other nits that need action.

(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?

Yes, it is empty, so please remove it upon publication.

(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?

N/A

(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
The IETF has developed a one way packet loss metric that measures the
loss rate on a Poisson probe stream between two hosts. However, the
impact of packet loss on applications is in general sensitive not
just to the average loss rate, but also to the way in which packet
losses are distributed in loss episodes (i.e., maximal sets of
consecutively lost probe packets). This draft defines one-way packet
loss episode metrics, specifically the frequency and average duration
of loss episodes, and a probing methodology under which the loss
episode metrics are to be measured.



Working Group Summary
The normal WG process was followed and the document has been discussed for
several years. The document as it is now, reflects WG consensus, with nothing
special worth noticing.

Document Quality
Good