From renata.teixeira@lip6.fr Thu Dec 2 08:39:21 2010 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 2E3A328C158 for ; Thu, 2 Dec 2010 08:39:21 -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 dnJbsCk+kpZH for ; Thu, 2 Dec 2010 08:39:20 -0800 (PST) Received: from osiris.lip6.fr (osiris.lip6.fr [132.227.60.30]) by core3.amsl.com (Postfix) with ESMTP id 2368928C192 for ; Thu, 2 Dec 2010 08:39:18 -0800 (PST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.14.4/lip6) with ESMTP id oB2GV3T0004866 for ; Thu, 2 Dec 2010 17:31:03 +0100 (CET) X-pt: osiris.lip6.fr Received: from [127.0.0.1] ([132.227.127.85]) (authenticated bits=0) by tibre.lip6.fr (8.14.4/8.13.3) with ESMTP id oB2GUwWr026368 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 2 Dec 2010 17:31:02 +0100 (MET) Message-ID: <4CF7C9BB.2000900@lip6.fr> Date: Thu, 02 Dec 2010 17:30:51 +0100 From: Renata Teixeira User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: ippm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (osiris.lip6.fr [132.227.60.30]); Thu, 02 Dec 2010 17:31:03 +0100 (CET) X-Scanned-By: MIMEDefang 2.71 on 132.227.60.30 X-Mailman-Approved-At: Fri, 03 Dec 2010 08:03:03 -0800 Subject: [ippm] Help Us with Measurement Research for Human-Centered Networks X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: renata.teixeira@lip6.fr List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 16:39:21 -0000 Dear colleagues, We need your help to conduct our research and are giving away gift certificates! We have designed HostView, a tool that collects network performance data along with user feedback of the network. Traces collected with HostView will help us understand end-user perception of network performance and will guide our research on diagnosing performance problems. To thank you for installing HostView, we are giving away 50$ Amazon gift certificates to 40 users selected at random from the first 100 that run it for a month. You can also ask HostView to give you feedback on the health of your network connectivity and application bandwidth consumption. HostView runs on MAC and Linux PCs. If you are not a Linux or MAC user, please forward this email to your colleagues and friends! Otherwise, please download HostView at: http://cmon.lip6.fr/EMD/Download.html. Once HostView is running there isn't much for you to do, except one thing. HostView includes a "user questionnaire" that should take 1 minute to fill out. We are interested in knowing how you perceive the performance of your machine at various performance points. There are two ways to answer this questionnaire: either when it pop ups (at most 3 times a day) or by hitting the "I am annoyed button" when you are unsatisfied with your network performance. More details on how to answer the questions is in the user manual that you can grab from the EMD project webpage. To see more about the tool and why we have done this, please see our web page at http://cmon.lip6.fr/EMD. A lot has gone into the development of HostView. We have tested and selected particular methods for data collection and data processing so as to have minimal overhead on your machine. A detailed description of HostView is in our Hotmetrics paper (http://hotmetrics.cs.caltech.edu/program.shtml). To address privacy concerns we did a user survey and we designed our tool according to majority opinions from this input (e.g., we included a pause button). The survey results appeared as a short paper in the April 2010 issue of CCR. For your privacy, we have also implemented state-of-the art anonymization techniques. A description of our commitment to your privacy can be found on the project webpage as well. Your help and participation is enormously appreciated! Diana Joumblatt, Renata Teixeira Laboratoire LIP6 CNRS AND UPMC Paris Universitas Jaideep Chandrashekar, Nina Taft Intel Labs, Berkeley From acmorton@att.com Fri Dec 3 08:34:22 2010 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 704983A6965 for ; Fri, 3 Dec 2010 08:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.605 X-Spam-Level: X-Spam-Status: No, score=-105.605 tagged_above=-999 required=5 tests=[AWL=0.191, 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 v77da-uJgywI for ; Fri, 3 Dec 2010 08:34:20 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 1CBD13A6894 for ; Fri, 3 Dec 2010 08:34:19 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-8.tower-161.messagelabs.com!1291394136!45574507!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 17520 invoked from network); 3 Dec 2010 16:35:37 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Dec 2010 16:35:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB3GZsYn005091 for ; Fri, 3 Dec 2010 11:35:54 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB3GZoBG005006 for ; Fri, 3 Dec 2010 11:35:50 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB3GZU4s012577 for ; Fri, 3 Dec 2010 11:35:30 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB3GZQPL012428 for ; Fri, 3 Dec 2010 11:35:26 -0500 Message-Id: <201012031635.oB3GZQPL012428@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-245-95.vpn.east.att.com[135.70.245.95](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101203163525gw1004lkg8e>; Fri, 3 Dec 2010 16:35:25 +0000 X-Originating-IP: [135.70.245.95] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Dec 2010 11:35:53 -0500 To: renata.teixeira@lip6.fr, ippm@ietf.org From: Al Morton In-Reply-To: <4CF7C9BB.2000900@lip6.fr> References: <4CF7C9BB.2000900@lip6.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] Help Us with Measurement Research for Human-Centered Networks 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, 03 Dec 2010 16:34:22 -0000 At 11:30 AM 12/2/2010, Renata Teixeira wrote: >... HostView runs on MAC and Linux PCs. If you are not ... I think many people will consider this a strong source of bias in your opinion data, so remember to address that aspect in your paper. good luck with the study, Al From henk@ripe.net Mon Dec 6 01:58:45 2010 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 1F4D93A6A04 for ; Mon, 6 Dec 2010 01:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_05=-1.11, 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 VwpWrxqGZqI2 for ; Mon, 6 Dec 2010 01:58:43 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 605C13A69AC for ; Mon, 6 Dec 2010 01:58:43 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PPXrW-00061I-Io for ippm@ietf.org; Mon, 06 Dec 2010 11:00:06 +0100 Received: from [193.0.21.124] (helo=guest169.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PPXrV-0003CK-EO for ippm@ietf.org; Mon, 06 Dec 2010 11:00:01 +0100 Message-ID: <4CFCB422.3060109@ripe.net> Date: Mon, 06 Dec 2010 11:00:02 +0100 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5a1d87ef8f339d8fd7a34c3385a11808c X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5a1d87ef8f339d8fd7a34c3385a11808c Subject: [ippm] On the metrics registry 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, 06 Dec 2010 09:58:45 -0000 IPPM group, I've been thinking about how to proceed with the registry. Judging from the feedback in Beijing, my impression is that the consensus is that the current registry is not used and is not what we want. At the same time, there is some interest in a new registry. It is clear from the discussion that if this idea is developed, the outcome will be a registry that is significantly different from the current one. The data in the current registry might help to populate the new registry, but this won't be much more than a fraction of the data needed. Thus, there is little or no harm in not maintaining the current registry. With that in mind, I propose to: 1. Last call draft-morton-ippm-rfc4148-obsolete, starting in a week or two. 2. If there is sufficient interest in working on a new registry, establish a group to do so. For (2), we need a group with sufficient critical mass (say, 5 to 10 people) to make progress. If you are interested in this, let me know. Goal would be to have a proposal by the Prague meeting. Comments welcome, Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku 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 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From acmorton@att.com Mon Dec 6 06:45:55 2010 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 960E83A67AB for ; Mon, 6 Dec 2010 06:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[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 TN8Tu66VFysr for ; Mon, 6 Dec 2010 06:45:54 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id DD5A83A6808 for ; Mon, 6 Dec 2010 06:45:52 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-14.tower-129.messagelabs.com!1291646835!34127411!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 14012 invoked from network); 6 Dec 2010 14:47:15 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-14.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Dec 2010 14:47:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB6ElYpJ023853 for ; Mon, 6 Dec 2010 09:47:34 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB6ElRIr023704 for ; Mon, 6 Dec 2010 09:47:28 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB6El8bE029775 for ; Mon, 6 Dec 2010 09:47:08 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB6El6j3029717 for ; Mon, 6 Dec 2010 09:47:06 -0500 Message-Id: <201012061447.oB6El6j3029717@alpd052.aldc.att.com> Received: from acmt.att.com (ds135-16-251-243.dhcps.ugn.att.com[135.16.251.243](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101206144705gw1004lkk7e>; Mon, 6 Dec 2010 14:47:05 +0000 X-Originating-IP: [135.16.251.243] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Dec 2010 09:47:33 -0500 To: Henk Uijterwaal , IETF IPPM WG From: Al Morton In-Reply-To: <4CFCB422.3060109@ripe.net> References: <4CFCB422.3060109@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] On the metrics registry 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, 06 Dec 2010 14:45:55 -0000 At 05:00 AM 12/6/2010, Henk Uijterwaal wrote: > 2. If there is sufficient interest in working on a new registry, > establish a group to do so. I would suggest to broaden this item with an investigation of alternate possibilities to solve the metric identification/exchange problem, and to (first) formalize the problem statement that the work will address. We heard some interesting suggestions during the Beijing session, which led me to the impression that another IANA registry might not be the best answer. Al's 2 cents... From henk@ripe.net Mon Dec 6 07:05:28 2010 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 1A29B3A6808 for ; Mon, 6 Dec 2010 07:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, 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 YRZ2-o3Cy-fr for ; Mon, 6 Dec 2010 07:05:27 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 8C7873A67FF for ; Mon, 6 Dec 2010 07:05:26 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PPceO-0004Y1-0E; Mon, 06 Dec 2010 16:06:49 +0100 Received: from [193.0.21.124] (helo=guest169.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1PPceN-0008Lo-Sl; Mon, 06 Dec 2010 16:06:47 +0100 Message-ID: <4CFCFC07.2010906@ripe.net> Date: Mon, 06 Dec 2010 16:06:47 +0100 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Al Morton References: <4CFCB422.3060109@ripe.net> <201012061447.oB6El6mu029716@alpd052.aldc.att.com> In-Reply-To: <201012061447.oB6El6mu029716@alpd052.aldc.att.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d581488590a76de4bb616c65fccafe0145 X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d581488590a76de4bb616c65fccafe0145 Cc: IETF IPPM WG Subject: Re: [ippm] On the metrics registry 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, 06 Dec 2010 15:05:28 -0000 On 06/12/2010 15:47, Al Morton wrote: > At 05:00 AM 12/6/2010, Henk Uijterwaal wrote: >> 2. If there is sufficient interest in working on a new registry, >> establish a group to do so. > > I would suggest to broaden this item with an investigation of > alternate possibilities to solve the metric identification/exchange > problem, and to (first) formalize the problem statement that the > work will address. > > We heard some interesting suggestions during the Beijing session, > which led me to the impression that another IANA registry might > not be the best answer. I agree, though I still think that there should be sufficient interest to work on this problem for it to become a WG item. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku 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 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From acmorton@att.com Mon Dec 6 07:30:53 2010 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 AD30D3A6819 for ; Mon, 6 Dec 2010 07:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[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 3oE1j84MLDaj for ; Mon, 6 Dec 2010 07:30:52 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 681BD3A67B2 for ; Mon, 6 Dec 2010 07:30:52 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-7.tower-146.messagelabs.com!1291649531!23302112!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 22384 invoked from network); 6 Dec 2010 15:32:11 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Dec 2010 15:32:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB6FWU82001999 for ; Mon, 6 Dec 2010 10:32:30 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oB6FWS9N001982 for ; Mon, 6 Dec 2010 10:32:28 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB6FW8lw021124 for ; Mon, 6 Dec 2010 10:32:08 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oB6FW6gf021083 for ; Mon, 6 Dec 2010 10:32:07 -0500 Message-Id: <201012061532.oB6FW6gf021083@alpd052.aldc.att.com> Received: from acmt.att.com (ds135-16-251-243.dhcps.ugn.att.com[135.16.251.243](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101206153206gw1004lkkme>; Mon, 6 Dec 2010 15:32:06 +0000 X-Originating-IP: [135.16.251.243] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Dec 2010 10:32:34 -0500 To: Henk Uijterwaal From: Al Morton In-Reply-To: <4CFCFC07.2010906@ripe.net> References: <4CFCB422.3060109@ripe.net> <201012061447.oB6El6mu029716@alpd052.aldc.att.com> <4CFCFC07.2010906@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IETF IPPM WG Subject: Re: [ippm] On the metrics registry 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, 06 Dec 2010 15:30:53 -0000 Agree completely! I sought only to broaden the topic where you are seeking interest, to improve the probability of a useful outcome. Personally, I'm not committing more time to this unless the problem statement is compelling... At 10:06 AM 12/6/2010, Henk Uijterwaal wrote: >On 06/12/2010 15:47, Al Morton wrote: > > At 05:00 AM 12/6/2010, Henk Uijterwaal wrote: > >> 2. If there is sufficient interest in working on a new registry, > >> establish a group to do so. > > > > I would suggest to broaden this item with an investigation of > > alternate possibilities to solve the metric identification/exchange > > problem, and to (first) formalize the problem statement that the > > work will address. > > > > We heard some interesting suggestions during the Beijing session, > > which led me to the impression that another IANA registry might > > not be the best answer. > >I agree, though I still think that there should be sufficient >interest to work on this problem for it to become a WG item. > >Henk > > > >-- >------------------------------------------------------------------------------ >Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net >RIPE Network Coordination Centre http://www.xs4all.nl/~henku >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 >------------------------------------------------------------------------------ > >I confirm today what I denied yesterday. Anonymous Politician. >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From alexander.zimmermann@comsys.rwth-aachen.de Mon Dec 6 23:59:19 2010 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 57B273A692C for ; Mon, 6 Dec 2010 23:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 v3908FXy5Tzf for ; Mon, 6 Dec 2010 23:59:17 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 77EB73A68F5 for ; Mon, 6 Dec 2010 23:59:17 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LD1000Y0SX6YAA0@mta-1.ms.rz.RWTH-Aachen.de> for ippm@ietf.org; Tue, 07 Dec 2010 09:00:42 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.59,310,1288566000"; d="sig'?scan'208";a="84290491" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 07 Dec 2010 09:00:42 +0100 Received: from [137.226.12.58] ([unknown] [137.226.12.58]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LD1002QNSX6DG10@relay-auth-2.ms.rz.rwth-aachen.de> for ippm@ietf.org; Tue, 07 Dec 2010 09:00:42 +0100 (CET) From: Alexander Zimmermann Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-7--130969581 Content-transfer-encoding: 7bit Date: Tue, 07 Dec 2010 09:00:42 +0100 Message-id: <8B5BB7B2-BAFC-488B-8151-C1CC605FC036@comsys.rwth-aachen.de> To: ippm@ietf.org X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Subject: [ippm] IPPM TCP draft-08 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, 07 Dec 2010 07:59:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-7--130969581 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Copy of my review to ippm list Alex -- Hi Barry, here are my comments... * Sec 1, para 4: In this document, the maximum achievable TCP throughput is that amount of data per unit time that TCP transports when trying to reach Equilibrium, i.e. after the initial slow start and congestion avoidance phases. IMO (see [1], [2]) TCP use SS tow reach Equilibrium and CA to "stay" in = Equilibrium. IMO the statement above is not correct. However, I'm not a Congestion Control geek, more a = Lost Recovery expert. Maybe (If you like, I you have time,...) you can ask Michael Welzl = (IERTF ICCRG chair, author of [2]) for a review, comment... * Sec 1, para 5: A larger TCP CWND permits a higher throughput. Hmm. If I have 1GB/s linespeed and an RTT of 2 ms, my BDP (CWND) is = around 175 segments. On the other hand if you have a 100Mb/s linespeed and an RTT of 25 ms, the BDP = is around 219 segments. Which connection is faster :-) TCP "slow start" and "congestion avoidance" algorithms together determine the TCP CWND size Maybe better to say that the BDP of (path/network) determines the CWND, = and with the help of SS and CA you probe the path characteristic. Take also a look at = http://staff.psc.edu/jheffner/papers/senior_thesis.ps. I think we can = get inspired by John's text (esapecially section 2 and 3) In order to obtain the maximum throughput, it is critical to use optimal TCP Send and Receive Socket Buffer sizes as well as the optimal TCP Receive Window size. The first part of the sentence is correct, the second part not. You = CANNOT (directly) tune (eg per sysctl) TCP Receive Window size. This is not under your control. = Nagle and Clark have some effects on this, and mainly the auto tuning algos (see [3], [4], = [5], ([6])) tune your advertised window. You set the buffer size via sysctl (tcp_rmem, tcp_wmem,) and = maybe you can disable auto tuning (tcp_moderate_rcvbuf=3D0), but (IMO) you cannot tune Receive = Window. So, IMO in the whole doc, I would prefer if you write "I/we set the = receiver buffer socket size" * Sec 2.1 1 - The Slow Start phase, which occurs at the beginning of a TCP transmission or after a retransmission time out. You are in SS if CWND is less the SSTHRESH. Starting with the = transmission and RTO a only two examples why this could happen. Restart after idle is another example. = There are many reasons why we could slow start. You examples are the common cases. A simple = rewriting of the sentence can fix this issue. 3 - The Retransmission Time-out phase =3D> Loss Recovery phase and delete the word "multiple", since in general Reno cannot recover = multiple loss without an RTO (see RFC3782) * Sec 2.1, last para TCP test programs such as iperf, ttcp, etc. allow the sender to = control the quantity of TCP Bytes transmitted and unacknowledged (in-flight), commonly referred to as the Send Socket Buffer. I'm not a native speaker (as you can see :-)), but what do you want to = say here? Maybe that the size of the send buffer limit the data in flight? * Sec 3, para 8: What is RED? :-) Add also add ref here=20 * Sec 3, para 11: =20 Linux OS kernel using TCP Reno You can only choose NewReno under Linux (nevertheless the sysctl is = named reno) * Sec 3, para 13: A compliant TCP Throughput Test Device MUST allow adjusting both Send Socket Buffer and TCP Receive Window sizes. The same as before... IMO "adjusting both Send and Receive Socket Buffer size" is better. If you agree with me, grep for other sentences in the = doc. There are many of them. * Sec 3, para 14: - Measuring RTT and retransmissions per connection will generally require a dedicated communications test instrument Or use our tool measurement tool flowgrind = (http://freshmeat.net/projects/flowgrind) Sorry for the advertisement ;-) * Sec 3.2.1 If you use ping for the RTT calc, it is important to set the right = packet size (-s) (if the network is fast and have a low delay) -- [1] Van Jacobson. =E2=80=9CCongestion Avoidance and Control=E2=80=9D. = In: Proceedings of the ACM Symposium on Communications Architectures and Protocols (SIGCOMM=E2=80=9988). ACM = Press, 1988, pp. 314=E2=80=93329. isbn: 0-89791-279-9. doi: 10. 1145/52324.52356. [2] M. Welzl, M. Scharf, and B. Briscoe. Open Research Issues in = Internet Congestion Control. Ed. by D. Papadimitriou. Internet Draft. Sept. 2010. url: = http://tools.ietf.org/html/draft-irtf-iccrg-welzl-congestion-control-open-= research-08. [3] eduPERT. Automatic Tuning of TCP Buffers. url: http://kb.pert.geant.net/PERTKB/TCPBufferAutoTuning. [4] Pittsburgh Supercomputing Center. Enabling High Performance Data = Transfers. url: http://www.psc.edu/networking/projects/tcptune/. [5] Mike Fisk and Wu chun Feng. =E2=80=9CDynamic Right-Sizing in TCP=E2=80= =9D. In: Proceedings of the 2nd Annual Los Alamos Computer Science Institute Symposium (LACSI=E2=80=9901). = 2001. [6] Jeffrey Semke, Jamshid Mahdavi, and Matthew Mathis. =E2=80=9CAutomatic= TCP Buffer Tuning=E2=80=9D. In: SIGCOMM Computer Communication Review 28.4 (Oct. 1998), pp. 315=E2=80=93323. = issn: 0146-4833. doi: 10.1145/285243.285292. // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-7--130969581 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz96aoACgkQdyiq39b9uS5HOgCgoDIn0klFF2pOk+mTsTbOiZh+ jI0AoOwasnt9S1hugYmVchIuqvNM/gVk =Nzb5 -----END PGP SIGNATURE----- --Apple-Mail-7--130969581-- From steve.baillargeon@ericsson.com Tue Dec 7 11:38:43 2010 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 6DB523A69AB for ; Tue, 7 Dec 2010 11:38:42 -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 RwtYJMbsBzuH for ; Tue, 7 Dec 2010 11:38:37 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id CD16E3A68B6 for ; Tue, 7 Dec 2010 11:38:26 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oB7K8xO9020707 for ; Tue, 7 Dec 2010 14:09:04 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 7 Dec 2010 14:39:26 -0500 From: Steve Baillargeon To: IETF IPPM WG Date: Tue, 7 Dec 2010 14:39:23 -0500 Thread-Topic: SID for IPv6 Thread-Index: AcuWRnNocCqWfhZgRsOoHsPwS2sHQQ== Message-ID: <4383945B8C24AA4FBC33555BB7B829EF0963EF124C@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4383945B8C24AA4FBC33555BB7B829EF0963EF124CEUSAACMS0701e_" MIME-Version: 1.0 Subject: [ippm] SID for IPv6 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, 07 Dec 2010 19:38:43 -0000 --_000_4383945B8C24AA4FBC33555BB7B829EF0963EF124CEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I have one quick question about the construction of a SID for an IPv6 host = that does not support IPv4. The OWAMP/TWAMP spec states the following: SIDs SHOULD be constructed by concatenation of the 4-octet IPv4 IP number belonging to the generating machine, an 8-octet timestamp, and a 4-octet random value. To reduce the probability of collisions, if the generating machine has any IPv4 addresses (with the exception of loopback), one of them SHOULD be used for SID generation, even if all communication is IPv6-based. If it has no IPv4 addresses at all, the last four octets of an IPv6 address MAY be used instead. Note that SID is always chosen by the receiver. If truly random values are not available, it is important that the SID be made unpredictable, as knowledge of the SID might be used for access control. The spec suggests to use the last four octets of an IPv6 address. Does this mean the first 4 octets of the SID could be the last four octets = of an interface identifier (see RFC4291) ? I am afraid the use of the last four octets of an interface identifier will= not ensure SID uniqueness across the network unless the timestamp and rand= om value are truly random. Any comments/suggestions? Regards Steve --_000_4383945B8C24AA4FBC33555BB7B829EF0963EF124CEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
I have one quick question about the construction of a SID for an IPv6 = host that does not support IPv4.
 
The OWAMP/TWAMP spec states the following:
 
   SIDs SHOULD be cons= tructed by concatenation of the 4-octet IPv4 IP
   number belonging to= the generating machine, an 8-octet timestamp, and
   a 4-octet random va= lue.  To reduce the probability of collisions, if
   the generating mach= ine has any IPv4 addresses (with the exception of
   loopback), one of t= hem SHOULD be used for SID generation, even if all
   communication is IP= v6-based.  If it has no IPv4 addresses at all, the
   last four octets of= an IPv6 address MAY be used instead.  Note that
   SID is always chose= n by the receiver.  If truly random values are not
   available, it is im= portant that the SID be made unpredictable, as
   knowledge of the SI= D might be used for access control.
 
The spec suggests to use the last four octets of an IPv6 address.
 
Does this mean the first 4 octets of the SID could be the last four oc= tets of an interface identifier (see RFC4291) ?
 
I am afraid the use of the last four octets of an interface identifier= will not ensure SID uniqueness across the network unless the timestamp and= random value are truly random.
 
Any comments/suggestions?
 
Regards
Steve=
 
 
 
 --_000_4383945B8C24AA4FBC33555BB7B829EF0963EF124CEUSAACMS0701e_-- From boote@internet2.edu Tue Dec 7 12:31:30 2010 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 614DB3A6899 for ; Tue, 7 Dec 2010 12:31:30 -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 rBlWilGuuo99 for ; Tue, 7 Dec 2010 12:31:29 -0800 (PST) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id 006323A686B for ; Tue, 7 Dec 2010 12:31:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id A592B225B4D; Tue, 7 Dec 2010 15:32:54 -0500 (EST) X-Virus-Scanned: amavisd-new at magus.merit.edu 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 Kt3CHYxDkv94; Tue, 7 Dec 2010 15:32:54 -0500 (EST) Received: from [192.168.5.100] (69-92-227-23.cpe.cableone.net [69.92.227.23]) by magus.merit.edu (Postfix) with ESMTPSA id 71348225B25; Tue, 7 Dec 2010 15:32:53 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2--85840919 From: "Jeff W. Boote" In-Reply-To: <4383945B8C24AA4FBC33555BB7B829EF0963EF124C@EUSAACMS0701.eamcs.ericsson.se> Date: Tue, 7 Dec 2010 13:32:51 -0700 Message-Id: References: <4383945B8C24AA4FBC33555BB7B829EF0963EF124C@EUSAACMS0701.eamcs.ericsson.se> To: Steve Baillargeon X-Keywords: EMAILLIST IETF X-Mailtags: { "mailTagsKeyWords" : ["EMAILLIST", "IETF"]} X-Mailtags-Version: 2.5 X-Mailer: Apple Mail (2.1082) Cc: IETF IPPM WG Subject: Re: [ippm] SID for IPv6 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, 07 Dec 2010 20:31:30 -0000 --Apple-Mail-2--85840919 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 7, 2010, at 12:39 PM, Steve Baillargeon wrote: > Hi > I have one quick question about the construction of a SID for an IPv6 = host that does not support IPv4. > =20 > The OWAMP/TWAMP spec states the following: > =20 > SIDs SHOULD be constructed by concatenation of the 4-octet IPv4 IP > number belonging to the generating machine, an 8-octet timestamp, = and > a 4-octet random value. To reduce the probability of collisions, = if > the generating machine has any IPv4 addresses (with the exception = of > loopback), one of them SHOULD be used for SID generation, even if = all > communication is IPv6-based. If it has no IPv4 addresses at all, = the > last four octets of an IPv6 address MAY be used instead. Note that > SID is always chosen by the receiver. If truly random values are = not > available, it is important that the SID be made unpredictable, as > knowledge of the SID might be used for access control. > =20 > The spec suggests to use the last four octets of an IPv6 address. > =20 > Does this mean the first 4 octets of the SID could be the last four = octets of an interface identifier (see RFC4291) ? > =20 > I am afraid the use of the last four octets of an interface identifier = will not ensure SID uniqueness across the network unless the timestamp = and random value are truly random. > =20 > Any comments/suggestions? Why does this concern you? Is it because you think the SID might be = easily guessed in this case, and the SID might be used for access = control? Or is it something else? I don't believe there is any requirement that the SID be unique across = the network for the protocol to work. (I agree that the text makes it = sound desirable.) It needs to be unique at a specific receiver for the = fetch-sessions messages to work, but these bytes will be identical for = that use case anyway. It is possible that a process managing many sender = sessions to several receivers might key on the SID as a key. But, there = are many other fields that could be used there as well with the most = likely being remote host address. jeff > =20 > Regards > Steve > =20 > =20 > =20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail-2--85840919 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Dec 7, 2010, at 12:39 PM, = Steve Baillargeon wrote:

Hi
I have one quick = question about the construction of a SID for an IPv6 host that does not = support IPv4.
 
The OWAMP/TWAMP spec states the = following:
 
   SIDs SHOULD be constructed by concatenation of = the 4-octet IPv4 IP
   number belonging to the generating machine, an = 8-octet timestamp, and
   a 4-octet random value.  To reduce the = probability of collisions, if
   the generating machine has any IPv4 = addresses (with the exception of
   loopback), one of them SHOULD be used for = SID generation, even if all
   communication is IPv6-based.  If it has no = IPv4 addresses at all, the
   last four octets of an IPv6 address MAY be used = instead.  Note that
   SID is always chosen by the receiver.  If = truly random values are not
   available, it is important that the SID be made = unpredictable, as
   knowledge of the SID might be used for access = control.
 
The spec suggests to use the last = four octets of an IPv6 address.
 
Does this = mean the first 4 octets of the SID could be the last four octets of an = interface identifier (see RFC4291) ?
 
I am = afraid the use of the last four octets of an interface identifier will = not ensure SID uniqueness across the network unless the timestamp and = random value are truly random.
 
Any = comments/suggestions?

Why does this concern you? Is it because you think the SID might = be easily guessed in this case, and the SID might be used for access = control? Or is it something else?

I don't = believe there is any requirement that the SID be unique across the = network for the protocol to work. (I agree that the text makes it sound = desirable.) It needs to be unique at a specific receiver for the = fetch-sessions messages to work, but these bytes will be identical for = that use case anyway. It is possible that a process managing many sender = sessions to several receivers might key on the SID as a key. But, there = are many other fields that could be used there as well with the most = likely being remote host = address.

jeff

 
Regards
Steve
 
 
 
___________________= ____________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/m= ailman/listinfo/ippm

= --Apple-Mail-2--85840919-- From Internet-Drafts@ietf.org Tue Dec 7 13:00:03 2010 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 4008A28C0F9; Tue, 7 Dec 2010 13:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, 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 ssOSOXirgsy5; Tue, 7 Dec 2010 13:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C19328C0F3; Tue, 7 Dec 2010 13:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101207210002.23338.17197.idtracker@localhost> Date: Tue, 07 Dec 2010 13:00:02 -0800 Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-tcp-throughput-tm-09.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, 07 Dec 2010 21:00:03 -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 : Framework for TCP Throughput Testing Author(s) : B. Constantine, et al. Filename : draft-ietf-ippm-tcp-throughput-tm-09.txt Pages : 25 Date : 2010-12-07 This framework describes a methodology for measuring end-to-end TCP throughput performance in a managed IP network. The intention is to provide a practical methodology to validate TCP layer performance. The goal is to provide a better indication of the user experience. In this framework, various TCP and IP parameters are identified and should be tested as part of a managed IP network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-tcp-throughput-tm-09.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-tcp-throughput-tm-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-07124617.I-D@ietf.org> --NextPart-- From henk@ripe.net Sun Dec 19 23:07:35 2010 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 607DC3A69A3 for ; Sun, 19 Dec 2010 23:07:35 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): X-RIPE-Spam-Report: ...al Points: -2.9 points\n \n pts rule nam[...] X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, 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 v6wLTWDOLwEp for ; Sun, 19 Dec 2010 23:07:34 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id D4CF33A676A for ; Sun, 19 Dec 2010 23:07:33 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PUZs4-0008Ln-RL for ippm@ietf.org; Mon, 20 Dec 2010 08:09:25 +0100 Received: from [193.0.21.124] (helo=geir.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PUZs4-00016R-M9 for ippm@ietf.org; Mon, 20 Dec 2010 08:09:24 +0100 Message-ID: <4D0F0124.3090809@ripe.net> Date: Mon, 20 Dec 2010 08:09:24 +0100 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5d0c55185cbd6f7c4d511b071c0c006cc X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5d0c55185cbd6f7c4d511b071c0c006cc Subject: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 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, 20 Dec 2010 07:07:35 -0000 IPPM Group, This is a Working Group Last Call for the draft: RFC 4148 and the IPPM Metrics Registry are Obsolete draft-morton-ippm-rfc4148-obsolete-02 This draft has been discussed extensively at the Maastricht and Beijing meetings, as well as on the list. Please review the draft and raise any issues by Monday, January 3, 9:00 UTC. An URL for the draft is: https://datatracker.ietf.org/doc/draft-morton-ippm-rfc4148-obsolete/ Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku 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 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From emile.stephan@orange-ftgroup.com Tue Dec 21 15:50:53 2010 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 BB8CF3A6ABE for ; Tue, 21 Dec 2010 15:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 owSWdBnXtKTg for ; Tue, 21 Dec 2010 15:50:51 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 5EB6D3A6AAF for ; Tue, 21 Dec 2010 15:50:50 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A0325FC4005; Wed, 22 Dec 2010 00:52:49 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8EFE1FC4001; Wed, 22 Dec 2010 00:52:49 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 00:52:46 +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, 22 Dec 2010 00:52:44 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D0F0124.3090809@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 Thread-Index: AcugFNpLGkXOEfJjT22LGGXF+cXSMgBVNkGw References: <4D0F0124.3090809@ripe.net> From: To: , X-OriginalArrivalTime: 21 Dec 2010 23:52:46.0911 (UTC) FILETIME=[2AEF1CF0:01CBA16A] Cc: acmorton@att.com Subject: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 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, 21 Dec 2010 23:50:54 -0000 Hi Henk Most of the people are not available during Christmas time. So I suggest delaying the end of the last call to mid January instead of = the 14 of January 2010.=20 > -----Message d'origine----- > De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de > Henk Uijterwaal > Envoy=E9=A0: lundi 20 d=E9cembre 2010 08:09 > =C0=A0: IETF IPPM WG > Objet=A0: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 >=20 > IPPM Group, >=20 > This is a Working Group Last Call for the draft: >=20 > RFC 4148 and the IPPM Metrics Registry are Obsolete > draft-morton-ippm-rfc4148-obsolete-02 >=20 > This draft has been discussed extensively at the Maastricht and = Beijing > meetings, as well as on the list. Please review the draft and raise = any > issues by Monday, January 3, 9:00 UTC. An URL for the draft is: >=20 > = https://datatracker.ietf.org/doc/draft-morton-ippm-rfc4148-obsolete/ >=20 > Matt & Henk >=20 >=20 > -- > = -------------------------------------------------------------------------= - > ---- > Henk Uijterwaal Email: > henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.xs4all.nl/~henku > 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 > = -------------------------------------------------------------------------= - > ---- >=20 > I confirm today what I denied yesterday. Anonymous = Politician. > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From henk@ripe.net Wed Dec 22 00:14:51 2010 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 4C6A73A6AE8 for ; Wed, 22 Dec 2010 00:14:51 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): X-RIPE-Spam-Report: ...al Points: -2.9 points\n \n pts rule nam[...] X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, 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 cyX2dIPC0WvD for ; Wed, 22 Dec 2010 00:14:49 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 68D773A6AEF for ; Wed, 22 Dec 2010 00:14:48 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PVJsK-0001ZF-Db; Wed, 22 Dec 2010 09:16:45 +0100 Received: from [193.0.21.124] (helo=guest133.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PVJsK-0003TE-7B; Wed, 22 Dec 2010 09:16:44 +0100 Message-ID: <4D11A815.9060000@ripe.net> Date: Wed, 22 Dec 2010 08:26:13 +0100 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: emile.stephan@orange-ftgroup.com References: <4D0F0124.3090809@ripe.net> <843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5bafad88739a46208115170a66d7eacc7 X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d5bafad88739a46208115170a66d7eacc7 Cc: acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 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, 22 Dec 2010 08:14:51 -0000 Hi Emile, > Most of the people are not available during Christmas time. > > So I suggest delaying the end of the last call to mid January instead of the 14 of January 2010. The topic has been under discussion since July, nobody spoke up in support of the registry, the document is very short and can be reviewed in 5 minutes, so I don't see that a longer WGLC is needed. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku 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 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From emile.stephan@orange-ftgroup.com Wed Dec 22 00:42:39 2010 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 CB5123A677D for ; Wed, 22 Dec 2010 00:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 9jKau+EjsSow for ; Wed, 22 Dec 2010 00:42:38 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 8E60C3A6AF1 for ; Wed, 22 Dec 2010 00:42:38 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F069858004; Wed, 22 Dec 2010 09:48:48 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 85F5E760001; Wed, 22 Dec 2010 09:48:48 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 09:44:35 +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, 22 Dec 2010 09:44:30 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201632B40@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D11A815.9060000@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 Thread-Index: AcuhsJnkePJYk0moSh60r5QZ6upxIQAALVAA References: <4D0F0124.3090809@ripe.net><843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr> <4D11A815.9060000@ripe.net> From: To: X-OriginalArrivalTime: 22 Dec 2010 08:44:35.0330 (UTC) FILETIME=[75D57620:01CBA1B4] Cc: ietfdbh@comcast.net, acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 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, 22 Dec 2010 08:42:39 -0000 Hi Henk,=20 The situation has changed. In Beijing we discussed about the freezing of = the registry after spatial composition draft becomes RFC. On going = discussions during the AUTH48 phase of spatial composition draft are = taking a totally different direction.=20 You and Al consider draft-morton-ippm-rfc4148-obsolete-02 as an = important document. Then why do you place the WGLC in a period where = nobody will take care of the document? At large I will oppose that we obsolete the current IPPM metric registry = until the WG provides a replacement to this registry which corrects its = lacks. I will send a proposal but need time for editing and discussions. Regards Emile=20 > -----Message d'origine----- > De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de > Henk Uijterwaal > Envoy=E9=A0: mercredi 22 d=E9cembre 2010 08:26 > =C0=A0: STEPHAN Emile RD-CORE-LAN > Cc=A0: acmorton@att.com; ippm@ietf.org > Objet=A0: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 >=20 > Hi Emile, >=20 > > Most of the people are not available during Christmas time. > > > > So I suggest delaying the end of the last call to mid January = instead of > the 14 of January 2010. >=20 > The topic has been under discussion since July, nobody spoke up in = support > of the registry, the document is very short and can be reviewed in 5 > minutes, > so I don't see that a longer WGLC is needed. >=20 > Henk >=20 >=20 >=20 > -- > = -------------------------------------------------------------------------= - > ---- > Henk Uijterwaal Email: > henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.xs4all.nl/~henku > 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 > = -------------------------------------------------------------------------= - > ---- >=20 > I confirm today what I denied yesterday. Anonymous = Politician. > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From henk@ripe.net Wed Dec 22 00:56:18 2010 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 634763A6AF7 for ; Wed, 22 Dec 2010 00:56:18 -0800 (PST) X-Quarantine-ID: <0Ats7P78yjtG> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): X-RIPE-Spam-Report: ...al Points: -2.9 points\n \n pts rule nam[...] X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, 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 0Ats7P78yjtG for ; Wed, 22 Dec 2010 00:56:17 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id E47783A677D for ; Wed, 22 Dec 2010 00:56:16 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PVKWR-0005Y7-Df for ippm@ietf.org; Wed, 22 Dec 2010 09:58:13 +0100 Received: from [193.0.21.124] (helo=guest133.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1PVKWR-0006QH-Ac for ippm@ietf.org; Wed, 22 Dec 2010 09:58:11 +0100 Message-ID: <4D11BDA3.7010004@ripe.net> Date: Wed, 22 Dec 2010 09:58:11 +0100 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: ippm@ietf.org References: <4D0F0124.3090809@ripe.net><843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr> <4D11A815.9060000@ripe.net> <843DA8228A1BA74CA31FB4E111A5C46201632B40@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201632B40@ftrdmel0.rd.francetelecom.fr> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d554104e214b07ec9feb9c7efdbc0a1b57 X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d554104e214b07ec9feb9c7efdbc0a1b57 Subject: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 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, 22 Dec 2010 08:56:18 -0000 Hi Emile, > The situation has changed. In Beijing we discussed about the freezing of the > registry after spatial composition draft becomes RFC. On going discussions > during the AUTH48 phase of spatial composition draft are taking a totally > different direction. That is not how I remember it. We discussed freezing the registry with the content it has on the day it is frozen. If the spatial composition draft would become an RFC before that date, the metrics will be in the registry, otherwise, they won't. > You and Al consider draft-morton-ippm-rfc4148-obsolete-02 as an important > document. Then why do you place the WGLC in a period where nobody will take > care of the document? The issue has been discussed since July, the document merely reflects the conclusion that was drawn. Yes, this makes it an important document but No, this does not require a lengthy review period. The document doesn't say much more than "obsolete the registry". > I will send a proposal but need time for editing and discussions. As I said earlier, there does not seem to be sufficient interest to work on this topic at the moment. If this changes, then yes, this can become a WG document. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku 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 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From acmorton@att.com Wed Dec 22 06:22:32 2010 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 016963A6B6E for ; Wed, 22 Dec 2010 06:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.538 X-Spam-Level: X-Spam-Status: No, score=-105.538 tagged_above=-999 required=5 tests=[AWL=0.258, 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 Efnryco+y3wl for ; Wed, 22 Dec 2010 06:22:30 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 545C53A69F9 for ; Wed, 22 Dec 2010 06:22:30 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-146.messagelabs.com!1293027865!34060811!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 31403 invoked from network); 22 Dec 2010 14:24:25 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Dec 2010 14:24:25 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBMEOjvV032377 for ; Wed, 22 Dec 2010 09:24:45 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBMEOgFi032285 for ; Wed, 22 Dec 2010 09:24:42 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBMEOKLd011992 for ; Wed, 22 Dec 2010 09:24:21 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBMEOGPN011855 for ; Wed, 22 Dec 2010 09:24:17 -0500 Message-Id: <201012221424.oBMEOGPN011855@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-70-244.vpn.swst.att.com[135.70.70.244](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101222142415gw1004lkq5e>; Wed, 22 Dec 2010 14:24:16 +0000 X-Originating-IP: [135.70.70.244] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Dec 2010 09:24:44 -0500 To: Henk Uijterwaal , ippm@ietf.org, emile.stephan@orange-ftgroup.com From: Al Morton In-Reply-To: <4D11BDA3.7010004@ripe.net> References: <4D0F0124.3090809@ripe.net> <843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr> <4D11A815.9060000@ripe.net> <843DA8228A1BA74CA31FB4E111A5C46201632B40@ftrdmel0.rd.francetelecom.fr> <4D11BDA3.7010004@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 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, 22 Dec 2010 14:22:32 -0000 Hi Emile, I think you are overlooking yet another advantage of freezing the registry as soon as possible. For the sake of others on the list, let me briefly summarize the recent discussions and delays during the publication of RFC 6049-to-be, the Spatial Composition Metrics. I'm still trying to understand more details of the problem, but in summary: IPPM can not simply append metrics to the registry with a dedicated section at the end of a memo, as we have done before. Apparently, additional licensing conditions are now needed for anyone who extracts information from the IPPM Metrics Registry MIB, beyond the original copyright from 2005. There was a request to republish the entire registry document under the new licenses. But with no one using the registry, only the licensing issues would be served. RFC 6049 was held for 2 months trying to sort this out. So, the current registry continues to require attention and effort (any draft with metrics needs the IANA section, or ?), but as we've learned over the last 6 months, no one benefits. The sooner we freeze the 4148 registry, the better. regards, Al At 03:58 AM 12/22/2010, Henk Uijterwaal wrote: >Hi Emile, > > > The situation has changed. In Beijing we discussed about the > freezing of the > > registry after spatial composition draft becomes RFC. On going discussions > > during the AUTH48 phase of spatial composition draft are taking a totally > > different direction. > >That is not how I remember it. We discussed freezing the registry with the >content it has on the day it is frozen. If the spatial composition draft >would become an RFC before that date, the metrics will be in the registry, >otherwise, they won't. > > > You and Al consider draft-morton-ippm-rfc4148-obsolete-02 as an important > > document. Then why do you place the WGLC in a period where nobody will take > > care of the document? > >The issue has been discussed since July, the document merely reflects the >conclusion that was drawn. Yes, this makes it an important document but >No, this does not require a lengthy review period. The document doesn't >say much more than "obsolete the registry". > > > > I will send a proposal but need time for editing and discussions. > >As I said earlier, there does not seem to be sufficient interest to >work on this topic at the moment. If this changes, then yes, this >can become a WG document. > >Henk > >-- >------------------------------------------------------------------------------ >Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net >RIPE Network Coordination Centre http://www.xs4all.nl/~henku >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 >------------------------------------------------------------------------------ > >I confirm today what I denied yesterday. Anonymous Politician. >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From emile.stephan@orange-ftgroup.com Wed Dec 22 09:05:15 2010 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 AB4633A69B9 for ; Wed, 22 Dec 2010 09:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.099 X-Spam-Level: X-Spam-Status: No, score=-101.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_DEALS=2.3, 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 K8y2AkWXGy+l for ; Wed, 22 Dec 2010 09:05:14 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 306063A67AD for ; Wed, 22 Dec 2010 09:05:14 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7FC06C0004; Wed, 22 Dec 2010 18:07:36 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id DCAFB6C0001; Wed, 22 Dec 2010 18:07:36 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 18:07:10 +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, 22 Dec 2010 18:07:07 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201632CF7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <201012221424.oBMEOGPN011855@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC6049-to-be Thread-Index: Acuh5AdKntn6k8yqSLmWcYfSXn37xAAAaP/g References: <4D0F0124.3090809@ripe.net><843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr><4D11A815.9060000@ripe.net><843DA8228A1BA74CA31FB4E111A5C46201632B40@ftrdmel0.rd.francetelecom.fr><4D11BDA3.7010004@ripe.net> <201012221424.oBMEOGPN011855@alpd052.aldc.att.com> From: To: , , X-OriginalArrivalTime: 22 Dec 2010 17:07:10.0152 (UTC) FILETIME=[AB822480:01CBA1FA] Subject: [ippm] RFC6049-to-be 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, 22 Dec 2010 17:05:15 -0000 Hi Al, My concern is that nobody points the rule which has changed. In 2009 we = updated the registry with 2 new set of metrics from 2 different RFC = without any difficulties.=20 Is it because it is a MIB module? What is the exact text that has to be = added? Why not inserting this text in the DESCRIPTION field of the = REVISION added by IANA? ' REVISION "201009070000Z" -- September 7, 2010 DESCRIPTION "Added values 71-83 as published in = RFC-ietf-ippm-spatial-composition-16."' Regards Emile > -----Message d'origine----- > De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de Al > Morton > Envoy=E9=A0: mercredi 22 d=E9cembre 2010 15:25 > =C0=A0: Henk Uijterwaal; ippm@ietf.org; STEPHAN Emile RD-CORE-LAN > Objet=A0: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 >=20 > Hi Emile, >=20 > I think you are overlooking yet another advantage of > freezing the registry as soon as possible. For the sake > of others on the list, let me briefly summarize the > recent discussions and delays during the publication of > RFC 6049-to-be, the Spatial Composition Metrics. >=20 > I'm still trying to understand more details of the problem, > but in summary: IPPM can not simply append metrics to the registry > with a dedicated section at the end of a memo, as we have done before. > Apparently, additional licensing conditions are now needed > for anyone who extracts information from the IPPM Metrics Registry = MIB, > beyond the original copyright from 2005. There was a request to > republish the entire registry document under the new licenses. > But with no one using the registry, only the licensing issues > would be served. RFC 6049 was held for 2 months trying to sort this = out. >=20 > So, the current registry continues to require attention and > effort (any draft with metrics needs the IANA section, or ?), > but as we've learned over the last 6 months, no one benefits. > The sooner we freeze the 4148 registry, the better. >=20 > regards, > Al >=20 > At 03:58 AM 12/22/2010, Henk Uijterwaal wrote: > >Hi Emile, > > > > > The situation has changed. In Beijing we discussed about the > > freezing of the > > > registry after spatial composition draft becomes RFC. On going > discussions > > > during the AUTH48 phase of spatial composition draft are taking a > totally > > > different direction. > > > >That is not how I remember it. We discussed freezing the registry = with > the > >content it has on the day it is frozen. If the spatial composition = draft > >would become an RFC before that date, the metrics will be in the = registry, > >otherwise, they won't. > > > > > You and Al consider draft-morton-ippm-rfc4148-obsolete-02 as an > important > > > document. Then why do you place the WGLC in a period where nobody = will > take > > > care of the document? > > > >The issue has been discussed since July, the document merely reflects = the > >conclusion that was drawn. Yes, this makes it an important document = but > >No, this does not require a lengthy review period. The document = doesn't > >say much more than "obsolete the registry". > > > > > > > I will send a proposal but need time for editing and discussions. > > > >As I said earlier, there does not seem to be sufficient interest to > >work on this topic at the moment. If this changes, then yes, this > >can become a WG document. > > > >Henk > > > >-- > = >------------------------------------------------------------------------= - > ----- > >Henk Uijterwaal Email: > henk.uijterwaal(at)ripe.net > >RIPE Network Coordination Centre http://www.xs4all.nl/~henku > >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 > = >------------------------------------------------------------------------= - > ----- > > > >I confirm today what I denied yesterday. Anonymous = Politician. > >_______________________________________________ > >ippm mailing list > >ippm@ietf.org > >https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Wed Dec 22 10:54:34 2010 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 16C4E3A6A50 for ; Wed, 22 Dec 2010 10:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.403 X-Spam-Level: X-Spam-Status: No, score=-104.403 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, MANGLED_DEALS=2.3, 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 tLciatF7lBZX for ; Wed, 22 Dec 2010 10:54:32 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 883F13A68AE for ; Wed, 22 Dec 2010 10:54:32 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-146.messagelabs.com!1293044190!29571493!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 19770 invoked from network); 22 Dec 2010 18:56:30 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Dec 2010 18:56:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBMIuoI6019897 for ; Wed, 22 Dec 2010 13:56:50 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBMIun1Z019888 for ; Wed, 22 Dec 2010 13:56:49 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBMIuS6h020611 for ; Wed, 22 Dec 2010 13:56:28 -0500 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBMIuQg7020555 for ; Wed, 22 Dec 2010 13:56:27 -0500 Message-Id: <201012221856.oBMIuQg7020555@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-70-244.vpn.swst.att.com[135.70.70.244](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101222185625gw1004lksee>; Wed, 22 Dec 2010 18:56:26 +0000 X-Originating-IP: [135.70.70.244] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Dec 2010 13:56:53 -0500 To: emile.stephan@orange-ftgroup.com, , From: Al Morton In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201632CF7@ftrdmel0.rd.franc etelecom.fr> References: <4D0F0124.3090809@ripe.net> <843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr> <4D11A815.9060000@ripe.net> <843DA8228A1BA74CA31FB4E111A5C46201632B40@ftrdmel0.rd.francetelecom.fr> <4D11BDA3.7010004@ripe.net> <201012221424.oBMEOGPN011855@alpd052.aldc.att.com> <843DA8228A1BA74CA31FB4E111A5C46201632CF7@ftrdmel0.rd.francetelecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [ippm] RFC6049-to-be 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, 22 Dec 2010 18:54:34 -0000 Hi Emile, According to Russ, it is the new approach to IETF Copyright that has changed, and now a BSD license is required when extracting code (the IANA section, with new elements for the registry MIB). It appears that adding the text you suggest below won't cover the BSD license (I think the text was shared with us in one of the messages from the RFC Editor). Al At 12:07 PM 12/22/2010, emile.stephan@orange-ftgroup.com wrote: >Hi Al, > >My concern is that nobody points the rule which=20 >has changed. In 2009 we updated the registry=20 >with 2 new set of metrics from 2 different RFC without any difficulties. > >Is it because it is a MIB module? What is the=20 >exact text that has to be added? Why not=20 >inserting this text in the DESCRIPTION field of the REVISION added by IANA? > >' REVISION "201009070000Z" -- September 7, 2010 > DESCRIPTION > "Added values 71-83 as published=20 > in RFC-ietf-ippm-spatial-composition-16."' > >Regards >Emile > > > -----Message d'origine----- > > De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part de= Al > > Morton > > Envoy=E9 : mercredi 22 d=E9cembre 2010 15:25 > > =C0 : Henk Uijterwaal; ippm@ietf.org; STEPHAN Emile RD-CORE-LAN > > Objet : Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 > > > > Hi Emile, > > > > I think you are overlooking yet another advantage of > > freezing the registry as soon as possible. For the sake > > of others on the list, let me briefly summarize the > > recent discussions and delays during the publication of > > RFC 6049-to-be, the Spatial Composition Metrics. > > > > I'm still trying to understand more details of the problem, > > but in summary: IPPM can not simply append metrics to the registry > > with a dedicated section at the end of a memo, as we have done before. > > Apparently, additional licensing conditions are now needed > > for anyone who extracts information from the IPPM Metrics Registry MIB, > > beyond the original copyright from 2005. There was a request to > > republish the entire registry document under the new licenses. > > But with no one using the registry, only the licensing issues > > would be served. RFC 6049 was held for 2 months trying to sort this out. > > > > So, the current registry continues to require attention and > > effort (any draft with metrics needs the IANA section, or ?), > > but as we've learned over the last 6 months, no one benefits. > > The sooner we freeze the 4148 registry, the better. > > > > regards, > > Al > > > > At 03:58 AM 12/22/2010, Henk Uijterwaal wrote: > > >Hi Emile, > > > > > > > The situation has changed. In Beijing we discussed about the > > > freezing of the > > > > registry after spatial composition draft becomes RFC. On going > > discussions > > > > during the AUTH48 phase of spatial composition draft are taking a > > totally > > > > different direction. > > > > > >That is not how I remember it. We discussed freezing the registry with > > the > > >content it has on the day it is frozen. If the spatial composition= draft > > >would become an RFC before that date, the metrics will be in the= registry, > > >otherwise, they won't. > > > > > > > You and Al consider draft-morton-ippm-rfc4148-obsolete-02 as an > > important > > > > document. Then why do you place the WGLC in a period where nobody= will > > take > > > > care of the document? > > > > > >The issue has been discussed since July, the document merely reflects= the > > >conclusion that was drawn. Yes, this makes it an important document= but > > >No, this does not require a lengthy review period. The document= doesn't > > >say much more than "obsolete the registry". > > > > > > > > > > I will send a proposal but need time for editing and discussions. > > > > > >As I said earlier, there does not seem to be sufficient interest to > > >work on this topic at the moment. If this changes, then yes, this > > >can become a WG document. > > > > > >Henk > > > > > >-- > >= >------------------------------------------------------------------------- > > ----- > > >Henk Uijterwaal Email: > > henk.uijterwaal(at)ripe.net > > >RIPE Network Coordination Centre http://www.xs4all.nl/~henku > > >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 > >= >------------------------------------------------------------------------- > > ----- > > > > > >I confirm today what I denied yesterday. Anonymous= Politician. > > >_______________________________________________ > > >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 >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From emile.stephan@orange-ftgroup.com Fri Dec 24 01:19:35 2010 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 41D843A6918 for ; Fri, 24 Dec 2010 01:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 3FpyNPbMJJwx for ; Fri, 24 Dec 2010 01:19:34 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id B54333A690E for ; Fri, 24 Dec 2010 01:19:33 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E63FA6C000E; Fri, 24 Dec 2010 10:22:01 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id DB0656C000D; Fri, 24 Dec 2010 10:22:01 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Dec 2010 10:21:35 +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: Fri, 24 Dec 2010 10:21:33 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201632EB7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D11BDA3.7010004@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 Thread-Index: AcuhtnQqLbBUplN+TVSraacFjdrsngBlPMhg References: <4D0F0124.3090809@ripe.net><843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr> <4D11A815.9060000@ripe.net><843DA8228A1BA74CA31FB4E111A5C46201632B40@ftrdmel0.rd.francetelecom.fr> <4D11BDA3.7010004@ripe.net> From: To: , X-OriginalArrivalTime: 24 Dec 2010 09:21:35.0234 (UTC) FILETIME=[F5D36E20:01CBA34B] Cc: acmorton@att.com Subject: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 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, 24 Dec 2010 09:19:35 -0000 Hi Henk Is not is not a matter of interest. Most people (see below) are on = vacation and will only return to work on 3 January, 2010. S I think that it is reasonable to delay the end of WGLC to mid January. Regards Emile -----Message d'origine----- De : RFC Editor [mailto:rfc-editor@rfc-editor.org]=20 Envoy=E9 : mercredi 22 d=E9cembre 2010 18:51 =C0 : rfc-dist@rfc-editor.org; ietf-announce@ietf.org Cc : RFC Editor Objet : RFC Production Center Holiday Schedule Greetings All, Please note that the RFC Production Center staff will be on holiday from 24 December - 31 December. We will return to the office on 3 January, 2010. If there are any urgent issues, please send mail to rfc-editor@rfc-editor.org, as staff will be monitoring the mail throughout the week. =20 We hope that you are all enjoying the holiday season and that the new year finds you in good health. (Our apologies if you receive this message multiple times.) Thanks, Sandy for the RFC Production Center > -----Message d'origine----- > De=A0: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part = de > Henk Uijterwaal > Envoy=E9=A0: mercredi 22 d=E9cembre 2010 09:58 > =C0=A0: ippm@ietf.org > Objet=A0: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 >=20 > Hi Emile, >=20 > > The situation has changed. In Beijing we discussed about the = freezing of > the > > registry after spatial composition draft becomes RFC. On going > discussions > > during the AUTH48 phase of spatial composition draft are taking a > totally > > different direction. >=20 > That is not how I remember it. We discussed freezing the registry = with > the > content it has on the day it is frozen. If the spatial composition = draft > would become an RFC before that date, the metrics will be in the = registry, > otherwise, they won't. >=20 > > You and Al consider draft-morton-ippm-rfc4148-obsolete-02 as an > important > > document. Then why do you place the WGLC in a period where nobody = will > take > > care of the document? >=20 > The issue has been discussed since July, the document merely reflects = the > conclusion that was drawn. Yes, this makes it an important document = but > No, this does not require a lengthy review period. The document = doesn't > say much more than "obsolete the registry". >=20 >=20 > > I will send a proposal but need time for editing and discussions. >=20 > As I said earlier, there does not seem to be sufficient interest to > work on this topic at the moment. If this changes, then yes, this > can become a WG document. >=20 > Henk >=20 > -- > = -------------------------------------------------------------------------= - > ---- > Henk Uijterwaal Email: > henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.xs4all.nl/~henku > 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 > = -------------------------------------------------------------------------= - > ---- >=20 > I confirm today what I denied yesterday. Anonymous = Politician. > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Fri Dec 24 07:23:45 2010 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 6D7203A695A for ; Fri, 24 Dec 2010 07:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.457 X-Spam-Level: X-Spam-Status: No, score=-105.457 tagged_above=-999 required=5 tests=[AWL=0.339, 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 QYxDtqahFh6C for ; Fri, 24 Dec 2010 07:23:44 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id E358B3A67EB for ; Fri, 24 Dec 2010 07:23:43 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-167.messagelabs.com!1293204345!20637225!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 3570 invoked from network); 24 Dec 2010 15:25:46 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Dec 2010 15:25:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBOFQ5o1023452 for ; Fri, 24 Dec 2010 10:26:06 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oBOFPwE4023378 for ; Fri, 24 Dec 2010 10:25:59 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBOFPc6a003943 for ; Fri, 24 Dec 2010 10:25:38 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id oBOFPXCN003902 for ; Fri, 24 Dec 2010 10:25:33 -0500 Message-Id: <201012241525.oBOFPXCN003902@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-214-123.vpn.east.att.com[135.70.214.123](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101224152531gw1004lkuae>; Fri, 24 Dec 2010 15:25:32 +0000 X-Originating-IP: [135.70.214.123] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Dec 2010 10:25:59 -0500 To: emile.stephan@orange-ftgroup.com, , From: Al Morton In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201632EB7@ftrdmel0.rd.franc etelecom.fr> References: <4D0F0124.3090809@ripe.net> <843DA8228A1BA74CA31FB4E111A5C46201632B1A@ftrdmel0.rd.francetelecom.fr> <4D11A815.9060000@ripe.net> <843DA8228A1BA74CA31FB4E111A5C46201632B40@ftrdmel0.rd.francetelecom.fr> <4D11BDA3.7010004@ripe.net> <843DA8228A1BA74CA31FB4E111A5C46201632EB7@ftrdmel0.rd.francetelecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 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, 24 Dec 2010 15:23:45 -0000 FYI - I just fielded a request to *start* a BMWG Last call *before* the holidays, because many people use this time for best-effort reviews and volunteer work... Al bmwg chair At 04:21 AM 12/24/2010, emile.stephan@orange-ftgroup.com wrote: >Hi Henk > >Is not is not a matter of interest. Most people=20 >(see below) are on vacation and will only return to work on 3 January,= 2010. > >S I think that it is reasonable to delay the end of WGLC to mid January. > >Regards >Emile > >-----Message d'origine----- >De : RFC Editor [mailto:rfc-editor@rfc-editor.org] >Envoy=E9 : mercredi 22 d=E9cembre 2010 18:51 >=C0 : rfc-dist@rfc-editor.org; ietf-announce@ietf.org >Cc : RFC Editor >Objet : RFC Production Center Holiday Schedule > >Greetings All, > >Please note that the RFC Production Center staff will be on holiday >from 24 December - 31 December. We will return to the office on >3 January, 2010. If there are any urgent issues, please send mail to >rfc-editor@rfc-editor.org, as staff will be monitoring the mail >throughout the week. > >We hope that you are all enjoying the holiday season and that the new >year finds you in good health. > >(Our apologies if you receive this message multiple times.) > >Thanks, >Sandy >for the RFC Production Center > > > > -----Message d'origine----- > > De : ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] De la part de > > Henk Uijterwaal > > Envoy=E9 : mercredi 22 d=E9cembre 2010 09:58 > > =C0 : ippm@ietf.org > > Objet : Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02 > > > > Hi Emile, > > > > > The situation has changed. In Beijing we discussed about the freezing= of > > the > > > registry after spatial composition draft becomes RFC. On going > > discussions > > > during the AUTH48 phase of spatial composition draft are taking a > > totally > > > different direction. > > > > That is not how I remember it. We discussed freezing the registry with > > the > > content it has on the day it is frozen. If the spatial composition= draft > > would become an RFC before that date, the metrics will be in the= registry, > > otherwise, they won't. > > > > > You and Al consider draft-morton-ippm-rfc4148-obsolete-02 as an > > important > > > document. Then why do you place the WGLC in a period where nobody will > > take > > > care of the document? > > > > The issue has been discussed since July, the document merely reflects= the > > conclusion that was drawn. Yes, this makes it an important document but > > No, this does not require a lengthy review period. The document doesn't > > say much more than "obsolete the registry". > > > > > > > I will send a proposal but need time for editing and discussions. > > > > As I said earlier, there does not seem to be sufficient interest to > > work on this topic at the moment. If this changes, then yes, this > > can become a WG document. > > > > Henk > > > > -- > >= -------------------------------------------------------------------------- > > ---- > > Henk Uijterwaal Email: > > henk.uijterwaal(at)ripe.net > > RIPE Network Coordination Centre http://www.xs4all.nl/~henku > > 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 > >= -------------------------------------------------------------------------- > > ---- > > > > I confirm today what I denied yesterday. Anonymous= Politician. > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm From Internet-Drafts@ietf.org Fri Dec 31 13:45:04 2010 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 7D14D3A681E; Fri, 31 Dec 2010 13:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, 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 TXi4cxwW2nEl; Fri, 31 Dec 2010 13:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DF33A6821; Fri, 31 Dec 2010 13:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101231214502.7903.86780.idtracker@localhost> Date: Fri, 31 Dec 2010 13:45:02 -0800 Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-loss-episode-metrics-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: Fri, 31 Dec 2010 21:45:04 -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 : Loss Episode Metrics for IPPM Author(s) : N. Duffield, et al. Filename : draft-ietf-ippm-loss-episode-metrics-01.txt Pages : 22 Date : 2010-12-31 The IETF has developed a one way packet loss metric that measures the loss rate on a Poisson probe stream between two hosts. However, the impact of packet loss on applications is in general sensitive not just to the average loss rate, but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This draft defines one-way packet loss episode metrics, specifically the frequency and average duration of loss episodes, and a probing methodology under which the loss episode metrics are to be measured. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-loss-episode-metrics-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-loss-episode-metrics-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-31133700.I-D@ietf.org> --NextPart--