Subject: [ippm] Publication request: draft-ietf-ippm-duplicate-06.txt

From: Matthew J Zekauskas <[email-masked]>
Date: Thu, 22 Jan 2009 10:45:28 -0500

The IETF IPPM working group requests publication of
draft-ietf-ippm-duplicate-06 as a proposed standard.

Matt Zekauskas <[email-masked]> will be Document Shepherd.

The Document Shepherd writeup is attached.

--Matt
Document shepherd writeup for draft-ietf-ippm-duplicate-06.txt, 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 Matt Zekauskas <[email-masked]>
The document shepherd has personally reviewed this document and
believes this version is read for forwarding to the IESG for
publication.

    (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.  I don't believe there are key non-WG members that need to
review the document; I did ask Dave Thalor about IPv6 terminology to
make sure we were consistent.  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? 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. Has an IPR disclosure related to this document 
          been filed? If so, please include a reference to the 
          disclosure and summarize the WG discussion and conclusion on 
          this issue. 

I know of no unusual conerns of which the AD and IESG in general should
be aware.

I know of no IPR disclosures related to this document.

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

I believe this document fills a missing hole in the IPPM metrics, and there
is fairly broad consensus for this document.  There have been reviews and
comment by the vocal members.

    (1.f) 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 
          entered into the ID Tracker.) 

no.

    (1.g) Has the Document Shepherd personally verified that the 
          document satisfies all ID nits? (See 
          http://www.ietf.org/ID-Checklist.html and 
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
          not enough; this check needs to be thorough. Has the document 
          met all formal review criteria it needs to, such as the MIB 
          Doctor, media type and URI type reviews? 

Yes, however one reference currently in the "informative" catagory
should be moved to normative based on the last revision.  See next.

    (1.h) Has the document split its references into normative and 
          informative? 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 
          strategy for their completion? Are there normative references 
          that are downward references, as described in [RFC3967]? If 
          so, list these downward references to support the Area 
          Director in the Last Call procedure for them [RFC3967]. 

The references are split into normative and non-normative.  However,
the last revision moved one reference [RFC3432] from "Informative" to
"Normative".  We discussed this with our AD, and believe that it can
be corrected either in updates based on comments from the IETF-wide
last call, or during the RFC editing process.  There are no "downard
references" nor references to drafts.

    (1.i) Has the Document Shepherd verified that the document IANA 
          consideration section exists and is consistent with the body 
          of the document? If the document specifies protocol 
          extensions, are reservations requested in appropriate IANA 
          registries? Are the IANA registries clearly identified? If 
          the document creates a new registry, does it define the 
          proposed initial contents of the registry and an allocation 
          procedure for future registrations? Does it suggest a 
          reasonable name for the new registry? See [RFC5226]. If the 
          document describes an Expert Review process has Shepherd 
          conferred with the Responsible Area Director so that the IESG 
          can appoint the needed Expert during the IESG Evaluation? 

The IANA consideration section exists, and is consistent with the
metrics registry rquiremetns it references.

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

There are no such sections.

    (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 
             Relevant content can frequently be found in the abstract 
             and/or introduction of the document. If not, this may be 
             an indication that there are deficiencies in the abstract 
             or introduction. 

When a packet is sent from one host to the other, one normally
expects that exactly one copy of the packet that was sent arrives
at the destination.  It is, however, possible that a packet is
either lost or that multiple copies arrive.  This document defines
a metric for the case where a packet is sent, but multiple copies
arrive.  The document also discusses streams and methods to
summarize the results of streams.

          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 when creating a succint summary of IPPM
metrics for reporting to users; this was one that was missing from the
IPPM metric suite.  There is consensus that this is the right definition.
There has been some question as to whether the definition is crisp and
unambiguous for both IPv4 and IPv6, and the document has been modified
to address those concerns.

          Document Quality 
             Are there existing implementations of the protocol? Have a 
             significant number of vendors indicated their plan to 
             implement the specification? Are there any reviewers that 
             merit special mention as having done a thorough review, 
             e.g., one that resulted in important changes or a 
             conclusion that the document had no substantive issues? If 
             there was a MIB Doctor, Media Type or other expert review, 
             what was its course (briefly)? In the case of a Media Type 
             review, on what date was the request posted? 

I know of no current implementations that claim to implement this metric.
However, vendors in the working group have read and agreed with the
specification.

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 23 Jan 2009 17:45:10 +0200

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 26 Jan 2009 10:29:22 +0100

Hi,

> Section 2.7., paragraph 1:
>  >    Refer to section 2.7 of [RFC2680]
> 
>   Section 2.7 of [RFC2680] contains a lot of stuff that doesn't seem to
>   be relevant to duplication. We may need to extract the relevant bits
>   and place them here. (The other sections in this document that refer
>   to 2680/3432 point to sections there that seem general enough.)

I've tried that and then ended up with about half the text of 2680.  What
did survive, didn't make much sense anymore, so the whole section had to
be re-written.  And then nobody would realize that this was simply extracted
from 2680 anymore.

Looking at it from a more practical point of view.  I'd expect that this
metric is used as part of a measurement system that measures properties
of packets (delay, loss, jitter, reordering, duplication).  The tricky
part is to set up the delay, with all clock issues related to that.  Once
you have done that, all others are simple.  Some of the clock stuff for
delay may be overkill for the other metrics, but who cares?

> Section 2.4., paragraph 2:
>   Same text appears in the first bullet above. Copy/paste issue?

Yes, fixed.  This is probably caused by having to do 3 versions with
very small changes over a relatively long period.

> Section 2.4., paragraph 5:
>  >    If a packet is fragmented during transport and if, for whatever
>  >    reason, re-assembly does not occur, then the packet will be deemed
>  >    lost.  It is thus not included in the Type-P-one-way-packet-arrival-
>  >    count.
> 
>   I'm a bit confused by the "re-assembly does not occur" part. Couldn't
>   we simply say that this metric can on only be meaningfully applied to
>   IP packets  after reassembly?

I don't think the latter is correct.  Suppose a packet A is split into A1
and A2.  A1 is duplicated during transport, A2 isn't.  My receiver thus
gets A1, A2, A1*.  It merges A1 and A2, then has A1* left in its buffers
and will be waiting for the other half to arrive.  One could argue that
there is duplication and Type-P-o-w-p-a-c should be >1.

In the metric, we have decided to consider these remnants lost and set
the value to 1.

> Section 2.5., paragraph 3: 
>   s/should/SHOULD/ (and why not MUST?)

MUST is indeed better.  (At least I cannot think of a reason why you would
use different timeouts).

> 
> 
> Section 9.2., paragraph 2:
>   This must become a normative reference, because 4.2.5, 4.2.6 and 4.2.7
>   simply point off to it.

Fixed.

I have a -07 version on my laptop ready to go if there are no further
comments.

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: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Belgium: an unsolvable problem, discussed in endless meetings, with no
          hope for a solution, where everybody still lives happily.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 Jan 2009 12:01:04 +0200

Hi,

> In the metric, we have decided to consider these remnants lost and set

right, that's exactly what I was trying to express. The metric only  
applies to packets after reassembly, and because no A2* is received,  
there is no duplicate.

I may have simply been confused by the wording in the draft, but if it  
was clear to everyone else so far, leave it as-is.

> I have a -07 version on my laptop ready to go if there are no further

Submit it and we'll go to IETF last call then.

Thanks,
Lars

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 27 Jan 2009 10:44:18 +0100

Hi Lars,

> Submit it and we'll go to IETF last call then.

Done.

Henk