RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete
draft-morton-ippm-rfc4148-obsolete-03

[Ballot comment]
1. It would be useful to introduce a terminology section that would explain terms like 'zombie' and 'apocalypse' used in the Security Considerations section.

2. In the IANA Considerations section:

>  The registry will no longer be updated, and the current contents will
  be maintained as-is on the day that RFC XXXX was published.

As this is text to be appended to the Description of the registry on the IANA Web site, it would be useful I think to specify explicitly the date of publication of the RFC - which is also the date of definitive freeze of the registry.

[Ballot comment]
This Informational document is Obsoleting a BCP (4148 is also BCP 108). Given 4148's content, I agree with the choice of this document's intended status.

[Ballot comment]
I would like to see the security considerations expanded to explain the environments where the risk of a zombie
apocalypse is considered most likely, and any suggested mitigations.

IANA understands that, upon approval of this document, there are two
actions that IANA must complete.

On the IANA matrix located at:

http://www.iana.org/protocols/

the entry for "IANA IPPM Metrics Registry MIB" will be modified to
include the words: "this registry is obsolete upon approval of [RFC-to-be]."

Second, in the registry located at:

http://www.iana.org/assignments/ianaippmmetricsregistry-mib

the text:

"This module defines a registry for IP Performance Metrics."

will be replaced with the following text:

"With the approval and publication of [RFC-to-be], this module is
designated Obsolete.

The registry will no longer be updated, and the current contents will be
maintained as-is on the day that RFC XXXX was published."

IANA understands that these two actions are all that IANA need to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RFC 4148 and the IPPM Metrics Registry are Obsolete) to Informational RFC


The IESG has received a request from the IP Performance Metrics WG (ippm)
to consider the following document:
- 'RFC 4148 and the IPPM Metrics Registry are Obsolete'
  as an Informational RFC

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

The file can be obtained via
http://datatracker.ietf.org/doc/draft-morton-ippm-rfc4148-obsolete/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-morton-ippm-rfc4148-obsolete/

RFC 4148 and the IPPM Metrics Registry are Obsolete
draft-morton-ippm-rfc4148-obsolete-02

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Document sheperd is Henk Uijterwaal. I have reviewed the document and I think it
is ready for publication.

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

Yes.

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

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of?

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document proposes to withdraw a registry. As the registry is not used
in practice, the majority of the WG does not care about this document.

The WG did try to find users of the registry. None were identified
during a 6 month search. Thus, I think that there is consensus that the
registry is not used and can be withdrawn.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

The author of the document that introduced the registry (RFC4148, by
Emile Stephan) is not happy that the registry is obsoleted and has
said that he plans to take further action if WG consensus is declared.

The WG has repeatedly asked Emile to identify people using the registry
or otherwise show that there is support or need for the registry. So-far,
Emile failed to answer this question other than in very vague terms.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits?

Yes, there are 3:

== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year

This is correct, the document was submitted last year. Rerunning it with
xml2rfc will solve this.

== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.

This section can indeed be removed on publication.

-- The document date (October 25, 2010) is 70 days in the past. Is this
intentional?

Yes, this is intentional.


(1.h) Has the document split its references into normative and
informative?

Yes. The reference to RFC2330 should be informative, not normative. This
can be fixed by the editor.

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

No

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This memo recommends that RFC 4148, the IP Performance Metrics (IPPM)
Registry be reclassified as Historic, and the IANA IPPM Metrics
Registry itself be withdrawn from use. The current registry
structure has been found to be insufficiently detailed to uniquely
identify IPPM metrics. Despite apparent efforts to find current or
even future users, no one has responded to the third quarter of 2010
call for interest in the RFC 4148 registry.

Working Group Summary
This is a strange draft in a sense that it does not contain any technical
content, it only asks IANA to stop updating a registry. Technically, it
is therefore very simple and does not need lots of reviews.

The issue itself, do we need a registry for IPPM metrics, has been under
discussion for about 6 months. During those 6 months, the WG could not
identify anybody actually using the registry or interested in upgrading
it to something more useful. Further evidence that the registry is not
used, is given in the document. It should also be noted that obsoleting
this registry will not break anything. IANA practice is to keep the
files related to an obsoleted registry at their current location, if
somebody is actively using these files, they will still be there with
their current content.

An obvious questions is why the WG cares about an unused registry. The
problem is that even though the registry is not used, it needs to be
maintained. Maintaining it requires considerable effort from both
document authors for new metrics (in particular when they are not familiar
with the concept of a registry) and the IANA. We want to avoid that.

Document Quality
Good