From walt.steverson@gmail.com Sun Mar 1 13:50:55 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F383A6BD6 for ; Sun, 1 Mar 2009 13:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQQF3WGhlK+C for ; Sun, 1 Mar 2009 13:50:54 -0800 (PST) Received: from mail-qy0-f6.google.com (mail-qy0-f6.google.com [209.85.221.6]) by core3.amsl.com (Postfix) with ESMTP id 05ECC3A6BE7 for ; Sun, 1 Mar 2009 13:50:53 -0800 (PST) Received: by qyk6 with SMTP id 6so427934qyk.29 for ; Sun, 01 Mar 2009 13:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=j+HF+95ogHtMiIzoM2X5XieYsTflkHnLcGEHoHls3pA=; b=EBvLgfZ3kOCIz/t/Ls3bYmDGcQkSRE1uPsqMOOmqarudbdgNt9z0xXv2Sv1CgVG7un fjNOBpruNYe0O6ukigoaxnesE+xmbOAmk17pHWYi7RIOdZJVuFUCU73OL5wVnYekAbtN QgoUrBlocwL5GwFE5E1NpuB7F/DH0X8G1Mru4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o73G7TWVAf9rkzmY2c3KNNUuLcJMwdVXUF39d3+tYN4FaVjOQH1b4NUfooyOPkT9oE +pUk5sG6S6fnJQel2KHv8juzJaANIE5zpG8aoY2/HRYwCIbhPucnuSRp+DN8IpB7a9iG MPyZg+IKJDXl5RAjipq10VuArE8dTJY0KQCIk= MIME-Version: 1.0 Received: by 10.229.82.76 with SMTP id a12mr2393861qcl.7.1235944278868; Sun, 01 Mar 2009 13:51:18 -0800 (PST) In-Reply-To: References: <200902202129.n1KLT1St021663@klph001.kcdc.att.com> Date: Sun, 1 Mar 2009 15:51:18 -0600 Message-ID: From: Walt Steverson To: "Krzanowski, Roman" Content-Type: multipart/alternative; boundary=0016364ee068b4446d046415b3a2 Cc: lencia@att.com, Al Morton , ippm@ietf.org Subject: Re: [ippm] Reflect-Octets: New TWAMP Test Packet Format? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 21:50:55 -0000 --0016364ee068b4446d046415b3a2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I do not think that the uneven boundaries on Reflected Padding will be a problem. That being said the proposed alternative test packet format makes it easier in the Test-Reflector to reuse the received test packet buffer in order to generate the response packet. In other words, just allowing the Test-Reflector to overwrite the Discard Fill padding can save a good bit of work when building up responses to TWAMP-Test packets. However, I think that there should be only one TWAMP-Test packet format and maintaining two ways of building up response test packets in the Test-Reflector based on the negotiated Reflect Padding option is undesirable in my opinion. This draft seems useful to me as a way to attach an opaque blob of data to each TWAMP-Test packet and guarantee that it will be sent back unchanged by the Test-Reflector to the Test-Sender. The Test-Sender can store whatever it wants in this payload (TLv, XML, etc.) and it should not be necessary to formally specify its format in a TWAMP extension because the Test-Reflector does not know or care about what the reflected padding octets represent. On Fri, Feb 20, 2009 at 4:26 PM, Krzanowski, Roman < roman.krzanowski@verizon.com> wrote: > Al > I am for the TLV structure as it would open TWAMP for future > enhancements as well as > For some propratary extensions , if needed vendor specific TLV code, > optional TLVs and so on... > In most of the control algorithms ( and other) I see TLv as an elegant > solution to the data structures > > > We would need to preserve the compatibility with the current format but > .. I guess this canbe done > My 3cs.. > rmk > > > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of > Al Morton > Sent: Friday, February 20, 2009 4:29 PM > To: ippm@ietf.org > Cc: lencia@att.com > Subject: [ippm] Reflect-Octets: New TWAMP Test Packet Format? > > IPPM, > > Len Ciavattone and I introduced the possibility > for a significant test packet format overhaul last > November at IETF-73: > http://www.ietf.org/proceedings/08nov/slides/ippm-4/ippm-4.htm > > and in the draft > http://tools.ietf.org/html/draft-ietf-ippm-twamp-reflect-octets-00#secti > on-5 > > We were proposing to make some changes as part of the Reflect-Octets > draft/work item, because it makes sense to deal with several format > aspects at once. > > There were some suggestions made at the mike and captured in the > minutes: > > >Open question: consider change the structure of the TWAMP structure > >to TLV type structure to make it more extensible. > > > >Questions from the floor: Roman Kraznowski said he had some things he'd > >like to add. He'd post to the list. > > Please take a look at the slides and the draft > and make further comments, so we can determine a path forward. > > thanks and regards, > Al and Len > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --0016364ee068b4446d046415b3a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do not think that the uneven boundaries on Reflected Padding will be a pr= oblem.=A0 That being said the proposed alternative test packet format makes= it easier in the Test-Reflector to reuse the received test packet buffer i= n order to generate the response packet.=A0 In other words, just allowing t= he Test-Reflector to overwrite the Discard Fill padding can save a good bit= of work when building up responses to TWAMP-Test packets.=A0 However, I th= ink that there should be only one TWAMP-Test packet format and maintaining = two ways of building up response test packets in the Test-Reflector based o= n the negotiated Reflect Padding option is undesirable in my opinion.=A0
This draft seems useful to me as a way to attach an opaque blob of data= to each TWAMP-Test packet and guarantee that it will be sent back unchange= d by the Test-Reflector to the Test-Sender.=A0 The Test-Sender can store wh= atever it wants in this payload (TLv, XML, etc.) and it should not be neces= sary to formally specify its format in a TWAMP extension because the Test-R= eflector does not know or care about what the reflected padding octets repr= esent.


On Fri, Feb 20, 2009 at 4:26 PM, Krzanow= ski, Roman <roman.krzanowski@verizon.com> wrote:
Al
I am for the TLV structure as it would open TWAMP for future
enhancements as well as
For some propratary =A0extensions , if needed vendor specific TLV code,
optional TLVs and so on...
In most of the control algorithms ( and other) I see TLv as an elegant
solution to the data structures


We would need to preserve the compatibility with the current format but
.. I guess this canbe done
My 3cs..
rmk


-----Original Message-----
From: ippm-bounces@ietf.org [m= ailto:ippm-bounces@ietf.org] O= n Behalf Of
Al Morton
Sent: Friday, February 20, 2009 4:29 PM
To: ippm@ietf.org
Cc: lencia@att.com
Subject: [ippm] Reflect-Octets: New TWAMP Test Packet Format?

IPPM,

Len Ciavattone and I introduced the possibility
for a significant test packet format overhaul last
November at IETF-73:
http://www.ietf.org/proceedings/08nov/slides/ippm-4/ippm-= 4.htm

and in the draft
http://tools.ietf.org/html/draft-ietf-ip= pm-twamp-reflect-octets-00#secti
on-5

We were proposing to make some changes as part of the Reflect-Octets
draft/work item, because it makes sense to deal with several format
aspects at once.

There were some suggestions made at the mike and captured in the
minutes:

>Open question: consider change the structure of the TWAMP structure
>to TLV type structure to make it more extensible.
>
>Questions from the floor: Roman Kraznowski said he had some things he&#= 39;d
>like to add. =A0He'd post to the list.

Please take a look at the slides and the draft
and make further comments, so we can determine a path forward.

thanks and regards,
Al and Len


_______________________________________________
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm

--0016364ee068b4446d046415b3a2-- From bortzmeyer@nic.fr Sun Mar 1 23:54:20 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BDC43A6892 for ; Sun, 1 Mar 2009 23:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUGxXAo4FbjG for ; Sun, 1 Mar 2009 23:54:20 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id C9D013A67F9 for ; Sun, 1 Mar 2009 23:54:19 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 11C6C1C018B for ; Mon, 2 Mar 2009 08:54:45 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0D7A31C017A for ; Mon, 2 Mar 2009 08:54:45 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id E51497BA476 for ; Mon, 2 Mar 2009 08:54:44 +0100 (CET) Date: Mon, 2 Mar 2009 08:54:44 +0100 From: Stephane Bortzmeyer To: ippm@ietf.org Message-ID: <20090302075444.GA9490@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [ippm] XSLT stylesheet for RFC 5388 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 07:54:20 -0000 I'm looking for a XSLT stylesheet to translate reports in RFC 5388 syntax to XHTML. Anyone has this? Otherwise, I plan to write it but I'm lazy and would prefer an existing stylesheet. From henk@ripe.net Tue Mar 3 02:10:25 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DF328C265 for ; Tue, 3 Mar 2009 02:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.754 X-Spam-Level: X-Spam-Status: No, score=-7.754 tagged_above=-999 required=5 tests=[AWL=2.845, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0hIwr3vhwvH for ; Tue, 3 Mar 2009 02:10:22 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id D42033A6B05 for ; Tue, 3 Mar 2009 02:10:19 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1LeRaF-0007zq-63; Tue, 03 Mar 2009 11:10:45 +0100 Received: from geir.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 1A75D2F583; Tue, 3 Mar 2009 11:10:43 +0100 (CET) Message-ID: <49AD0223.8040505@ripe.net> Date: Tue, 03 Mar 2009 11:10:43 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Al Morton References: <7.1.0.9.0.20081109092728.0036fb48@att.com> <200902202117.n1KLHdQY009905@klph001.kcdc.att.com> In-Reply-To: <200902202117.n1KLHdQY009905@klph001.kcdc.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5cc52d02ef698ffd82912fa7d3adc5188 Cc: ippm-ads@tools.ietf.org, ippm@ietf.org Subject: Re: [ippm] Use TLS in TWAMP-Control? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 10:10:25 -0000 IPPM group, Al Morton wrote: > At the last IPPM meeting, I was asked to re-send this > to the list, to see if it might prompt any additional > discussion ... This hasn't generated much discussion in the last 2 weeks. If people feel strongly about this, please speak up in the next week. If we don't hear from anybody by 10/3, the topic is dropped. 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 wwwrun@core3.amsl.com Tue Mar 3 10:58:59 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 29DF528C2EE; Tue, 3 Mar 2009 10:58:59 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090303185859.29DF528C2EE@core3.amsl.com> Date: Tue, 3 Mar 2009 10:58:59 -0800 (PST) Cc: henk@ripe.net, matt@internet2.edu, ippm@ietf.org Subject: [ippm] WG Action: RECHARTER: IP Performance Metrics (ippm) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:58:59 -0000 The charter of the IP Performance Metrics (ippm) working group in the Transport Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. IP Performance Metrics (ippm) -------------------------------------------- Last Modified: 2009-02-19 Status: Active Working Group Additional information is available at tools.ietf.org/wg/ippm Chair(s): Matthew Zekauskas [matt@internet2.edu] Henk Uijterwaal [henk@ripe.net] Transport Area Director(s): Magnus Westerlund [magnus.westerlund@ericsson.com] Lars Eggert [lars.eggert@nokia.com] Transport Area Advisor: Lars Eggert [lars.eggert@nokia.com] Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ippm In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ippm/index.html Description of Working Group: The IPPM WG has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. It is important that the metrics not represent a value judgment (i.e. define "good" and "bad"), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. This is the current list of fundamental metrics and the existing set of derived metrics. - connectivity - one-way delay and loss - round-trip delay. - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity - packet duplication The working group will advance these metrics along the standards track within the IETF. The WG will document the process of moving documents along the standards track, based on draft-bradner-metricstest. As this process is likely to be needed by other groups as well (in particular BMWG, PMOL), the group will collaborate with other groups in order to ensure that there is consensus amongst all groups expected to use the process. Additionally, the WG will produce Proposed Standard AS documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, packet bursts or multimedia streams. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. The AS documents can also discuss the use of the metrics to verify performance expectations, such as SLA's, report results to specific user groups or investigate network problems. The focus is, again, to define how this should be done, not to define a value judgment. The WG may define additional statistics for its metrics if needed. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will work on documents describing how to compose and decompose the results of its metrics over time or space. The WG has produced protocols to enable communication among test equipment that implements the one- and two-way metrics (OWAMP and TWAMP respectively). OWAMP and TWAMP will be advanced along the standards track. Further development of these protocols will also be done inside the WG. The metrics developed by the WG were developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most metrics can be used inside a passive context as well. No work is planned is this area though, this may be changed with AD approval. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF) to promote consistent approaches and metrics. Within the IETF process, IPPM metrics definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersect with the requirement of these specific metrics. The WG will, on request, provide input to other IETF WG on the use of these metrics. Goals and Milestones: Done Submit drafts of standard metrics for connectivity and treno- bulk-throughput. Done Submit a framework document describing terms and notions used in the IPPM effort, and the creation of metrics by the working group to IESG for publication as an Informational RFC. Done Submit documents on delay and loss to IESG for publication as Informational RFCs. Done Submit a document on connectivity to IESG for publication as an Informational RFC. Done Submit a document on bulk-throughput to IESG for publication as an Informational RFC. Done Submit draft on loss pattern sample metrics to the IESG for publication as an Informational RFC. Done Submit draft on metrics for periodic streams to the IESG for publication as a Proposed Standard RFC. Done Submit draft on IP delay variation to the IESG for publication as a Proposed Standard RFC. Done First draft for AS on one-way delay and loss. Done Submit draft on One-Way Active Measurement Protocol Requirements to the IESG for consideration as an Informational RFC. Done Create initial draft on a MIB for reporting IPPM metrics. Done Create initial draft on a packet reordering metric. Done Create draft on a One-Way Active Measurement Protocol that satisfies the requirements document. Done Submit draft on the One-Way Active Measurement Protocol to the IESG for consideration as a PS. Done Submit draft on implementation reports for RFCs 2678-2681 to the IESG Done Submit initial draft on framework for Composition and Aggregation Metrics Done Submit draft on the One-Way Active Measurement Protocol to the IESG for consideration as a PS Done Submit draft on a packet reordering metric to the IESG for Proposed Standard Done Submit initial applicability statement for the IPPM and ITU Jitter Measurements to the WG Done Submit link bandwidth capacity definitions draft to the IESG, for consideration as an Informational RFC Done Submit draft on storing results of traceroute measurements to the IESG Done Submit draft on Two-way active measurements protocol (TWAMP) to the IESG for consideration as proposed standard Done Develop new charter text Done Delay Variation Applicability Statement (Informational) to IESG Review Mar 2009 Assemble editorial team to work on the process draft (WG version of draft-bradner-metricstest) Mar 2009 -00 version of SLA validation draft Apr 2009 Submit draft on spatial composition of metrics to the IESG Apr 2009 Submit draft on Temporal Aggregation of Metrics to the IESG Apr 2009 Submit draft on spatial decomposition and multicast metrics to the IESG Apr 2009 Submit "more TWAMP" draft to IESG Jun 2009 Initial version of process draft Nov 2009 Submit other TWAMP extensions draft to IESG. Dec 2009 Final version of process draft Mar 2010 Implementation report based on process draft Jun 2010 Revise charter From rfc-editor@rfc-editor.org Tue Mar 3 16:02:30 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CAE28C29D; Tue, 3 Mar 2009 16:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.112 X-Spam-Level: X-Spam-Status: No, score=-17.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2w8401gFGXt; Tue, 3 Mar 2009 16:02:29 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 9E34E28C2A8; Tue, 3 Mar 2009 16:02:28 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 1961123D298; Tue, 3 Mar 2009 16:01:34 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090304000134.1961123D298@bosco.isi.edu> Date: Tue, 3 Mar 2009 16:01:34 -0800 (PST) Cc: ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 5481 on Packet Delay Variation Applicability Statement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:02:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5481 Title: Packet Delay Variation Applicability Statement Author: A. Morton, B. Claise Status: Informational Date: March 2009 Mailbox: acmorton@att.com, bclaise@cisco.com Pages: 39 Characters: 92218 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-delay-var-as-02.txt URL: http://www.rfc-editor.org/rfc/rfc5481.txt 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. This memo provides information for the Internet community. This document is a product of the IP Performance Metrics Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From Ruediger.Geib@telekom.de Wed Mar 4 05:32:03 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FA528C285 for ; Wed, 4 Mar 2009 05:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcxtY4ZCQ37D for ; Wed, 4 Mar 2009 05:32:02 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 973B828C287 for ; Wed, 4 Mar 2009 05:32:02 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 04 Mar 2009 14:32:28 +0100 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 14:32:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 14:32:26 +0100 Message-ID: <151C164FE2E066418D8D44D0801543A5A1714F@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <20090303185859.29DF528C2EE@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Assemble editorial team to work on WG version of draft-bradner-metricstest Thread-Index: AcmcMnS0Kgg6hsfsSdWbvz5cP6t28QAmVkpg References: <20090303185859.29DF528C2EE@core3.amsl.com> From: To: , X-OriginalArrivalTime: 04 Mar 2009 13:32:28.0098 (UTC) FILETIME=[A9653220:01C99CCD] Cc: ippm@ietf.org Subject: [ippm] Assemble editorial team to work on WG version of draft-bradner-metricstest X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 13:32:03 -0000 Hi Henk, hi Matt, please add me to that team.=20 Should my colleague ever have time to review my personal and yet = unpublished draft (he's moved that review to end of March by now), we = are happy to publish the document as personal draft and maybe he is = willing to join the team too.=20 I'll also forward my personal draft without Deutsche Telekom internal = review to the editorial team, once it is set up. As I'm not an expert on = statistics, I'm shying away from a distribution to the list without = getting the review of my colleague, who's having that expertise. Sorry for failing again to produce something prior to an IETF meeting. Regards, Ruediger From ljorgenson@apparentnetworks.com Thu Mar 5 11:06:32 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C5828C495 for ; Thu, 5 Mar 2009 11:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifu8Rc4amb11 for ; Thu, 5 Mar 2009 11:06:31 -0800 (PST) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id 5392528C425 for ; Thu, 5 Mar 2009 11:06:31 -0800 (PST) X-AuditID: ac108108-00000dc800000758-20-49af2c0b3f24 Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 17:34:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99D31.EA934C50" Date: Wed, 4 Mar 2009 17:34:04 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: comments on draft-ietf-ippm-multimetrics-09 thread-index: AcmdMnLmimDfDjp8RgegFEopM4/DXg== From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Subject: [ippm] comments on draft-ietf-ippm-multimetrics-09 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:06:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99D31.EA934C50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments related to meaning and readability - most of the following are simply corrections to mangled English (seeming ESL errors) - in some cases the original intention is not apparent. Nothing of technical issue is raised. =20 ----- =20 Section 2.6 - It would be useful to make some direct reference to multicast at this point. Otherwise it leaves the reader wondering what the relationship between one-to-group and multicast is, and what else it could be. =20 Section 8. =20 Paragraph 2 - "As an example, delay..." should be "As an example, delays..." =20 Paragraph 3 - "... requirement is the online gaming." should be "... requirement is online gaming." - "A very light delay..." should be "A very small delay..." =20 Paragraph 8 - "might want to know how this statistics distributed over ...." should be "might want to know how these statistics are distributed over..." - "... information on how good the service...." should be "... information on how well the service..." - "It needs twice calculation..." should be "It requires twice as much calculation..." - "We name this kind of statistics 2-level statistics to distinct with.... " should be "This kind of statistics is referred to as 2-level statistics to distinguish them from..." =20 Section 8.1 Paragraph 1 - "For example, the lost packet..." should be "For example a lost packet..." - "However, the packet loss has so strong impact on ..." should be "However, packet loss has such a strong impact on..." =20 Paragraph 2 - "... no single packet arrives all users..." is broken - it is not clear what it should be. As a guess "... in the case where no packets arrive at any user..." =20 Section 9.1 - "... when the measurement has huge number..." should be "... includes a very large number ..." - "... reference point by over load the ... " should be "... reference point by overloading the ..." - ... and release the pressure of the scalability issue ..." should be " ... and mitigate issues arising from scalability..." - "... between the bandwidth consuming and ..." should be " ... between bandwidth consumption and ..." - "... and the information acquiring has to be taken into account when design the measurement campaign ..." should be " and information acquisition has to be taken into account when designing the measurement approach ..." - "The possible solution... " should be "One possible solution..." - "If the detail results are required.... " should be "If detailed results are required ..." =20 Section 9.2 - "... to be routed than send and ..." should be "to be routed than sent and...." =20 Section 9.3 - "2 methods" should be "Two methods" (appears twice at least). - "...for computing the stat over space." should be "... for subsequent computations over the spatial dimension." =20 Section 9.3.1 - "2 methods" should be "Two methods"=20 - "... by each points of interest..." should be "... for each point of interest..." - "method2" should be "Method2" =20 Section 9.3.2 - "2 methods" should be "Two methods" =20 Section 10.2.1 - "... there is a path tree SHOULD be reported rather than A path." is broken - it is unclear what it should properly say. - "If, by anyway, ... " should be "If, in any case, ..." - "... might be difficult to identify its position..." should be " ... might make it difficult to identify its position ..." - " ... the packet travelled through ..." should be "... the packet travelling along ..." =20 Section 10.2.2 - ".. there is no need of order of points of interest." is broken - it is unclear what it should say. =20 Section 10.4=20 Paragraph 2 - "The information model is build...." should be "The information model is built..." - "... by sections "Methodology" and "errors and Uncertainties" sections." should drop the second use of "sections". =20 =20 Loki Jorgenson e ljorgenson@ApparentNetworks.com t 604 433 2333 ext 105 w www.ApparentNetworks.com =20 ------_=_NextPart_001_01C99D31.EA934C50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Comments related to=20 meaning and readability - most of the following are simply corrections = to=20 mangled English (seeming ESL errors) - in some cases the original = intention is=20 not apparent.  Nothing of technical issue is = raised.
 
-----
 
Section 2.6 - It=20 would be useful to make some direct reference to multicast at this = point. =20 Otherwise it leaves the reader wondering what the relationship between=20 one-to-group and multicast is, and what else it could = be.
 
Section 8. =20
Paragraph 2 - "As an=20 example, delay..." should be "As an example, = delays..."
 
Paragraph 3 - "...=20 requirement is the online gaming." should be "... requirement is online=20 gaming."
       &nbs= p;          -=20 "A very light delay..." should be "A very small = delay..."
 
Paragraph 8 - "might=20 want to know how this statistics distributed over ...." should be "might = want to=20 know how these statistics are distributed over..."
       &nbs= p;         =20 - "... information on how good the service...." should be "... = information on=20 how well the service..."
       &nbs= p;         =20 - "It needs twice calculation..." should be "It requires twice as much=20 calculation..."
       &nbs= p;         =20 - "We name this kind of statistics 2-level statistics to distinct = with.... "=20 should be "This kind of statistics is referred to as 2-level statistics = to=20 distinguish them from..."
 
Section=20 8.1
Paragraph 1 - "For=20 example, the lost packet..." should be "For example a lost=20 packet..."
       &nbs= p;         =20 - "However, the packet loss has so strong impact on ..." should be = "However,=20 packet loss has such a strong impact on..."
 
Paragraph 2 - "...=20 no single packet arrives all users..." is broken - it is not clear what = it=20 should be.  As a guess "... in the case where no packets arrive at = any=20 user..."
 
Section 9.1 - "...=20 when the measurement has huge number..." should be "... includes a very = large=20 number ..."
       &nbs= p;         =20 - "... reference point by over load the ... " should be "... reference = point by=20 overloading the ..."
       &nbs= p;         =20 - ... and release the pressure of the scalability issue ..." should be " = ... and=20 mitigate issues arising from scalability..."
       &nbs= p;         =20 - "... between the bandwidth consuming and ..." should be " ... between=20 bandwidth consumption and ..."
       &nbs= p;         =20 - "... and the information acquiring has to be taken into account = when=20 design the measurement campaign ..." should be " and information = acquisition has=20 to be taken into account when designing the measurement approach=20 ..."
       &nbs= p;         =20 - "The possible solution... " should be "One possible=20 solution..."
       &nbs= p;         =20 - "If the detail results are required.... " should be "If detailed = results are=20 required ..."
 
Section 9.2 - "...=20 to be routed than send and ..." should be "to be routed than sent=20 and...."
 
Section 9.3 - "2=20 methods" should be "Two methods" (appears twice at = least).
       &nbs= p;         -=20 "...for computing the stat over space." should be "... for subsequent=20 computations over the spatial dimension."
 
Section 9.3.1 - "2=20 methods" should be "Two methods"
       &nbs= p;           =20 - "... by each points of interest..." should be "... for each point of=20 interest..."
       &nbs= p;           =20 - "method2" should be "Method2"
 
Section 9.3.2 - "2=20 methods" should be "Two methods"
 
Section 10.2.1 -=20 "... there is a path tree SHOULD be reported rather than A path." is = broken - it=20 is unclear what it should properly say.
       &nbs= p;            = ;  -=20 "If, by anyway, ... " should be "If, in any case, = ..."
       &nbs= p;            = ;  -=20 "... might be difficult to identify its position..." should be " ... = might make=20 it difficult to identify its position ..."
       &nbs= p;            = ; =20 - " ... the packet travelled through ..." should be "... the packet = travelling along ..."
 
Section 10.2.2 - "..=20 there is no need of order of points of interest."  is broken - it = is=20 unclear what it should say.
 
Section 10.4=20
Paragraph 2 - "The=20 information model is build...." should be "The information model is=20 built..."
       &nbs= p;          -=20 "... by sections "Methodology" and "errors and Uncertainties" sections." = should=20 drop the second use of "sections".
 
 
Loki Jorgenson

e  =20 ljorgenson@ApparentNetworks.com
t   604 433 2333 ext=20 105
w   www.ApparentNetworks.com

 
------_=_NextPart_001_01C99D31.EA934C50-- From mchiba@cisco.com Fri Mar 6 08:53:40 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38ADA28C159 for ; Fri, 6 Mar 2009 08:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsc58bREyX-G for ; Fri, 6 Mar 2009 08:53:38 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C94A03A6921 for ; Fri, 6 Mar 2009 08:53:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,315,1233532800"; d="scan'208,217,223";a="262640698" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Mar 2009 16:54:09 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n26Gs9Gr010573; Fri, 6 Mar 2009 08:54:09 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n26Gs9Fi006318; Fri, 6 Mar 2009 16:54:09 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Mar 2009 08:54:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99E7C.2B07073E" Date: Fri, 6 Mar 2009 08:54:08 -0800 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] Reflect-Octets: New TWAMP Test Packet Format? Thread-Index: Acmat93dW+PQ7iccSaGTlkWFxbKYLgDwh1tw References: <200902202129.n1KLT1St021663@klph001.kcdc.att.com> From: "Murtaza Chiba (mchiba)" To: "Walt Steverson" , "Krzanowski, Roman" X-OriginalArrivalTime: 06 Mar 2009 16:54:09.0554 (UTC) FILETIME=[2B405720:01C99E7C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12816; t=1236358449; x=1237222449; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20RE=3A=20[ippm]=20Reflect-Octets=3A=20New=20TWAM P=20Test=20Packet=20Format? |Sender:=20; bh=3g/rKBMGj1AfS5iSnfWLzMyuByxix06H4YvjpLiWZmY=; b=bHhEV2O8jTXpY3OOJ4Tt7SWr+3PYe+za35pZu969oVCu/1AYdf/36SAjqO Arvv5zO/4DQL4CuQ1X4t1EHvG6AxC/I+Tx44NFWvqIyWLXvVHJ36f7N+Fapc rNmRi1VOz9; Authentication-Results: sj-dkim-2; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lencia@att.com, Al Morton , ippm@ietf.org Subject: Re: [ippm] Reflect-Octets: New TWAMP Test Packet Format? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 16:53:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99E7C.2B07073E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From an implementation perspective and in the spirit of allowing quick turnarounds, the original timestamp location should not be juggled around. That would allow implementations to add the two new stamps into the original incoming packet and send it out quickly and save having to create a new packet or do mem-copies to temporary locations. The feature to have the same size test packets in both directions is definitely a plus. =20 On the TLV issue, if they are to be opaque then its ok to have them. Is the spec looking to coordinate the interpretation of the TLV on the sender? =20 -murtaza =20 =20 From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Walt Steverson Sent: Sunday, March 01, 2009 1:51 PM To: Krzanowski, Roman Cc: lencia@att.com; Al Morton; ippm@ietf.org Subject: Re: [ippm] Reflect-Octets: New TWAMP Test Packet Format? =20 I do not think that the uneven boundaries on Reflected Padding will be a problem. That being said the proposed alternative test packet format makes it easier in the Test-Reflector to reuse the received test packet buffer in order to generate the response packet. In other words, just allowing the Test-Reflector to overwrite the Discard Fill padding can save a good bit of work when building up responses to TWAMP-Test packets. However, I think that there should be only one TWAMP-Test packet format and maintaining two ways of building up response test packets in the Test-Reflector based on the negotiated Reflect Padding option is undesirable in my opinion. =20 This draft seems useful to me as a way to attach an opaque blob of data to each TWAMP-Test packet and guarantee that it will be sent back unchanged by the Test-Reflector to the Test-Sender. The Test-Sender can store whatever it wants in this payload (TLv, XML, etc.) and it should not be necessary to formally specify its format in a TWAMP extension because the Test-Reflector does not know or care about what the reflected padding octets represent. On Fri, Feb 20, 2009 at 4:26 PM, Krzanowski, Roman wrote: Al I am for the TLV structure as it would open TWAMP for future enhancements as well as For some propratary extensions , if needed vendor specific TLV code, optional TLVs and so on... In most of the control algorithms ( and other) I see TLv as an elegant solution to the data structures We would need to preserve the compatibility with the current format but .. I guess this canbe done My 3cs.. rmk -----Original Message----- From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of Al Morton Sent: Friday, February 20, 2009 4:29 PM To: ippm@ietf.org Cc: lencia@att.com Subject: [ippm] Reflect-Octets: New TWAMP Test Packet Format? IPPM, Len Ciavattone and I introduced the possibility for a significant test packet format overhaul last November at IETF-73: http://www.ietf.org/proceedings/08nov/slides/ippm-4/ippm-4.htm and in the draft http://tools.ietf.org/html/draft-ietf-ippm-twamp-reflect-octets-00#secti on-5 =20 We were proposing to make some changes as part of the Reflect-Octets draft/work item, because it makes sense to deal with several format aspects at once. There were some suggestions made at the mike and captured in the minutes: >Open question: consider change the structure of the TWAMP structure >to TLV type structure to make it more extensible. > >Questions from the floor: Roman Kraznowski said he had some things he'd >like to add. He'd post to the list. Please take a look at the slides and the draft and make further comments, so we can determine a path forward. thanks and regards, Al and Len _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm =20 ------_=_NextPart_001_01C99E7C.2B07073E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From an implementation perspective and in the spirit of = allowing quick turnarounds, the original timestamp location should not be juggled = around.  That would allow implementations to add the two new stamps into the = original incoming packet and send it out quickly and save having to create a new = packet or do mem-copies to temporary locations. The feature to have the same = size test packets in both directions is definitely a plus.

 

On the TLV issue, if they are to be opaque then its ok to = have them. Is the spec looking to coordinate the interpretation of the TLV on = the sender?

 

-murtaza

 

 

From:= ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of = Walt Steverson
Sent: Sunday, March 01, 2009 1:51 PM
To: Krzanowski, Roman
Cc: lencia@att.com; Al Morton; ippm@ietf.org
Subject: Re: [ippm] Reflect-Octets: New TWAMP Test Packet = Format?

 

I do not think that = the uneven boundaries on Reflected Padding will be a problem.  That being said = the proposed alternative test packet format makes it easier in the = Test-Reflector to reuse the received test packet buffer in order to generate the = response packet.  In other words, just allowing the Test-Reflector to = overwrite the Discard Fill padding can save a good bit of work when building up = responses to TWAMP-Test packets.  However, I think that there should be only one TWAMP-Test packet format and maintaining two ways of building up = response test packets in the Test-Reflector based on the negotiated Reflect Padding = option is undesirable in my opinion. 

This draft seems useful to me as a way to attach an opaque blob of data = to each TWAMP-Test packet and guarantee that it will be sent back unchanged by = the Test-Reflector to the Test-Sender.  The Test-Sender can store = whatever it wants in this payload (TLv, XML, etc.) and it should not be necessary to formally specify its format in a TWAMP extension because the = Test-Reflector does not know or care about what the reflected padding octets = represent.

On Fri, Feb 20, 2009 at 4:26 PM, Krzanowski, Roman = <roman.krzanowski@verizon.com= > wrote:

Al
I am for the TLV structure as it would open TWAMP for future
enhancements as well as
For some propratary  extensions , if needed vendor specific TLV = code,
optional TLVs and so on...
In most of the control algorithms ( and other) I see TLv as an = elegant
solution to the data structures


We would need to preserve the compatibility with the current format = but
.. I guess this canbe done
My 3cs..
rmk



-----Original Message-----
From: ippm-bounces@ietf.org = [mailto:ippm-bounces@ietf.org] On = Behalf Of
Al Morton
Sent: Friday, February 20, 2009 4:29 PM
To: ippm@ietf.org
Cc: lencia@att.com
Subject: [ippm] Reflect-Octets: New TWAMP Test Packet Format?

IPPM,

Len Ciavattone and I introduced the possibility
for a significant test packet format overhaul last
November at IETF-73:
http://www.ietf.org/proceedings/08nov/slides/ippm-4/ipp= m-4.htm

and in the draft
http://tools.ietf.org/html/draft-ietf-ippm-twamp-reflec= t-octets-00#secti
on-5

We were proposing to make some changes as part of the Reflect-Octets
draft/work item, because it makes sense to deal with several format
aspects at once.

There were some suggestions made at the mike and captured in the
minutes:

>Open question: consider change the structure of the TWAMP = structure
>to TLV type structure to make it more extensible.
>
>Questions from the floor: Roman Kraznowski said he had some things = he'd
>like to add.  He'd post to the list.

Please take a look at the slides and the draft
and make further comments, so we can determine a path forward.

thanks and regards,
Al and Len


_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

 

------_=_NextPart_001_01C99E7C.2B07073E-- From root@core3.amsl.com Sat Mar 7 08:00:01 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D5D113A69BF; Sat, 7 Mar 2009 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090307160001.D5D113A69BF@core3.amsl.com> Date: Sat, 7 Mar 2009 08:00:01 -0800 (PST) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-spatial-composition-08.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Spatial Composition of Metrics Author(s) : A. Morton, E. Stephan Filename : draft-ietf-ippm-spatial-composition-08.txt Pages : 26 Date : 2009-03-07 This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-spatial-composition-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-spatial-composition-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07075427.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sat Mar 7 08:00:01 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E019C3A69CB; Sat, 7 Mar 2009 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090307160001.E019C3A69CB@core3.amsl.com> Date: Sat, 7 Mar 2009 08:00:01 -0800 (PST) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-reflect-octets-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : TWAMP Reflect Octets Feature Author(s) : A. Morton, L. Ciavattone Filename : draft-ietf-ippm-twamp-reflect-octets-01.txt Pages : 18 Date : 2009-03-07 The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes a new feature for TWAMP: an optional capability where the responder host returns some of the command octets or padding octets to the controller, and/or ensures that the same test packet sizes are used in both directions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-reflect-octets-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-twamp-reflect-octets-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07075500.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sat Mar 7 08:00:02 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E7D613A69CD; Sat, 7 Mar 2009 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090307160001.E7D613A69CD@core3.amsl.com> Date: Sat, 7 Mar 2009 08:00:01 -0800 (PST) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-twamp-session-cntrl-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Individual Session Control Feature for TWAMP Author(s) : A. Morton, M. Chiba Filename : draft-ietf-ippm-twamp-session-cntrl-01.txt Pages : 18 Date : 2009-03-07 The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes a new feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions previously requested and accepted to start and stop at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-session-cntrl-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-twamp-session-cntrl-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07075521.I-D@ietf.org> --NextPart-- From henk@ripe.net Mon Mar 9 06:39:21 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED173A6C48 for ; Mon, 9 Mar 2009 06:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.258 X-Spam-Level: X-Spam-Status: No, score=-7.258 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueuQe7QmeIR0 for ; Mon, 9 Mar 2009 06:39:20 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 803333A6C2D for ; Mon, 9 Mar 2009 06:39:19 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Lgfhu-0005CY-5o for ippm@ietf.org; Mon, 09 Mar 2009 14:39:52 +0100 Received: from geir.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 271D22F583 for ; Mon, 9 Mar 2009 14:39:50 +0100 (CET) Message-ID: <49B51C26.3060808@ripe.net> Date: Mon, 09 Mar 2009 14:39:50 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "ippm >> IETF IPPM WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5949f56c3484a17f608e00fe4ea8ac8a6 X-RIPE-Spam-Report: Spam detection software, running on the system "ibis.ripe.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi all, 1. Administrativia (chairs, 5') 2. Current work. (10') Status of milestones and drafts not discussed today. [...] Content analysis details: (-4.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list Subject: [ippm] draft agenda for SF meeting X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 13:39:22 -0000 Hi all, 1. Administrativia (chairs, 5') 2. Current work. (10') Status of milestones and drafts not discussed today. 3. Burst loss metrics (Nick Duffield) draft-duffield-ippm-burst-loss-metrics-00 4. TWAMP extensions. a. Mixed Mode Extension for TWAMP (Morton and Hedayat) b. TWAMP Reflect Padding Feature (Morton and Ciavattone) c. Individual Session Control Feature for TWAMP (Morton) d. Use of TLS in TWAMP Control (Morton) 5. Metrics composition drafts 6. Establish editorial team to work on the metrics-test document 7. Liaison Report from SG12, Question 17 on Packet Performance 8. AOB Comments and additions welcome, 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 bortzmeyer@nic.fr Mon Mar 9 09:12:56 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6DD43A6C37 for ; Mon, 9 Mar 2009 09:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.219 X-Spam-Level: X-Spam-Status: No, score=-5.219 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbuEe0Tf68iP for ; Mon, 9 Mar 2009 09:12:55 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id C55083A680B for ; Mon, 9 Mar 2009 09:12:55 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id DAAB91C015A for ; Mon, 9 Mar 2009 17:08:27 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id D68771C011D for ; Mon, 9 Mar 2009 17:08:27 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id CB442A1D9A8 for ; Mon, 9 Mar 2009 17:08:27 +0100 (CET) Date: Mon, 9 Mar 2009 17:08:27 +0100 From: Stephane Bortzmeyer To: ippm@ietf.org Message-ID: <20090309160827.GA4670@nic.fr> References: <20090302075444.GA9490@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090302075444.GA9490@nic.fr> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [ippm] XSLT stylesheet for RFC 5388 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 16:12:57 -0000 On Mon, Mar 02, 2009 at 08:54:44AM +0100, Stephane Bortzmeyer wrote a message of 7 lines which said: > I'm looking for a XSLT stylesheet to translate reports in RFC 5388 > syntax to XHTML. Anyone has this? Well, I'm writing one so if you have requirments, or want to beta-test or are willing to code, get in touch with me, off-list. From root@core3.amsl.com Mon Mar 9 13:30:02 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 29DAF3A6C2B; Mon, 9 Mar 2009 13:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309203002.29DAF3A6C2B@core3.amsl.com> Date: Mon, 9 Mar 2009 13:30:02 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-reporting-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Reporting IP Performance Metrics to Users Author(s) : S. Shalunov, M. Swany Filename : draft-ietf-ippm-reporting-03.txt Pages : 44 Date : 2009-03-09 The aim of this document is to define a small set of metrics that are robust, easy to understand, orthogonal, relevant, and easy to compute. The IPPM WG has defined a large number of richly parameterized metrics because network measurement has many purposes. Often, the ultimate purpose is to report a concise set of metrics describing a network's state to an end user. It is for this purpose that the present set of metrics is defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ippm-reporting-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09132829.I-D@ietf.org> --NextPart-- From henk@ripe.net Mon Mar 9 23:55:44 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E623A6C77 for ; Mon, 9 Mar 2009 23:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.922 X-Spam-Level: X-Spam-Status: No, score=-7.922 tagged_above=-999 required=5 tests=[AWL=1.385, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94i-jg2yUnzn for ; Mon, 9 Mar 2009 23:55:39 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 2FF333A6A60 for ; Mon, 9 Mar 2009 23:55:39 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Lgvso-0004rz-G5 for ippm@ietf.org; Tue, 10 Mar 2009 07:56:12 +0100 Received: from geir.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 6DE952F583 for ; Tue, 10 Mar 2009 07:56:10 +0100 (CET) Message-ID: <49B60F0A.8020704@ripe.net> Date: Tue, 10 Mar 2009 07:56:10 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 Cc: ippm@ietf.org References: <20090309203002.29DAF3A6C2B@core3.amsl.com> In-Reply-To: <20090309203002.29DAF3A6C2B@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5dc5d2d8e77ff6dc2f735db222ddeee94 X-RIPE-Spam-Report: Spam detection software, running on the system "ibis.ripe.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Stas, Martin, Do you want agenda time for this in SF? Henk [...] Content analysis details: (-4.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list Subject: Re: [ippm] I-D Action:draft-ietf-ippm-reporting-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 06:55:44 -0000 Stas, Martin, Do you want agenda time for this in SF? 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 henk@ripe.net Tue Mar 10 03:42:41 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335033A6A38 for ; Tue, 10 Mar 2009 03:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.706 X-Spam-Level: X-Spam-Status: No, score=-4.706 tagged_above=-999 required=5 tests=[AWL=-2.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwPfD+tI-lbN for ; Tue, 10 Mar 2009 03:42:40 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 099153A6911 for ; Tue, 10 Mar 2009 03:42:40 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1LgzQH-0001Lm-0Y; Tue, 10 Mar 2009 11:42:59 +0100 Received: from geir.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id E20452F583; Tue, 10 Mar 2009 11:42:56 +0100 (CET) Message-ID: <49B64430.2040408@ripe.net> Date: Tue, 10 Mar 2009 11:42:56 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Henk Uijterwaal References: <7.1.0.9.0.20081109092728.0036fb48@att.com> <200902202117.n1KLHdQY009905@klph001.kcdc.att.com> <49AD0223.8040505@ripe.net> In-Reply-To: <49AD0223.8040505@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5fb5e50d9f9983f9fd17c945ea42bb738 X-RIPE-Spam-Report: Spam detection software, running on the system "gull.ripe.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: IPPM group, > Al Morton wrote: >> At the last IPPM meeting, I was asked to re-send this >> to the list, to see if it might prompt any additional >> discussion ... > > This hasn't generated much discussion in the last 2 weeks. If people > feel strongly about this, please speak up in the next week. If we don't > hear from anybody by 10/3, the topic is dropped. [...] Content analysis details: (-4.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list Cc: ippm-ads@tools.ietf.org, Al Morton , ippm@ietf.org Subject: Re: [ippm] Use TLS in TWAMP-Control? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 10:42:41 -0000 IPPM group, > Al Morton wrote: >> At the last IPPM meeting, I was asked to re-send this >> to the list, to see if it might prompt any additional >> discussion ... > > This hasn't generated much discussion in the last 2 weeks. If people > feel strongly about this, please speak up in the next week. If we don't > hear from anybody by 10/3, the topic is dropped. Nobody spoke up, so this topic is dropped until there is sufficient interest to work on this. 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 henk@ripe.net Tue Mar 10 03:46:06 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572833A6CF7 for ; Tue, 10 Mar 2009 03:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.515 X-Spam-Level: X-Spam-Status: No, score=-8.515 tagged_above=-999 required=5 tests=[AWL=2.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxnMElzaBE4X for ; Tue, 10 Mar 2009 03:46:05 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 1D7E03A6911 for ; Tue, 10 Mar 2009 03:46:05 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1LgzTm-0002YW-Hc for ippm@ietf.org; Tue, 10 Mar 2009 11:46:36 +0100 Received: from geir.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 78F362F583 for ; Tue, 10 Mar 2009 11:46:34 +0100 (CET) Message-ID: <49B6450A.7050906@ripe.net> Date: Tue, 10 Mar 2009 11:46:34 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d55fbe79ccdc84a0d9f33722c6f84b5659 X-RIPE-Spam-Report: Spam detection software, running on the system "ibis.ripe.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: IPPM group, This is a WGLC for the draft: draft-ietf-ippm-more-twamp-00.txt The draft has been discussed extensively in this group and appears to to be stable by now. We like to start a WGLC in order to move it forward. Please raise any remaining issues by Tuesday, March 31, 9:00am GMT. [...] Content analysis details: (-4.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list Subject: [ippm] WGLC for draft-ietf-ippm-more-twamp-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 10:46:06 -0000 IPPM group, This is a WGLC for the draft: draft-ietf-ippm-more-twamp-00.txt The draft has been discussed extensively in this group and appears to to be stable by now. We like to start a WGLC in order to move it forward. Please raise any remaining issues by Tuesday, March 31, 9:00am GMT. An URL for the draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-more-twamp-00.txt Matt & 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 henk@ripe.net Tue Mar 10 03:54:01 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB74E3A6CED for ; Tue, 10 Mar 2009 03:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.688 X-Spam-Level: X-Spam-Status: No, score=-4.688 tagged_above=-999 required=5 tests=[AWL=-2.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qktBJYt9OE5r for ; Tue, 10 Mar 2009 03:54:00 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 99E1F3A69B7 for ; Tue, 10 Mar 2009 03:54:00 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1LgzbU-0001Vt-5f for ippm@ietf.org; Tue, 10 Mar 2009 11:54:34 +0100 Received: from geir.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 1C66A2F583 for ; Tue, 10 Mar 2009 11:54:32 +0100 (CET) Message-ID: <49B646E8.1070502@ripe.net> Date: Tue, 10 Mar 2009 11:54:32 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d53bb1d8f4de9da1e7639eeab6412f472b X-RIPE-Spam-Report: Spam detection software, running on the system "ibis.ripe.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Also uploaded at: http://www.ietf.org/proceedings/09mar/agenda/ippm.txt where corrections will appear. Comments welcome, if you are presenting, please send me your slides. Agenda IPPM Meeting @ IETF74. ============================= Tuesday, 13:00-15:00) [...] Content analysis details: (-4.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list Subject: [ippm] Agenda for SF X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 10:54:01 -0000 Also uploaded at: http://www.ietf.org/proceedings/09mar/agenda/ippm.txt where corrections will appear. Comments welcome, if you are presenting, please send me your slides. Agenda IPPM Meeting @ IETF74. ============================= Tuesday, 13:00-15:00) 1. Administrativia (chairs, 5') 2. Status of milestones and drafts not discussed today. (Chairs, 10') 3. TWAMP extensions. (5' each) a. Mixed Mode Extension for TWAMP (Hedayat and Morton) b. Individual Session Control Feature for TWAMP (Chiba and Morton) c. TWAMP Reflect Padding Feature (Morton and Ciavattone) 4. Metrics composition drafts. a. Framework draft. Report from reviewers (10', Stein, Kraznowski) draft-ietf-ippm-framework-compagg-07.txt b. Other drafts. (5') 5. Reporting draft a. Group draft (Swany, 10') draft-ietf-ippm-reporting-03.txt b. Individual submission (Morton, 5') 6. Burst loss metrics (Nick Duffield, 20') draft-duffield-ippm-burst-loss-metrics-00 7. Establish editorial team to work on the metrics-test document (20') (Chairs to introduce, then floor discussion). 8. Liaison Report from SG12, Question 17 on Packet Performance (5') 9. AOB ------------------------------------------------------------------------------ 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 acmorton@att.com Tue Mar 10 05:33:42 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62023A6A3D for ; Tue, 10 Mar 2009 05:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.747 X-Spam-Level: X-Spam-Status: No, score=-105.747 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnwkTuNFeUq4 for ; Tue, 10 Mar 2009 05:33:42 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id EB90B3A67BD for ; Tue, 10 Mar 2009 05:33:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-11.tower-146.messagelabs.com!1236688454!15994719!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 1675 invoked from network); 10 Mar 2009 12:34:14 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 10 Mar 2009 12:34:14 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2ACYCPO013602 for ; Tue, 10 Mar 2009 08:34:12 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2ACY8Je013540 for ; Tue, 10 Mar 2009 08:34:08 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n2ACY8GF000568 for ; Tue, 10 Mar 2009 08:34:08 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n2ACY4Gk000534 for ; Tue, 10 Mar 2009 08:34:04 -0400 Message-Id: <200903101234.n2ACY4Gk000534@alph001.aldc.att.com> Received: from acmt.att.com (vpn-135-70-160-70.vpn.mwst.att.com[135.70.160.70](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090310123403gw1000u6c0e>; Tue, 10 Mar 2009 12:34:03 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Mar 2009 08:34:00 -0400 To: Henk Uijterwaal , IETF IPPM WG From: Al Morton In-Reply-To: <49B646E8.1070502@ripe.net> References: <49B646E8.1070502@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] Agenda for SF X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 12:33:42 -0000 At 06:54 AM 3/10/2009, Henk Uijterwaal wrote: ... >5. Reporting draft > a. Group draft (Swany, 10') > draft-ietf-ippm-reporting-03.txt > b. Individual submission (Morton, 5') http://tools.ietf.org/html/draft-morton-ippm-reporting-metrics-06 We've had some good discussion of this draft in the past, and I've found the opportunity to reference some of the material it presents, in RFC 5481 for example. I'd like to get any further comments on the draft and its disposition. thanks, Al From ljorgenson@apparentnetworks.com Fri Mar 13 16:22:47 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDAE3A68C4 for ; Fri, 13 Mar 2009 16:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06vqFT9fqFy8 for ; Fri, 13 Mar 2009 16:22:46 -0700 (PDT) Received: from JSRVR18.jaalam.net (relay2.apparentnetworks.net [209.139.228.52]) by core3.amsl.com (Postfix) with ESMTP id 8EE293A67F0 for ; Fri, 13 Mar 2009 16:22:46 -0700 (PDT) X-AuditID: ac108108-00000db000000758-32-49baeaed5da7 Received: from jsrvr8.jaalam.net ([172.16.128.105] RDNS failed) by JSRVR18.jaalam.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 16:23:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A432.1A048556" Date: Fri, 13 Mar 2009 16:23:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: comments on draft-ietf-ippm-framework-compagg-07 thread-index: AcmkMq5fJ/lo4jftTfm6fVLFXWoXig== From: "Loki Jorgenson" To: X-Brightmail-Tracker: AAAAAA== Cc: Al Morton Subject: [ippm] comments on draft-ietf-ippm-framework-compagg-07 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 23:22:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A432.1A048556 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.1 - The term "measurement point" is never used subsequently - it should be removed - unless changes are made to utilize it (no suggestions where). =20 Section 3.4 - The term "complete time interval" is never used subsequently - it should be removed - unless, changes are made to utilize it in sections (e.g. 6.1.1) =20 Section 3.7 - The tem "index" is never used subsequently - should be removed - given its relevance to PMOL, it probably should not be introduced. =20 Section 4.5 (second paragraph) "The seconds step..." --> "The second step...." =20 Section 5 - for clarity, I would suggest making the last paragraph regarding IPR into section 5.1 =20 =20 Has there been any substantial discussion regarding applicability to capacity (available or total) and reordering measures? It is not clear to me why this framework should not include either - except that there are no IPPM RFC definitions/metrics to refer to. =20 Is there any need to keep and expand the meaning of "index"? Or is it sufficient to push it off to PMOL as a discussion point within the metric framework? I would recommend that it be pushed to PMOL and the existing cross-referencing be reinforced. =20 These last two points MAY be brought up at the meeting. Loki Jorgenson Chief Scientist Apparent Networks The Hudson House Suite 400 - 321 Water Street Vancouver, BC, Canada, V6B 1B8 e ljorgenson@ApparentNetworks.com t 604 433 2333 ext 105 f 604 433 2311 m 604 250-4642 w www.ApparentNetworks.com =20 ------_=_NextPart_001_01C9A432.1A048556 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Section 3.1 - The term "measurement = point" is=20 never used subsequently - it should be removed - unless changes are made = to=20 utilize it (no suggestions where).
 
Section 3.4 = - The=20 term "complete time interval" is never used subsequently - it = should be=20 removed - unless, changes are made to utilize it in sections (e.g.=20 6.1.1)
 
Section 3.7 -=20 The tem "index" is never used subsequently - should be removed - = given its=20 relevance to PMOL, it probably should not be = introduced.
 
Section 4.5 (second=20 paragraph) "The seconds step..." --> "The second=20 step...."
 
Section 5 - for=20 clarity, I would suggest making the last paragraph regarding IPR into = section=20 5.1
 
 
Has = there been any=20 substantial discussion regarding applicability to capacity (available or = total)=20 and reordering measures?  It is not clear to me why this framework = should=20 not include either - except that there are no IPPM RFC = definitions/metrics to=20 refer to.
 
Is = there any need to=20 keep and expand the meaning of "index"?  Or is it sufficient to = push it off=20 to PMOL as a discussion point within the metric framework?  I would = recommend that it be pushed to PMOL and the existing cross-referencing = be=20 reinforced.
 
These = last two=20 points MAY be brought up at the meeting.

Loki Jorgenson
Chief Scientist
Apparent = Networks
The=20 Hudson House
Suite 400 - 321 Water Street
Vancouver, BC, Canada, = V6B=20 1B8

e   = ljorgenson@ApparentNetworks.com
t   604=20 433 2333 ext 105
f   604 433 2311
m   604=20 250-4642
w   www.ApparentNetworks.com

 
------_=_NextPart_001_01C9A432.1A048556-- From acmorton@att.com Mon Mar 23 06:16:57 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F0B3A6858 for ; Mon, 23 Mar 2009 06:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=-2.230, BAYES_20=-0.74, DATE_IN_PAST_24_48=1.219, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSdPBmKpzBas for ; Mon, 23 Mar 2009 06:16:56 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id CD2E53A69D7 for ; Mon, 23 Mar 2009 06:16:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-129.messagelabs.com!1237814265!9177634!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 6495 invoked from network); 23 Mar 2009 13:17:46 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-13.tower-129.messagelabs.com with AES256-SHA encrypted SMTP; 23 Mar 2009 13:17:46 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2NDHjL8020748 for ; Mon, 23 Mar 2009 06:17:45 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2NDHdBb020667 for ; Mon, 23 Mar 2009 06:17:39 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n2NDHdUN012475 for ; Mon, 23 Mar 2009 08:17:39 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n2NDHaYa012441 for ; Mon, 23 Mar 2009 08:17:36 -0500 Message-Id: <200903231317.n2NDHaYa012441@klph001.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-34-82.vpn.west.att.com[135.70.34.82](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090323131735gw1000u65re>; Mon, 23 Mar 2009 13:17:35 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Mar 2009 14:35:45 -0400 To: "Loki Jorgenson" , From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: Re: [ippm] comments on draft-ietf-ippm-framework-compagg-07 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:16:57 -0000 Hi Loki,

Thanks for your comments, see below.

Al

At 07:23 PM 3/13/2009, Loki Jorgenson wrote:
Section 3.1 - The term "measurement point" is never used subsequently - it should be removed - unless changes are made to utilize it (no suggestions where).

But this is a Framework, providing the core definitions for other drafts.
We use this term in the spatial composition draft. (e.g., 4.1.7)

 
Section 3.4 - The term "complete time interval" is never used subsequently - it should be removed - unless, changes are made to utilize it in sections (e.g. 6.1.1)

That's a good suggestion, and I expect that this term
will be used in a future draft on temporal aggregation.

 
Section 3.7 - The tem "index" is never used subsequently - should be removed - given its relevance to PMOL, it probably should not be introduced.

I think we agreed to do pull it into the PMOL framework at the
last PMOL meeting (the ippm document was not revised since then).

 
Section 4.5 (second paragraph) "The seconds step..." --> "The second step...."
 
Section 5 - for clarity, I would suggest making the last paragraph regarding IPR into section 5.1
 
 
Has there been any substantial discussion regarding applicability to capacity (available or total) and reordering measures?  It is not clear to me why this framework should not include either - except that there are no IPPM RFC definitions/metrics to refer to.

Yes, we discussed reordering at the outset of the project,
and excluded it because it didn't appear to conform to the
assumption of independent performance between segments,
and because reordering in one segment might be completely undone
in another, or made worse - hard to predict.
We didn't discuss Capacity specifically, but we didn't have
the RFC definitions yet, either.
 
Is there any need to keep and expand the meaning of "index"?  Or is it sufficient to push it off to PMOL as a discussion point within the metric framework?  I would recommend that it be pushed to PMOL and the existing cross-referencing be reinforced.

I prefer to move it cleanly (delete in the "composition" framework),
as it's not a critical part of this topic, AFAICT.
From henk@ripe.net Mon Mar 23 08:56:21 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1713A69E0 for ; Mon, 23 Mar 2009 08:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.38 X-Spam-Level: X-Spam-Status: No, score=-8.38 tagged_above=-999 required=5 tests=[AWL=2.219, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ2nmxaBB8d9 for ; Mon, 23 Mar 2009 08:56:21 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id DF1993A6803 for ; Mon, 23 Mar 2009 08:56:20 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1LlmWR-0008Dt-LZ for ippm@ietf.org; Mon, 23 Mar 2009 16:57:10 +0100 Received: from dhcp-13e9.meeting.ietf.org (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 5126F2F583 for ; Mon, 23 Mar 2009 16:57:07 +0100 (CET) Message-ID: <49C7B152.4080704@ripe.net> Date: Mon, 23 Mar 2009 16:57:06 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d50cf847862dcc2fc134fcb022f4b18bfe Subject: [ippm] Slides for tomorrow X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 15:56:21 -0000 Hi all, If you are presenting in the meeting tomorrow (and you haven't already done this), then please send us your slides. 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 matt@internet2.edu Mon Mar 23 10:38:59 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1A93A684E for ; Mon, 23 Mar 2009 10:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOK1PPCOfDwI for ; Mon, 23 Mar 2009 10:38:58 -0700 (PDT) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id 99F9A3A67C1 for ; Mon, 23 Mar 2009 10:38:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id A1D74225A5F; Mon, 23 Mar 2009 13:39:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QtC-QLzVzvj; Mon, 23 Mar 2009 13:39:48 -0400 (EDT) Received: from dhcp-53e5.meeting.ietf.org (unknown [130.129.83.229]) (Authenticated sender: matt@internet2.edu) by magus.merit.edu (Postfix) with ESMTP id E0F92225472; Mon, 23 Mar 2009 13:39:46 -0400 (EDT) Message-ID: <49C7C95E.204@internet2.edu> Date: Mon, 23 Mar 2009 13:39:42 -0400 From: Matthew J Zekauskas User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Hedayat, Kaynam" , roman.krzanowski@verizon.com, Al Morton , kyum@juniper.net, babiarz@nortel.com X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsv-ads@tools.ietf.org, IETF IPPM WG Subject: [ippm] Clearing RFC 5357 errata X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:38:59 -0000 Hi, Henk and I have been asked to work on clearing out the RFC Editor Errata queue for IPPM RFCs. There were a bunch submitted for RFC 5357. You can see them here: What we need to do is have you (as authors) look at them, and decide if you think they are - in the correct catagory (technical or editorial) - Verified (an interoperability issue that needs to change) (we can suggest alternate wording or solution) - Rejected (not applicable) - Hold for document update (something that should be considered the next time the document is updated, but isn't important enough to make a statement about now). Guidelines for making these decisions are at and more information on what the catagories and states represent are at . Would you look and give us your opinions by close of business Friday, April 24? Thanks, --Matt From acmorton@att.com Mon Mar 23 10:58:30 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF82F3A6B03 for ; Mon, 23 Mar 2009 10:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.577 X-Spam-Level: X-Spam-Status: No, score=-105.577 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTeMwN1YdAMp for ; Mon, 23 Mar 2009 10:58:30 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id AF3183A6BF4 for ; Mon, 23 Mar 2009 10:57:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-167.messagelabs.com!1237831126!10368581!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22719 invoked from network); 23 Mar 2009 17:58:46 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-4.tower-167.messagelabs.com with AES256-SHA encrypted SMTP; 23 Mar 2009 17:58:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2NHwkE5028122 for ; Mon, 23 Mar 2009 13:58:46 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2NHwh4C028098 for ; Mon, 23 Mar 2009 13:58:43 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n2NHwg7Q009537 for ; Mon, 23 Mar 2009 13:58:42 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n2NHwcUt009005 for ; Mon, 23 Mar 2009 13:58:38 -0400 Message-Id: <200903231758.n2NHwcUt009005@alph001.aldc.att.com> Received: from acmt.att.com (vpn-135-70-33-188.vpn.west.att.com[135.70.33.188](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090323175836gw1000u69me>; Mon, 23 Mar 2009 17:58:37 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Mar 2009 13:58:32 -0400 To: Matthew J Zekauskas , "Hedayat, Kaynam" , roman.krzanowski@verizon.com, kyum@juniper.net, babiarz@nortel.com From: Al Morton In-Reply-To: <49C7C95E.204@internet2.edu> References: <49C7C95E.204@internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tsv-ads@tools.ietf.org, IETF IPPM WG Subject: Re: [ippm] Clearing RFC 5357 errata X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:58:31 -0000 At 01:39 PM 3/23/2009, Matthew J Zekauskas wrote: >...Would you look and give us your opinions by close of business Friday, >April 24? I did look through them about a month ago, and there may have been something minor I disagreed with, but the vast majority were "valid" errors, with decent corrections. I'm not too familiar with the process, need to check it out... Al From bortzmeyer@nic.fr Tue Mar 24 03:05:01 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D343A6CCB for ; Tue, 24 Mar 2009 03:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.668 X-Spam-Level: X-Spam-Status: No, score=-5.668 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfsUJNiRGXEW for ; Tue, 24 Mar 2009 03:04:57 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 7EB2E3A684C for ; Tue, 24 Mar 2009 03:04:56 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id C1AC61C0157 for ; Tue, 24 Mar 2009 10:31:51 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B0F501C0134 for ; Tue, 24 Mar 2009 10:31:51 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id AE62E7B0041 for ; Tue, 24 Mar 2009 10:31:51 +0100 (CET) Date: Tue, 24 Mar 2009 10:31:51 +0100 From: Stephane Bortzmeyer To: ippm@ietf.org Message-ID: <20090324093151.GA11936@nic.fr> References: <20090302075444.GA9490@nic.fr> <20090309160827.GA4670@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <20090309160827.GA4670@nic.fr> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [ippm] XSLT stylesheet for RFC 5388 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 10:05:01 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 09, 2009 at 05:08:27PM +0100, Stephane Bortzmeyer wrote a message of 13 lines which said: > Well, I'm writing one so if you have requirments, or want to beta-test > or are willing to code, get in touch with me, off-list. First version. It should work with any XSLT 1.0 processor. There is the main file and two drivers, one for generating standalone HTML and one for generating a snippet, intended to be included in a larger Web page. --5mCyUwZo2JvN/JJP Content-Type: application/xml Content-Disposition: attachment; filename="traceroute2html.xsl" Content-Transfer-Encoding: quoted-printable =0A=0A=0A]>=0A=0A =0A =0A=0A =0A =0A =0A =0A=0A =0A =0A <= xsl:template match=3D"tr:traceRoute"> =0A
= &newline;=0A = =0A
=0A =0A=0A =0A =0A =0A= =0A =0A

Traceroute: =

&new= line;=0A =0A =

=0A =0A

=0A = =0A &newline;=0A = =0A=0A =0A =0A =0A=0A =0A=0A =0A = OS name:
= &newline;=0A =0A=0A =0A OS version:
&newline;=0A =0A=0A =0A Tool name= :
&newlin= e;=0A =0A=0A =0A Tool version:
&newline;=0A =0A=0A = =0A Source = address:
&newl= ine;=0A =0A=0A =0A Target name or address:
&newline;=0A =0A=0A =0A Initial TTL:
&newline; =0A =0A=0A =0A Maximum TTL:
&newline;=0A =0A=0A =0A =0A =0A=0A =0A =0A =0A =0A= =0A =0A =0A =0A=0A =0A =0A = =0A =0A = =0A=0A =0A =0A =0A = =0A =0A=0A =0A = =0A =0A =0A =0A=0A =0A =0A = =0A=0A =0A =0A *=0A =0A =0A=0A =0A =0A =0A=0A =0A =0A ms=0A =0A = =0A=0A =0A =0A =0A=0A =0A =0A =0A =0A = =0A =0A OK (=0A =0A =0A =0A )=0A =0A =0A =0A =0A = =0A = Time out=0A =0A = =0A *=0A = =0A =0A =0A = UNKNOWN STATUS=0A = =0A =0A =0A=0A =0A =0A =0A =0A =0A =0A =0A = =0A=0A =0A =0A =0A =0A =0A=0A =0A =0A =0A =0A =0A=0A =0A =0A =0A =0A =0A=0A =0A =0A =0A =0A = =0A=0A =0A = =0A =0A =0A =0A=0A =0A =0A Address unknown=0A =0A =0A=0A = =0A =0A =0A =0A =0A=0A =0A =0A =0A= =0A =0A=0A =0A =0A = =0A=0A =0A = =0A =0A =0A = =0A =0A = =0A =0A =0A = =0A =0A
HopMachine
=0A = =0A=0A=0A =0A =0A Probe #=0A =0A =0A =0A =0A =0A =0A=0A=0A =0A =0A =0A =0A =0A =0A =0A =0A =0A =0A =0A= =0A =0A = =0A =0A (=0A =0A )=0A = =0A =0A =0A =0A =0A =0A=0A =0A =0A =0A = Traceroute&newline;= &newline;=0A =0A = &newline;=0A =0A = =0A =0A =0A =0A =0A=0A =0A =0A =0A Unknown element =0A = =0A =0A =0A=0A =0A --5mCyUwZo2JvN/JJP Content-Type: application/xml Content-Disposition: attachment; filename="standalone-traceroute2html.xsl" Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A =0A=0A =0A=0A = =0A=0A=0A --5mCyUwZo2JvN/JJP Content-Type: application/xml Content-Disposition: attachment; filename="snippet-traceroute2html.xsl" Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A =0A=0A =0A=0A =0A=0A=0A --5mCyUwZo2JvN/JJP-- From henk@ripe.net Tue Mar 24 09:33:49 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46F13A6B44 for ; Tue, 24 Mar 2009 09:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.45 X-Spam-Level: X-Spam-Status: No, score=-8.45 tagged_above=-999 required=5 tests=[AWL=2.149, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S9vVl2q2UUu for ; Tue, 24 Mar 2009 09:33:48 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 7A8913A6A3C for ; Tue, 24 Mar 2009 09:33:48 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Lm9aG-0006Bd-8m for ippm@ietf.org; Tue, 24 Mar 2009 17:34:38 +0100 Received: from geir.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 314DF2F592 for ; Tue, 24 Mar 2009 17:34:35 +0100 (CET) Message-ID: <49C90B9A.9010204@ripe.net> Date: Tue, 24 Mar 2009 17:34:34 +0100 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d55c83f5c5af0ac491860f5be32423ba1b Subject: [ippm] Missing slides X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:33:49 -0000 Hi all, I'm still missing the slides for = Metrics composition drafts, reports from reviewers: Stein, Kraznowski = Reporting Draft/Swany, Zekauskas If you see your name in the list above, then please send me your slides. 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 matt@internet2.edu Tue Mar 24 09:38:12 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC7A28C2AF for ; Tue, 24 Mar 2009 09:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5GGJpJ51LeH for ; Tue, 24 Mar 2009 09:38:12 -0700 (PDT) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id D4CB328C26B for ; Tue, 24 Mar 2009 09:38:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id 1E998225BB9; Tue, 24 Mar 2009 12:38:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q9QqDDxpLXA; Tue, 24 Mar 2009 12:38:52 -0400 (EDT) Received: from dhcp-61fd.meeting.ietf.org (unknown [130.129.97.253]) (Authenticated sender: matt@internet2.edu) by magus.merit.edu (Postfix) with ESMTP id B5DA8225BCD; Tue, 24 Mar 2009 12:38:52 -0400 (EDT) Message-ID: <49C90C9A.6090005@internet2.edu> Date: Tue, 24 Mar 2009 12:38:50 -0400 From: Matthew J Zekauskas User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Henk Uijterwaal References: <49C90B9A.9010204@ripe.net> In-Reply-To: <49C90B9A.9010204@ripe.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IPPM WG Subject: Re: [ippm] Missing slides X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:38:12 -0000 On 3/24/09 12:34 PM, Henk Uijterwaal wrote: > Hi all, > > I'm still missing the slides for > > = Metrics composition drafts, reports from reviewers: Stein, Kraznowski > > = Reporting Draft/Swany, Zekauskas I uploaded this one directly :) --Matt > > If you see your name in the list above, then please send me your slides. > > Henk > From lars.eggert@nokia.com Tue Mar 24 14:23:55 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFAEC3A6D43 for ; Tue, 24 Mar 2009 14:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8TV1F+2fGVE for ; Tue, 24 Mar 2009 14:23:54 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 278F03A6BFF for ; Tue, 24 Mar 2009 14:23:51 -0700 (PDT) Received: from [IPv6:2001:df8::16:219:e3ff:fe06:dc74] ([IPv6:2001:df8:0:16:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2OLOVEc016226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2009 23:24:34 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <830000E6-D146-4A23-BCA0-0AAD8FC2B312@nokia.com> From: Lars Eggert To: IETF IPPM WG Content-Type: multipart/signed; boundary=Apple-Mail-26--222850047; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 14:24:31 -0700 X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Tue, 24 Mar 2009 23:24:36 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9160/Tue Mar 24 18:50:40 2009 on fit.nokia.com X-Virus-Status: Clean Cc: js1893@att.com, nd1321@att.com, jk2594@att.com Subject: [ippm] draft-duffield-ippm-burst-loss-metrics IPR X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:23:55 -0000 --Apple-Mail-26--222850047 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, the IPR text in draft-duffield-ippm-burst-loss-metrics points to https://datatracker.ietf.org/ipr/1009/ https://datatracker.ietf.org/ipr/1010/ However, both of these IPR disclosures are on slide decks *about* the draft, rather than on the draft itself. What is missing is an IPR disclosure on the draft itself. I encourage the IPR holder to file such a disclosure at their earliest convenience. Thanks, Lars --Apple-Mail-26--222850047 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTAzMjQyMTI0MzFaMCMGCSqGSIb3DQEJBDEWBBRZjG03mq9YsdOi HG228c+ETg35pzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAP1fuoy9ByJRa2NGOgxKJV7geaBjQt9BwTgbbtcdJc5k9E9IbAPFJ ZhmrXTa74ByoleGhA6jwAVundz40OoB9aUP9CSveTIA0QLyLzy9Xjusnpgx+zFyyDfMM8rEAk2/8 O1HpBcGv9MZdwnyBN6EkTVeqB+KqK6PylE2oQhDntidZOIuA9TBTjevWVFG7BgrqYm9gKErWdv88 zMWJBcVaynyWll7D5kIjWeTldTtlR/YlcbaTquwCiNaehMnseNS2BjBHVxmlIaIFaSfG/iLhNXXw zf/GhI6Iq2gRETZ4QrAAJ4kSK8kHxCD+kEtZ6tZRMWw/CWhBxu1v8wH5M59BsgAAAAAAAA== --Apple-Mail-26--222850047-- From matt@internet2.edu Thu Mar 26 15:53:14 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FBA3A6A55 for ; Thu, 26 Mar 2009 15:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-cSn2tUGs+j for ; Thu, 26 Mar 2009 15:53:13 -0700 (PDT) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id 739853A68D6 for ; Thu, 26 Mar 2009 15:52:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id 3F6D7225CA3; Thu, 26 Mar 2009 18:53:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0k0Za5bhz1R; Thu, 26 Mar 2009 18:53:37 -0400 (EDT) Received: from dhcp-61fd.meeting.ietf.org (unknown [130.129.97.253]) (Authenticated sender: matt@internet2.edu) by magus.merit.edu (Postfix) with ESMTP id 523F1225CA1; Thu, 26 Mar 2009 18:53:37 -0400 (EDT) Message-ID: <49CC076F.3010503@internet2.edu> Date: Thu, 26 Mar 2009 18:53:35 -0400 From: Matthew J Zekauskas User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Matt Zekauskas Subject: [ippm] Clearing errata 398, RFC 2679, A One-way Delay Metric for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:53:14 -0000 We've been asked to clear outstanding errata. There is some long-outstanding errata on RFC 2679, 2680 and 2681. This is for RFC 2679. To see the original (text below) ; guidelines for how to clear errata on IESG documents are at . My proposed response is below. If anyone feels it should be otherwise, let me or the list know. I will send it in to Lars for processing next week... --Matt -=-=-=- This one is clearly in IPPM purview. The errata is valid, and should be classified as "Technical". I think it could cause confusion for implementors, however the confusion should cause one to look deeper, and understand there is an error here. It is in an example, and hasn't caused anyone else a problem in 10 years. I recommend the Errata be 'Hold for Docment Update', and I would add something to the "It should say" to point to the IPPM Percentile definition in 2330: " Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 500 msec and 'undefined' are larger. See Section 11.3 of [1] for computing percentiles. " ----- RFC2679, "A One-way Delay Metric for IPPM", September 1999 Source of RFC: Legacy Errata ID: 398 Status: Reported Type: Technical Reported By: Andrew Main Date Reported: 2002-11-18 Section 5.1 says: Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 110 msec and 'undefined' are larger. It should say: Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 500 msec and 'undefined' are larger. Notes: See the list of samples immediately preceding that paragraph. From matt@internet2.edu Thu Mar 26 17:25:27 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2873A69A8 for ; Thu, 26 Mar 2009 17:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIXstekjfase for ; Thu, 26 Mar 2009 17:25:18 -0700 (PDT) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id D2DE03A676A for ; Thu, 26 Mar 2009 17:25:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id CE67C225CA3; Thu, 26 Mar 2009 20:26:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXdF-rAWxMSz; Thu, 26 Mar 2009 20:26:08 -0400 (EDT) Received: from dhcp-61fd.meeting.ietf.org (unknown [130.129.97.253]) (Authenticated sender: matt@internet2.edu) by magus.merit.edu (Postfix) with ESMTP id 3A07D225BFE; Thu, 26 Mar 2009 20:26:08 -0400 (EDT) Message-ID: <49CC1D1E.10501@internet2.edu> Date: Thu, 26 Mar 2009 20:26:06 -0400 From: Matthew J Zekauskas User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Matt Zekauskas Subject: [ippm] Clearing errata 397, RFC 2681, A Round-trip Delay Metric for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:25:27 -0000 We've been asked to clear outstanding errata. There is some long-outstanding errata on RFC 2679, 2680 and 2681. This is for RFC 2681. To see the original (text below) ; guidelines for how to clear errata on IESG documents are at . My proposed response is below. If anyone feels it should be otherwise, let me or the list know. I will send it in to Lars for processing next week... --Matt -=-=-=- This one is clearly in IPPM purview. The errata is valid, and should be classified as "Technical". I think it could cause confusion for implementors, however the confusion should cause one to look deeper, and understand there is an error here. It is in an example, and hasn't caused anyone else a problem in 10 years. I recommend the Errata be 'Hold for Docment Update', and I would add something to the "It should say" to point to the IPPM Percentile definition in 2330: " Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 500 msec and 'undefined' are larger. See Section 11.3 of [1] for computing percentiles. " ----- RFC2681, "A Round-trip Delay Metric for IPPM", September 1999 Source of RFC: Legacy Errata ID: 397 Status: Reported Type: Technical Reported By: Andrew Main Date Reported: 2002-11-18 Section 4.1 says: Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 110 msec and 'undefined' are larger. It should say: Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 500 msec and 'undefined' are larger. Notes: From matt@internet2.edu Thu Mar 26 17:44:24 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505593A676A for ; Thu, 26 Mar 2009 17:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfOLks0ri1Qu for ; Thu, 26 Mar 2009 17:44:23 -0700 (PDT) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id 5E9423A6ADE for ; Thu, 26 Mar 2009 17:44:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id 6BD83225CAF; Thu, 26 Mar 2009 20:45:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOEUZWinJU1W; Thu, 26 Mar 2009 20:45:16 -0400 (EDT) Received: from dhcp-61fd.meeting.ietf.org (unknown [130.129.97.253]) (Authenticated sender: matt@internet2.edu) by magus.merit.edu (Postfix) with ESMTP id 7209F225C78; Thu, 26 Mar 2009 20:45:16 -0400 (EDT) Message-ID: <49CC219B.3040107@internet2.edu> Date: Thu, 26 Mar 2009 20:45:15 -0400 From: Matthew J Zekauskas User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Matt Zekauskas Subject: [ippm] Clearing errata 1528, RFC 2680, A One-way Packet Loss Metric for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:44:24 -0000 We've been asked to clear outstanding errata. There is some long-outstanding errata on RFC 2679, 2680 and 2681. This is for RFC 2680. To see the original (text below) ; guidelines for how to clear errata on IESG documents are at . My proposed response is below. If anyone feels it should be otherwise, let me or the list know. I will send it in to Lars for processing next week... --Matt -=-=-=- This one is clearly in IPPM purview. The errata is valid, however it should be classified as "Technical". I think it could cause confusion. It is relatively minor, and hasn't cause major problems in the last 10 years, but since it is in the description we should post it. I recommend the Errata be 'Verified', and the correction can stand as-is. ----- RFC2680, "A One-way Packet Loss Metric for IPPM", September 1999 Source of RFC: Legacy Errata ID: 1528 Status: Reported Type: Editorial Reported By: Wenxia Dong Date Reported: 2008-09-24 Section 2.7 says: The first two sources are interrelated and could result in a test packet with finite delay being reported as lost. Type-P-One-way- Packet-Loss is 0 if the test packet does not arrive, or if it does arrive and the difference between Src timestamp and Dst timestamp is greater than the "reasonable period of time", or loss threshold. It should say: The first two sources are interrelated and could result in a test packet with finite delay being reported as lost. Type-P-One-way- Packet-Loss is 1 if the test packet does not arrive, or if it does arrive and the difference between Src timestamp and Dst timestamp is greater than the "reasonable period of time", or loss threshold. Notes: Type-P-One-way-Packet-Loss is 1 if the test packet does not arrive, according to section 2.4 Definition in RFC2680. From henk@ripe.net Tue Mar 31 01:34:59 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CCF3A696E for ; Tue, 31 Mar 2009 01:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.537 X-Spam-Level: X-Spam-Status: No, score=-4.537 tagged_above=-999 required=5 tests=[AWL=-1.938, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgRqaVM8h4ox for ; Tue, 31 Mar 2009 01:34:59 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id D78D43A6880 for ; Tue, 31 Mar 2009 01:34:58 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1LoZRh-0006Z8-Py for ippm@ietf.org; Tue, 31 Mar 2009 10:35:54 +0200 Received: from geir.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id B42462F594; Tue, 31 Mar 2009 10:35:45 +0200 (CEST) Message-ID: <49D1D5E1.1020907@ripe.net> Date: Tue, 31 Mar 2009 10:35:45 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Henk Uijterwaal References: <49B6450A.7050906@ripe.net> In-Reply-To: <49B6450A.7050906@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d59a58a0a665478b21be567aa601ef1847 Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-more-twamp-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 08:35:00 -0000 IPPM Group, > This is a WGLC for the draft: draft-ietf-ippm-more-twamp-00.txt > > The draft has been discussed extensively in this group and appears to > to be stable by now. We like to start a WGLC in order to move it forward. > Please raise any remaining issues by Tuesday, March 31, 9:00am GMT. > > An URL for the draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-more-twamp-00.txt > No issues have been raised, so we'll move this document forward. Matt & 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 henk@uijterwaal.nl Tue Mar 31 05:29:44 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE823A6B23 for ; Tue, 31 Mar 2009 05:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkUMBsmvntpZ for ; Tue, 31 Mar 2009 05:29:43 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by core3.amsl.com (Postfix) with ESMTP id D183C3A67D7 for ; Tue, 31 Mar 2009 05:29:42 -0700 (PDT) Received: from geir.local (213-84-116-40.adsl.xs4all.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id n2VCUdmi082735 for ; Tue, 31 Mar 2009 14:30:40 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <49D20CEF.9010004@uijterwaal.nl> Date: Tue, 31 Mar 2009 14:30:39 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: IETF IPPM WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Tue, 31 Mar 2009 05:30:25 -0700 Subject: [ippm] Editorial team to work on "advancement of metrics draft". X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 12:29:44 -0000 IPPM Group, Our charter has this work item: The working group will advance these metrics along the standards track within the IETF. The WG will document the process of moving documents along the standards track, based on draft-bradner-metricstest. As this process is likely to be needed by other groups as well (in particular BMWG, PMOL), the group will collaborate with other groups in order to ensure that there is consensus amongst all groups expected to use the process. At our meeting in SF last week, we asked for volunteers for a small team (5-7 people) to work on this document. Several people voluntered but we feel that those not present should also have a chance to volunteer. The team is expected to have a 1st draft ready mid-June, in time for discussion in Stockholm. If you are interested in this topic, then please drop us a note. Those who already contacted us (Ruediger, Mike, Carol, Al, Scott) do not have to repeat this. We hope to assemble the team next week (April 7). Matt & 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.