Subject: [PMOL] FW: draft-morton-perf-metrics-framework-01

From: "Alan Clark" <[email-masked]>
Date: Thu, 6 Dec 2007 12:55:54 -0500

Apologies - we forgot to forward this to the PMOL list!!

Regards

Alan

A new version of I-D, draft-morton-perf-metrics-framework-01.txt has been
successfuly submitted by Alan Clark and posted to the IETF repository.

Filename:	       draft-morton-perf-metrics-framework
Revision:	       01
Title:		 Framework for Performance Metric Development
Creation_date:	 2007-11-18
WG ID:		 Independent Submission
Number_of_pages:   11

Abstract:
This memo describes a framework and guidelines for the development of
performance metrics that are beyond the scope of existing working group
charters in the IETF.  In this version, the memo refers to a Performance
Metrics Entity, or PM Entity, which may in future be a working group or
directorate or a combination of these two.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-01.t
xt

The IETF Secretariat.

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

---

From: KIKUCHI Yutaka <[email-masked]>
Date: Fri, 07 Dec 2007 04:35:50 +0900 (JST)

Alan, and folks,

Here is a brief report of our experience of the framework I-D.
Sorry for the message just before the PMOL meeting.

Totally, the framework was useful to check our draft.

I want that some points will be more strictly described
because results of the test might includes arbitrary evaluations.
For example, in "the tests of the usefulness" of the section 3.2,
we could say both YES and NO in some situations.
Moreover we could avoid discussions about nerve cases.

In the section 3.6 "Qualifying Metrics",
we need concrete criteria of some qualifications to show
unambiguity, repeatability and implementability.

The section 3.7 "Reporting Models" felt strange to me,
because there are some typical ways, i.e. SNMP and syslog,
for reporting in OAM most cases. It seems a rare case
to define a new reporting model on metrics definition.

I think it may be useful for metrics developers to mention
about "security considerations" and "IANA considerations"
even it always should be written in all the proposals.

Refer to our I-D draft-kikuchi-passive-measure-01.txt
for an evaluation example. Note that this evaluation
was based on the -00 version of the framework draft.

We hope the report helps.

-- Yu.