[ippm] Draft-ietf-ippm-delay-var-as-01

[Henk Uijterwaal <[e-mail]>]

Hi Lars,

The IPPM WG requests publication of draft-ietf-ippm-delay-var-as-01.  The
sheperd note for this document is below.  Let me know if you need anything
else from us.

Henk


- - - -

As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding [rfc4858],
this is the
current template for the Document Shepherd Write-Up. Changes are expected over
time. This
version is dated September 17, 2008.

Document shepherd writeup for draft-ietf-ippm-delay-var-as-01, as required by
rfc4858, and
specfied in the 17-Sep-2008 version of
<http://www.ietf.org/IESG/content/Doc-Writeup.html>.

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

The document shepherd is Henk Uijterwaal <[e-mail]>.  I have personally
reviewed
this document and would not have bothered to write this not if I didn't feel it
was ready for the IESG.

     (1.b) Has the document had adequate review both from key WG members
           and from key non-WG members? Does the Document Shepherd have
           any concerns about the depth or breadth of the reviews that
           have been performed?

I believe the document has received sufficent review from key WG members (see
acknowledgements
for names).  I don't believe there are key non-WG members that need to review
the document.
I have no concerns about the depth or breadth of reivews for this document.

     (1.c) Does the Document Shepherd have concerns that the document
           needs more review from a particular or broader perspective,
           e.g., security, operational complexity, someone familiar with
           AAA, internationalization or XML?

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?

None.

           Has an IPR disclosure related to this document been filed?

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 WG asked for this document after a talk from Roman Krasnowski at IETF-65,
the authors then voluntered to write it.  It has been presented at a couple
of meetings, received support and the authors have been thanked for writing
the document as it is needed in day to day operations.  The document has been
reviewed in dept by about 5 members of the group.   I have no indication that
the majority of the WG members does not understand what this document is about.


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

No.

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

There are currently 4 nits:

   == It looks like you're using RFC 3978 boilerplate.  You should update
      this, as the boilerplate described in the IETF Trust License Policy
      document (see http://trustee.ietf.org/license-info) is accepted from 10
      November 2008, and will soon be required.  Version 1.34 of xml2rfc can
      (when released) be used to produce documents with boilerplate according
      to the mentioned Trust License Policy document.

      I believe that this is a timing issue, the document was finished before the
      new boilerplate was.

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

      This reference can be removed by the editor.

   == Outdated reference: A later version (-07) exists of
      draft-ietf-ippm-framework-compagg-06
   == Outdated reference: A later version (-07) exists of
      draft-ietf-ippm-spatial-composition-06

      These are again timing issues.

           Has the document met all formal review criteria it needs to, such as
the MIB
           Doctor, media type and URI type reviews?

None of these are necessary.

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

Yes.

           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?

There is an IANA considerations section.  It is empty as the document doesn't
require anything from the IANA.

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

Not applicable.

     (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
    Packet delay variation metrics appear in many different standards
    documents.  The metric definition in RFC 3393 has considerable
    flexibility, and it allows multiple formulations of delay variation
    through the specification of different packet selection functions.

    Although flexibility provides wide coverage and room for new ideas,
    it can make comparisons of independent implementations more
    difficult.  Two different formulations of delay variation have come
    into wide use in the context of active measurements.  This memo
    examines a range of circumstances for active measurements of delay
    variation and their uses, and recommends which of the two forms is
    best matched to particular conditions and tasks.


           Working Group Summary
              Was there anything in WG process that is worth noting? For
              example, was there controversy about particular points or
              were there decisions where the consensus was particularly
              rough?

This document was suggested after a talk on this topic at IETF-65.  There
was no controversy in the WG process.  Consensus was smooth.

           Document Quality
              Are there existing implementations of the protocol?

This document does not describe a new protocal.


-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: [phone]
1001 EB Amsterdam      1016 AB Amsterdam  Fax: [phone]
The Netherlands        The Netherlands    Mobile: [phone]
------------------------------------------------------------------------------

Ceterum censeo Asplain esse delendam  (Cato & Henk)


-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: [phone]
1001 EB Amsterdam      1016 AB Amsterdam  Fax: [phone]
The Netherlands        The Netherlands    Mobile: [phone]
------------------------------------------------------------------------------

Ceterum censeo Asplain esse delendam  (Cato & Henk)
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm