Subject: [ippm] I-D ACTION:draft-ietf-ippm-metrics-registry-02.txt

From: [email-masked]
Date: Thu, 06 Mar 2003 06:27:17 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Metrics Working Group of the IETF.

	Title		: IPPM metrics registry
	Author(s)	: E. Stephan
	Filename	: draft-ietf-ippm-metrics-registry-02.txt
	Pages		: 12
	Date		: 2003-3-5
	
This memo defines a registry of the IPPM working group metrics. It 
provides an OBJECT IDENTIFIER to each metric currently standardized 
by the IPPM WG. It defines the rules for the identification of the 
metrics standardized in the future.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ippm-metrics-registry-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ippm-metrics-registry-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 23 Mar 2003 20:14:26 -0800

Hi -

Here are a few quick comments on draft-ietf-ippm-metrics-registry-02.txt
I didn't see discussion of these in the WG archive; my apologies if
they've already been covered somewhere.

Technical comments:
  Section 4, where it says:
|   The name of the metric has to respect ASN.1 constraints. The name has
|   to start with a lower case. The letter - is forbidden (more or less)
|   in the name. In a way to preserve the readability of the metric name
|   the letters following a - are forced to upper case.
  This is not quite right.  The restrictions come from RFC 2578 section 3.1.
  The readability guideline presumably belongs to this registry.  The talk
  about "-" being "more or less" forbidden is confusing.  RFC 2578 forbids "-"
  in this context (since these registrations are not coming from SMIv1
  translations).  If "-" is prohibited, the text saying that letters following
  "-" are mapped to upper case doesn't make sense.  Suggested replacement:
          The name of the metric must respect the [SMIv2] rules for descriptors.

  Section 4, where it says:
|   Each metrics specification will include a section describing its
|   metrics identifiers.
  I started out trying to treat this as an editorial nit, but then realized
  that the possible changes needed to make it grammatical had different
  technical meaning.  The fundamental question is whether this is a requirement
  for registry documents or for the metrics' base specifications.  (which, I
  suppose, might be the same document in some cases)  Fix depends on what is meant.

  4.1: the template needs IMPORTS for the MODULE-IDENTITY and OBJECT-IDENTITY
  macros.  An instance would also need an IMPORTS for "rfc" or "other"
  the template should also make it clear that the module name needs to be unique.
  http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt
  has useful guidelines.

  4.3: (forgive me if the WG has already considered this) Might it make sense
  to structure this like other registries, e.g., the one for ifTypes?  First,
  the current proposal leads to a proliferation of MIB modules.  Secondly, the
  proposed approval mechanism requires an immortal IPPM WG, so a backup review
  mechanism might make sense.

  4.4: Nothing prevents other organizations from registering metrics in their
  own object identifier trees.

Editorial nits that jumped out at me:
  Abstract:  "provides"..."to" should be either "assigns"..."to" or
  "provides"..."for"

  Section 1: it's not clear to me whether the MIB boilerplate really
  applies to this document, but, since it does define a MIB module,
  I'm sure the question will keep popping up.

  Section 2, first bullet:  there is no reference (informative, I
  suppose) for RFC 2330.

  Section 3: "the future" -> "future" (both places)

  Section 4, first sentence: "IDENTIFIER" -> "IDENTIFIERs"
  "associates"..."to" -> "associates"..."with"
  "the node the branch" -> "which branch"
  "the document not the semantic" -> "the document, not the semantic"
  "to uniforms the metrics names" -> "to unify the metrics' names"
  "Each metrics specification" -> "Each metric's specification"

  Section 4.1 "where are identified" -> "which identifies"
  "where is defined the registry" -> "where the registry is defined"
  "terminate by" -> "should end with"
  "a OBJECT-IDENTITY" -> "an OBJECT-IDENITTY"

  Section 4.3:  "when they names" -> "when their names"

  Section 4.4 "organization" -> "organizations" (both places)

  Section 5: CONTACT-INFO list in MODULE-IDENTITY should be updated;
  see http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt
  section 4.5 for specific requirements

  Section 5:  copyright notice is missing.  See
  http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt
  for details on MIB module copyright notices.

  Section 5: the DESCRIPTIONs for these are not terribly helpful.  The REFERENCEs
  make them better than useless, but not much.  :-)

  Section 8: references section should be split into normative and informative
  references per http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-04.txt
  and should include RFC 2578 as a normative reference, since it defines
  IMPORTed macros and object identifiers.

  Full Copyright Statement:  "2001" -> "2003", expiration date is wrong.
  I
  IPR section required by RFC 2026 section 10 is missing.

Randy

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 23 Mar 2003 20:14:26 -0800

Hi -

Technical comments:

Randy