The IESG has approved the following document:
- 'Ericsson TWAMP Value-Added Octets'
  (draft-ietf-ippm-twamp-value-added-octets-09.txt) as Informational RFC

This document is the product of the IP Performance Metrics Working Group.

The IESG contact persons are Wesley Eddy and Martin Stiemerling.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-value-added-octets/




Technical Summary

  This memo describes an extension to the TWAMP test protocol for
  identifying and managing packet trains, which enables measuring
  capacity metrics like the available path capacity, tight section
  capacity and UDP delivery rate in the forward and reverse path
  directions.

  This memo contains the description of a working prototype. It does
  not represent a consensus of the IETF community. The IETF community
  is currently working on the problem statement and has not reached
  consensus on the preferred method for measuring capacity metrics. 

Working Group Summary

  The prototype (and the first version of the draft) was presented at the
  March 2011 meeting, as the result of an experiment conducted by the authors.
  At the meeting, there was consensus that the prototype addressed a problem,
  though there was no consensus on what the problem exactly was.  In subsequent
  discussion, the WG agreed to work on the problem statement, while publishing
  this document in order to document the work done.

  As the prototype evolved during the year, and people brought up ideas,
  the document evolved as well.  There was some discussion on what should (not)
  be in this write-up.  This has been settled. 

  There were no objections from the IPPM working group to publishing this 
revision
  of the document.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

Personnel

  Henk Uijterwaal is the document shepherd, the responsible AD is Wes Eddy. 


RFC Editor Note

Please change the 2nd sentence of the 2nd paragraph of the "Status of This
Memo" boilerplate text that will appear in the published RFC to say:
"It does not represent a consensus of the IETF community."
This will match the statements made in the abstract and introduction.

Reply via email to