Subject: [ippm] reminder: last calls underway

From: Matthew J Zekauskas <[email-masked]>
Date: Fri, 20 Jun 2008 10:12:15 -0400

There are currently two WGLC underway,

* draft-ietf-ippm-duplicate-03, ending 26-June-2008 23:59 UTC
<http://www.ietf.org/mail-archive/web/ippm/current/msg01485.html>
* draft-ietf-ippm-storetraceroutes-10, ending 4-July-2008 09:00 UTC
<http://www.ietf.org/mail-archive/web/ippm/current/msg01491.html>

Please read and comment.

In addition, there is also an IETF last call underway for
draft-ief-ippm-twamp-08, ending 2008-06-26.
<http://www.ietf.org/mail-archive/web/ippm/current/msg01489.html>

--Matt

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 27 Jun 2008 17:21:51 +0300

Hi,

I managed to squeeze in the AD review during WGLC.

High-level bit: Ready for publication, after we've clarified exactly  
which packet header fields need to be compared to determine duplication.

Lars

Detailed comments:

INTRODUCTION, paragraph 14:
 >    In earlier work, the IPPM (IP Performance Metrics) group defined a
 >    metric for packet loss.  This metric quantifies the case where a
 >    packet that is sent, never arrives at its destination.

   Nit: Rephrase to talk about RFC2680 rather than about the IPPM WG
   (published docs should avoid referring to WGs, because they are
   ephemeral).

Section 2.4., paragraph 1:
 >    Two packets are considered identical when were sent by one and the
 >    same host and contain identical information fields.  The recipient
 >    thus could take either packet and use it in an application, the  
other
 >    copy would not contain any additional information.
 >    The IP headers do not necessarily have to be identical.

   Related to the ongoing discussion about this on the mailing list, I
   agree that we need to clearly defined which fields of the IP header
   are compared to detect duplicates across a set of packets. Source and
   destination IP address, length, next header/protocol, IP ID (for
   IPv4), flow label (for IPv6), IP version and DSCP? (Also, nit: s/when
   were/when they were/)

Section 5.1., paragraph 1:
 >    This statistics gives the fraction of additional packets that  
arrived

   Nit: /statistics/statistic/

Section 5.1., paragraph 3:
 >    Note: this statistics is the equivalent of the Y.1540 IPDR [Y1540]

   Nit: /statistics/statistic/

Section 5.2., paragraph 1:
 >    This statistics gives the fraction of packets that was duplicated

   Nit: /statistics/statistic/

Section 1., paragraph 0:
 >    criterium as a fraction of the total.  (In other words: # with

   Nit: s/criterium/criterion/

Section 1., paragraph 3:
 >    Note: this statistics is the equivalent of the Y.1540 RIPR [Y1540]

   Nit: /statistics/statistic/

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 30 Jun 2008 11:17:06 +0200

Hi all,

I've just submitted the next iteration of the duplicate draft.  This one
addresses all comments and nits raised on the list.

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

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Jul 2008 11:54:29 +0300

Hi,

so this says that the source and destination IP address need to be the  
same for packet to be duplicates, but it's still vague about which  
fields in the next header ("transport" header, usually) need to be  
identical. I'm not convinced that this text will lead to  
implementations that will come up with the same measurement results  
for the same packet sequence. Can we be more precise?

>    Two packets are considered identical if and only if:
>
>    o  Both contain identical information fields.  The recipient thus
>       could take either packet and use the data in an application.   
> The
>       other packet does not contain any additional information.
>    o  Both packets appear to have been sent by one and the same  
> host, to
>       one and the same destination.  Host are identified by their IP
>       addresses.
>    o  Both contain valid, but not necessarily identical IP header
>       fields.

Lars