draft-ietf-ippm-initial-registry-02.txt		draft-ietf-ippm-initial-registry-03.txt
	Network Working Group A. Morton		Network Working Group A. Morton
	Internet-Draft AT&T Labs		Internet-Draft AT&T Labs
	Intended status: Standards Track M. Bagnulo		Intended status: Standards Track M. Bagnulo
	Expires: May 2, 2017 UC3M		Expires: September 10, 2017 UC3M
	P. Eardley		P. Eardley
	BT		BT
	K. D'Souza		K. D'Souza
	AT&T Labs		AT&T Labs
	October 29, 2016		March 9, 2017
	Initial Performance Metric Registry Entries		Initial Performance Metric Registry Entries
	draft-ietf-ippm-initial-registry-02		draft-ietf-ippm-initial-registry-03
	Abstract		Abstract
	This memo defines the Initial Entries for the Performance Metrics		This memo defines the Initial Entries for the Performance Metrics
	Registry. This version includes:		Registry. This version includes:
	* All section 4 and 5 parameters reference YANG types for alternate		* All section 4, 5, 6, 7, and 8 parameters reference YANG types for
	data formats.		alternate data formats.
	* implementation of standard naming format for parameters.		* implementation of standard naming format for parameters.
	Still need: * revisions that follow section 4 changes in proposed		* implementation of many IANA early-review comments.
	metrics defined in sections 6, 7, 8.
			Still need: Add MBM metric entry.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 2, 2017.		This Internet-Draft will expire on September 10, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 40 ¶		skipping to change at page 2, line 40 ¶
	4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9		4.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9		4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9
	4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9		4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9
	4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9		4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9
	4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9		4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Reference Definition . . . . . . . . . . . . . . . . 9		4.2.1. Reference Definition . . . . . . . . . . . . . . . . 9
	4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10		4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10
	4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11		4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11
	4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11		4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11
	4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12		4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12
	4.3.3. Traffic Filtering (observation) Details . . . . . . . 12		4.3.3. Traffic Filtering (observation) Details . . . . . . . 13
	4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13		4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13
	4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13		4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13
	4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14		4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14		4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14		4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.4.2. Reference Definition . . . . . . . . . . . . . . . . 14		4.4.2. Reference Definition . . . . . . . . . . . . . . . . 15
	4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15		4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15
	4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15		4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15
	4.5. Administrative items . . . . . . . . . . . . . . . . . . 16		4.5. Administrative items . . . . . . . . . . . . . . . . . . 16
	4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16		4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16
	4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 16		4.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 16
	4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16		4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16
	4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16		4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16
	4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16		4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16
	5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16		5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16
	5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16		5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 17
	5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16		5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17		5.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17		5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17
	5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17		5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17
	5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17		5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17
	5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17		5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17
	5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17		5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17
	5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18		5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18
	5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19		5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19
	5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19		5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19
	5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 20		5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 20
	5.3.3. Traffic Filtering (observation) Details . . . . . . . 20		5.3.3. Traffic Filtering (observation) Details . . . . . . . 21
	5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20		5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 21
	5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20		5.3.5. Run-time Parameters and Data Format . . . . . . . . . 21
	5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21		5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21
	5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 22		5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 22
	5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 22		5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 22
	5.4.2. Reference Definition . . . . . . . . . . . . . . . . 22		5.4.2. Reference Definition . . . . . . . . . . . . . . . . 22
	5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 23		5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 23
	5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 23		5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 23
	5.5. Administrative items . . . . . . . . . . . . . . . . . . 24		5.5. Administrative items . . . . . . . . . . . . . . . . . . 24
	5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 24		5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 24
	5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 24		5.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 24
	5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 24		5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 24
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24		6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24
	6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24		6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24
	6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 25		6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 25		6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 25		6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 25
	6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 25		6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 25
	6.1.6. Version (of Registry Format) . . . . . . . . . . . . 25		6.1.6. Version (of Registry Format) . . . . . . . . . . . . 25
	6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 25		6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 25
	6.2.1. Reference Definition . . . . . . . . . . . . . . . . 25		6.2.1. Reference Definition . . . . . . . . . . . . . . . . 25
	6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 26		6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 26
	6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 27		6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 28
	6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 27		6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 28
	6.3.2. Packet Generation Stream . . . . . . . . . . . . . . 28		6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 29
	6.3.3. Traffic Filtering (observation) Details . . . . . . . 29		6.3.3. Traffic Filtering (observation) Details . . . . . . . 30
	6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29		6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 30
	6.3.5. Run-time Parameters and Data Format . . . . . . . . . 29		6.3.5. Run-time Parameters and Data Format . . . . . . . . . 30
	6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30		6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 31
	6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30		6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 31
	6.4.1. Type/Value (two diff terms used) . . . . . . . . . . 30		6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 31
	6.4.2. Reference Definition . . . . . . . . . . . . . . . . 31		6.4.2. Reference Definition . . . . . . . . . . . . . . . . 32
	6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 31		6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 32
	6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 32		6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 32
	6.5. Administrative items . . . . . . . . . . . . . . . . . . 32		6.5. Administrative items . . . . . . . . . . . . . . . . . . 33
	6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 32		6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 33
	6.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 32		6.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 33
	6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 32		6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 33
	6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 32		6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 33
	6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 32		6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 33
	7. UDP Poisson One-way Delay Registry Entries . . . . . . . . . 32		7. UDP Poisson One-way Delay Registry Entries . . . . . . . . . 33
	7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32		7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 34
	7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 33		7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 34
	7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 33		7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 34
	7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 33		7.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 34
	7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 33		7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 34
	7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 33		7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 35
	7.2.1. Reference Definition . . . . . . . . . . . . . . . . 33		7.2.1. Reference Definition . . . . . . . . . . . . . . . . 35
	7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 34		7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35
	7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 35		7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 36
	7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 35		7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36
	7.3.2. Packet Generation Stream . . . . . . . . . . . . . . 35		7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 37
	7.3.3. Traffic Filtering (observation) Details . . . . . . . 36		7.3.3. Traffic Filtering (observation) Details . . . . . . . 38
	7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 36		7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 38
	7.3.5. Run-time Parameters and Data Format . . . . . . . . . 36		7.3.5. Run-time Parameters and Data Format . . . . . . . . . 38
	7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 37		7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 39
	7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 37		7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 39
	7.4.1. Type/Value (two diff terms used) . . . . . . . . . . 37		7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 39
	7.4.2. Reference Definition . . . . . . . . . . . . . . . . 37		7.4.2. Reference Definition . . . . . . . . . . . . . . . . 39
	7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 39		7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 42
	7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 39		7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 42
	7.5. Administrative items . . . . . . . . . . . . . . . . . . 39		7.5. Administrative items . . . . . . . . . . . . . . . . . . 43
	7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 39		7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 43
	7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 40		7.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 43
	7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 40		7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 43
	7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 40		7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 43
	7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 40		7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 43
	8. UDP Periodic One-way Delay Registry Entries . . . . . . . . . 40		8. UDP Periodic One-way Delay Registry Entries . . . . . . . . . 43
	8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 40		8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 44
	8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 40		8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 44
	8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 40		8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 44
	8.1.3. URI and URL . . . . . . . . . . . . . . . . . . . . . 41		8.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 44
	8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 41		8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 45
	8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 41		8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 45
	8.2.1. Reference Definition . . . . . . . . . . . . . . . . 41		8.2.1. Reference Definition . . . . . . . . . . . . . . . . 45
	8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 42		8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 46
	8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 42		8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 47
	8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 43		8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 47
	8.3.2. Packet Generation Stream . . . . . . . . . . . . . . 43		8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 48
	8.3.3. Traffic Filtering (observation) Details . . . . . . . 43		8.3.3. Traffic Filtering (observation) Details . . . . . . . 48
	8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 44		8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 48
	8.3.5. Run-time Parameters and Data Format . . . . . . . . . 44		8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48
	8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 44		8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 49
	8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 45		8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 49
	8.4.1. Type/Value (two diff terms used) . . . . . . . . . . 45		8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 49
	8.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 45		8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49
	8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 47		8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 52
	8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 47		8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52
	8.5. Administrative items . . . . . . . . . . . . . . . . . . 47		8.5. Administrative items . . . . . . . . . . . . . . . . . . 53
	8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 47		8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53
	8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 47		8.5.2. Requestor (keep?) . . . . . . . . . . . . . . . . . . 53
	8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 47		8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53
	8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 48		8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53
	8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 48		8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 53
	9. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 48		9. ver08 BLANK Registry Entry . . . . . . . . . . . . . . . . . 54
	9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 48		9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 54
	9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 48		9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 54
	9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 48		9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54
	9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 48		9.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 54
	9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 48		9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 54
	9.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 48		9.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 54
	9.1.6. Change Controller . . . . . . . . . . . . . . . . . . 48		9.1.6. Change Controller . . . . . . . . . . . . . . . . . . 54
	9.1.7. Version (of Registry Format) . . . . . . . . . . . . 48		9.1.7. Version (of Registry Format) . . . . . . . . . . . . 54
	9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 49		9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 54
	9.2.1. Reference Definition . . . . . . . . . . . . . . . . 49		9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55
	9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 49		9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 55
	9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 49		9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 55
	9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 49		9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 55
	9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 49		9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 55
	9.3.3. Traffic Filtering (observation) Details . . . . . . . 49		9.3.3. Traffic Filtering (observation) Details . . . . . . . 55
	9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 49		9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 55
	9.3.5. Run-time Parameters and Data Format . . . . . . . . . 50		9.3.5. Run-time Parameters and Data Format . . . . . . . . . 55
	9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 50		9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 55
	9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 50		9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 56
	9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 50		9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 56
	9.4.2. Reference Definition . . . . . . . . . . . . . . . . 50		9.4.2. Reference Definition . . . . . . . . . . . . . . . . 56
	9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 50		9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 56
	9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 50		9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 56
	9.5. Administrative items . . . . . . . . . . . . . . . . . . 50		9.5. Administrative items . . . . . . . . . . . . . . . . . . 56
	9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 50		9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 56
	9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 50		9.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . . 56
	9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 50		9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 56
	9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 51		9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 56
	9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 51		9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 56
	10. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 51		10. Example RTCP-XR Registry Entry . . . . . . . . . . . . . . . 57
	10.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 51		10.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 57
	10.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 51		10.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 57
	10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 51		10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 57
	10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 51		10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 57
	10.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 51		10.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 57
	10.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 51		10.1.5. Requestor . . . . . . . . . . . . . . . . . . . . . 57
	10.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 51		10.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 57
	10.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 52		10.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 57
	10.1.8. Description . . . . . . . . . . . . . . . . . . . . 52		10.1.8. Description . . . . . . . . . . . . . . . . . . . . 57
	10.1.9. Reference Specification(s) . . . . . . . . . . . . . 52		10.1.9. Reference Specification(s) . . . . . . . . . . . . . 58
	10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 52		10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 58
	10.2.1. Reference Definition . . . . . . . . . . . . . . . . 52		10.2.1. Reference Definition . . . . . . . . . . . . . . . . 58
	10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 52		10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 58
	10.3. Method of Measurement . . . . . . . . . . . . . . . . . 53		10.3. Method of Measurement . . . . . . . . . . . . . . . . . 59
	10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 53		10.3.1. Reference Method . . . . . . . . . . . . . . . . . . 59
	10.3.2. Stream Type and Stream Parameters . . . . . . . . . 53		10.3.2. Stream Type and Stream Parameters . . . . . . . . . 59
	10.3.3. Output Type and Data Format . . . . . . . . . . . . 53		10.3.3. Output Type and Data Format . . . . . . . . . . . . 59
	10.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 54		10.3.4. Metric Units . . . . . . . . . . . . . . . . . . . . 59
	10.3.5. Run-time Parameters and Data Format . . . . . . . . 54		10.3.5. Run-time Parameters and Data Format . . . . . . . . 60
	10.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 55		10.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 61
	11. Revision History . . . . . . . . . . . . . . . . . . . . . . 56		11. Revision History . . . . . . . . . . . . . . . . . . . . . . 61
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 56		12. Security Considerations . . . . . . . . . . . . . . . . . . . 62
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
	15.1. Normative References . . . . . . . . . . . . . . . . . . 57		15.1. Normative References . . . . . . . . . . . . . . . . . . 63
	15.2. Informative References . . . . . . . . . . . . . . . . . 59		15.2. Informative References . . . . . . . . . . . . . . . . . 64
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
	1. Introduction		1. Introduction
	Note: Efforts to synchronize structure and terminology with		Note: Efforts to synchronize structure and terminology with
	[I-D.ietf-ippm-metric-registry] will likely be incomplete until both		[I-D.ietf-ippm-metric-registry] will likely be incomplete until both
	drafts are stable.		drafts are stable.
	This memo proposes an initial set of entries for the Performance		This memo proposes an initial set of entries for the Performance
	Metric Registry. It uses terms and definitions from the IPPM		Metric Registry. It uses terms and definitions from the IPPM
	literature, primarily [RFC2330]. Proponents of Passive Performance		literature, primarily [RFC2330]. Proponents of Passive Performance
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 43 ¶
	--------------------		--------------------
	4. UDP Round-trip Latency Registry Entry		4. UDP Round-trip Latency Registry Entry
	This section gives an initial registry entry for the UDP Round-trip		This section gives an initial registry entry for the UDP Round-trip
	Latency.		Latency.
	Note: Each Registry entry only produces a "raw" output or a		Note: Each Registry entry only produces a "raw" output or a
	statistical summary. To describe both "raw" and one or more		statistical summary. To describe both "raw" and one or more
	statistics efficiently, the Identifier, Name, and Output Categories		statistics efficiently, the Identifier, Name, and Output Categories
	can be split and this section can become two or more closely-related		can be split and a single section can specify two or more closely-
	metrics. See Section 7 for an example specifying multiple Registry		related metrics. See Section 7 for an example specifying multiple
	entries with many common columns.		Registry entries with many common columns.
	4.1. Summary		4.1. Summary
	This category includes multiple indexes to the registry entry: the		This category includes multiple indexes to the registry entry: the
	element ID and metric name.		element ID and metric name.
	4.1.1. ID (Identifier)		4.1.1. ID (Identifier)
	<insert a numeric identifier, an integer, TBD>		<insert a numeric identifier, an integer, TBD>
	4.1.2. Name		4.1.2. Name
	<insert name according to metric naming convention>		<insert name according to metric naming convention>
	RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile		RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile
	4.1.3. URIs		4.1.3. URIs
	URN: Prefix urn:ietf:params:performance:metric:<name>		URN: Prefix urn:ietf:metrics:perf:<name>
	URL: http://<TBD by IANA>/<name>		URL: http://<TBD by IANA>/<name>
	4.1.4. Description		4.1.4. Description
	This metric assesses the delay of a stream of packets exchanged		This metric assesses the delay of a stream of packets exchanged
	between two hosts (which are the two measurement points), and the		between two hosts (which are the two measurement points), and the
	Output is the Round-trip delay for all successfully exchanged packets		Output is the Round-trip delay for all successfully exchanged packets
	expressed as the 95th percentile of their conditional delay		expressed as the 95th percentile of their conditional delay
	distribution.		distribution.
	skipping to change at page 10, line 10 ¶		skipping to change at page 10, line 10 ¶
	[RFC2681]		[RFC2681]
	<specific section reference and additional clarifications, if needed>		<specific section reference and additional clarifications, if needed>
	Section 2.4 of [RFC2681] provides the reference definition of the		Section 2.4 of [RFC2681] provides the reference definition of the
	singleton (single value) Round-trip delay metric. Section 3.4 of		singleton (single value) Round-trip delay metric. Section 3.4 of
	[RFC2681] provides the reference definition expanded to cover a		[RFC2681] provides the reference definition expanded to cover a
	multi-singleton sample. Note that terms such as singleton and sample		multi-singleton sample. Note that terms such as singleton and sample
	are defined in Section 11 of [RFC2330].		are defined in Section 11 of [RFC2330].
	Note that although the definition of "Round-trip-Delay between Src		Note that although the [RFC2681] definition of "Round-trip-Delay
	and Dst" is directionally ambiguous in the text, this metric tightens		between Src and Dst" is directionally ambiguous in the text, this
	the definition further to recognize that the host in the "Src" role		metric tightens the definition further to recognize that the host in
	will send the first packet to "Dst", and ultimately receive the		the "Src" role will send the first packet to "Dst", and ultimately
	corresponding return packet from "Dst" (when neither are lost).		receive the corresponding return packet from "Dst" (when neither are
			lost).
	Finally, note that the variable "dT" is used in [RFC2681] to refer to		Finally, note that the variable "dT" is used in [RFC2681] to refer to
	the value of Round-trip delay in metric definitions and methods. The		the value of Round-trip delay in metric definitions and methods. The
	variable "dT" has been re-used in other IPPM literature to refer to		variable "dT" has been re-used in other IPPM literature to refer to
	different quantities, and cannot be used as a global variable name.		different quantities, and cannot be used as a global variable name.
	4.2.2. Fixed Parameters		4.2.2. Fixed Parameters
	<list and specify Fixed Parameters, input factors that must be		<list and specify Fixed Parameters, input factors that must be
	determined and embedded in the measurement system for use when		determined and embedded in the measurement system for use when
	skipping to change at page 10, line 47 ¶		skipping to change at page 10, line 48 ¶
	o IPv6 header values:		o IPv6 header values:
	* DSCP: set to 0		* DSCP: set to 0
	* Hop Count: set to 255		* Hop Count: set to 255
	* Protocol: Set to 17 (UDP)		* Protocol: Set to 17 (UDP)
	o UDP header values:		o UDP header values:
	* Checksum: the checksum MUST be calculated		* Checksum: the checksum MUST be calculated and included in the
			header
	o UDP Payload		o UDP Payload
	* total of 9 bytes		* total of 9 bytes
	Other measurement parameters:		Other measurement parameters:
	o Tmax: a loss threshold waiting time		o Tmax: a loss threshold waiting time
	* 3.0, expressed in units of seconds, as a positive value of type		* 3.0, expressed in units of seconds, as a positive value of type
	decimal64 with fraction digits = 5 (see section 9.3 of		decimal64 with fraction digits = 5 (see section 9.3 of
	[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with		[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with
	lossless conversion to/from the 32-bit NTP timestamp as per		lossless conversion to/from the 32-bit NTP timestamp as per
	skipping to change at page 15, line 35 ¶		skipping to change at page 15, line 42 ¶
	<insert units for the measured results, and the reference		<insert units for the measured results, and the reference
	specification>.		specification>.
	The 95th Percentile of Round-trip Delay is expressed in seconds.		The 95th Percentile of Round-trip Delay is expressed in seconds.
	4.4.4. Calibration		4.4.4. Calibration
	Section 3.7.3 of [RFC7679] provides a means to quantify the		Section 3.7.3 of [RFC7679] provides a means to quantify the
	systematic and random errors of a time measurement. In-situ		systematic and random errors of a time measurement. In-situ
	calibration could be enabled with an internal loopback that includes		calibration could be enabled with an internal loopback at the Source
	as much of the measurement system as possible, performs address		host that includes as much of the measurement system as possible,
	manipulation as needed, and provides some form of isolation (e.g.,		performs address manipulation as needed, and provides some form of
	deterministic delay) to avoid send-receive interface contention.		isolation (e.g., deterministic delay) to avoid send-receive interface
	Some portion of the random and systematic error can be characterized		contention. Some portion of the random and systematic error can be
	this way.		characterized this way.
	When a measurement controller requests a calibration measurement, the		When a measurement controller requests a calibration measurement, the
	loopback is applied and the result is output in the same format as a		loopback is applied and the result is output in the same format as a
	normal measurement with additional indication that it is a		normal measurement with additional indication that it is a
	calibration result.		calibration result.
	Both internal loopback calibration and clock synchronization can be		Both internal loopback calibration and clock synchronization can be
	used to estimate the *available accuracy* of the Output Metric Units.		used to estimate the *available accuracy* of the Output Metric Units.
	For example, repeated loopback delay measurements will reveal the		For example, repeated loopback delay measurements will reveal the
	portion of the Output result resolution which is the result of system		portion of the Output result resolution which is the result of system
	skipping to change at page 17, line 7 ¶		skipping to change at page 17, line 17 ¶
	<insert numeric identifier, an integer>		<insert numeric identifier, an integer>
	5.1.2. Name		5.1.2. Name
	<insert name according to metric naming convention>		<insert name according to metric naming convention>
	OWPDV_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile		OWPDV_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile
	5.1.3. URIs		5.1.3. URIs
	URI: Prefix urn:ietf:metric:<name>		URI: Prefix urn:ietf:metrics:perf:<name>
	URL: http://<TBD by IANA>/<name>		URL: http://<TBD by IANA>/<name>
	5.1.4. Description		5.1.4. Description
	An assessment of packet delay variation with respect to the minimum		An assessment of packet delay variation with respect to the minimum
	delay observed on the stream, and the Output is expressed as the 95th		delay observed on the stream, and the Output is expressed as the 95th
	percentile of the packet delay variation distribution.		percentile of the packet delay variation distribution.
	5.1.5. Change Controller		5.1.5. Change Controller
	<org or person >		<org or person >
			IETF
	5.1.6. Version (of Registry Format)		5.1.6. Version (of Registry Format)
	1.0		1.0
	5.2. Metric Definition		5.2. Metric Definition
	This category includes columns to prompt the entry of all necessary		This category includes columns to prompt the entry of all necessary
	details related to the metric definition, including the RFC reference		details related to the metric definition, including the RFC reference
	and values of input factors, called fixed parameters.		and values of input factors, called fixed parameters.
	skipping to change at page 18, line 32 ¶		skipping to change at page 18, line 43 ¶
	o IPv6 header values:		o IPv6 header values:
	* DSCP: set to 0		* DSCP: set to 0
	* Hop Count: set to 255		* Hop Count: set to 255
	* Protocol: Set to 17 (UDP)		* Protocol: Set to 17 (UDP)
	o UDP header values:		o UDP header values:
	* Checksum: the checksum MUST be calculated		* Checksum: the checksum MUST be calculated and included in the
			header
	o UDP Payload		o UDP Payload
	* total of 200 bytes		* total of 200 bytes
	Other measurement parameters:		Other measurement parameters:
	Tmax: a loss threshold waiting time with value 3.0, expressed in		Tmax: a loss threshold waiting time with value 3.0, expressed in
	units of seconds, as a positive value of type decimal64 with		units of seconds, as a positive value of type decimal64 with
	fraction digits = 5 (see section 9.3 of [RFC6020]) and with		fraction digits = 5 (see section 9.3 of [RFC6020]) and with
	resolution of 0.0001 seconds (0.1 ms), with lossless conversion		resolution of 0.0001 seconds (0.1 ms), with lossless conversion
	to/from the 32-bit NTP timestamp as per section 6 of [RFC5905].		to/from the 32-bit NTP timestamp as per section 6 of [RFC5905].
	F a selection function unambiguously defining the packets from the		F a selection function unambiguously defining the packets from the
	stream selected for the metric. See section 4.2 of [RFC5481] for		stream selected for the metric. See section 4.2 of [RFC5481] for
	the PDV form.		the PDV form.
			See the Packet Stream generation category for two additional Fixed
			Parameters.
	5.3. Method of Measurement		5.3. Method of Measurement
	This category includes columns for references to relevant sections of		This category includes columns for references to relevant sections of
	the RFC(s) and any supplemental information needed to ensure an		the RFC(s) and any supplemental information needed to ensure an
	unambiguous methods for implementations.		unambiguous methods for implementations.
	5.3.1. Reference Method		5.3.1. Reference Method
	<for metric, insert relevant section references and supplemental		<for metric, insert relevant section references and supplemental
	info>		info>
	skipping to change at page 20, line 20 ¶		skipping to change at page 20, line 29 ¶
	Poisson sampling intervals. the reciprocal of lambda is the average		Poisson sampling intervals. the reciprocal of lambda is the average
	packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/		packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/
	lambda, in seconds.		lambda, in seconds.
	>>> Check with Sam, most likely it is this...		>>> Check with Sam, most likely it is this...
	Method 3 SHALL be used, where given a start time (Run-time		Method 3 SHALL be used, where given a start time (Run-time
	Parameter), the subsequent send times are all computed prior to		Parameter), the subsequent send times are all computed prior to
	measurement by computing the pseudo-random distribution of inter-		measurement by computing the pseudo-random distribution of inter-
	packet send times, (truncating the distribution as specified in the		packet send times, (truncating the distribution as specified in the
	Run-time Parameter, Trunc), and the Src sends each packet at the		Parameter Trunc), and the Src sends each packet at the computed
	computed times.		times.
	Note that Trunc is the upper limit on inter-packet times in the		Note that Trunc is the upper limit on inter-packet times in the
	Poisson distribution. A random value greater than Trunc is set equal		Poisson distribution. A random value greater than Trunc is set equal
	to Trunc instead.		to Trunc instead.
	o lambda, a rate in reciprocal seconds (for Poisson Streams).		Reciprocal_lambda average packet interval for Poisson Streams
	lambda = 1 packet per second		expressed in units of seconds, as a positive value of type
			decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020])
			with resolution of 0.0001 seconds (0.1 ms), and with lossless
			conversion to/from the 32-bit NTP timestamp as per section 6 of
			[RFC5905]. Reciprocal_lambda = 1 packet per second.
	o Upper limit on Poisson distribution (values above this limit will		Trunc Upper limit on Poisson distribution expressed in units of
	be clipped and set to the limit value). Upper limit = 30 seconds.		seconds, as a positive value of type decimal64 with fraction
			digits = 5 (see section 9.3 of [RFC6020]) with resolution of
			0.0001 seconds (0.1 ms), and with lossless conversion to/from the
			32-bit NTP timestamp as per section 6 of [RFC5905] (values above
			this limit will be clipped and set to the limit value). Trunc =
			30.0000 seconds.
	5.3.3. Traffic Filtering (observation) Details		5.3.3. Traffic Filtering (observation) Details
	<insert the measured results based on a filtered version of the		<insert the measured results based on a filtered version of the
	packets observed, and this section provides the filter details (when		packets observed, and this section provides the filter details (when
	present), and section reference>.		present), and section reference>.
	NA		NA
	5.3.4. Sampling Distribution		5.3.4. Sampling Distribution
	skipping to change at page 21, line 25 ¶		skipping to change at page 21, line 45 ¶
	[RFC2330]. When T0 is "all-zeros", a start time is unspecified		[RFC2330]. When T0 is "all-zeros", a start time is unspecified
	and Tf is to be interpreted as the Duration of the measurement		and Tf is to be interpreted as the Duration of the measurement
	interval. The start time is controlled through other means.		interval. The start time is controlled through other means.
	Tf a time, the end of a measurement interval, (format "date-and-time"		Tf a time, the end of a measurement interval, (format "date-and-time"
	as specified in Section 5.6 of [RFC3339], see also Section 3 of		as specified in Section 5.6 of [RFC3339], see also Section 3 of
	[RFC6991]). The UTC Time Zone is required by Section 6.1 of		[RFC6991]). The UTC Time Zone is required by Section 6.1 of
	[RFC2330]. When T0 is "all-zeros", a end time date is ignored and		[RFC2330]. When T0 is "all-zeros", a end time date is ignored and
	Tf is interpreted as the Duration of the measurement interval.		Tf is interpreted as the Duration of the measurement interval.
	Reciprocal_lambda average packet interval for Poisson Streams
	expressed in units of seconds, as a positive value of type
	decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020])
	with resolution of 0.0001 seconds (0.1 ms), and with lossless
	conversion to/from the 32-bit NTP timestamp as per section 6 of
	[RFC5905].
	Trunc Upper limit on Poisson distribution expressed in units of
	seconds, as a positive value of type decimal64 with fraction
	digits = 5 (see section 9.3 of [RFC6020]) with resolution of
	0.0001 seconds (0.1 ms), and with lossless conversion to/from the
	32-bit NTP timestamp as per section 6 of [RFC5905] (values above
	this limit will be clipped and set to the limit value). (if fixed,
	Trunc = 30.0000 seconds.)
	>>> should Poisson run-time params be fixed instead? probably yes if
	modeling a specific version of MBA tests.
	5.3.6. Roles		5.3.6. Roles
	<lists the names of the different roles from the measurement method>		<lists the names of the different roles from the measurement method>
	Src launches each packet to Dst.		Src launches each packet to Dst.
	Dst waits for each packet from Src.		Dst waits for each packet from Src.
	5.4. Output		5.4. Output
	skipping to change at page 25, line 9 ¶		skipping to change at page 25, line 9 ¶
	<skipping some admin columns for now>		<skipping some admin columns for now>
	6.1.1. ID (Identifier)		6.1.1. ID (Identifier)
	<insert numeric identifier, an integer>		<insert numeric identifier, an integer>
	6.1.2. Name		6.1.2. Name
	<insert name according to metric naming convention>		<insert name according to metric naming convention>
	RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile		RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_Raw
	6.1.3. URI		6.1.3. URI
	URI: Prefix urn:ietf:metric:<name>		URI: Prefix urn:ietf:metrics:perf:<name>
	URL: http://<TBD by IANA>/<name>		URL: http://<TBD by IANA>/<name>
	6.1.4. Description		6.1.4. Description
	This metric assesses the response time, the interval from the query		This metric assesses the response time, the interval from the query
	transmission to the response.		transmission to the response.
	6.1.5. Change Controller		6.1.5. Change Controller
	skipping to change at page 26, line 7 ¶		skipping to change at page 26, line 7 ¶
	Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay		Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
	Metric for IPPM", RFC 2681, September 1999.		Metric for IPPM", RFC 2681, September 1999.
	[RFC2681]		[RFC2681]
	<specific section reference and additional clarifications, if needed>		<specific section reference and additional clarifications, if needed>
	Section 2.4 of [RFC2681] provides the reference definition of the		Section 2.4 of [RFC2681] provides the reference definition of the
	singleton (single value) Round-trip delay metric. Section 3.4 of		singleton (single value) Round-trip delay metric. Section 3.4 of
	[RFC2681] provides the reference definition expanded to cover a		[RFC2681] provides the reference definition expanded to cover a
	multi-value sample. Note that terms such as singleton and sample are		multi-singleton sample. Note that terms such as singleton and sample
	defined in Section 11 of [RFC2330].		are defined in Section 11 of [RFC2330].
	For DNS Response Latency, the entities in [RFC1035] must be mapped to		For DNS Response Latency, the entities in [RFC1035] must be mapped to
	[RFC2681]. The Local Host with its User Program and Resolver take		[RFC2681]. The Local Host with its User Program and Resolver take
	the role of "Src", and the Foreign Name Server takes the role of		the role of "Src", and the Foreign Name Server takes the role of
	"Dst".		"Dst".
	Note that although the definition of "Round-trip-Delay between Src		Note that although the [RFC2681] definition of "Round-trip-Delay
	and Dst at T" is directionally ambiguous in the text, this metric		between Src and Dst at T" is directionally ambiguous in the text,
	tightens the definition further to recognize that the host in the		this metric tightens the definition further to recognize that the
	"Src" role will send the first packet to "Dst", and ultimately		host in the "Src" role will send the first packet to "Dst", and
	receive the corresponding return packet from "Dst" (when neither are		ultimately receive the corresponding return packet from "Dst" (when
	lost).		neither are lost).
	6.2.2. Fixed Parameters		6.2.2. Fixed Parameters
	<list and specify Fixed Parameters, input factors that must be		<list and specify Fixed Parameters, input factors that must be
	determined and embedded in the measurement system for use when		determined and embedded in the measurement system for use when
	needed>		needed>
	Type-P:		Type-P as defined in Section 13 of [RFC2330]:
	o IPv4 header values:		o IPv4 header values:
	* DSCP: set to 0		* DSCP: set to 0
	* TTL set to 255		* TTL set to 255
	* Protocol: Set to 17 (UDP)		* Protocol: Set to 17 (UDP)
			o IPv6 header values:
			* DSCP: set to 0
			* Hop Count: set to 255
			* Protocol: Set to 17 (UDP)
	o UDP header values:		o UDP header values:
	* Source port: 53		* Source port: 53
	* Destination port: 53		* Destination port: 53
			* Checksum: the checksum must be calculated and included in the
	* Checksum: the checksum must be calculated		header
	o Payload: The payload contains a DNS message as defined in RFC 1035		o Payload: The payload contains a DNS message as defined in RFC 1035
	[RFC1035] with the following values:		[RFC1035] with the following values:
	* The DNS header section contains:		* The DNS header section contains:
			+ Identification (see the Run-time column)
	+ QR: set to 0 (Query)		+ QR: set to 0 (Query)
	+ OPCODE: set to 0 (standard query)		+ OPCODE: set to 0 (standard query)
	+ AA: not set		+ AA: not set
	+ TC: not set		+ TC: not set
	+ RD: set to one (recursion desired)		+ RD: set to one (recursion desired)
	+ RA: not set		+ RA: not set
	skipping to change at page 27, line 26 ¶		skipping to change at page 27, line 38 ¶
	+ QDCOUNT: set to one (only one entry)		+ QDCOUNT: set to one (only one entry)
	+ ANCOUNT: not set		+ ANCOUNT: not set
	+ NSCOUNT: not set		+ NSCOUNT: not set
	+ ARCOUNT: not set		+ ARCOUNT: not set
	* The Question section contains:		* The Question section contains:
	+ QNAME: the FQDN provided as input for the test		+ QNAME: the Fully Qualified Domain Name (FQDN) provided as
			input for the test, see the Run-time column
	+ QTYPE: the query type provided as input for the test		+ QTYPE: the query type provided as input for the test, see
			the Run-time column
	+ QCLASS: set to IN		+ QCLASS: set to 1 for IN
	* The other sections do not contain any Resource Records.		* The other sections do not contain any Resource Records.
			Other measurement parameters:
			o Tmax: a loss threshold waiting time (and to help disambiguate
			queries)
			* 5.0, expressed in units of seconds, as a positive value of type
			decimal64 with fraction digits = 5 (see section 9.3 of
			[RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with
			lossless conversion to/from the 32-bit NTP timestamp as per
			section 6 of [RFC5905].
	Observation: reply packets will contain a DNS response and may		Observation: reply packets will contain a DNS response and may
	contain RRs.		contain RRs.
	Timeout: Tmax = 5 seconds (to help disambiguate queries)
	6.3. Method of Measurement		6.3. Method of Measurement
	This category includes columns for references to relevant sections of		This category includes columns for references to relevant sections of
	the RFC(s) and any supplemental information needed to ensure an		the RFC(s) and any supplemental information needed to ensure an
	unambiguous methods for implementations.		unambiguous methods for implementations.
	6.3.1. Reference Method		6.3.1. Reference Method
	<for metric, insert relevant section references and supplemental		<for metric, insert relevant section references and supplemental
	info>		info>
	The methodology for this metric is defined as Type-P-Round-trip-		The methodology for this metric is defined as Type-P-Round-trip-
	Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section		Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section
	3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under		3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under
	Fixed Parameters.		Fixed Parameters.
	The method requires sequence numbers or other send-order information		The reference method distinguishes between long-delayed packets and
	to be retained at the Src or included with each packet to dis-		lost packets by implementing a maximum waiting time for packet
	ambiguate packet reordering if it occurs. Sequence number is part of		arrival. Tmax is the waiting time used as the threshold to declare a
	the payload described under Fixed Parameters.		packet lost. Lost packets SHALL be designated as having undefined
			delay.
	DNS Messages bearing Queries provide for random ID Numbers, so more		The calculations on the delay (RTT) SHALL be performed on the
	than one query may be launched while a previous request is		conditional distribution, conditioned on successful packet arrival
	outstanding when the ID Number is used.		within Tmax. Also, when all packet delays are stored, the process
			which calculates the RTT value MAY enforce the Tmax threshold on
			stored values before calculations. See section 4.1 of [RFC3393] for
			details on the conditional distribution to exclude undefined values
			of delay, and Section 5 of [RFC6703] for background on this analysis
			choice.
			The reference method requires some way to distinguish between
			different packets in a stream to establish correspondence between
			sending times and receiving times for each successfully-arriving
			reply. Therefore, sequence numbers or other send-order
			identification MUST be retained at the Src or included with each
			packet to dis-ambiguate packet reordering if it occurs. Sequence
			number is part of the payload described under Fixed Parameters.
			DNS Messages bearing Queries provide for random ID Numbers in the
			Identification header field, so more than one query may be launched
			while a previous request is outstanding when the ID Number is used.
	IF a DNS response does not arrive within Tmax, the result is		IF a DNS response does not arrive within Tmax, the result is
	undefined. The Message ID SHALL be used to disambiguate the		undefined. The Message ID SHALL be used to disambiguate the
	successive queries.		successive queries.
	>>> This would require support of ID generation and population in the		>>> This would require support of ID generation and population in the
	Message. An alternative would be to use a random Source port on the		Message. An alternative would be to use a random Source port on the
	Query Message, but we would choose ONE before proceding.		Query Message, but we would choose ONE before proceding.
	Refer to Section 4.4 of [RFC6673] for expanded discussion of the		Refer to Section 4.4 of [RFC6673] for expanded discussion of the
	instruction to "send a Type-P packet back to the Src as quickly as		instruction to "send a Type-P packet back to the Src as quickly as
	possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of		possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of
	[RFC6673] presents additional requirements which shall be included in		[RFC6673] presents additional requirements which shall be included in
	the method of measurement for this metric.		the method of measurement for this metric.
	6.3.2. Packet Generation Stream		In addition to operations described in [RFC2681], the Src MUST parse
			the DNS headers of the reply and prepare the information for
			subsequent reporting as a measured result, along with the Round-Trip
			Delay.
			6.3.2. Packet Stream Generation
	This section gives the details of the packet traffic which is the		This section gives the details of the packet traffic which is the
	basis for measurement. In IPPM metrics, this is called the Stream,		basis for measurement. In IPPM metrics, this is called the Stream,
	and can easily be dscribed by providing the list of stream		and can easily be dscribed by providing the list of stream
	parameters.		parameters.
	<list of generation parameters and section/spec references if needed>		<list of generation parameters and section/spec references if needed>
	Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to		Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to
	generate Poisson sampling intervals. the reciprocal of lambda is the		generate Poisson sampling intervals. The reciprocal of lambda is the
	average packet rate, thus the Run-time Parameter is 1/lambda.		average packet rate, thus the Run-time Parameter is Reciprocal_lambda
			= 1/lambda, in seconds.
	>>> Check with Sam, most likely it is this...
	Method 3 is used, where given a start time (Run-time Parameter), the		Method 3 is used, where given a start time (Run-time Parameter), the
	subsequent send times are all computed prior to measurement by		subsequent send times are all computed prior to measurement by
	computing the pseudo-random distribution of inter-packet send times,		computing the pseudo-random distribution of inter-packet send times,
	(truncating the distribution as specified in the Run-time		(truncating the distribution as specified in the Run-time
	Parameters), and the Src sends each packet at the computed times.		Parameters), and the Src sends each packet at the computed times.
			Note that Trunc is the upper limit on inter-packet times in the
			Poisson distribution. A random value greater than Trunc is set equal
			to Trunc instead.
	6.3.3. Traffic Filtering (observation) Details		6.3.3. Traffic Filtering (observation) Details
	The measured results based on a filtered version of the packets		The measured results based on a filtered version of the packets
	observed, and this section provides the filter details (when		observed, and this section provides the filter details (when
	present).		present).
	<section reference>.		<section reference>.
	NA		NA
	skipping to change at page 29, line 30 ¶		skipping to change at page 30, line 30 ¶
	NA		NA
	6.3.5. Run-time Parameters and Data Format		6.3.5. Run-time Parameters and Data Format
	Run-time Parameters are input factors that must be determined,		Run-time Parameters are input factors that must be determined,
	configured into the measurement system, and reported with the results		configured into the measurement system, and reported with the results
	for the context to be complete.		for the context to be complete.
	<list of run-time parameters, and their data formats>		<list of run-time parameters, and their data formats>
	o Src, the IP address of a host (32-bit value for IPv4, 128-bit		Src the IP address of the host in the Src Role (format ipv4-address-
	value for IPv6)		no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
			see Section 4 of [RFC6991])
	o Dst, the IP address of a host (32-bit value for IPv4, 128-bit		Dst the IP address of the host in the Dst Role (format ipv4-address-
	value for IPv6)		no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
			see section 4 of [RFC6991])
	o T0, a time (start of measurement interval, 128-bit NTP Date		T0 a time, the start of a measurement interval, (format "date-and-
	Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a		time" as specified in Section 5.6 of [RFC3339], see also Section 3
	start time is unspecified and Tf is to be interpreted as the		of [RFC6991]). The UTC Time Zone is required by Section 6.1 of
	Duration of the measurement interval.		[RFC2330]. When T0 is "all-zeros", a start time is unspecified
			and Tf is to be interpreted as the Duration of the measurement
			interval. The start time is controlled through other means.
	o Tf, a time (end of measurement interval, 128-bit NTP Date Format,		Tf a time, the end of a measurement interval, (format "date-and-time"
	see section 6 of [RFC5905]), interpreted as the Duration of the		as specified in Section 5.6 of [RFC3339], see also Section 3 of
	measurement interval.		[RFC6991]). The UTC Time Zone is required by Section 6.1 of
			[RFC2330]. When T0 is "all-zeros", a end time date is ignored and
			Tf is interpreted as the Duration of the measurement interval.
	o 1/lambda, average packet rate (for Poisson Streams). (1/lambda =		Reciprocal_lambda average packet interval for Poisson Streams
	0.1 packet per second, if fixed)		expressed in units of seconds, as a positive value of type
			decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020])
			with resolution of 0.0001 seconds (0.1 ms), and with lossless
			conversion to/from the 32-bit NTP timestamp as per section 6 of
			[RFC5905].
	o Upper limit on Poisson distribution (values above this limit will		Trunc Upper limit on Poisson distribution expressed in units of
	be clipped and set to the limit value). (if fixed, Upper limit =		seconds, as a positive value of type decimal64 with fraction
	300 seconds.)		digits = 5 (see section 9.3 of [RFC6020]) with resolution of
			0.0001 seconds (0.1 ms), and with lossless conversion to/from the
			32-bit NTP timestamp as per section 6 of [RFC5905] (values above
			this limit will be clipped and set to the limit value). (if fixed,
			Trunc = 30.0000 seconds.)
	o ID, the 16-bit identifier assigned by the program that generates		ID The 16-bit identifier assigned by the program that generates the
	the query, and which must vary in successive queries, see		query, and which must vary in successive queries, see
	Section 4.1.1 of [RFC1035]. This identifier is copied into the		Section 4.1.1 of [RFC1035]. This identifier is copied into the
	corresponding reply and can be used by the requester to match-up		corresponding reply and can be used by the requester (Src) to
	replies to outstanding queries.		match-up replies to outstanding queries.
	The format for 1/lambda and Upper limit of Poisson Dist. are the		QNAME The domain name of the Query, formatted as specified in
	short format in [RFC5905] (32 bits) and is as follows: the first 16		section 4 of [RFC6991].
	bits represent the integer number of seconds; the next 16 bits
	represent the fractional part of a second.
	>>> should Poisson run-time params be fixed instead? probably yes if		QTYPE The Query Type, which will correspond to the IP address family
	modeling a specific version of MBA tests.		of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a
			uint16, as per section 9.2 of [RFC6020].
	6.3.6. Roles		6.3.6. Roles
	<lists the names of the different roles from the measurement method>		<lists the names of the different roles from the measurement method>
	Src - launches each packet and waits for return transmissions from		Src launches each packet and waits for return transmissions from
	Dst.		Dst.
	Dst - waits for each packet from Src and sends a return packet to		Dst waits for each packet from Src and sends a return packet to Src.
	Src.
	6.4. Output		6.4. Output
	This category specifies all details of the Output of measurements		This category specifies all details of the Output of measurements
	using the metric.		using the metric.
	6.4.1. Type/Value (two diff terms used)		6.4.1. Type
	<insert name of the output type, raw or a selected summary statistic>		<insert name of the output type, raw or a selected summary statistic>
	For all output types:		Raw -- for each DNS Query packet sent, sets of values as defined in
			the next column, including the status of the response, only assigning
	o T0, a time (start of measurement interval, 128-bit NTP Date		delay values to successful query-response pairs.
	Format, see section 6 of [RFC5905])
	o Tf, a time (end of measurement interval, 128-bit NTP Date Format,
	see section 6 of [RFC5905])
	Raw -- for each packet sent, pairs of values.
	>>> and the status of the response, only assigning values to
	successful query-response pairs.
	Percentile -- for the conditional distribution of all packets with a
	valid value of Round-trip delay (undefined delays are excluded), a
	single value corresponding to the 95th percentile.
	6.4.2. Reference Definition		6.4.2. Reference Definition
	<describe the data format for each type of result>		<describe the data format for each type of result>
	Raw -- for each packet sent, pairs of values as follows:		For all outputs:
	o T, the time when the packet was sent from Src, 128-bit NTP Date
	Format, see section 6 of [RFC5905])
	o dT, a value of Round-trip delay, format is *similar to* the 32-bit
	short NTP Time format in Section 6 of [RFC5905] and is as follows:
	the first 16 bits represent the *signed* integer number of
	seconds; the next 16 bits represent the fractional part of a
	second.
	o dT is undefined when the packet is not received at Src in waiting
	time Tmxax seconds (need undefined code for no-response or un-
	successful response)
	Percentile -- for the conditional distribution of all packets with a
	valid value of Round-trip delay (undefined delays are excluded), a
	single value as follows:
	See section 4.1 of [RFC3393] for details on the conditional
	distribution to exclude undefined values of delay, and Section 5 of
	[RFC6703] for background on this analysis choice.
	See section 4.3 of [RFC3393] for details on the percentile statistic		T the time the DNS Query was sent during the measurement interval,
	(where Round-trip delay should be substituted for "ipdv").		(format "date-and-time" as specified in Section 5.6 of [RFC3339],
			see also Section 3 of [RFC6991]). The UTC Time Zone is required
			by Section 6.1 of [RFC2330].
	The percentile = 95.		dT The time value of the round-trip delay to receive the DNS
			response, expressed in units of seconds, as a positive value of
			type decimal64 with fraction digits = 9 (see section 9.3 of
			[RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and
			with lossless conversion to/from the 64-bit NTP timestamp as per
			section 6 of RFC [RFC5905]. This value is undefined when the
			response packet is not received at Src within waiting time Tmxax
			seconds.
	Data format is a 32-bit signed floating point value, *similar to* the		Rcode The value of the Rcode field in the DNS response header,
	32-bit short NTP Time format in Section 6 of [RFC5905] and is as		expressed as a uint64 as specified in section 9.2 of [RFC6020].
	follows: the first 16 bits represent the *signed* integer number of		Non-zero values convey errors in the response, and such replies
	seconds; the next 16 bits represent the fractional part of a second.		must be analyzed separately from successful requests.
	6.4.3. Metric Units		6.4.3. Metric Units
	<insert units for the measured results, and the reference		<insert units for the measured results, and the reference
	specification>.		specification>.
	Round-trip Delay, dT, is expressed in seconds.		Round-trip Delay, dT, is expressed in seconds.
	The 95th Percentile of Round-trip Delay is expressed in seconds.
	6.4.4. Calibration		6.4.4. Calibration
	<pointer to >		Section 3.7.3 of [RFC7679] provides a means to quantify the
			systematic and random errors of a time measurement. In-situ
			calibration could be enabled with an internal loopback at the Source
			host that includes as much of the measurement system as possible,
			performs address and payload manipulation as needed, and provides
			some form of isolation (e.g., deterministic delay) to avoid send-
			receive interface contention. Some portion of the random and
			systematic error can be characterized this way.
			When a measurement controller requests a calibration measurement, the
			loopback is applied and the result is output in the same format as a
			normal measurement with additional indication that it is a
			calibration result.
			Both internal loopback calibration and clock synchronization can be
			used to estimate the *available accuracy* of the Output Metric Units.
			For example, repeated loopback delay measurements will reveal the
			portion of the Output result resolution which is the result of system
			noise, and thus inaccurate.
	6.5. Administrative items		6.5. Administrative items
	6.5.1. Status		6.5.1. Status
	<current or depricated>		<current or depricated>
	6.5.2. Requestor (keep?)		6.5.2. Requestor
	name or RFC, etc.		name or RFC, etc.
	6.5.3. Revision		6.5.3. Revision
	1.0		1.0
	6.5.4. Revision Date		6.5.4. Revision Date
	YYYY-MM-DD		YYYY-MM-DD
	6.6. Comments and Remarks		6.6. Comments and Remarks
	Additional (Informational) details for this entry		Additional (Informational) details for this entry
	7. UDP Poisson One-way Delay Registry Entries		7. UDP Poisson One-way Delay Registry Entries
	This section gives an initial registry entry for the UDP Poisson One-		This section specifies five initial registry entries for the UDP
	way Delay.		Poisson One-way Delay.
	Note: Each Registry "Name" below specifies a single registry entry,		Note: Each Registry "Name" below specifies a single registry entry,
	whose output format varies according to a component of the name that		whose output format varies according to the <statistic> element of
	specifies one form of statistical summary.		the name that specifies one form of statistical summary.
	IANA is asked to assign a different numeric identifiers to each Name.		IANA is asked to assign a different numeric identifiers to each of
	All column entries beside the Summary and Output categories are the		the five Metrics. All column entries beside the ID, Name,
	same, thus this section proposes five closely-related registry		Description, and Output Reference Method categories are the same,
	entries. As a result, IANA is also asked to assign corresponding		thus this section proposes five closely-related registry entries. As
	URIs and URLs.		a result, IANA is also asked to assign corresponding URNs and URLs to
			each Named Metric.
	7.1. Summary		7.1. Summary
	This category includes multiple indexes to the registry entries, the		This category includes multiple indexes to the registry entries, the
	element ID and metric name.		element ID and metric name.
	7.1.1. ID (Identifier)		7.1.1. ID (Identifier)
	<insert numeric identifier, an integer, one corresponding to each		<insert numeric identifier, an integer, one corresponding to each
	name below>		name below>
	7.1.2. Name		7.1.2. Name
	<insert name according to metric naming convention>		<insert name according to metric naming convention>
	OWDelay_Active_IP-UDP-Poisson-		OWDelay_Active_IP-UDP-Poisson-
	Payload250B_RFCXXXXsecY_Seconds_<statistic>		Payload250B_RFCXXXXsecY_Seconds_<statistic>
	OWDelay_Active_IP-UDP-Poisson-		where <statistic> is one of:
	Payload250B_RFCXXXXsecY_Seconds_95Percentile
	OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Mean		o 95Percentile
	OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Min		o Mean
	OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Max		o Min
	OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_StdDev		o Max
			o StdDev
	7.1.3. URI and URL		7.1.3. URI and URL
	URI: Prefix urn:ietf:params:performance:metric...<name>		URI: Prefix urn:ietf:metrics:perf:<name>
	URL: http:\\www.iana.org\ ... <name>		URL: http:\\www.iana.org\ ... <name>
	7.1.4. Description		7.1.4. Description
	This metric assesses the delay of a stream of packets exchanged		This metric assesses the delay of a stream of packets exchanged
	between two hosts (or measurement points), and reports the		between two hosts (or measurement points), and reports the
	<statistic> One-way delay for all successfully exchanged packets		<statistic> One-way delay for all successfully exchanged packets
	based on their conditional delay distribution.		based on their conditional delay distribution.
			where <statistic> is one of:
			o 95Percentile
			o Mean
			o Min
			o Max
			o StdDev
	7.2. Metric Definition		7.2. Metric Definition
	This category includes columns to prompt the entry of all necessary		This category includes columns to prompt the entry of all necessary
	details related to the metric definition, including the RFC reference		details related to the metric definition, including the RFC reference
	and values of input factors, called fixed parameters.		and values of input factors, called fixed parameters.
	7.2.1. Reference Definition		7.2.1. Reference Definition
	<Full bibliographic reference to an immutable doc.>		<Full bibliographic reference to an immutable doc.>
	Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-		Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-
	Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC		Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC
	7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-		7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-
	editor.org/info/rfc7679>.		editor.org/info/rfc7679>.
	[RFC2679]		[RFC7679]
	Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC		Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC
	6049, January 2011.		6049, January 2011.
	[RFC6049]		[RFC6049]
	<specific section reference and additional clarifications, if needed>		<specific section reference and additional clarifications, if needed>
	Section 3.4 of [RFC2679] provides the reference definition of the		Section 3.4 of [RFC7679] provides the reference definition of the
	singleton (single value) One-way delay metric. Section 4.4 of		singleton (single value) One-way delay metric. Section 4.4 of
	[RFC2679] provides the reference definition expanded to cover a		[RFC7679] provides the reference definition expanded to cover a
	multi-value sample. Note that terms such as singleton and sample are		multi-value sample. Note that terms such as singleton and sample are
	defined in Section 11 of [RFC2330].		defined in Section 11 of [RFC2330].
	Only successful packet transfers with finite delay are included in		Only successful packet transfers with finite delay are included in
	the sample, as prescribed in section 4.1.2 of [RFC6049].		the sample, as prescribed in section 4.1.2 of [RFC6049].
	NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft-
	ietf-ippm-2679-bis-01.
	7.2.2. Fixed Parameters		7.2.2. Fixed Parameters
	<list and specify Fixed Parameters, input factors that must be		<list and specify Fixed Parameters, input factors that must be
	determined and embedded in the measurement system for use when		determined and embedded in the measurement system for use when
	needed>		needed>
	Type-P:		Type-P:
	o IPv4 header values:		o IPv4 header values:
	* DSCP: set to 0		* DSCP: set to 0
	* TTL set to 255		* TTL: set to 255
			* Protocol: Set to 17 (UDP)
			o IPv6 header values:
			* DSCP: set to 0
			* Hop Count: set to 255
	* Protocol: Set to 17 (UDP)		* Protocol: Set to 17 (UDP)
	o UDP header values:		o UDP header values:
	* Checksum: the checksum must be calculated		* Checksum: the checksum MUST be calculated and included in the
			header
	o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357]		o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357]
	* Security features in use influence the number of Padding		* Security features in use influence the number of Padding
	octets.		octets.
	* 250 octets total, including the TWAMP format		* 250 octets total, including the TWAMP format
	Timeout, Tmax: 3 seconds		Other measurement parameters:
			Tmax: a loss threshold waiting time with value 3.0, expressed in
			units of seconds, as a positive value of type decimal64 with
			fraction digits = 5 (see section 9.3 of [RFC6020]) and with
			resolution of 0.0001 seconds (0.1 ms), with lossless conversion
			to/from the 32-bit NTP timestamp as per section 6 of [RFC5905].
			See the Packet Stream generation category for two additional Fixed
			Parameters.
	7.3. Method of Measurement		7.3. Method of Measurement
	This category includes columns for references to relevant sections of		This category includes columns for references to relevant sections of
	the RFC(s) and any supplemental information needed to ensure an		the RFC(s) and any supplemental information needed to ensure an
	unambiguous methods for implementations.		unambiguous methods for implementations.
	7.3.1. Reference Method		7.3.1. Reference Method
	<for metric, insert relevant section references and supplemental		<for metric, insert relevant section references and supplemental
	skipping to change at page 35, line 19 ¶		skipping to change at page 37, line 4 ¶
	7.3. Method of Measurement		7.3. Method of Measurement
	This category includes columns for references to relevant sections of		This category includes columns for references to relevant sections of
	the RFC(s) and any supplemental information needed to ensure an		the RFC(s) and any supplemental information needed to ensure an
	unambiguous methods for implementations.		unambiguous methods for implementations.
	7.3.1. Reference Method		7.3.1. Reference Method
	<for metric, insert relevant section references and supplemental		<for metric, insert relevant section references and supplemental
	info>		info>
	The methodology for this metric is defined as Type-P-One-way-Delay-		The methodology for this metric is defined as Type-P-One-way-Delay-
	Poisson-Stream in section 3.6 of [RFC2679] and section 4.6 of		Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of
	[RFC2679] using the Type-P and Timeout defined under Fixed		[RFC7679] using the Type-P and Tmax defined under Fixed Parameters.
	Parameters.
	The method requires sequence numbers or other send-order information		The reference method distinguishes between long-delayed packets and
	to be retained at the Src or included with each packet to dis-		lost packets by implementing a maximum waiting time for packet
	ambiguate packet reordering if it occurs. Sequence number is part of		arrival. Tmax is the waiting time used as the threshold to declare a
	the TWAMP payload described under Fixed Parameters.		packet lost. Lost packets SHALL be designated as having undefined
			delay.
	7.3.2. Packet Generation Stream		The calculations on the one-way delay SHALL be performed on the
			conditional distribution, conditioned on successful packet arrival
			within Tmax. Also, when all packet delays are stored, the process
			which calculates the one-way delay value MAY enforce the Tmax
			threshold on stored values before calculations. See section 4.1 of
			[RFC3393] for details on the conditional distribution to exclude
			undefined values of delay, and Section 5 of [RFC6703] for background
			on this analysis choice.
			The reference method requires some way to distinguish between
			different packets in a stream to establish correspondence between
			sending times and receiving times for each successfully-arriving
			packet. Sequence numbers or other send-order identification MUST be
			retained at the Src or included with each packet to dis-ambiguate
			packet reordering if it occurs.
			Since a standard measurement protocol is employed [RFC5357], then the
			measurement process will determine the sequence numbers or timestamps
			applied to test packets after the Fixed and Runtime parameters are
			passed to that process. The measurement protocol dictates the format
			of sequence numbers and time-stamps conveyed in the TWAMP-Test packet
			payload.
			7.3.2. Packet Stream Generation
	This section gives the details of the packet traffic which is the		This section gives the details of the packet traffic which is the
	basis for measurement. In IPPM metrics, this is called the Stream,		basis for measurement. In IPPM metrics, this is called the Stream,
	and can easily be dscribed by providing the list of stream		and can easily be dscribed by providing the list of stream
	parameters.		parameters.
	<list of generation parameters and section/spec references if needed>		<list of generation parameters and section/spec references if needed>
	Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to		Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to
	generate Poisson sampling intervals. The reciprocal of lambda is the		generate Poisson sampling intervals. the reciprocal of lambda is the
	average packet rate, thus the Run-time Parameter is 1/lambda.		average packet spacing, thus the Run-time Parameter is
			Reciprocal_lambda = 1/lambda, in seconds.
	Method 3 or equivalent SHALL used, where given a start time (Run-time		Method 3 SHALL be used, where given a start time (Run-time
	Parameter), the subsequent send times are all computed prior to		Parameter), the subsequent send times are all computed prior to
	measurement by computing the pseudo-random distribution of inter-		measurement by computing the pseudo-random distribution of inter-
	packet send times, (truncating the distribution as specified in the		packet send times, (truncating the distribution as specified in the
	Run-time Parameters), and the Src sends each packet at the computed		Parameter Trunc), and the Src sends each packet at the computed
	times.		times.
			Note that Trunc is the upper limit on inter-packet times in the
			Poisson distribution. A random value greater than Trunc is set equal
			to Trunc instead.
			Reciprocal_lambda average packet interval for Poisson Streams
			expressed in units of seconds, as a positive value of type
			decimal64 with fraction digits = 5 (see section 9.3 of [RFC6020])
			with resolution of 0.0001 seconds (0.1 ms), and with lossless
			conversion to/from the 32-bit NTP timestamp as per section 6 of
			[RFC5905]. Reciprocal_lambda = 1 packet per second.
			Trunc Upper limit on Poisson distribution expressed in units of
			seconds, as a positive value of type decimal64 with fraction
			digits = 5 (see section 9.3 of [RFC6020]) with resolution of
			0.0001 seconds (0.1 ms), and with lossless conversion to/from the
			32-bit NTP timestamp as per section 6 of [RFC5905] (values above
			this limit will be clipped and set to the limit value). Trunc =
			30.0000 seconds.
	7.3.3. Traffic Filtering (observation) Details		7.3.3. Traffic Filtering (observation) Details
	NA		NA
	7.3.4. Sampling Distribution		7.3.4. Sampling Distribution
	NA		NA
	7.3.5. Run-time Parameters and Data Format		7.3.5. Run-time Parameters and Data Format
	Run-time Parameters are input factors that must be determined,		Run-time Parameters are input factors that must be determined,
	configured into the measurement system, and reported with the results		configured into the measurement system, and reported with the results
	for the context to be complete.		for the context to be complete.
	<list of run-time parameters, and their data formats>		<list of run-time parameters, and their data formats>
	o Src, the IP address of a host (32-bit value for IPv4, 128-bit		Src the IP address of the host in the Src Role (format ipv4-address-
	value for IPv6)		no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
			see Section 4 of [RFC6991])
	o Dst, the IP address of a host (32-bit value for IPv4, 128-bit
	value for IPv6)
	o T0, a time (start of measurement interval, 128-bit NTP Date
	Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a
	start time is unspecified and Tf is to be interpreted as the
	Duration of the measurement interval.
	o Tf, a time (end of measurement interval, 128-bit NTP Date Format,
	see section 6 of [RFC5905]), interpreted as the Duration of the
	measurement interval.
	o 1/lambda, average packet rate (for Poisson Streams). (1/lambda =
	1 packet per second, if fixed)
	o Upper limit on Poisson distribution (values above this limit will		Dst the IP address of the host in the Dst Role (format ipv4-address-
	be clipped and set to the limit value). (if fixed, Upper limit =		no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
	30 seconds.)		see section 4 of [RFC6991])
	The format for 1/lambda and Upper limit of Poisson Dist. are the		T0 a time, the start of a measurement interval, (format "date-and-
	short format in [RFC5905] (32 bits) and is as follows: the first 16		time" as specified in Section 5.6 of [RFC3339], see also Section 3
	bits represent the integer number of seconds; the next 16 bits		of [RFC6991]). The UTC Time Zone is required by Section 6.1 of
	represent the fractional part of a second.		[RFC2330]. When T0 is "all-zeros", a start time is unspecified
			and Tf is to be interpreted as the Duration of the measurement
			interval. The start time is controlled through other means.
	>>> should Poisson run-time params be fixed instead? probably yes if		Tf a time, the end of a measurement interval, (format "date-and-time"
	modeling a specific version of tests. Note in the NAME, i.e.		as specified in Section 5.6 of [RFC3339], see also Section 3 of
	Poisson3.3		[RFC6991]). The UTC Time Zone is required by Section 6.1 of
			[RFC2330]. When T0 is "all-zeros", a end time date is ignored and
			Tf is interpreted as the Duration of the measurement interval.
	7.3.6. Roles		7.3.6. Roles
	<lists the names of the different roles from the measurement method>		<lists the names of the different roles from the measurement method>
	Src - launches each packet and waits for return transmissions from		Src launches each packet and waits for return transmissions from
	Dst. This is the TWAMP Session-Sender.		Dst. This is the TWAMP Session-Sender.
	Dst - waits for each packet from Src and sends a return packet to		Dst waits for each packet from Src and sends a return packet to Src.
	Src. This is the TWAMP Session-Reflector.		This is the TWAMP Session-Reflector.
	7.4. Output		7.4. Output
	This category specifies all details of the Output of measurements		This category specifies all details of the Output of measurements
	using the metric.		using the metric.
	7.4.1. Type/Value (two diff terms used)		7.4.1. Type
	<insert name of the output type, raw or a selected summary statistic>		<insert name of the output type, raw or a selected summary statistic>
	See subsection titles below for Types.		See subsection titles below for Types.
	7.4.2. Reference Definition		7.4.2. Reference Definition
	<describe the data format for each type of result>		<describe the data format for each type of result>
	For all output types ---		For all output types ---
	o T0, a time (start of measurement interval, 128-bit NTP Date		T0 the start of a measurement interval, (format "date-and-time" as
	Format, see section 6 of [RFC5905])		specified in Section 5.6 of [RFC3339], see also Section 3 of
			[RFC6991]). The UTC Time Zone is required by Section 6.1 of
			[RFC2330].
	o Tf, a time (end of measurement interval, 128-bit NTP Date Format,		Tf the end of a measurement interval, (format "date-and-time" as
	see section 6 of [RFC5905])		specified in Section 5.6 of [RFC3339], see also Section 3 of
			[RFC6991]). The UTC Time Zone is required by Section 6.1 of
			[RFC2330].
			For each <statistic>, one of the following sub-sections apply:
	7.4.2.1. Percentile95		7.4.2.1. Percentile95
	The 95th percentile SHALL be calculated using the conditional		The 95th percentile SHALL be calculated using the conditional
	distribution of all packets with a finite value of One-way delay		distribution of all packets with a finite value of One-way delay
	(undefined delays are excluded), a single value as follows:		(undefined delays are excluded), a single value as follows:
	See section 4.1 of [RFC3393] for details on the conditional		See section 4.1 of [RFC3393] for details on the conditional
	distribution to exclude undefined values of delay, and Section 5 of		distribution to exclude undefined values of delay, and Section 5 of
	[RFC6703] for background on this analysis choice.		[RFC6703] for background on this analysis choice.
	See section 4.3 of [RFC3393] for details on the percentile statistic		See section 4.3 of [RFC3393] for details on the percentile statistic
	(where Round-trip delay should be substituted for "ipdv").		(where Round-trip delay should be substituted for "ipdv").
	The percentile = 95.		The percentile = 95, meaning that the reported delay, "95Percentile",
			is the smallest value of one-way delay for which the Empirical
			Distribution Function (EDF), F(95Percentile) >= 95% of the singleton
			one-way delay values in the conditional distribution. See section
			11.3 of [RFC2330] for the definition of the percentile statistic
			using the EDF.
	The time value of the result is expressed in units of seconds, as a		95Percentile The time value of the result is expressed in units of
	positive value of type decimal64 with fraction digits = 9 (see		seconds, as a positive value of type decimal64 with fraction
	section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0		digits = 9 (see section 9.3 of [RFC6020]) with resolution of
	ns), and with lossless conversion to/from the 64-bit NTP timestamp as		0.000000001 seconds (1.0 ns), and with lossless conversion to/from
	per section 6 of RFC [RFC5905].		the 64-bit NTP timestamp as per section 6 of RFC [RFC5905]
	7.4.2.2. Mean		7.4.2.2. Mean
	The mean SHALL be calculated using the conditional distribution of		The mean SHALL be calculated using the conditional distribution of
	all packets with a finite value of One-way delay (undefined delays		all packets with a finite value of One-way delay (undefined delays
	are excluded), a single value as follows:		are excluded), a single value as follows:
	See section 4.1 of [RFC3393] for details on the conditional		See section 4.1 of [RFC3393] for details on the conditional
	distribution to exclude undefined values of delay, and Section 5 of		distribution to exclude undefined values of delay, and Section 5 of
	[RFC6703] for background on this analysis choice.		[RFC6703] for background on this analysis choice.
	See section 4.2.2 of [RFC6049] for details on calculating this		See section 4.2.2 of [RFC6049] for details on calculating this
	statistic, and 4.2.3 of [RFC6049].		statistic, and 4.2.3 of [RFC6049].
	The time value of the result is expressed in units of seconds, as a		Mean The time value of the result is expressed in units of seconds,
	positive value of type decimal64 with fraction digits = 9 (see		as a positive value of type decimal64 with fraction digits = 9
	section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0		(see section 9.3 of [RFC6020]) with resolution of 0.000000001
	ns), and with lossless conversion to/from the 64-bit NTP timestamp as		seconds (1.0 ns), and with lossless conversion to/from the 64-bit
	per section 6 of RFC [RFC5905].		NTP timestamp as per section 6 of RFC [RFC5905]
	7.4.2.3. Min		7.4.2.3. Min
	The minimum SHALL be calculated using the conditional distribution of		The minimum SHALL be calculated using the conditional distribution of
	all packets with a finite value of One-way delay (undefined delays		all packets with a finite value of One-way delay (undefined delays
	are excluded), a single value as follows:		are excluded), a single value as follows:
	See section 4.1 of [RFC3393] for details on the conditional		See section 4.1 of [RFC3393] for details on the conditional
	distribution to exclude undefined values of delay, and Section 5 of		distribution to exclude undefined values of delay, and Section 5 of
	[RFC6703] for background on this analysis choice.		[RFC6703] for background on this analysis choice.
	See section 4.3.2 of [RFC6049] for details on calculating this		See section 4.3.2 of [RFC6049] for details on calculating this
	statistic, and 4.3.3 of [RFC6049].		statistic, and 4.3.3 of [RFC6049].
	The time value of the result is expressed in units of seconds, as a		Min The time value of the result is expressed in units of seconds,
	positive value of type decimal64 with fraction digits = 9 (see		as a positive value of type decimal64 with fraction digits = 9
	section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0		(see section 9.3 of [RFC6020]) with resolution of 0.000000001
	ns), and with lossless conversion to/from the 64-bit NTP timestamp as		seconds (1.0 ns), and with lossless conversion to/from the 64-bit
	per section 6 of RFC [RFC5905].		NTP timestamp as per section 6 of RFC [RFC5905]
	7.4.2.4. Max		7.4.2.4. Max
	The maximum SHALL be calculated using the conditional distribution of		The maximum SHALL be calculated using the conditional distribution of
	all packets with a finite value of One-way delay (undefined delays		all packets with a finite value of One-way delay (undefined delays
	are excluded), a single value as follows:		are excluded), a single value as follows:
	See section 4.1 of [RFC3393] for details on the conditional		See section 4.1 of [RFC3393] for details on the conditional
	distribution to exclude undefined values of delay, and Section 5 of		distribution to exclude undefined values of delay, and Section 5 of
	[RFC6703] for background on this analysis choice.		[RFC6703] for background on this analysis choice.
	See section 4.3.2 of [RFC6049] for a closely related method for		See section 4.3.2 of [RFC6049] for a closely related method for
	calculating this statistic, and 4.3.3 of [RFC6049]. The formula is		calculating this statistic, and 4.3.3 of [RFC6049]. The formula is
	as follows:		as follows:
	Max = (FiniteDelay [j])		Max = (FiniteDelay [j])
	such that for some index, j, where 1 <= j <= N		such that for some index, j, where 1 <= j <= N
	FiniteDelay[j] >= FiniteDelay[n] for all n		FiniteDelay[j] >= FiniteDelay[n] for all n
	The time value of the result is expressed in units of seconds, as a		Max The time value of the result is expressed in units of seconds,
	positive value of type decimal64 with fraction digits = 9 (see		as a positive value of type decimal64 with fraction digits = 9
	section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0		(see section 9.3 of [RFC6020]) with resolution of 0.000000001
	ns), and with lossless conversion to/from the 64-bit NTP timestamp as		seconds (1.0 ns), and with lossless conversion to/from the 64-bit
	per section 6 of RFC [RFC5905].		NTP timestamp as per section 6 of RFC [RFC5905]
	7.4.2.5. Std_Dev		7.4.2.5. Std_Dev
			The Std_Dev SHALL be calculated using the conditional distribution of
			all packets with a finite value of One-way delay (undefined delays
			are excluded), a single value as follows:
			See section 4.1 of [RFC3393] for details on the conditional
			distribution to exclude undefined values of delay, and Section 5 of
			[RFC6703] for background on this analysis choice.
			See section 4.3.2 of [RFC6049] for a closely related method for
			calculating this statistic, and 4.3.3 of [RFC6049]. The formula is
			the classic calculation for standard deviation of a population.
			Std_Dev The time value of the result is expressed in units of
			seconds, as a positive value of type decimal64 with fraction
			digits = 9 (see section 9.3 of [RFC6020]) with resolution of
			0.000000001 seconds (1.0 ns), and with lossless conversion to/from
			the 64-bit NTP timestamp as per section 6 of RFC [RFC5905]
	7.4.3. Metric Units		7.4.3. Metric Units
	<insert units for the measured results, and the reference		<insert units for the measured results, and the reference
	specification>.		specification>.
	The <statistic> of One-way Delay is expressed in seconds.		The <statistic> of One-way Delay is expressed in seconds.
	The 95th Percentile of One-way Delay is expressed in seconds.
	7.4.4. Calibration		7.4.4. Calibration
	<pointer to >		Section 3.7.3 of [RFC7679] provides a means to quantify the
			systematic and random errors of a time measurement. In-situ
			calibration could be enabled with an internal loopback that includes
			as much of the measurement system as possible, performs address
			manipulation as needed, and provides some form of isolation (e.g.,
			deterministic delay) to avoid send-receive interface contention.
			Some portion of the random and systematic error can be characterized
			this way.
			For one-way delay measurements, the error calibration must include an
			assessment of the internal clock synchronization with its external
			reference (this internal clock is supplying timestamps for
			measurement). In practice, the time offsets of clocks at both the
			source and destination are needed to estimate the systematic error
			due to imperfect clock synchronization (the time offsets are
			smoothed, thus the random variation is not usually represented in the
			results).
			time_offset The time value of the result is expressed in units of
			seconds, as a signed value of type decimal64 with fraction digits
			= 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001
			seconds (1.0 ns), and with lossless conversion to/from the 64-bit
			NTP timestamp as per section 6 of RFC [RFC5905]
			When a measurement controller requests a calibration measurement, the
			loopback is applied and the result is output in the same format as a
			normal measurement with additional indication that it is a
			calibration result. In any measurement, the measurement function
			SHOULD report its current estimate of time offset as an indicator of
			the degree of synchronization.
			Both internal loopback calibration and clock synchronization can be
			used to estimate the *available accuracy* of the Output Metric Units.
			For example, repeated loopback delay measurements will reveal the
			portion of the Output result resolution which is the result of system
			noise, and thus inaccurate.
	7.5. Administrative items		7.5. Administrative items
	7.5.1. Status		7.5.1. Status
	<current or depricated>		<current or depricated>
	7.5.2. Requestor (keep?)		7.5.2. Requestor (keep?)
	name or RFC, etc.		name or RFC, etc.
	skipping to change at page 40, line 23 ¶		skipping to change at page 43, line 48 ¶
	7.5.4. Revision Date		7.5.4. Revision Date
	YYYY-MM-DD		YYYY-MM-DD
	7.6. Comments and Remarks		7.6. Comments and Remarks
	Additional (Informational) details for this entry		Additional (Informational) details for this entry
	8. UDP Periodic One-way Delay Registry Entries		8. UDP Periodic One-way Delay Registry Entries
	This section gives an initial registry entry for the UDP Periodic		This section specifies five initial registry entries for the UDP
	One-way Delay.		Periodic One-way Delay.
	Note: Each Registry "Name" below specifies a single registry entry,		Note: Each Registry "Name" below specifies a single registry entry,
	whose output format varies according to a component of the name that		whose output format varies according to the <statistic> element of
	specifies one form of statistical summary.		the name that specifies one form of statistical summary.
	IANA is asked to assign a different numeric identifiers to each Name.		IANA is asked to assign a different numeric identifiers to each of
	All other column entries are the same, thus this section is proposes		the five Metrics. All column entries beside the ID, Name,
	five closely-related registry entries. As a result, IANA is also		Description, and Output Reference Method categories are the same,
	asked to assign corresponding URIs and URLs.		thus this section proposes five closely-related registry entries. As
			a result, IANA is also asked to assign corresponding URNs and URLs to
			each Named Metric.
	8.1. Summary		8.1. Summary
	This category includes multiple indexes to the registry entries, the		This category includes multiple indexes to the registry entries, the
	element ID and metric name.		element ID and metric name.
	8.1.1. ID (Identifier)		8.1.1. ID (Identifier)
	<insert numeric identifier, an integer, one corresponding to each		<insert numeric identifier, an integer, one corresponding to each
	name below>		name below>
	8.1.2. Name		8.1.2. Name
	<insert name according to metric naming convention>		<insert name according to metric naming convention>
	OWDelay_Active_IP-UDP-Periodic-		OWDelay_Active_IP-UDP-Periodic-
	Payload142B_RFCXXXXsecY_Seconds_<statistic>		Payload142B_RFCXXXXsecY_Seconds_<statistic>
	OWDelay_Active_IP-UDP-Periodic-
	Payload142B_RFCXXXXsecY_Seconds_95Percentile
	OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Mean		where <statistic> is one of:
	OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Min		o 95Percentile
	OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Max		o Mean
	OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_StdDev		o Min
	8.1.3. URI and URL		o Max
	URI: Prefix urn:ietf:metric...<name>		o StdDev
			8.1.3. URIs
			URI: Prefix urn:ietf:metrics:perf:<name>
	URL: http:\\www.iana.org\ ... <name>		URL: http:\\www.iana.org\ ... <name>
	8.1.4. Description		8.1.4. Description
	This metric assesses the delay of a stream of packets exchanged		This metric assesses the delay of a stream of packets exchanged
	between two hosts (or measurement points), and reports the		between two hosts (or measurement points), and reports the
	<statistic> One-way delay for all successfully exchanged packets		<statistic> One-way delay for all successfully exchanged packets
	based on their conditional delay distribution.		based on their conditional delay distribution.
			where <statistic> is one of:
			o 95Percentile
			o Mean
			o Min
			o Max
			o StdDev
	8.2. Metric Definition		8.2. Metric Definition
	This category includes columns to prompt the entry of all necessary		This category includes columns to prompt the entry of all necessary
	details related to the metric definition, including the RFC reference		details related to the metric definition, including the RFC reference
	and values of input factors, called fixed parameters.		and values of input factors, called fixed parameters.
	8.2.1. Reference Definition		8.2.1. Reference Definition
	<Full bibliographic reference to an immutable doc.>		<Full bibliographic reference to an immutable doc.>
	Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric		Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-
	for IPPM", RFC 2679, September 1999.		Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC
			7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-
			editor.org/info/rfc7679>.
	[RFC2679]		[RFC7679]
	Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC		Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC
	6049, January 2011.		6049, January 2011.
	[RFC6049]		[RFC6049]
	<specific section reference and additional clarifications, if needed>		<specific section reference and additional clarifications, if needed>
	Section 3.4 of [RFC2679] provides the reference definition of the		Section 3.4 of [RFC7679] provides the reference definition of the
	singleton (single value) One-way delay metric. Section 4.4 of		singleton (single value) One-way delay metric. Section 4.4 of
			[RFC7679] provides the reference definition expanded to cover a
	[RFC2679] provides the reference definition expanded to cover a
	multi-value sample. Note that terms such as singleton and sample are		multi-value sample. Note that terms such as singleton and sample are
	defined in Section 11 of [RFC2330].		defined in Section 11 of [RFC2330].
	Only successful packet transfers with finite delay are included in		Only successful packet transfers with finite delay are included in
	the sample, as prescribed in section 4.1.2 of [RFC6049].		the sample, as prescribed in section 4.1.2 of [RFC6049].
	NOTE: RFC2679 will be replaced by 2679-bis on approval, see draft-
	ietf-ippm-2679-bis-01.
	ANY other conditions, ...
	8.2.2. Fixed Parameters		8.2.2. Fixed Parameters
	<list and specify Fixed Parameters, input factors that must be		<list and specify Fixed Parameters, input factors that must be
	determined and embedded in the measurement system for use when		determined and embedded in the measurement system for use when
	needed>		needed>
	Type-P:		Type-P:
	o IPv4 header values:		o IPv4 header values:
	* DSCP: set to 0		* DSCP: set to 0
	* TTL set to 255		* TTL: set to 255
			* Protocol: Set to 17 (UDP)
			o IPv6 header values:
			* DSCP: set to 0
			* Hop Count: set to 255
	* Protocol: Set to 17 (UDP)		* Protocol: Set to 17 (UDP)
	o UDP header values:		o UDP header values:
	* Checksum: the checksum must be calculated		* Checksum: the checksum MUST be calculated and included in the
			header
	o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357]		o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357]
	* Security features in use influence the number of Padding		* Security features in use influence the number of Padding
	octets.		octets.
	* 142 octets total, including the TWAMP format		* 142 octets total, including the TWAMP format
	Timeout, Tmax: 3 seconds		Other measurement parameters:
			Tmax: a loss threshold waiting time with value 3.0, expressed in
			units of seconds, as a positive value of type decimal64 with
			fraction digits = 5 (see section 9.3 of [RFC6020]) and with
			resolution of 0.0001 seconds (0.1 ms), with lossless conversion
			to/from the 32-bit NTP timestamp as per section 6 of [RFC5905].
			See the Packet Stream generation category for two additional Fixed
			Parameters.
	8.3. Method of Measurement		8.3. Method of Measurement
	This category includes columns for references to relevant sections of		This category includes columns for references to relevant sections of
	the RFC(s) and any supplemental information needed to ensure an		the RFC(s) and any supplemental information needed to ensure an
	unambiguous methods for implementations.		unambiguous methods for implementations.
	8.3.1. Reference Method		8.3.1. Reference Method
	<for metric, insert relevant section references and supplemental		<for metric, insert relevant section references and supplemental
	info>		info>
	The methodology for this metric is defined as Type-P-One-way-Delay-		The methodology for this metric is defined as Type-P-One-way-Delay-
	Poisson-Stream in section 3.6 of [RFC2679] and section 4.6 of		Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of
	[RFC2679] using the Type-P and Timeout defined under Fixed		[RFC7679] using the Type-P and Tmax defined under Fixed Parameters.
	Parameters.
	The method requires sequence numbers or other send-order information		The reference method distinguishes between long-delayed packets and
	to be retained at the Src or included with each packet to dis-		lost packets by implementing a maximum waiting time for packet
	ambiguate packet reordering if it occurs. Sequence number is part of		arrival. Tmax is the waiting time used as the threshold to declare a
	the TWAMP payload described under Fixed Parameters.		packet lost. Lost packets SHALL be designated as having undefined
			delay.
	8.3.2. Packet Generation Stream		The calculations on the one-way delay SHALL be performed on the
			conditional distribution, conditioned on successful packet arrival
			within Tmax. Also, when all packet delays are stored, the process
			which calculates the one-way delay value MAY enforce the Tmax
			threshold on stored values before calculations. See section 4.1 of
			[RFC3393] for details on the conditional distribution to exclude
			undefined values of delay, and Section 5 of [RFC6703] for background
			on this analysis choice.
			The reference method requires some way to distinguish between
			different packets in a stream to establish correspondence between
			sending times and receiving times for each successfully-arriving
			packet. Sequence numbers or other send-order identification MUST be
			retained at the Src or included with each packet to dis-ambiguate
			packet reordering if it occurs.
			Since a standard measurement protocol is employed [RFC5357], then the
			measurement process will determine the sequence numbers or timestamps
			applied to test packets after the Fixed and Runtime parameters are
			passed to that process. The measurement protocol dictates the format
			of sequence numbers and time-stamps conveyed in the TWAMP-Test packet
			payload.
			8.3.2. Packet Stream Generation
			<list of generation parameters and section/spec references if needed>
	This section gives the details of the packet traffic which is the		This section gives the details of the packet traffic which is the
	basis for measurement. In IPPM metrics, this is called the Stream,		basis for measurement. In IPPM metrics, this is called the Stream,
	and can easily be dscribed by providing the list of stream		and can easily be described by providing the list of stream
	parameters.		parameters.
	<list of generation parameters and section/spec references if needed>
	Section 3 of [RFC3432] prescribes the method for generating Periodic		Section 3 of [RFC3432] prescribes the method for generating Periodic
	streams using associated parameters.		streams using associated parameters.
	o incT, the nominal duration of inter-packet interval, first bit to		incT the nominal duration of inter-packet interval, first bit to
	first bit		first bit
	o dT, the duration of the interval for allowed sample start times		dT the duration of the interval for allowed sample start times
	o T0, the actual start time		T0 the actual start time of the periodic stream
	NOTE: an initiation process with a number of control exchanges		NOTE: an initiation process with a number of control exchanges
	resulting in unpredictable start times (within a time interval) may		resulting in unpredictable start times (within a time interval) may
	be sufficient to avoid synchronization of periodic streams, and		be sufficient to avoid synchronization of periodic streams, and
	therefore a valid replacement for selecting a start time at random		therefore a valid replacement for selecting a start time at random
	from a fixed interval.		from a fixed interval.
	These stream parameters will be specified as Run-time parameters.		These stream parameters will be specified as Run-time parameters.
	8.3.3. Traffic Filtering (observation) Details		8.3.3. Traffic Filtering (observation) Details
	skipping to change at page 44, line 17 ¶		skipping to change at page 48, line 48 ¶
	NA		NA
	8.3.5. Run-time Parameters and Data Format		8.3.5. Run-time Parameters and Data Format
	Run-time Parameters are input factors that must be determined,		Run-time Parameters are input factors that must be determined,
	configured into the measurement system, and reported with the results		configured into the measurement system, and reported with the results
	for the context to be complete.		for the context to be complete.
	<list of run-time parameters, and their data formats>		<list of run-time parameters, and their data formats>
	o Src, the IP address of a host (32-bit value for IPv4, 128-bit		Src the IP address of the host in the Src Role (format ipv4-address-
	value for IPv6)		no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
			see Section 4 of [RFC6991])
	o Dst, the IP address of a host (32-bit value for IPv4, 128-bit
	value for IPv6)
	o T0, a time (start of measurement interval, 128-bit NTP Date
	Format, see section 6 of [RFC5905]). When T0 is "all-zeros", a
	start time is unspecified and Tf is to be interpreted as the
	Duration of the measurement interval.
	o Tf, a time (end of measurement interval, 128-bit NTP Date Format,
	see section 6 of [RFC5905]), interpreted as the Duration of the
	measurement interval.
	o incT, the nominal duration of inter-packet interval, first bit to		Dst the IP address of the host in the Dst Role (format ipv4-address-
	first bit		no-zone value for IPv4, or ipv6-address-no-zone value for IPv6,
			see section 4 of [RFC6991])
	o dT, the duration of the interval for allowed sample start times		T0 a time, the start of a measurement interval, (format "date-and-
			time" as specified in Section 5.6 of [RFC3339], see also Section 3
			of [RFC6991]). The UTC Time Zone is required by Section 6.1 of
			[RFC2330]. When T0 is "all-zeros", a start time is unspecified
			and Tf is to be interpreted as the Duration of the measurement
			interval. The start time is controlled through other means.
	The format for incT and dT are the short format in [RFC5905] (32		Tf a time, the end of a measurement interval, (format "date-and-time"
	bits) and is as follows: the first 16 bits represent the integer		as specified in Section 5.6 of [RFC3339], see also Section 3 of
	number of seconds; the next 16 bits represent the fractional part of		[RFC6991]). The UTC Time Zone is required by Section 6.1 of
	a second.		[RFC2330]. When T0 is "all-zeros", a end time date is ignored and
			Tf is interpreted as the Duration of the measurement interval.
	>>> should Periodic run-time params be fixed instead? probably yes if		>>> should Periodic run-time params be fixed instead? probably yes if
	modeling a specific version of tests. Note in the NAME, i.e.		modeling a specific version of tests. Note in the NAME, i.e.
	Poisson3.3		Poisson3.3
	8.3.6. Roles		8.3.6. Roles
	<lists the names of the different roles from the measurement method>		<lists the names of the different roles from the measurement method>
	Src - launches each packet and waits for return transmissions from		Src launches each packet and waits for return transmissions from
	Dst. This is the TWAMP Session-Sender.		Dst. This is the TWAMP Session-Sender.
	Dst - waits for each packet from Src and sends a return packet to		Dst waits for each packet from Src and sends a return packet to Src.
	Src. This is the TWAMP Session-Reflector.		This is the TWAMP Session-Reflector.
	8.4. Output		8.4. Output
	This category specifies all details of the Output of measurements		This category specifies all details of the Output of measurements
	using the metric.		using the metric.
	8.4.1. Type/Value (two diff terms used)		8.4.1. Type
	<insert name of the output type, raw or a selected summary statistic>		<insert name of the output type, raw or a selected summary statistic>
	See subsection titles in Data Format for Types.		See subsection titles in Data Format for Types.
	8.4.2. Data Format		8.4.2. Reference Definition
	<describe the data format for each type of result>		<describe the data format for each type of result>
	For all output types ---		For all output types ---
			T0 the start of a measurement interval, (format "date-and-time" as
			specified in Section 5.6 of [RFC3339], see also Section 3 of
			[RFC6991]). The UTC Time Zone is required by Section 6.1 of
			[RFC2330].
	o T0, a time (start of measurement interval, 128-bit NTP Date		Tf the end of a measurement interval, (format "date-and-time" as
	Format, see section 6 of [RFC5905])		specified in Section 5.6 of [RFC3339], see also Section 3 of
			[RFC6991]). The UTC Time Zone is required by Section 6.1 of
			[RFC2330].
	o Tf, a time (end of measurement interval, 128-bit NTP Date Format,		For each <statistic>, one of the following sub-sections apply:
	see section 6 of [RFC5905])
	8.4.2.1. 95Percentile		8.4.2.1. Percentile95
	The 95th percentile SHALL be calculated using the conditional		The 95th percentile SHALL be calculated using the conditional
	distribution of all packets with a finite value of One-way delay		distribution of all packets with a finite value of One-way delay
	(undefined delays are excluded), a single value as follows:		(undefined delays are excluded), a single value as follows:
	See section 4.1 of [RFC3393] for details on the conditional		See section 4.1 of [RFC3393] for details on the conditional
	distribution to exclude undefined values of delay, and Section 5 of		distribution to exclude undefined values of delay, and Section 5 of
	[RFC6703] for background on this analysis choice.		[RFC6703] for background on this analysis choice.
	See section 4.3 of [RFC3393] for details on the percentile statistic		See section 4.3 of [RFC3393] for details on the percentile statistic
	(where Round-trip delay should be substituted for "ipdv").		(where Round-trip delay should be substituted for "ipdv").
	The percentile = 95.		The percentile = 95, meaning that the reported delay, "95Percentile",
			is the smallest value of one-way delay for which the Empirical
	Data format is a 32-bit signed value, *similar to* the 32-bit short		Distribution Function (EDF), F(95Percentile) >= 95% of the singleton
	NTP Time format in Section 6 of [RFC5905] and is as follows: the		one-way delay values in the conditional distribution. See section
	first 16 bits represent the *signed* integer number of seconds; the		11.3 of [RFC2330] for the definition of the percentile statistic
	next 16 bits represent the fractional part of a second.		using the EDF.
	The time value of the result is expressed in units of seconds, as a		95Percentile The time value of the result is expressed in units of
	positive value of type decimal64 with fraction digits = 9 (see		seconds, as a positive value of type decimal64 with fraction
	section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0		digits = 9 (see section 9.3 of [RFC6020]) with resolution of
	ns), and with lossless conversion to/from the 64-bit NTP timestamp as		0.000000001 seconds (1.0 ns), and with lossless conversion to/from
	per section 6 of RFC [RFC5905].		the 64-bit NTP timestamp as per section 6 of RFC [RFC5905]
	8.4.2.2. Mean		8.4.2.2. Mean
	The mean SHALL be calculated using the conditional distribution of		The mean SHALL be calculated using the conditional distribution of
	all packets with a finite value of One-way delay (undefined delays		all packets with a finite value of One-way delay (undefined delays
	are excluded), a single value as follows:		are excluded), a single value as follows:
	See section 4.1 of [RFC3393] for details on the conditional		See section 4.1 of [RFC3393] for details on the conditional
	distribution to exclude undefined values of delay, and Section 5 of		distribution to exclude undefined values of delay, and Section 5 of
	[RFC6703] for background on this analysis choice.		[RFC6703] for background on this analysis choice.
	See section 4.2.2 of [RFC6049] for details on calculating this		See section 4.2.2 of [RFC6049] for details on calculating this
	statistic, and 4.2.3 of [RFC6049].		statistic, and 4.2.3 of [RFC6049].
	The time value of the result is expressed in units of seconds, as a		Mean The time value of the result is expressed in units of seconds,
	positive value of type decimal64 with fraction digits = 9 (see		as a positive value of type decimal64 with fraction digits = 9
	section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0		(see section 9.3 of [RFC6020]) with resolution of 0.000000001
	ns), and with lossless conversion to/from the 64-bit NTP timestamp as		seconds (1.0 ns), and with lossless conversion to/from the 64-bit
	per section 6 of RFC [RFC5905].		NTP timestamp as per section 6 of RFC [RFC5905]
	8.4.2.3. Min		8.4.2.3. Min
	The minimum SHALL be calculated using the conditional distribution of		The minimum SHALL be calculated using the conditional distribution of
	all packets with a finite value of One-way delay (undefined delays		all packets with a finite value of One-way delay (undefined delays
	are excluded), a single value as follows:		are excluded), a single value as follows:
	See section 4.1 of [RFC3393] for details on the conditional		See section 4.1 of [RFC3393] for details on the conditional
	distribution to exclude undefined values of delay, and Section 5 of		distribution to exclude undefined values of delay, and Section 5 of
	[RFC6703] for background on this analysis choice.		[RFC6703] for background on this analysis choice.
	See section 4.3.2 of [RFC6049] for details on calculating this		See section 4.3.2 of [RFC6049] for details on calculating this
	statistic, and 4.3.3 of [RFC6049].		statistic, and 4.3.3 of [RFC6049].
	The time value of the result is expressed in units of seconds, as a		Min The time value of the result is expressed in units of seconds,
	positive value of type decimal64 with fraction digits = 9 (see		as a positive value of type decimal64 with fraction digits = 9
	section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0		(see section 9.3 of [RFC6020]) with resolution of 0.000000001
	ns), and with lossless conversion to/from the 64-bit NTP timestamp as		seconds (1.0 ns), and with lossless conversion to/from the 64-bit
	per section 6 of RFC [RFC5905].		NTP timestamp as per section 6 of RFC [RFC5905]
	8.4.2.4. Max		8.4.2.4. Max
	The maximum SHALL be calculated using the conditional distribution of		The maximum SHALL be calculated using the conditional distribution of
	all packets with a finite value of One-way delay (undefined delays		all packets with a finite value of One-way delay (undefined delays
	are excluded), a single value as follows:		are excluded), a single value as follows:
	See section 4.1 of [RFC3393] for details on the conditional		See section 4.1 of [RFC3393] for details on the conditional
	distribution to exclude undefined values of delay, and Section 5 of		distribution to exclude undefined values of delay, and Section 5 of
	[RFC6703] for background on this analysis choice.		[RFC6703] for background on this analysis choice.
	See section 4.3.2 of [RFC6049] for a closely related method for		See section 4.3.2 of [RFC6049] for a closely related method for
	calculating this statistic, and 4.3.3 of [RFC6049]. The formula is		calculating this statistic, and 4.3.3 of [RFC6049]. The formula is
	as follows:		as follows:
	Max = (FiniteDelay [j])		Max = (FiniteDelay [j])
	such that for some index, j, where 1 <= j <= N		such that for some index, j, where 1 <= j <= N
	FiniteDelay[j] >= FiniteDelay[n] for all n		FiniteDelay[j] >= FiniteDelay[n] for all n
	The time value of the result is expressed in units of seconds, as a		Max The time value of the result is expressed in units of seconds,
	positive value of type decimal64 with fraction digits = 9 (see		as a positive value of type decimal64 with fraction digits = 9
	section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0		(see section 9.3 of [RFC6020]) with resolution of 0.000000001
	ns), and with lossless conversion to/from the 64-bit NTP timestamp as		seconds (1.0 ns), and with lossless conversion to/from the 64-bit
	per section 6 of RFC [RFC5905].		NTP timestamp as per section 6 of RFC [RFC5905]
	8.4.2.5. Std_Dev		8.4.2.5. Std_Dev
			The Std_Dev SHALL be calculated using the conditional distribution of
			all packets with a finite value of One-way delay (undefined delays
			are excluded), a single value as follows:
			See section 4.1 of [RFC3393] for details on the conditional
			distribution to exclude undefined values of delay, and Section 5 of
			[RFC6703] for background on this analysis choice.
			See section 4.3.2 of [RFC6049] for a closely related method for
			calculating this statistic, and 4.3.3 of [RFC6049]. The formula is
			the classic calculation for standard deviation of a population.
			Std_Dev The time value of the result is expressed in units of
			seconds, as a positive value of type decimal64 with fraction
			digits = 9 (see section 9.3 of [RFC6020]) with resolution of
			0.000000001 seconds (1.0 ns), and with lossless conversion to/from
			the 64-bit NTP timestamp as per section 6 of RFC [RFC5905]
	8.4.3. Metric Units		8.4.3. Metric Units
	<insert units for the measured results, and the reference		<insert units for the measured results, and the reference
	specification>.		specification>.
	The <statistic> of One-way Delay is expressed in seconds.		The <statistic> of One-way Delay is expressed in seconds.
	8.4.4. Calibration		8.4.4. Calibration
	<pointer to >		Section 3.7.3 of [RFC7679] provides a means to quantify the
			systematic and random errors of a time measurement. In-situ
			calibration could be enabled with an internal loopback that includes
			as much of the measurement system as possible, performs address
			manipulation as needed, and provides some form of isolation (e.g.,
			deterministic delay) to avoid send-receive interface contention.
			Some portion of the random and systematic error can be characterized
			this way.
			For one-way delay measurements, the error calibration must include an
			assessment of the internal clock synchronization with its external
			reference (this internal clock is supplying timestamps for
			measurement). In practice, the time offsets of clocks at both the
			source and destination are needed to estimate the systematic error
			due to imperfect clock synchronization (the time offsets are
			smoothed, thus the random variation is not usually represented in the
			results).
			time_offset The time value of the result is expressed in units of
			seconds, as a signed value of type decimal64 with fraction digits
			= 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001
			seconds (1.0 ns), and with lossless conversion to/from the 64-bit
			NTP timestamp as per section 6 of RFC [RFC5905]
			When a measurement controller requests a calibration measurement, the
			loopback is applied and the result is output in the same format as a
			normal measurement with additional indication that it is a
			calibration result. In any measurement, the measurement function
			SHOULD report its current estimate of time offset as an indicator of
			the degree of synchronization.
			Both internal loopback calibration and clock synchronization can be
			used to estimate the *available accuracy* of the Output Metric Units.
			For example, repeated loopback delay measurements will reveal the
			portion of the Output result resolution which is the result of system
			noise, and thus inaccurate.
	8.5. Administrative items		8.5. Administrative items
	8.5.1. Status		8.5.1. Status
	<current or depricated>		<current or depricated>
	8.5.2. Requestor (keep?)		8.5.2. Requestor (keep?)
	name or RFC, etc.		name or RFC, etc.
	skipping to change at page 48, line 32 ¶		skipping to change at page 54, line 24 ¶
	9.1.1. ID (Identifier)		9.1.1. ID (Identifier)
	<insert numeric identifier, an integer>		<insert numeric identifier, an integer>
	9.1.2. Name		9.1.2. Name
	<insert name according to metric naming convention>		<insert name according to metric naming convention>
	9.1.3. URIs		9.1.3. URIs
	URI: Prefix urn:ietf:params:performance:metric		URI: Prefix urn:ietf:metrics:perf:<name>
	URL:		URL:
	9.1.4. Description		9.1.4. Description
	TBD.		TBD.
	9.1.5. Reference		9.1.5. Reference
	<reference to the RFC of spec where the registry entry is defined>		<reference to the RFC of spec where the registry entry is defined>
	skipping to change at page 51, line 37 ¶		skipping to change at page 57, line 29 ¶
	An integer having enough digits to uniquely identify each entry in		An integer having enough digits to uniquely identify each entry in
	the Registry.		the Registry.
	10.1.2. Name		10.1.2. Name
	A metric naming convention is TBD.		A metric naming convention is TBD.
	10.1.3. URI		10.1.3. URI
	Prefix urn:ietf:params:performance:metric		Prefix urn:ietf:metrics:param:<name>
	10.1.4. Status		10.1.4. Status
	current		current
	10.1.5. Requestor		10.1.5. Requestor
	Alcelip Mornuley		Alcelip Mornuley
	10.1.6. Revision		10.1.6. Revision
	skipping to change at page 56, line 26 ¶		skipping to change at page 62, line 14 ¶
	measurement has been removed. * Explanation of Conditional delay		measurement has been removed. * Explanation of Conditional delay
	distribution.		distribution.
	Version 03 addressed Phil Eardley's comments and suggestions in		Version 03 addressed Phil Eardley's comments and suggestions in
	sections 1-4. and resolved the definition of Percentiles.		sections 1-4. and resolved the definition of Percentiles.
	Version 04 * All section 4 parameters reference YANG types for		Version 04 * All section 4 parameters reference YANG types for
	alternate data formats. * Discussion has concluded that usecase(s)		alternate data formats. * Discussion has concluded that usecase(s)
	for machine parse-able registry columns are not needed.		for machine parse-able registry columns are not needed.
	Still need: * suggestion of standard naming format for parameters.
	Note: lambda parameter description is correct in section 4, elsewhere
	needs fix.
	12. Security Considerations		12. Security Considerations
	These registry entries represent no known security implications for		These registry entries represent no known security implications for
	Internet Security. Each referenced Metric contains a Security		Internet Security. Each referenced Metric contains a Security
	Considerations section.		Considerations section.
	13. IANA Considerations		13. IANA Considerations
	IANA is requested to populate The Performance Metric Registry defined		IANA is requested to populate The Performance Metric Registry defined
	in [I-D.ietf-ippm-metric-registry] with the values defined above.		in [I-D.ietf-ippm-metric-registry] with the values defined above.
	<more is needed here>		See the IANA Considerations section of
			[I-D.ietf-ippm-metric-registry] for additional requests and
			considerations.
	14. Acknowledgements		14. Acknowledgements
	The authors thank Brian Trammell for suggesting the term "Run-time		The authors thank Brian Trammell for suggesting the term "Run-time
	Parameters", which led to the distinction between run-time and fixed		Parameters", which led to the distinction between run-time and fixed
	parameters implemented in this memo, for identifying the IPFIX metric		parameters implemented in this memo, for identifying the IPFIX metric
	with Flow Key as an example, and for many other productive		with Flow Key as an example, and for many other productive
	suggestions. Thanks to Peter Koch, who provided several useful		suggestions. Thanks to Peter Koch, who provided several useful
	suggestions for disambiguating successive DNS Queries in the DNS		suggestions for disambiguating successive DNS Queries in the DNS
	Response time metric.		Response time metric.
	The authors also acknowledge the constructive reviews and helpful		The authors also acknowledge the constructive reviews and helpful
	suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and		suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, and
	participants in the LMAP working group.		participants in the LMAP working group. Thanks to Michelle Cotton
			for her early IANA review, and to Amanda Barber for answering
			questions related to the presentation of the registry and
			accessibility of the complete template via URL.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[I-D.ietf-ippm-metric-registry]		[I-D.ietf-ippm-metric-registry]
	Bagnulo, M., Claise, B., Eardley, P., and A. Morton,		Bagnulo, M., Claise, B., Eardley, P., and A. Morton,
	"Registry for Performance Metrics", Internet Draft (work		"Registry for Performance Metrics", Internet Draft (work
	in progress) draft-ietf-ippm-metric-registry, 2014.		in progress) draft-ietf-ippm-metric-registry, 2014.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <http://www.rfc-editor.org/info/rfc1035>.		November 1987, <http://www.rfc-editor.org/info/rfc1035>.
End of changes. 162 change blocks.
	510 lines changed or deleted		787 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/