Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track
RFC 6808

[Ballot comment]
I am assuming that during this evaluation all metrics, metric
parameters, and methodologies defined in RFC 2679 were found to have
been implemented and to be of use.

Looking forward to seeing the action to advance RFC 2679.

[Ballot comment]
As Barry, and Adrian say this looks like an implementation report. If that is the case it would be useful to modify the title, Abstract and Introduction to reflect that.

NetProbe and Perfas+ need references.

[Ballot comment]
The last paragraph of the introduction points to 2026 instead of 6410. Should it be updated to reflect 6410 the way similar text in 5657 was updated?

Does the first observation in section 6.3.2 ("it was not possible to confirm the estimated serialization time increases in field tests") indicate a need to update what 5657 asks for?

Fun fact: If the text survives, this will be the first RFC to contain the word "overlord".

[Ballot comment]
Adrian beat me to the click here: This says it's advancing 2679, but it's not, really.  It's an implementation report.  Are we going to have a 2679bis document to actually do the advancement?  Just a management item?  Discussion on the telechat to follow....

[Ballot discuss]
This note is for discussion with the other ADs during the IESG telechat
and will then be removed. No action is required from the document
authors.

The document says that its purpose is to advance RFC 2679 along the
standards track. That is fine. How do we intend to do it?

I note that RFC 2679 has an Errata Report held for document update.

[Ballot comment]
I am assuming that during this evaluation all metrics, metric
parameters, and methodologies defined in RFC 2679 were found to have
been implemented and to be of use.

[Ballot discuss]

  The Gen-ART Review by Brian Carpenter on 24-Aug-2012 raises several
  concerns.  I understand that all of these concerns have been addressed
  in the unpublished -03 version of this document.  Please post the
  updated version so these concerns can be resolved.

IANA has reviewed draft-ietf-ippm-testplan-rfc2679-02, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Test Plan and Results for Advancing RFC 2679 on the Standards Track) to Informational RFC


The IESG has received a request from the IP Performance Metrics WG (ippm)
to consider the following document:
- 'Test Plan and Results for Advancing RFC 2679 on the Standards Track'
  as 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 2012-08-14. 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.

Abstract


  This memo proposes to advance a performance metric RFC along the
  standards track, specifically RFC 2679 on One-way Delay Metrics.
  Observing that the metric definitions themselves should be the
  primary focus rather than the implementations of metrics, this memo
  describes the test procedures to evaluate specific metric requirement
  clauses to determine if the requirement has been interpreted and
  implemented as intended.  Two completely independent implementations
  have been tested against the key specifications of RFC 2679.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2679/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2679/ballot/


No IPR declarations have been submitted directly on this I-D.

- suggest changing:
  "The IETF (IP Performance Metrics working group, IPPM)"
  to:
  "The IETF IP Performance Metrics (IPPM) working group"

- the reference to draft-bradner in the first sentence of
  the introduction is odd; I would expect it to just show
  up as "[draft-bradner-metricstest]" and not have the
  part that says "ref to work in progress" or the trailing
  dash on it

- in the last paragraph of section 1, a space is missing
  prior to the reference to RFC 5657

- in the last paragraph of section 1:
  "procedures, results"
  should be:
  "procedures, and results"

- in section 2, references to RFC 6576 should replace the
  ones to the earlier I-D, and this section should either
  be cut-down in content or eliminated as it attmpts to
  include too much verbatim from the other document that
  can simply be cited instead

- in section 3, "WIPM" is not expanded and doesn't have a
  citation; I don't expect all other readers to necessarily
  know what this is

- in paragraph 2 of section 3, "periodic" is uncapitalized,
  even though it was capitalized in the prior paragraph

- the URLs for Fedora in section 3 should probably be real
  informative references rather than URLs embedded in square
  brackets

- in section 3,
  ""mii-tool"when"
  should be:
  ""mii-tool" when"
  if there's really even a need to mention the command by
  name; I think it's sufficient to say that the links were
  found to be in half-duplex without mentioning mii-tool
  specifically

- section 3 mentions 3 packet sizes that were used (64, 340,
  and 500 bytes); was there any reason these specific
  numbers were picked?  Was there any reason to avoid
  larger packets that might have been interesting (e.g.
  ones that would be fragmented?)

- in section 4.1,
  "Best Effort DCSP"
  should be:
  "Best Effort DSCP"?

- Section 4.2 has some use of "Perfas" mixed with "Perfas+"
  in other places; one should be used consistently

- Section 5 seems to include a paraphrase of what's in RFC
  6576 Section 3.1, without citing it?

- reference to the metrictest document can be updated to
  point to RFC 6576

- in Section 6.1.4, "out lier" should be "outlier"

- Section 6.1.5 has this note:
  >>>> To be provided:
  >>>> Overall statement about Correction Factors w.r.t. section 5
  limits.
  >>>> Appendix with more details ???

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational.  Yes, this is indicated and it is an information document.

(2) 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 proposes to advance a performance metric RFC along the
  standards track, specifically RFC 2679 on One-way Delay Metrics.
  Observing that the metric definitions themselves should be the
  primary focus rather than the implementations of metrics, this memo
  describes the test procedures to evaluate specific metric requirement
  clauses to determine if the requirement has been interpreted and
  implemented as intended.  Two completely independent implementations
  have been tested against the key specifications of RFC 2679.


    Working Group Summary
The normal WG process was followed and the document has been discussed for
about 2 year.  The document as it is now, reflects WG consensus, with nothing
special worth noticing.

Document Quality

  Are there existing implementations of the protocol?

Yes, the document describes actual work done.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Henk Uijterwaal, AD Wes Eddy.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Followed and contributed to the discussion on the document.  Read the final
document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) 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? 

Good, this is a test-plan following the procedure described in RFC 6576.
The WG has reviewed the document, understands it, and agrees with the plan.
The work described in the plan has been carried out in real life.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


  ** There is 1 instance of too long lines in the document, the longest one
    being 1 character in excess of 72.
    I'm not sure where this line occurs, but this is something to be fix by
    the editor.
  == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the
    document.
    This is correct, addresses are what they should be.
  == There are 11 instances of lines with non-RFC5735-compliant IPv4
    addresses in the document.  If these are example addresses, they should
    be changed.
    This is correct, addresses are what they should be.
  == Line 833 has weird spacing: '...ean adj    raw...'
  == Line 1021 has weird spacing: '...Payload    s1 ...'
  == Line 1027 has weird spacing: '...Payload    p1 ...'
  == Line 1156 has weird spacing: '...centile    no ...'
    All 4 are correct.
  -- The document has a disclaimer for pre-RFC5378 work, but was first
    submitted on or after 10 November 2008.  Does it really need the
    disclaimer?
    Yes
  == Missing Reference: 'AS 7018' is mentioned on line 373, but not defined
  == Missing Reference: 'AS 3320' is mentioned on line 377, but not defined
    This is correct, they are not a references.
  == Unused Reference: 'RFC4814' is defined on line 1219, but no explicit
    reference was found in the text
  == Unused Reference: 'RFC5226' is defined on line 1223, but no explicit
    reference was found in the text
    Both can be removed on publication.
  == Outdated reference: draft-ietf-ippm-metrictest has been published as RFC
    6576
    To be fixed on publication.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes, one reference needs to be updated as the draft is now an RFC.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

None

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section is essentially empty and can be removed on publication

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A