From nobody Wed Apr 1 05:47:46 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127761A8A80 for ; Wed, 1 Apr 2015 05:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fChi494fUoyv for ; Wed, 1 Apr 2015 05:47:42 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A2F1A8AC9 for ; Wed, 1 Apr 2015 05:47:38 -0700 (PDT) Received: by wiaa2 with SMTP id a2so64867557wia.0 for ; Wed, 01 Apr 2015 05:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jcWxCeWMiPrPLeU+mfPLLMe0o8kB/q/dtCElY38s3/4=; b=kexRteK0EhnASa1kb7TrkLwqnE+DCokEi64pG+0XXIMdmaKw97SkfL+goN9eMf8hTu SP8DzE+dTXyw66aTdUlBIXPt0nUplcuZK50Jw7dM1v8bzur6GJotJja7mlUFm8wGzptQ vqmqbBBIWkVu/veqXumQOfuwi3+mqoPdzBec77eE/cueblRDLQHHTu3Bn6IQoA22PszS 5Jy6ArU1pQiY7eLYku5ZEdXFmgtK40RTbKGXq3fket27/9dMNvxcrouIPOANdIATk8vq bQHvDW1/Fgfv5/H15jqYP9INy6TZTnbEeCaJE98inOWDXjDSj6CmXtTQy6nuZ+RtkpEM Bt9g== MIME-Version: 1.0 X-Received: by 10.180.208.107 with SMTP id md11mr15103993wic.10.1427892457416; Wed, 01 Apr 2015 05:47:37 -0700 (PDT) Received: by 10.194.54.134 with HTTP; Wed, 1 Apr 2015 05:47:36 -0700 (PDT) Received: by 10.194.54.134 with HTTP; Wed, 1 Apr 2015 05:47:36 -0700 (PDT) In-Reply-To: <3A3D4A78-EE84-4CFF-A46A-E5E0E3318494@trammell.ch> References: <3A3D4A78-EE84-4CFF-A46A-E5E0E3318494@trammell.ch> Date: Wed, 1 Apr 2015 18:17:36 +0530 Message-ID: From: Vinayak Hegde To: Brian Trammell Content-Type: multipart/alternative; boundary=001a11c3898eb3ab5d0512a91e0e Archived-At: Cc: IETF IPPM WG Subject: Re: [ippm] WG adoption call for draft-morton-ippm-active-passive X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2015 12:47:45 -0000 --001a11c3898eb3ab5d0512a91e0e Content-Type: text/plain; charset=UTF-8 Yes. We should adopt and I will review. Thanks Vinayak --001a11c3898eb3ab5d0512a91e0e Content-Type: text/html; charset=UTF-8

Yes. We should adopt and I will review.

Thanks
Vinayak

--001a11c3898eb3ab5d0512a91e0e-- From nobody Wed Apr 1 15:22:13 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EAE1A1B1F for ; Wed, 1 Apr 2015 15:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDy0Ak7Ccv3b for ; Wed, 1 Apr 2015 15:22:08 -0700 (PDT) Received: from nm15-vm0.bullet.mail.ne1.yahoo.com (nm15-vm0.bullet.mail.ne1.yahoo.com [98.138.91.70]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB371A87AA for ; Wed, 1 Apr 2015 15:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427926927; bh=6BA/m4eOgGQtxutIkGt7mL0miH55xOXLMST1mpFTQoA=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Y+UQfmEuvacdVPPUT3iN2JgkrfDj8J5uOip42qTxiEHQ1bdac4ZrisEQfag/sVd8CpMEfEf0iw1ZUUpU1ZBbGwRNgs9Ia8MlCnsBfsXNbNPSAY5NUDDip0UZjmxj2VYNJzaNIfwRXYUKWM5A7u8/grPj5t5MouLlAlACSSf40FS5laoruIYSbQWT/bkYrlSYdqKfTvmgkgDbOXFTSHCckjr9Uy4IO5e7VNzlUfdim6mYJBx0j/q0O++wnq97+kns4qtH0jQ+NLUF0gIQUBY8Jlxjej3WlbkWEa3XOrH6FX0sydIyJRpaTS3U8lqSPx2o1LVlm0wDpC0KIzgb30o8Ww== Received: from [98.138.100.112] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 22:22:07 -0000 Received: from [98.138.89.252] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 22:22:07 -0000 Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 22:22:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 368384.81332.bm@omp1044.mail.ne1.yahoo.com X-YMail-OSG: B6yEgYcVM1lo15LWyJedxUqfSSVdWlyBBLrLfiCN0vSoXuSQmYFyCUP0zk4gWhw MUgFwBIEUTJAtgJLkVYYNZlRpM8hOrsoUJ2nhbOybYiRD9OyDdpy9gBF4y_f8wLvwbWI7b1k.USE t4QgAtYP1aOfRpnx5fgFx71VZguQiXx8Cqn.KxwriVyKRGSn8ZDupuVfE3mgq7qRkhax6i7dm63z Nje3GF0d6ShZsbJOb59wnltZjsns8qzXBQNcYUQMocsMfYfbeA_tMwsc3_xFRRMao_zCSvAjanuQ QaDUGBAck7WHe1xBzH7Z4Dk2PiadqVuRB1WmlCmBoh3a0vMfH8PzOpQzmSNf4lU8SdbY6ka9o22R LlwJAY8l9nk1OGHgHDhx9_EEcrGuqFasdkBsBSo8JuD2EnWrIrraupZ38LEpfNOn.eV5p5G.kIwC J283oAUpyyvb06zQZFIbaPUMqI2bgzZqyoJKhuuASVhLSc2iQ8kNGxrhTSeB3Bg7s_d010evMPPX EcXFTWfojNQvTzYnf0fnCKMkSWo2fr.RAr_zcO0j6My57NjGHJhzInfj81bQRamoQhes20Jdhzqz ni2C4Urse2BY1xrmtSdjY3wlwxg0gmwp8FG74S9hbqudiu73eCZt.j85IHg-- Received: by 98.138.105.212; Wed, 01 Apr 2015 22:22:06 +0000 Date: Wed, 1 Apr 2015 22:22:06 +0000 (UTC) From: Nalini Elkins To: IPPM IETF Message-ID: <201632139.3253063.1427926926199.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150401204420.26520.43166.idtracker@ietfa.amsl.com> References: <20150401204420.26520.43166.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3253062_308653591.1427926926195" Archived-At: Subject: [ippm] Fw: New Version Notification for draft-elkins-ippm-6man-pdm-option-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 22:22:12 -0000 ------=_Part_3253062_308653591.1427926926195 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IPPM'ers, As discussed at the WG in Dallas, we have created a version of our draft wh= ich combines both the IPPM considerations and PDM layout. =C2=A0 (And, yes,= I know this is April 1st, but this is actually NOT an April 1st RFC. =C2= =A0 Possibly should have posted tomorrow.) We have also addressed the comments kindly provided by Al Morton in this dr= aft as well. We await comments from the group & call for adoption on the list by WG chai= rs, as discussed in Dallas. =C2=A0(Unless there is something else that we n= eed to do!) Thank you all for your help. Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ----- Forwarded Message ----- From: "internet-drafts@ietf.org" To: Nalini Elkins ; Rob Hamilton ; Michael S. Ackermann ; Nalini Elkins <= nalini.elkins@insidethestack.com>; Robert Hamilton ; Mic= hael Ackermann =20 Sent: Wednesday, April 1, 2015 1:44 PM Subject: New Version Notification for draft-elkins-ippm-6man-pdm-option-00= .txt =20 A new version of I-D, draft-elkins-ippm-6man-pdm-option-00.txt has been successfully submitted by Nalini Elkins and posted to the IETF repository. Name:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 draft-elkins-ippm-6man-pdm-optio= n Revision:=C2=A0=C2=A0=C2=A0 00 Title:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 IPv6 Performance and Diagnostic= Metrics (PDM) Destination Option Document date:=C2=A0=C2=A0=C2=A0 2015-03-31 Group:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Individual Submission Pages:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 28 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-= drafts/draft-elkins-ippm-6man-pdm-option-00.txt Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/draft-e= lkins-ippm-6man-pdm-option/ Htmlized:=C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/draft-elkins-ippm-= 6man-pdm-option-00 Abstract: =C2=A0 To assess performance problems,=C2=A0 measurements based on optional =C2=A0 sequence numbers and timing may be embedded in each packet.=C2=A0 Su= ch =C2=A0 measurements may be interpreted in real-time or after the fact. An =C2=A0 implementation of the existing IPv6 Destination Options extension =C2=A0 header, the Performance and Diagnostic Metrics (PDM) Destination =C2=A0 Options extension header as well as the field limits, calculations, =C2=A0 and usage of the PDM in measurement are included in this document. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ------=_Part_3253062_308653591.1427926926195 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IPPM'= ers,

As discussed at th= e WG in Dallas, we have created a version of our draft which combines both = the IPPM considerations and PDM layout.   (And, yes, I know this is Ap= ril 1st, but this is actually NOT an April 1st RFC.   Possibly should = have posted tomorrow.)

= We have also addressed the comments kindly provided by Al Morton in this dr= aft as well.
<= br>
We await c= omments from the group & call for adoption on the list by WG chairs, as= discussed in Dallas.  (Unless there is something else that we need to= do!)

Thank you all for= your help.

Nalini Elkins
Inside Products, Inc.(831) 659-8360
www.insidethestack.com

=
----- = Forwarded Message -----
From:= "internet-drafts@ietf.org" <internet-drafts@ietf.org>
To: Nalini Elkins <nalini.elk= ins@insidethestack.com>; Rob Hamilton <rhamilton@cas.org>; Michael= S. Ackermann <mackermann@bcbsmi.com>; Nalini Elkins <nalini.elkin= s@insidethestack.com>; Robert Hamilton <rhamilton@cas.org>; Michae= l Ackermann <mackermann@bcbsmi.com>
Sent: Wednesday, April 1, 2015 1:44 PM
Subject: New Version Notification for= draft-elkins-ippm-6man-pdm-option-00.txt


A new versi= on of I-D, draft-elkins-ippm-6man-pdm-option-00.txt
has been successfull= y submitted by Nalini Elkins and posted to the
IETF repository.

N= ame:        draft-elkins-ippm-6man-pdm-option=
Revision:    00
Title:      =   IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
= Document date:    2015-03-31
Group:    &nb= sp;   Individual Submission
Pages:     &nb= sp;  28
URL:            http://www.ietf.org/internet-drafts/draft-elkins-ippm-6m= an-pdm-option-00.txt
Status:        https://datatracker.ietf.org/doc/draft-elkins-ippm-6man-pdm-opt= ion/
Htmlized:      http://tools.= ietf.org/html/draft-elkins-ippm-6man-pdm-option-00


Abstract:=
  To assess performance problems,  measurements based on opt= ional
  sequence numbers and timing may be embedded in each packet= .  Such
  measurements may be interpreted in real-time or aft= er the fact. An
  implementation of the existing IPv6 Destination = Options extension
  header, the Performance and Diagnostic Metrics= (PDM) Destination
  Options extension header as well as the field= limits, calculations,
  and usage of the PDM in measurement are i= ncluded in this document.

            =                      = ;                     &nb= sp;                     &= nbsp;    


Please note that it may take a couple of mi= nutes from the time of submission
until the htmlized version and diff ar= e available at tools.ietf.org.

The IETF Secretariat



<= /div>
------=_Part_3253062_308653591.1427926926195-- From rshearma@Brocade.com Thu Apr 2 07:18:10 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10FE1A9053 for ; Thu, 2 Apr 2015 07:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whO0rGkAfRS1 for ; Thu, 2 Apr 2015 07:18:04 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20CE1A9106 for ; Thu, 2 Apr 2015 07:18:04 -0700 (PDT) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t32DxYcY014420; Thu, 2 Apr 2015 07:18:03 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1tgtd91kvr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Apr 2015 07:18:03 -0700 Received: from BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 2 Apr 2015 07:18:02 -0700 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 2 Apr 2015 08:17:20 -0600 Received: from [172.27.236.49] (172.27.236.49) by imapeu.brocade.com (172.29.18.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 2 Apr 2015 16:15:46 +0200 Message-ID: <551D4F11.3050702@brocade.com> Date: Thu, 2 Apr 2015 15:15:45 +0100 From: Robert Shearman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-02_04:2015-04-02,2015-04-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=13 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504020135 Archived-At: X-Mailman-Approved-At: Thu, 02 Apr 2015 09:43:18 -0700 Cc: ippm@ietf.org Subject: [ippm] Mail regarding draft-elteto-ippm-twamp-mib X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 14:27:41 -0000 Dear authors, Thanks for your work on this MIB. I have a couple of comments/questions on the draft. However, in light of the recent publication of draft-cmzrjp-ippm-twamp-yang and its statement about progress on draft-elteto-ippm-twamp-mib being stalled, is it worth me articulating those comments? In other words, will there be any further updates to draft-elteto-ippm-twamp-mib? Thanks, Rob From nobody Thu Apr 2 21:23:05 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA581A0252 for ; Thu, 2 Apr 2015 21:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VM1hLhigMM_w for ; Thu, 2 Apr 2015 21:23:01 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990201A024E for ; Thu, 2 Apr 2015 21:23:01 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-30-551dbf6b5710 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.C4.12456.B6FBD155; Fri, 3 Apr 2015 00:15:07 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Fri, 3 Apr 2015 00:23:00 -0400 From: Gregory Mirsky To: Robert Shearman , "draft-elteto-ippm-twamp-mib@tools.ietf.org" Thread-Topic: Mail regarding draft-elteto-ippm-twamp-mib Thread-Index: AQHQbVE2xzypHBDtrkyIMdQPy6mytZ06r++A Date: Fri, 3 Apr 2015 04:22:59 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B93F3EB@eusaamb103.ericsson.se> References: <551D4F11.3050702@brocade.com> In-Reply-To: <551D4F11.3050702@brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXRPuG72ftlQg7ef5C2mLutmsuh58I7Z 4vqVOcwOzB49xy6zeSxZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGR9vihU0cVfsfreFtYHx DlcXIyeHhICJxJPTnxghbDGJC/fWs3UxcnEICRxllFgx9RMzhLOMUeL/vslMIFVsAkYSLzb2 sIMkRAQ6GSW2LnnFCpJgFlCW2PtqPtAoDg5hAXOJ70udQMIiAhYSW47eZ4KwjSReTjsAVs4i oCLRe7YJLM4r4Cvx/8BjZhBbSEBLYuOPjewgNqeAtsSmP/PBahiBrvt+ag0TxCpxiVtPIOIS AgISS/acZ4awRSVePv7HCmErSXz8PZ8d5BxmAU2J9bv0IVoVJaZ0P2SHWCsocXLmE5YJjGKz kEydhdAxC0nHLCQdCxhZVjFylBanluWmGxlsYgRGzTEJNt0djHteWh5iFOBgVOLhTciSCRVi TSwrrsw9xCjNwaIkzrvowcEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyqFr1SdRmyV3oq Zz5KjWJY8YjvwUvxPf/bXl+oez2tdvmKVP6DfTe4t9TkeizT3+7TfnH3teXv+VSd/3xd5yD/ T+3g+trq3EgVj1+f9mezatr0OhfNL6i/mnvNpNrycXHrxcvBaz69eHuPT8zp7Ma9alfuzq+t dQrh9nq4/ml0uGzLH7X/338qsRRnJBpqMRcVJwIA6TReMHsCAAA= Archived-At: Cc: "ippm@ietf.org" Subject: Re: [ippm] Mail regarding draft-elteto-ippm-twamp-mib X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 04:23:05 -0000 SGkgUm9iLA0KbWFueSB0aGFua3MgZm9yIHlvdXIgaW50ZXJlc3QgYW5kIGtpbmQgY29uc2lkZXJh dGlvbiBvZiBvdXIgd29yay4gSXQgaXMgdHJ1ZSB0aGF0IGFmdGVyIElFU0cgc3RhdGVtZW50IG9u IGRldmVsb3BtZW50IG9mIG5ldyBSL1cgTUlCcyBhdCBJRVRGIHdlJ3ZlIGRlY2lkZWQgdG8gc3Rv cCB0aGlzIHdvcmsuDQpCdXQgSSB0aGluayBpdCB3aWxsIGJlbmVmaXQgbm90IG9ubHkgYXV0aG9y cyBidXQgdGhlIElQUE0gV0cgaWYgeW91IGNvdWxkIHNoYXJlIHlvdXIgY29tbWVudHMgYW5kIHN1 Z2dlc3Rpb25zIHRoYXQgd291bGQgaGVscCBpbiB3b3JrIG9uIFRXQU1QIGFuZCBUV0FNUC1MaWdo dCBZQU5HIG1vZGVscy4NCg0KCVJlZ2FyZHMsDQoJCUdyZWcNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFJvYmVydCBTaGVhcm1hbiBbbWFpbHRvOnJzaGVhcm1hQGJyb2NhZGUu Y29tXSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwMiwgMjAxNSA3OjE2IEFNDQpUbzogZHJhZnQt ZWx0ZXRvLWlwcG0tdHdhbXAtbWliQHRvb2xzLmlldGYub3JnDQpDYzogaXBwbUBpZXRmLm9yZw0K U3ViamVjdDogTWFpbCByZWdhcmRpbmcgZHJhZnQtZWx0ZXRvLWlwcG0tdHdhbXAtbWliDQoNCkRl YXIgYXV0aG9ycywNCg0KVGhhbmtzIGZvciB5b3VyIHdvcmsgb24gdGhpcyBNSUIuDQoNCkkgaGF2 ZSBhIGNvdXBsZSBvZiBjb21tZW50cy9xdWVzdGlvbnMgb24gdGhlIGRyYWZ0LiBIb3dldmVyLCBp biBsaWdodCBvZiB0aGUgcmVjZW50IHB1YmxpY2F0aW9uIG9mIGRyYWZ0LWNtenJqcC1pcHBtLXR3 YW1wLXlhbmcgYW5kIGl0cyBzdGF0ZW1lbnQgYWJvdXQgcHJvZ3Jlc3Mgb24gZHJhZnQtZWx0ZXRv LWlwcG0tdHdhbXAtbWliIGJlaW5nIHN0YWxsZWQsIGlzIGl0IHdvcnRoIG1lIGFydGljdWxhdGlu ZyB0aG9zZSBjb21tZW50cz8gSW4gb3RoZXIgd29yZHMsIHdpbGwgdGhlcmUgYmUgYW55IGZ1cnRo ZXIgdXBkYXRlcyB0byBkcmFmdC1lbHRldG8taXBwbS10d2FtcC1taWI/DQoNClRoYW5rcywNClJv Yg0K From nobody Mon Apr 6 05:54:38 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6442F1A1B76; Mon, 6 Apr 2015 05:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIM0_Bg9Kf3T; Mon, 6 Apr 2015 05:54:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD6C1A1BA5; Mon, 6 Apr 2015 05:54:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> Date: Mon, 06 Apr 2015 05:54:32 -0700 Archived-At: Cc: ippm-chairs@ietf.org, ippm@ietf.org Subject: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 12:54:34 -0000 Brian Haberman has entered the following ballot position for draft-ietf-ippm-ipsec-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I hope this is a short discussion and I can change my ballot to a Yes... The applicability section says "Until an IANA registry for OWAMP Mode values is established, the use this feature in OWAMP implementations MUST be arranged privately among consenting OWAMP users." Is there an issue with this document creating that registry? Or, if separation is needed, a companion document spun quickly to create this registry? The functionality specified here seems quite applicable to OWAMP and requiring private agreements to use it seems sub-optimal. From nobody Mon Apr 6 07:11:40 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E531A0377; Mon, 6 Apr 2015 07:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sLqWr3FbugE; Mon, 6 Apr 2015 07:11:32 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 492F81A1B8A; Mon, 6 Apr 2015 07:11:32 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 4B0511200DB; Mon, 6 Apr 2015 10:29:21 -0400 (EDT) Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.99]) by mail-green.research.att.com (Postfix) with ESMTP id 1A721E0271; Mon, 6 Apr 2015 10:11:12 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by njmtcas1.research.att.com ([fe80::f1f7:6c06:d0d0:d48c%10]) with mapi; Mon, 6 Apr 2015 10:11:31 -0400 From: "MORTON, ALFRED C (AL)" To: Brian Haberman , The IESG Date: Mon, 6 Apr 2015 10:11:29 -0400 Thread-Topic: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) Thread-Index: AdBwaN1PUJJ5PunUTH2rwORdYACaewACkvlw Message-ID: <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> References: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> In-Reply-To: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ippm-chairs@ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 14:11:39 -0000 > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Haberman ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I hope this is a short discussion and I can change my ballot to a Yes... >=20 > The applicability section says "Until an IANA registry for OWAMP Mode > values is established, the use this feature in OWAMP implementations > MUST be arranged privately among consenting OWAMP users." >=20 > Is there an issue with this document creating that registry? Or, if > separation is needed, a companion document spun quickly to create this > registry? =20 [ACM]=20 I can spin-up a companion doc to create the OWAMP registry,=20 should be posted in about an hour. Al > The functionality specified here seems quite applicable to > OWAMP and requiring private agreements to use it seems sub-optimal. >=20 From nobody Mon Apr 6 09:44:19 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9473F1A88C9; Mon, 6 Apr 2015 09:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4v9qPyWey0t; Mon, 6 Apr 2015 09:44:14 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6652B1A88C0; Mon, 6 Apr 2015 09:44:14 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id D295D120B90; Mon, 6 Apr 2015 13:02:03 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg11.research.att.com [135.207.240.18]) by mail-green.research.att.com (Postfix) with ESMTP id 351A0E0699; Mon, 6 Apr 2015 12:43:54 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG11.research.att.com ([fe80::516e:6eec:2697:ec78%17]) with mapi; Mon, 6 Apr 2015 12:44:01 -0400 From: "MORTON, ALFRED C (AL)" To: Brian Haberman , The IESG Date: Mon, 6 Apr 2015 12:44:00 -0400 Thread-Topic: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) Thread-Index: AdBwaN1PUJJ5PunUTH2rwORdYACaewACkvlwAAVKELA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D8BA78987@NJFPSRVEXG0.research.att.com> References: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ippm-chairs@ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 16:44:15 -0000 > -----Original Message----- ... > > -----Original Message----- > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Haberman > ... > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I hope this is a short discussion and I can change my ballot to a > Yes... > > > > The applicability section says "Until an IANA registry for OWAMP Mode > > values is established, the use this feature in OWAMP implementations > > MUST be arranged privately among consenting OWAMP users." > > > > Is there an issue with this document creating that registry? Or, if > > separation is needed, a companion document spun quickly to create this > > registry? > [ACM] >=20 > I can spin-up a companion doc to create the OWAMP registry, should be > posted in about an hour. >=20 > Al >=20 >=20 http://tools.ietf.org/html/draft-morton-ippm-owamp-registry-00 took a little longer than an hour, we had a power outage here. This memo suggests the (new) assignment for IPsec mode in the draft IESG=20 is considering, so perhaps IPsec-09 can continue on its way. Al From nobody Mon Apr 6 10:04:34 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299B41A8BC2; Mon, 6 Apr 2015 10:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br1E_EY9utkB; Mon, 6 Apr 2015 10:04:28 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70611A8BC0; Mon, 6 Apr 2015 10:04:28 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id B1554880E1; Mon, 6 Apr 2015 10:04:28 -0700 (PDT) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 31D4D13682CB; Mon, 6 Apr 2015 10:04:28 -0700 (PDT) Message-ID: <5522BC93.3020003@innovationslab.net> Date: Mon, 06 Apr 2015 13:04:19 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , The IESG References: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78987@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D8BA78987@NJFPSRVEXG0.research.att.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7q653L56S2DHhw6N2ObbUGlcw38K6mKdW" Archived-At: Cc: "ippm-chairs@ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 17:04:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7q653L56S2DHhw6N2ObbUGlcw38K6mKdW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All, On 4/6/15 12:44 PM, MORTON, ALFRED C (AL) wrote: >=20 >> -----Original Message----- > ... >>> -----Original Message----- >>> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Haberman= >> ... >>> ---------------------------------------------------------------------= - >>> DISCUSS: >>> ---------------------------------------------------------------------= - >>> >>> I hope this is a short discussion and I can change my ballot to a >> Yes... >>> >>> The applicability section says "Until an IANA registry for OWAMP Mode= >>> values is established, the use this feature in OWAMP implementations >>> MUST be arranged privately among consenting OWAMP users." >>> >>> Is there an issue with this document creating that registry? Or, if >>> separation is needed, a companion document spun quickly to create thi= s >>> registry? >> [ACM] >> >> I can spin-up a companion doc to create the OWAMP registry, should be >> posted in about an hour. >> >> Al >> >> >=20 > http://tools.ietf.org/html/draft-morton-ippm-owamp-registry-00 >=20 > took a little longer than an hour, we had a power outage here. > This memo suggests the (new) assignment for IPsec mode in the draft IES= G=20 > is considering, so perhaps IPsec-09 can continue on its way. I will cut you some slack on the 1-hour promise given your power outage. = :) One issue we have is that IPsec-09 can't be published before your draft is approved and the IANA creates the registry. The text in IPsec-09 should be updated to reflect the soon-to-be existence of the registry. This is the point where the shepherding AD and WG should chime in. Regards, Brian --7q653L56S2DHhw6N2ObbUGlcw38K6mKdW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVIryaAAoJEBOZRqCi7goq3ecH/1h9YkvAVAbDtuVOEakqHpRp GyFeckhT+1x8EAEfzOyP0uZW543Dz9reW+V7iBZSP/hTlUQF9MPAoYOwPJ1sZuWL nomyQeGP3APdOgeRgN5U+dSiOdMrpl3GL4WWYmd0QMan7Disiox8RKMOD6XP9LAo c4C2/HhkcsaSPuTS0hJTxe1u09+2/eNilv7G5p4xEcecOCHeUZUuHqDicIexH3vl JQsV/QuPQJdIQfLivXFqGlAqrCqIw2lqIkef9bPr5nfCnwVFnI09/mTHv4Q+ZpOr ZJhNY4m+T3ezF6PTetCfZhL0Ej7V1zaCJPEmkGAo/qB/jdKwQDKKDAFnzUxLp/c= =sG0S -----END PGP SIGNATURE----- --7q653L56S2DHhw6N2ObbUGlcw38K6mKdW-- From nobody Mon Apr 6 13:45:09 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EB31A9167; Mon, 6 Apr 2015 13:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_r1rMuoL5sC; Mon, 6 Apr 2015 13:45:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0EB1A9165; Mon, 6 Apr 2015 13:45:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7CCF218046B; Mon, 6 Apr 2015 13:44:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150406204436.7CCF218046B@rfc-editor.org> Date: Mon, 6 Apr 2015 13:44:36 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 7497 on Rate Measurement Test Protocol Problem Statement and Requirements X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 20:45:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7497 Title: Rate Measurement Test Protocol Problem Statement and Requirements Author: A. Morton Status: Informational Stream: IETF Date: April 2015 Mailbox: acmorton@att.com Pages: 14 Characters: 31281 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-rate-problem-10.txt URL: https://www.rfc-editor.org/info/rfc7497 This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size. This document is a product of the IP Performance Metrics Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Apr 7 08:15:45 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AD21B36CC; Tue, 7 Apr 2015 08:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxIEZqSMYFh2; Tue, 7 Apr 2015 08:15:39 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45741B36C6; Tue, 7 Apr 2015 08:15:29 -0700 (PDT) Received: by labbd9 with SMTP id bd9so33233186lab.2; Tue, 07 Apr 2015 08:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UqJJG2IjaZ7uwJa+mHuk1bt27PX+amfW0G3Gv+I7eZc=; b=TJnpVEnDvMQo9nDrZPikW3FKIiRl531u+H+U4uvEE29GS4w8w52BzcJAk6iRhlcJT/ E4XRDDLWKPNFujAnwtDKP+B9Iw/tlaFPhOVRgRTbxJuFmzA0THQA2JsabhBddrM18oli 9kyZzxrXTh0GH+pFaQjeQtsuOS5s2sWsMBlzu8XVqKcONcLATgxnV8T8WuGcdiXAwLxM ob0FiyPGLgHjxGwT5+Rpj05eDzWyZ78K3cgNY9nq3Ku2e0S3D0aaJECXSQdInbhuic35 OU4rbEjL3yAmEv+lSiC6PO55yov9y9YoOikxPB7kPmkRVy+odRQdlztKAqERYqWIT0l7 TGQA== MIME-Version: 1.0 X-Received: by 10.112.98.201 with SMTP id ek9mr18692125lbb.68.1428419728424; Tue, 07 Apr 2015 08:15:28 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Tue, 7 Apr 2015 08:15:28 -0700 (PDT) In-Reply-To: <5522BC93.3020003@innovationslab.net> References: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78987@NJFPSRVEXG0.research.att.com> <5522BC93.3020003@innovationslab.net> Date: Tue, 7 Apr 2015 10:15:28 -0500 Message-ID: From: Spencer Dawkins at IETF To: Brian Haberman Content-Type: multipart/alternative; boundary=001a11345c8c80c4bc051323e293 Archived-At: Cc: "ippm-chairs@ietf.org" , "MORTON, ALFRED C \(AL\)" , "ippm@ietf.org" , The IESG Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 15:15:41 -0000 --001a11345c8c80c4bc051323e293 Content-Type: text/plain; charset=UTF-8 Hi, Brian, On Mon, Apr 6, 2015 at 12:04 PM, Brian Haberman wrote: > Hi All, > > On 4/6/15 12:44 PM, MORTON, ALFRED C (AL) wrote: > > > >> -----Original Message----- > > ... > >>> -----Original Message----- > >>> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Haberman > >> ... > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> I hope this is a short discussion and I can change my ballot to a > >> Yes... > >>> > >>> The applicability section says "Until an IANA registry for OWAMP Mode > >>> values is established, the use this feature in OWAMP implementations > >>> MUST be arranged privately among consenting OWAMP users." > >>> > >>> Is there an issue with this document creating that registry? Or, if > >>> separation is needed, a companion document spun quickly to create this > >>> registry? > >> [ACM] > >> > >> I can spin-up a companion doc to create the OWAMP registry, should be > >> posted in about an hour. > >> > >> Al > >> > >> > > > > http://tools.ietf.org/html/draft-morton-ippm-owamp-registry-00 > > > > took a little longer than an hour, we had a power outage here. > > This memo suggests the (new) assignment for IPsec mode in the draft IESG > > is considering, so perhaps IPsec-09 can continue on its way. > > I will cut you some slack on the 1-hour promise given your power outage. :) > > One issue we have is that IPsec-09 can't be published before your draft > is approved and the IANA creates the registry. > > The text in IPsec-09 should be updated to reflect the soon-to-be > existence of the registry. > > This is the point where the shepherding AD and WG should chime in. > I'm happy to give the WG a moment to chime in, but just to make sure I understand your point, it's to create a normative dependency on the companion draft creating the registry, so that IPsec-09 can be approved, but will not be published until the draft creating the registry is approved. Is that it? To the WG - is creating a registry OK? Let's start there ... Thanks, Spencer --001a11345c8c80c4bc051323e293 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Brian,

On Mon, Apr 6, 2015 at 12:04 PM, Brian Haberman <brian@in= novationslab.net> wrote:
Hi= All,

On 4/6/15 12:44 PM, MORTON, ALFRED C (AL) wrote:
>
>> -----Original Message-----
> ...
>>> -----Original Message-----
>>> From: ippm [mailto:ip= pm-bounces@ietf.org] On Behalf Of Brian Haberman
>> ...
>>> --------------------------------------------------------------= --------
>>> DISCUSS:
>>> --------------------------------------------------------------= --------
>>>
>>> I hope this is a short discussion and I can change my ballot t= o a
>> Yes...
>>>
>>> The applicability section says "Until an IANA registry fo= r OWAMP Mode
>>> values is established, the use this feature in OWAMP implement= ations
>>> MUST be arranged privately among consenting OWAMP users."=
>>>
>>> Is there an issue with this document creating that registry?= =C2=A0 Or, if
>>> separation is needed, a companion document spun quickly to cre= ate this
>>> registry?
>> [ACM]
>>
>> I can spin-up a companion doc to create the OWAMP registry, should= be
>> posted in about an hour.
>>
>> Al
>>
>>
>
> http://tools.ietf.org/html/draft-morton-ippm-owamp-r= egistry-00
>
> took a little longer than an hour, we had a power outage here.
> This memo suggests the (new) assignment for IPsec mode in the draft IE= SG
> is considering, so perhaps IPsec-09 can continue on its way.

I will cut you some slack on the 1-hour promise given your powe= r outage. :)

One issue we have is that IPsec-09 can't be published before your draft=
is approved and the IANA creates the registry.

The text in IPsec-09 should be updated to reflect the soon-to-be
existence of the registry.

This is the point where the shepherding AD and WG should chime in.

I'm happy to give the WG a moment to chime = in, but just to make sure I understand your point, it's to create a nor= mative dependency on the companion draft creating the registry, so that IPs= ec-09 can be approved, but will not be published until the draft creating t= he registry is approved.=C2=A0

Is that it?

To the WG - is creating a registry OK? Let's start th= ere ...

Thanks,

Spencer= =C2=A0

--001a11345c8c80c4bc051323e293-- From nobody Tue Apr 7 08:44:35 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4596A1A88F1; Tue, 7 Apr 2015 08:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVO_UP14PqUy; Tue, 7 Apr 2015 08:44:29 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAA51A893F; Tue, 7 Apr 2015 08:41:18 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6249C8812C; Tue, 7 Apr 2015 08:41:18 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id B752013682CB; Tue, 7 Apr 2015 08:41:17 -0700 (PDT) Message-ID: <5523FA96.9060700@innovationslab.net> Date: Tue, 07 Apr 2015 11:41:10 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Spencer Dawkins at IETF References: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78987@NJFPSRVEXG0.research.att.com> <5522BC93.3020003@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eFpQXvd44QbVc4KqxCGT9WLVT0BmMCXGX" Archived-At: Cc: "ippm-chairs@ietf.org" , "MORTON, ALFRED C \(AL\)" , "ippm@ietf.org" , The IESG Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 15:44:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eFpQXvd44QbVc4KqxCGT9WLVT0BmMCXGX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Spencer, On 4/7/15 11:15 AM, Spencer Dawkins at IETF wrote: > Hi, Brian, >=20 > On Mon, Apr 6, 2015 at 12:04 PM, Brian Haberman > wrote: >=20 >> Hi All, >> >> On 4/6/15 12:44 PM, MORTON, ALFRED C (AL) wrote: >>> >>>> -----Original Message----- >>> ... >>>>> -----Original Message----- >>>>> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Haberm= an >>>> ... >>>>> -------------------------------------------------------------------= --- >>>>> DISCUSS: >>>>> -------------------------------------------------------------------= --- >>>>> >>>>> I hope this is a short discussion and I can change my ballot to a >>>> Yes... >>>>> >>>>> The applicability section says "Until an IANA registry for OWAMP Mo= de >>>>> values is established, the use this feature in OWAMP implementation= s >>>>> MUST be arranged privately among consenting OWAMP users." >>>>> >>>>> Is there an issue with this document creating that registry? Or, i= f >>>>> separation is needed, a companion document spun quickly to create t= his >>>>> registry? >>>> [ACM] >>>> >>>> I can spin-up a companion doc to create the OWAMP registry, should b= e >>>> posted in about an hour. >>>> >>>> Al >>>> >>>> >>> >>> http://tools.ietf.org/html/draft-morton-ippm-owamp-registry-00 >>> >>> took a little longer than an hour, we had a power outage here. >>> This memo suggests the (new) assignment for IPsec mode in the draft I= ESG >>> is considering, so perhaps IPsec-09 can continue on its way. >> >> I will cut you some slack on the 1-hour promise given your power outag= e. :) >> >> One issue we have is that IPsec-09 can't be published before your draf= t >> is approved and the IANA creates the registry. >> >> The text in IPsec-09 should be updated to reflect the soon-to-be >> existence of the registry. >> >> This is the point where the shepherding AD and WG should chime in. >> >=20 > I'm happy to give the WG a moment to chime in, but just to make sure I > understand your point, it's to create a normative dependency on the > companion draft creating the registry, so that IPsec-09 can be approved= , > but will not be published until the draft creating the registry is > approved. >=20 > Is that it? Yes. We want IPsec-09 to say the right thing about OWAMP Mode values. Brian >=20 > To the WG - is creating a registry OK? Let's start there ... >=20 > Thanks, >=20 > Spencer >=20 --eFpQXvd44QbVc4KqxCGT9WLVT0BmMCXGX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVI/qWAAoJEBOZRqCi7goqB40H/3qpqc6ccmLJjVOgJQL+NSEG /OELTyspKApDPhJDM1zrMvxGUkQBlIrbW9EqmBEvgvS4mwIkjeW7BS+3TNdIMHge 3msIv1z6ZwA+T7Vfn58Uc4CPdR0nae4oJRulAj+f6EgLYLd+78bLyYlLIXIEQxtF 3FVkh/Q7vdhskhSI02iknquHRLCqhoDqG4tYb3HW+h6NAI6F/Z+GOGQaljvE1fVx D1yzqiZE4CbImvLCSjvUQM8i5JGL6hQJGL/Wt9GFlww/TLfKBGsC+e9MoI9v3KbP Ox8JWh/lhN0YnqLDf49s41iurxCCl3NvUtSP26MV62sydY+T3DA3MZPhMNOS/SE= =x+sT -----END PGP SIGNATURE----- --eFpQXvd44QbVc4KqxCGT9WLVT0BmMCXGX-- From nobody Tue Apr 7 09:45:28 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B751B37E3; Tue, 7 Apr 2015 09:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFS86Wq3nSOr; Tue, 7 Apr 2015 09:45:23 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id D95401B37E2; Tue, 7 Apr 2015 09:45:18 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 6268C120F19; Tue, 7 Apr 2015 13:03:11 -0400 (EDT) Received: from exchange.research.att.com (sentinel.research.att.com [135.207.255.38]) by mail-blue.research.att.com (Postfix) with ESMTP id 7008DF0436; Tue, 7 Apr 2015 12:45:15 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by sentinel.research.att.com ([fe80::7914:9c7e:6a73:a8d6%10]) with mapi; Tue, 7 Apr 2015 12:45:15 -0400 From: "MORTON, ALFRED C (AL)" To: Brian Haberman , Spencer Dawkins at IETF Date: Tue, 7 Apr 2015 12:45:14 -0400 Thread-Topic: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) Thread-Index: AdBxSVOoqAY+qlrPSIyKugMU/h4n5QABo8tg Message-ID: <4AF73AA205019A4C8A1DDD32C034631D8BA78AC6@NJFPSRVEXG0.research.att.com> References: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78987@NJFPSRVEXG0.research.att.com> <5522BC93.3020003@innovationslab.net> <5523FA96.9060700@innovationslab.net> In-Reply-To: <5523FA96.9060700@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ippm-chairs@ietf.org" , The IESG , "ippm@ietf.org" Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 16:45:25 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gSGFiZXJtYW4g W21haWx0bzpicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXRdDQo+IFNlbnQ6IFR1ZXNkYXksIEFwcmls IDA3LCAyMDE1IDExOjQxIEFNDQo+IFRvOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURg0KPiBDYzog TU9SVE9OLCBBTEZSRUQgQyAoQUwpOyBUaGUgSUVTRzsgaXBwbS1jaGFpcnNAaWV0Zi5vcmc7IGlw cG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtpcHBtXSBCcmlhbiBIYWJlcm1hbidzIERpc2N1 c3Mgb24gZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLQ0KPiAwOTogKHdpdGggRElTQ1VTUykNCj4gDQo+ IEhpIFNwZW5jZXIsDQo+IA0KLi4uDQo+ID4NCj4gPiBJJ20gaGFwcHkgdG8gZ2l2ZSB0aGUgV0cg YSBtb21lbnQgdG8gY2hpbWUgaW4sIGJ1dCBqdXN0IHRvIG1ha2Ugc3VyZSBJDQo+ID4gdW5kZXJz dGFuZCB5b3VyIHBvaW50LCBpdCdzIHRvIGNyZWF0ZSBhIG5vcm1hdGl2ZSBkZXBlbmRlbmN5IG9u IHRoZQ0KPiA+IGNvbXBhbmlvbiBkcmFmdCBjcmVhdGluZyB0aGUgcmVnaXN0cnksIHNvIHRoYXQg SVBzZWMtMDkgY2FuIGJlDQo+ID4gYXBwcm92ZWQsIGJ1dCB3aWxsIG5vdCBiZSBwdWJsaXNoZWQg dW50aWwgdGhlIGRyYWZ0IGNyZWF0aW5nIHRoZQ0KPiA+IHJlZ2lzdHJ5IGlzIGFwcHJvdmVkLg0K PiA+DQo+ID4gSXMgdGhhdCBpdD8NCj4gDQo+IFllcy4gIFdlIHdhbnQgSVBzZWMtMDkgdG8gc2F5 IHRoZSByaWdodCB0aGluZyBhYm91dCBPV0FNUCBNb2RlIHZhbHVlcy4NCj4gDQo+IEJyaWFuDQo+ IA0KPiA+DQo+ID4gVG8gdGhlIFdHIC0gaXMgY3JlYXRpbmcgYSByZWdpc3RyeSBPSz8gTGV0J3Mg c3RhcnQgdGhlcmUgLi4uDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiBTcGVuY2VyDQo+ID4N Cg0KVG8gc2F5ICJubyIgdG8gYW4gT1dBTVAgcmVnaXN0cnkgaXMgdG8gc2F5IHRoYXQgdGhlIFdH IGRvZXMNCm5vdCB3YW50IHRvIGV4dGVuZCBPV0FNUC4gVGhlIFdHIGhhcyBhZ3JlZWQgb24gYSBu ZXcgZmVhdHVyZQ0KYXBwbGljYWJsZSB0byBPV0FNUCwgYW5kIHRoZSBzY29wZSBvZiB0aGUgSVBz ZWMgZHJhZnQgaW5kaWNhdGVzIHRoZQ0KbmVlZCBmb3IgdGhlIG5ldyByZWdpc3RyeSB0byBhbGxv dyB0aGUgZmVhdHVyZSB0byBiZSB1c2VkDQppbiBhIHN0YW5kYXJkIHdheS4gIFNvLCB0aGUgZG9j dW1lbnRlZCBXRyBjb25zZW5zdXMgaXMgdmVyeSBjbG9zZQ0KdG8gInllcywgd2UgbmVlZCBhIHJl Z2lzdHJ5IiwgYW5kIGl0J3Mgc2ltcGxlIHRvIGFzayBleHBsaWNpdGx5Lg0KDQpJTU8sIFllcywN CkFsDQoNCg0KDQoNCg== From nobody Tue Apr 7 11:29:48 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950231B3A1E; Tue, 7 Apr 2015 11:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aRXdvp7ZxmD; Tue, 7 Apr 2015 11:29:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D491B3A1D; Tue, 7 Apr 2015 11:29:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407182944.23896.50197.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 11:29:44 -0700 Archived-At: Cc: ippm-chairs@ietf.org, ippm@ietf.org Subject: [ippm] Barry Leiba's No Objection on draft-ietf-ippm-ipsec-09: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 18:29:46 -0000 Barry Leiba has entered the following ballot position for draft-ietf-ippm-ipsec-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General: the "implementations compatible with this specification" stuff is really awkward and unnecessary. It would be better if it were changed to "implementations of this method" (and similar phrasing, such as "clients implementing this method") throughout the document. But this is non-blocking, and there's no reason to discuss it. I urge you to consider the change, but please do with that urging as you think best. -- Section 3 -- This document reserves from the TWAMP-Modes registry the Mode value IKEv2Derived which is equal to 128 (i.e. bit set in position 7) and MUST be used by TWAMP implementations compatible with this specification. Pete Resnick has left the IESG in body only, but not in spirit. I think what you mean here is that you signal that you're using this method by setting IKEv2Derived. Is that correct? Assuming so, this would be more clearly and simply said in a way such as this (definitely without any 2119 words, which aren't appropriate for that): NEW TWAMP implementations signal the use of this method by setting IKEv2Derived (see Section 7). END Please leave the details of the registry, and which bit was assigned, to the IANA Considerations section, where that stuff belongs. The reference to Section 7 makes it easy to find. -- Section 5.2 -- As in Section 3, it's better just to refer to IKEv2Derived, and not to talk about the registration details here. So: OLD The Modes field in Figure 2 will need to allow for support of key derivation as discussed in Section 5.1. As such, the Modes value extension MUST be supported by implementations compatible with this document, indicating support for deriving the shared key from the IKEv2 SA. The new Modes value indicating support for this specification is IKEv2Derived and is equal to 128 (i.e. bit set in position 7). Clearly, an implementation compatible with this specification MUST support the authenticated, encrypted and mixed modes as per [RFC4656][RFC5357][RFC5618]. NEW The Modes field in Figure 2 will need to allow for support of key derivation as discussed in Section 5.1. Therefore, when this method is used, the Modes value extension MUST be supported. Support for deriving the shared key from the IKEv2 SA is indicated by setting IKEv2Derived (see Section 7). The authenticated, encrypted and mixed modes (see [RFC4656][RFC5357][RFC5618]) MUST also be supported. END From nobody Tue Apr 7 22:26:30 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA74E1A9300; Tue, 7 Apr 2015 14:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-nTDB8xcIQA; Tue, 7 Apr 2015 14:59:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2974A1A92FC; Tue, 7 Apr 2015 14:59:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150407215944.10583.95929.idtracker@ietfa.amsl.com> Date: Tue, 07 Apr 2015 14:59:44 -0700 Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 22:26:29 -0700 Cc: ippm-chairs@ietf.org, ippm@ietf.org Subject: [ippm] Ben Campbell's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS and COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 21:59:45 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ippm-ipsec-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In the last paragraph, the text indicates that if the IKEv2 SA is rekeyed or deleted, O/TWAMP can continue to use the same shared secret. The language seems to make such a continuance optional. Does that cause an interoperability problem if the endpoints don't agree on the strategy? If so, this may need a 2119 MUST (or possibly SHOULD). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1, paragraph 4: This paragraph casts the decision whether to send O/TWAMP inside or outside of an IPSec tunnel as a question of how you want to secure the O/TWAMP packets. It seems to me that this is really more a matter of what you want to measure, given that the tunneled data and non-tunneled data may have different performance capabilities. Sentence starting with "In this case...": The antecedent of "this" is unclear. Section 1, 2nd to last paragraph: I assume the last sentence means that IKEv2 derived keys SHOULD be used instead of shared secrets when otherwise using IKEv2. That seems to add a normative requirement to OWAMP and TWAMP in general, in which case this doc should be listed as updating those. Section 3: I agree with Brian's DISCUSS. Section 4.1: Please expand HMAC on first mention. Section 5.1: "SK_d MUST be computed as per [ref]" :That doesn't need 2119 language. "string "IPPM" comprises four ASCII characters ": This is oddly constructed. Is this intended to observe that IPPM has 4 letters? Section 5.2, paragraph after Figure 2: "Clearly, an implementation .... MUST ..." It is not as clear to me. Why does the use of IKEv2 create a stronger requirement to support all 3 protection modes? Section 5.3:, first paragraph: "The Set-Up-Response Message should be updated": Do you mean to say it _is_ updated? Paragraph after figure 3: s/ "can uniquely identify" / "uniquely identifies" 5.4, last sentence: The sentence is confusing. Do you mean to say that O/TWAMP SHOULD be configured to use the tunnel? From nobody Wed Apr 8 02:27:54 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1291B2E7B for ; Wed, 8 Apr 2015 02:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlStGXEOXptE for ; Wed, 8 Apr 2015 02:27:51 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9D21B2E78 for ; Wed, 8 Apr 2015 02:27:44 -0700 (PDT) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t3890On3029517; Wed, 8 Apr 2015 02:27:40 -0700 Received: from brmwp-exchub02.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1tn0eeg5q9-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Apr 2015 02:27:39 -0700 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 8 Apr 2015 03:27:38 -0600 Received: from [172.27.236.49] (172.27.236.49) by imapeu.brocade.com (172.29.18.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 8 Apr 2015 11:27:37 +0200 Message-ID: <5524F488.2060409@brocade.com> Date: Wed, 8 Apr 2015 10:27:36 +0100 From: Robert Shearman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Gregory Mirsky , "draft-elteto-ippm-twamp-mib@tools.ietf.org" References: <551D4F11.3050702@brocade.com> <7347100B5761DC41A166AC17F22DF1121B93F3EB@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B93F3EB@eusaamb103.ericsson.se> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-08_03:2015-04-07,2015-04-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504080076 Archived-At: Cc: "ippm@ietf.org" Subject: Re: [ippm] Mail regarding draft-elteto-ippm-twamp-mib X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2015 09:27:52 -0000 Hi Greg, Thanks for your quick reply. I'm not sure how much help these comments will be in the development of the YANG model (which I intend to provide some feedback on separately), but here they are anyway. Editorial: ippmPDVMetricsGroup OBJECT-GROUP OBJECTS { pmForwardJitter, pmForwardJitterMaximum, pmReverseJitter, pmReverseJitterMaximum } STATUS current DESCRIPTION "Collection of one-way delay variation (jitter) metrics." ::= { twampGroups 5 } ippmReoMetricsGroup OBJECT-GROUP OBJECTS { pmForwardReordering, pmReverseReordering } STATUS current DESCRIPTION "Collection of one-way test packet re-order metrics." ::= { twampGroups 5 } The same oid is allocated for two objects. This can be resolved simply by bumping up the oid for ippmReoMetricsGroup and all subsequent members of twampGroups. Editorial: twampTest OBJECT IDENTIFIER ::= { twamp 2 } Since twampTest really provides a representation of the Server and Session-Reflector roles of RFC5357, it would perhaps have been better named twampServer. General: There is no way to configure more than one test session per control session via the controller, which is allowable by the protocol and potentially has good use cases. Similarly, on the server side, the ability to group the test sessions by the control session they belong to would be useful, along with providing access to properties of the control session, such as the far-end IP address and far-end TCP port. Thanks, Rob On 03/04/15 05:22, Gregory Mirsky wrote: > Hi Rob, > many thanks for your interest and kind consideration of our work. It is true that after IESG statement on development of new R/W MIBs at IETF we've decided to stop this work. > But I think it will benefit not only authors but the IPPM WG if you could share your comments and suggestions that would help in work on TWAMP and TWAMP-Light YANG models. > > Regards, > Greg > > -----Original Message----- > From: Robert Shearman [mailto:rshearma@brocade.com] > Sent: Thursday, April 02, 2015 7:16 AM > To: draft-elteto-ippm-twamp-mib@tools.ietf.org > Cc: ippm@ietf.org > Subject: Mail regarding draft-elteto-ippm-twamp-mib > > Dear authors, > > Thanks for your work on this MIB. > > I have a couple of comments/questions on the draft. However, in light of the recent publication of draft-cmzrjp-ippm-twamp-yang and its statement about progress on draft-elteto-ippm-twamp-mib being stalled, is it worth me articulating those comments? In other words, will there be any further updates to draft-elteto-ippm-twamp-mib? > > Thanks, > Rob > From nobody Wed Apr 8 08:41:01 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E17D1B3284; Wed, 8 Apr 2015 08:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqLa6jd2yhNz; Wed, 8 Apr 2015 08:40:55 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CB01B3281; Wed, 8 Apr 2015 08:40:54 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so70142019lbb.0; Wed, 08 Apr 2015 08:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AeFzMsKP3Rr8iVHdXLTyjWw9xt12bogjwS+/W+5kVK8=; b=xtlpbKV6OuVsWX2JxdyapoWURPOphmFQXQPu7TYo/Oubmbw+ddJkBuSJKgb+6nhnYG 5/RME8kOK5mzgLDHsFjjEDmEBs8yoRv3alzxO3pie/f2tHf3cIFEsHkHOZQKtKN0dlNd xv0Taad97s9XN6TNWH5nKfwa45j/E55lWrHd+OgDuvtFSOxHwtGt3ixsAEwXVMuNnPsw pjMYJ+Wt5GPdR4xei8O2Dtl5GbgxslQ4xWz4qyS4L6J2Co0ua0MoYC+6PMUylW4RsKjV KipGMB3kIkP1Ly2267Wuk4xS4s5F9MCL/1qiwP9IN7mSDQD/EWF55wh1QvLbTE4p0ZYm td1Q== MIME-Version: 1.0 X-Received: by 10.152.1.194 with SMTP id 2mr118186lao.38.1428507653219; Wed, 08 Apr 2015 08:40:53 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Wed, 8 Apr 2015 08:40:53 -0700 (PDT) In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D8BA78AC6@NJFPSRVEXG0.research.att.com> References: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78987@NJFPSRVEXG0.research.att.com> <5522BC93.3020003@innovationslab.net> <5523FA96.9060700@innovationslab.net> <4AF73AA205019A4C8A1DDD32C034631D8BA78AC6@NJFPSRVEXG0.research.att.com> Date: Wed, 8 Apr 2015 10:40:53 -0500 Message-ID: From: Spencer Dawkins at IETF To: "MORTON, ALFRED C (AL)" Content-Type: multipart/alternative; boundary=089e013c6bcc3aaa3f0513385bb6 Archived-At: Cc: "ippm-chairs@ietf.org" , The IESG , "ippm@ietf.org" Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2015 15:40:57 -0000 --089e013c6bcc3aaa3f0513385bb6 Content-Type: text/plain; charset=UTF-8 Hi, Al, On Tue, Apr 7, 2015 at 11:45 AM, MORTON, ALFRED C (AL) wrote: > > > > -----Original Message----- > > From: Brian Haberman [mailto:brian@innovationslab.net] > > Sent: Tuesday, April 07, 2015 11:41 AM > > To: Spencer Dawkins at IETF > > Cc: MORTON, ALFRED C (AL); The IESG; ippm-chairs@ietf.org; ippm@ietf.org > > Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec- > > 09: (with DISCUSS) > > > > Hi Spencer, > > > ... > > > > > > I'm happy to give the WG a moment to chime in, but just to make sure I > > > understand your point, it's to create a normative dependency on the > > > companion draft creating the registry, so that IPsec-09 can be > > > approved, but will not be published until the draft creating the > > > registry is approved. > > > > > > Is that it? > > > > Yes. We want IPsec-09 to say the right thing about OWAMP Mode values. > > > > Brian > > > > > > > > To the WG - is creating a registry OK? Let's start there ... > > > > > > Thanks, > > > > > > Spencer > > > > > To say "no" to an OWAMP registry is to say that the WG does > not want to extend OWAMP. The WG has agreed on a new feature > applicable to OWAMP, and the scope of the IPsec draft indicates the > need for the new registry to allow the feature to be used > in a standard way. So, the documented WG consensus is very close > to "yes, we need a registry", and it's simple to ask explicitly. > So, what I was asking unclearly, was if creating a registry NOW is OK with the working group ... Brian (Trammell) and Bill, If IPPM is headed this direction, my suggestion is - Al makes the IPsec draft normatively dependent on http://tools.ietf.org/html/draft-morton-ippm-owamp-registry-00. That could reasonably clear Brian Haberman's Discuss (or not, do the right thing). - The chairs do whatever IPPM normal practice is, to adopt the registry draft as a working group item, determine that IPPM has consensus for the draft, and request publication on the registry draft. - The IPsec draft needs four more positions, so I'm not seeing a strong reason to yank it off this week's telechat agenda. It can sit in REF-HOLD until the registry draft is ready to publish. That will slow the IPsec draft down, but if this text belongs in the registry draft and not in the IPec draft, that's what needs to happen, I believe. Does that make sense? Thanks, Spencer --089e013c6bcc3aaa3f0513385bb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Al,

On Tue, Apr 7, 2015 at 11:45 AM, MORTON, ALFRED C (AL) <acmorton@att= .com> wrote:


> -----Original Message-----
> From: Brian Haberman [mailto:brian@innovationslab.net]
> Sent: Tuesday, April 07, 2015 11:41 AM
> To: Spencer Dawkins at IETF
> Cc: MORTON, ALFRED C (AL); The IESG; ippm-chairs@ietf.org; ippm@ietf= .org
> Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ip= sec-
> 09: (with DISCUSS)
>
> Hi Spencer,
>
...
> >
> > I'm happy to give the WG a moment to chime in, but just to ma= ke sure I
> > understand your point, it's to create a normative dependency = on the
> > companion draft creating the registry, so that IPsec-09 can be > > approved, but will not be published until the draft creating the<= br> > > registry is approved.
> >
> > Is that it?
>
> Yes.=C2=A0 We want IPsec-09 to say the right thing about OWAMP Mode va= lues.
>
> Brian
>
> >
> > To the WG - is creating a registry OK? Let's start there ...<= br> > >
> > Thanks,
> >
> > Spencer
> >

To say "no" to an OWAMP registry is to say that the WG doe= s
not want to extend OWAMP. The WG has agreed on a new feature
applicable to OWAMP, and the scope of the IPsec draft indicates the
need for the new registry to allow the feature to be used
in a standard way.=C2=A0 So, the documented WG consensus is very close
to "yes, we need a registry", and it's simple to ask explicit= ly.

So, what I was asking unclearly, wa= s if creating a registry NOW is OK with the working group ...
Brian (Trammell) and Bill,=C2=A0

If IP= PM is headed this direction, my suggestion is=C2=A0

- Al makes the IPsec draft normatively dependent on http://tools.ietf.org= /html/draft-morton-ippm-owamp-registry-00.=C2=A0 That could reasonably = clear Brian Haberman's Discuss (or not, do the right thing).
=
- The chairs do whatever IPPM normal practice is, to adopt t= he registry draft as a working group item, determine that IPPM has consensu= s for the draft, and request publication on the registry draft.
<= br>
- The IPsec draft needs four more positions, so I'm not s= eeing a strong reason to yank it off this week's telechat agenda. It ca= n sit in REF-HOLD until the registry draft is ready to publish.
<= br>
That will slow the IPsec draft down, but if this text belongs= in the registry draft and not in the IPec draft, that's what needs to = happen, I believe.

Does that make sense?

Thanks,

Spencer
--089e013c6bcc3aaa3f0513385bb6-- From nobody Wed Apr 8 09:34:34 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627FB1A8A48; Wed, 8 Apr 2015 09:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_bVA7ozj8CE; Wed, 8 Apr 2015 09:34:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0162B1A8A3E; Wed, 8 Apr 2015 09:34:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408163432.11134.87121.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 09:34:32 -0700 Archived-At: Cc: ippm-chairs@ietf.org, ippm@ietf.org Subject: [ippm] Stephen Farrell's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS and COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 16:34:33 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ippm-ipsec-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Are O/TWAMP vulnerable to reflection attacks with this scheme? If so that's not good. Sorry that I didn't manage to figure that out in the time available but I'm hoping you can just tell me the answer quickly:-) If it's not vulnerable, that's great though it might be worth making that clearer. If it is, then that seems like a bad plan about which we ought chat. The usual solution would be to derive different keys for each direction of use, and just say to use those appropriately. And even if O/TWAMP are thusly vulnerable with a PSK, it'd be fine, and quite possible to fix that here now we're doing better key mgmt. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Since you're touching on the key managment code, I'd have loved to see you also update the O/TWAMP crypto itself to e.g. use an AEAD cipher rather than AES-CBC. Did the WG consider that? (I assume it's too late now, but I'm not clear from the write-up if this is implemented or not, so I guess there's a small chance that the WG may want to update more than just the key mgmt.) From nobody Wed Apr 8 09:57:44 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8D31B3460; Wed, 8 Apr 2015 09:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjW6zjXjuZl5; Wed, 8 Apr 2015 09:57:42 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 47F371B3474; Wed, 8 Apr 2015 09:57:42 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id A3CC212134C; Wed, 8 Apr 2015 13:15:37 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id 713DEE3570; Wed, 8 Apr 2015 12:57:20 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Wed, 8 Apr 2015 12:57:41 -0400 From: "MORTON, ALFRED C (AL)" To: Stephen Farrell , The IESG Date: Wed, 8 Apr 2015 12:57:40 -0400 Thread-Topic: [ippm] Stephen Farrell's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS and COMMENT) Thread-Index: AdByGfJdthqTyd8nSsG5rqh/0dnZnwAANvNA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D016088461E@NJFPSRVEXG0.research.att.com> References: <20150408163432.11134.87121.idtracker@ietfa.amsl.com> In-Reply-To: <20150408163432.11134.87121.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ippm-chairs@ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Stephen Farrell's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS and COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2015 16:57:43 -0000 Hi Stephen,=20 a reply to your comment from a non-author--*wamp-watcher below, > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Wednesday, April 08, 2015 12:35 PM ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > Since you're touching on the key managment code, I'd have loved to see > you also update the O/TWAMP crypto itself to e.g. > use an AEAD cipher rather than AES-CBC. Did the WG consider that? (I > assume it's too late now, but I'm not clear from the write-up if this is > implemented or not, so I guess there's a small chance that the WG may > want to update more than just the key mgmt.) >=20 The IPsec feature is an optional capability, and that's the scope limit of the draft, so it falls far short of replacing the current crypto features. Way back in , I investigated using a "more conve= ntional" crypto for TWAMP (at least for the Control connection) and asked whether the WG was interested - no takers. Pasi Eronen (SEC AD at the time) had encouraged the investigation/question2= wg=20 following the IESG review/approval of the TWAMP spec. At some future time, the answer might be different. Al From nobody Wed Apr 8 10:09:52 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52C1B349D for ; Wed, 8 Apr 2015 10:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt62bdaDyNjK for ; Wed, 8 Apr 2015 10:09:48 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047631B3499 for ; Wed, 8 Apr 2015 10:09:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6083F206CA for ; Wed, 8 Apr 2015 13:09:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 08 Apr 2015 13:09:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=hVHBB/yjIxwYRwjOuvUxquAAukM=; b=XSt5h gb8ydUnBYqMgbEbUTxbhGFD59D1sipd7+vjKc3E21QvBcw2Vfas8T7sA4//5rtTg +Q0GgVevcfhjTUNh6izv+oNQ3J/amY/qwF4m1LEqDAh9CFsB1gqOjOzKwOWZOoEs yUl738NOXWuflHEPAT8F96jopMUbgUZCIGH2qw= X-Sasl-enc: 4j5nbeZm5hqrhJv0lo28JUP0EqoAQb4U+JPd8ctumpD3 1428512987 Received: from eng-6-66.aa.arbor.net (unknown [216.130.192.3]) by mail.messagingengine.com (Postfix) with ESMTPA id DD6ED6800DE; Wed, 8 Apr 2015 13:09:46 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7129C175-FAE9-4472-826E-52883C8DBC4D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Bill Cerveny In-Reply-To: Date: Wed, 8 Apr 2015 13:09:46 -0400 Message-Id: References: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78987@NJFPSRVEXG0.research.att.com> <5522BC93.3020003@innovationslab.net> <5523FA96.9060700@innovationslab.net> <4AF73AA205019A4C8A1DDD32C034631D8BA78AC6@NJFPSRVEXG0.research.att.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ippm-chairs@ietf.org" , "ALFRED C \(AL\) MORTON" , "ippm@ietf.org" , The IESG Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2015 17:09:50 -0000 --Apple-Mail=_7129C175-FAE9-4472-826E-52883C8DBC4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Spencer, In trying to provide an informed response, I did some really brief = research. I looked at RFC 5618, "Mixed Security Mode for the Two-Way = Active Measurement Protocol (TWAMP)=E2=80=9D. This document included the = IANA text to create a TWAMP registry. However, there were only 3 small = sections defining the TWAMP registry. My spin on this is that, all things considered equal, since it is likely = that there would be consumers of a OWAMP registry other than ipsec, = having a separate OWAMP registry document would keep the ipsec document = more concise as well as make an owamp registry document concise. A = downside is how long this might slow draft-ietf-ippm-ipsec and what = impacts slowing the draft would have, but I=E2=80=99m hoping this = wouldn=E2=80=99t be an issue. So, Spencer, what you propose makes sense in my opinion. Finally, I=E2=80=99m interested in Brian Trammell=E2=80=99s concurrence = (or not). Thanks, Bill Cerveny > On Apr 8, 2015, at 11:40 AM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Al, >=20 > On Tue, Apr 7, 2015 at 11:45 AM, MORTON, ALFRED C (AL) = > wrote: >=20 >=20 > > -----Original Message----- > > From: Brian Haberman [mailto:brian@innovationslab.net = ] > > Sent: Tuesday, April 07, 2015 11:41 AM > > To: Spencer Dawkins at IETF > > Cc: MORTON, ALFRED C (AL); The IESG; ippm-chairs@ietf.org = ; ippm@ietf.org > > Subject: Re: [ippm] Brian Haberman's Discuss on = draft-ietf-ippm-ipsec- > > 09: (with DISCUSS) > > > > Hi Spencer, > > > ... > > > > > > I'm happy to give the WG a moment to chime in, but just to make = sure I > > > understand your point, it's to create a normative dependency on = the > > > companion draft creating the registry, so that IPsec-09 can be > > > approved, but will not be published until the draft creating the > > > registry is approved. > > > > > > Is that it? > > > > Yes. We want IPsec-09 to say the right thing about OWAMP Mode = values. > > > > Brian > > > > > > > > To the WG - is creating a registry OK? Let's start there ... > > > > > > Thanks, > > > > > > Spencer > > > >=20 > To say "no" to an OWAMP registry is to say that the WG does > not want to extend OWAMP. The WG has agreed on a new feature > applicable to OWAMP, and the scope of the IPsec draft indicates the > need for the new registry to allow the feature to be used > in a standard way. So, the documented WG consensus is very close > to "yes, we need a registry", and it's simple to ask explicitly. >=20 > So, what I was asking unclearly, was if creating a registry NOW is OK = with the working group ... >=20 > Brian (Trammell) and Bill,=20 >=20 > If IPPM is headed this direction, my suggestion is=20 >=20 > - Al makes the IPsec draft normatively dependent on = http://tools.ietf.org/html/draft-morton-ippm-owamp-registry-00 = . That = could reasonably clear Brian Haberman's Discuss (or not, do the right = thing). >=20 > - The chairs do whatever IPPM normal practice is, to adopt the = registry draft as a working group item, determine that IPPM has = consensus for the draft, and request publication on the registry draft. >=20 > - The IPsec draft needs four more positions, so I'm not seeing a = strong reason to yank it off this week's telechat agenda. It can sit in = REF-HOLD until the registry draft is ready to publish. >=20 > That will slow the IPsec draft down, but if this text belongs in the = registry draft and not in the IPec draft, that's what needs to happen, I = believe. >=20 > Does that make sense? >=20 > Thanks, >=20 > Spencer > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_7129C175-FAE9-4472-826E-52883C8DBC4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Spencer,

In trying to provide an informed response, I did some really = brief research. I looked at RFC 5618, "Mixed Security Mode for the = Two-Way Active Measurement Protocol (TWAMP)=E2=80=9D. This document = included the IANA text to create a TWAMP registry. However, there were = only 3 small sections defining the TWAMP registry.

My spin on this is that, = all things considered equal, since it is likely that there would be = consumers of a OWAMP registry other than ipsec, having a separate OWAMP = registry document would keep the ipsec document more concise as well as = make an owamp registry document concise. A downside is how long this = might slow draft-ietf-ippm-ipsec and what impacts slowing the draft = would have, but I=E2=80=99m hoping this wouldn=E2=80=99t be an = issue.

So, = Spencer, what you propose makes sense in my opinion.

Finally, I=E2=80=99m = interested in Brian Trammell=E2=80=99s concurrence (or not).

Thanks,

Bill Cerveny

On Apr 8, 2015, at 11:40 AM, = Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Al,

On Tue, Apr 7, 2015 at 11:45 AM, MORTON, ALFRED C = (AL) <acmorton@att.com> wrote:


> -----Original Message-----
> From: Brian Haberman [mailto:brian@innovationslab.net]
> Sent: Tuesday, April 07, 2015 11:41 AM
> To: Spencer Dawkins at IETF
> Cc: MORTON, ALFRED C (AL); The IESG; ippm-chairs@ietf.org; = ippm@ietf.org
> Subject: Re: [ippm] Brian Haberman's Discuss on = draft-ietf-ippm-ipsec-
> 09: (with DISCUSS)
>
> Hi Spencer,
>
...
> >
> > I'm happy to give the WG a moment to chime in, but just to = make sure I
> > understand your point, it's to create a normative dependency = on the
> > companion draft creating the registry, so that IPsec-09 can = be
> > approved, but will not be published until the draft creating = the
> > registry is approved.
> >
> > Is that it?
>
> Yes.  We want IPsec-09 to say the right thing about OWAMP Mode = values.
>
> Brian
>
> >
> > To the WG - is creating a registry OK? Let's start there = ...
> >
> > Thanks,
> >
> > Spencer
> >

To say "no" to an OWAMP registry is to say that the WG does
not want to extend OWAMP. The WG has agreed on a new feature
applicable to OWAMP, and the scope of the IPsec draft indicates the
need for the new registry to allow the feature to be used
in a standard way.  So, the documented WG consensus is very = close
to "yes, we need a registry", and it's simple to ask explicitly.

So, what I was asking unclearly, was if creating a registry = NOW is OK with the working group ...

Brian (Trammell) and = Bill, 

If = IPPM is headed this direction, my suggestion is 

- Al makes the IPsec = draft normatively dependent on http://tools.ietf.org/html/draft-morton-ippm-owamp-registry-00<= /a>.  That could reasonably clear Brian Haberman's Discuss (or not, = do the right thing).

- The chairs do whatever IPPM normal practice is, to adopt = the registry draft as a working group item, determine that IPPM has = consensus for the draft, and request publication on the registry = draft.

- The = IPsec draft needs four more positions, so I'm not seeing a strong reason = to yank it off this week's telechat agenda. It can sit in REF-HOLD until = the registry draft is ready to publish.

That will slow the IPsec draft down, = but if this text belongs in the registry draft and not in the IPec = draft, that's what needs to happen, I believe.

Does that make = sense?

Thanks,

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

= --Apple-Mail=_7129C175-FAE9-4472-826E-52883C8DBC4D-- From nobody Wed Apr 8 10:20:12 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F841B34BD; Wed, 8 Apr 2015 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2A0JZ9cqudR; Wed, 8 Apr 2015 10:20:05 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7947E1B34B9; Wed, 8 Apr 2015 10:20:05 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 413B0121301; Wed, 8 Apr 2015 13:38:01 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-azure.research.att.com (Postfix) with ESMTP id 32A02E355C; Wed, 8 Apr 2015 13:20:02 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Wed, 8 Apr 2015 13:20:02 -0400 From: "MORTON, ALFRED C (AL)" To: Bill Cerveny , Spencer Dawkins Date: Wed, 8 Apr 2015 13:20:00 -0400 Thread-Topic: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) Thread-Index: AdByHtphGF0qfrkORtuaIsQeXCTlOQAAIWsA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D016088462C@NJFPSRVEXG0.research.att.com> References: <20150406125432.16951.24372.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78920@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D8BA78987@NJFPSRVEXG0.research.att.com> <5522BC93.3020003@innovationslab.net> <5523FA96.9060700@innovationslab.net> <4AF73AA205019A4C8A1DDD32C034631D8BA78AC6@NJFPSRVEXG0.research.att.com> In-Reply-To: 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_4AF73AA205019A4C8A1DDD32C034631D016088462CNJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Cc: "ippm-chairs@ietf.org" , The IESG , "ippm@ietf.org" Subject: Re: [ippm] Brian Haberman's Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2015 17:20:09 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D016088462CNJFPSRVEXG0re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmlsbCwNClJGQyA1NjE4IElBTkEgc2VjdGlvbiBpcyBxdWl0ZSBzaG9ydCBiZWNhdXNlIHdl IG9ubHkNCmFza2VkIHRvIGVzdGFibGlzaCB0aGUgVFdBTVAtTW9kZXMgUmVnaXN0cnkuIExhdGVy LCB3ZQ0KbmVlZGVkIGEgQ29tbWFuZCBOdW1iZXIgUmVnaXN0cnkgdG9vLg0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtbW9ydG9uLWlwcG0tb3dhbXAtcmVnaXN0cnktMDANCmRvZXMg Ym90aCBmb3IgT1dBTVAuDQoNCkhpIFNwZW5jZXIsDQp5b3Ugd3JvdGU6DQotIEFsIG1ha2VzIHRo ZSBJUHNlYyBkcmFmdCBub3JtYXRpdmVseSBkZXBlbmRlbnQgb24gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbW9ydG9uLWlwcG0tb3dhbXAtcmVnaXN0cnktMDAuDQpUaGF0IGNvdWxk IHJlYXNvbmFibHkgY2xlYXIgQnJpYW4gSGFiZXJtYW4ncyBEaXNjdXNzIChvciBub3QsIGRvIHRo ZSByaWdodCB0aGluZykuDQoNCkkgdGhpbmsgdGhhdOKAmXMgdGhlIHJpZ2h0IHRoaW5nLCBidXQg SSBzaG91bGQgaGF2ZSBjbGFyaWZpZWQgdGhhdA0KSeKAmW0gbm90IGEgY28tYXV0aG9yIG9mIHRo ZSBUV0FNUC1JUFNFQyBkcmFmdCAoYW5kIHRoZXnigJlsbCBoYXZlIHRvDQplZGl0IGlmIHRoZXkg YWdyZWUpLiBJIHdhcyBqdXN0IHRyeWluZyB0byBoZWxwLg0KDQpBbA0KDQoNCkZyb206IEJpbGwg Q2VydmVueSBbbWFpbHRvOmlldGZAd2pjZXJ2ZW55LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXBy aWwgMDgsIDIwMTUgMToxMCBQTQ0KVG86IFNwZW5jZXIgRGF3a2lucw0KQ2M6IE1PUlRPTiwgQUxG UkVEIEMgKEFMKTsgaXBwbS1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHOyBpcHBtQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW2lwcG1dIEJyaWFuIEhhYmVybWFuJ3MgRGlzY3VzcyBvbiBkcmFmdC1p ZXRmLWlwcG0taXBzZWMtMDk6ICh3aXRoIERJU0NVU1MpDQoNCkhpIFNwZW5jZXIsDQoNCkluIHRy eWluZyB0byBwcm92aWRlIGFuIGluZm9ybWVkIHJlc3BvbnNlLCBJIGRpZCBzb21lIHJlYWxseSBi cmllZiByZXNlYXJjaC4gSSBsb29rZWQgYXQgUkZDIDU2MTgsICJNaXhlZCBTZWN1cml0eSBNb2Rl IGZvciB0aGUgVHdvLVdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgKFRXQU1QKeKAnS4g VGhpcyBkb2N1bWVudCBpbmNsdWRlZCB0aGUgSUFOQSB0ZXh0IHRvIGNyZWF0ZSBhIFRXQU1QIHJl Z2lzdHJ5LiBIb3dldmVyLCB0aGVyZSB3ZXJlIG9ubHkgMyBzbWFsbCBzZWN0aW9ucyBkZWZpbmlu ZyB0aGUgVFdBTVAgcmVnaXN0cnkuDQoNCk15IHNwaW4gb24gdGhpcyBpcyB0aGF0LCBhbGwgdGhp bmdzIGNvbnNpZGVyZWQgZXF1YWwsIHNpbmNlIGl0IGlzIGxpa2VseSB0aGF0IHRoZXJlIHdvdWxk IGJlIGNvbnN1bWVycyBvZiBhIE9XQU1QIHJlZ2lzdHJ5IG90aGVyIHRoYW4gaXBzZWMsIGhhdmlu ZyBhIHNlcGFyYXRlIE9XQU1QIHJlZ2lzdHJ5IGRvY3VtZW50IHdvdWxkIGtlZXAgdGhlIGlwc2Vj IGRvY3VtZW50IG1vcmUgY29uY2lzZSBhcyB3ZWxsIGFzIG1ha2UgYW4gb3dhbXAgcmVnaXN0cnkg ZG9jdW1lbnQgY29uY2lzZS4gQSBkb3duc2lkZSBpcyBob3cgbG9uZyB0aGlzIG1pZ2h0IHNsb3cg ZHJhZnQtaWV0Zi1pcHBtLWlwc2VjIGFuZCB3aGF0IGltcGFjdHMgc2xvd2luZyB0aGUgZHJhZnQg d291bGQgaGF2ZSwgYnV0IEnigJltIGhvcGluZyB0aGlzIHdvdWxkbuKAmXQgYmUgYW4gaXNzdWUu DQoNClNvLCBTcGVuY2VyLCB3aGF0IHlvdSBwcm9wb3NlIG1ha2VzIHNlbnNlIGluIG15IG9waW5p b24uDQoNCkZpbmFsbHksIEnigJltIGludGVyZXN0ZWQgaW4gQnJpYW4gVHJhbW1lbGzigJlzIGNv bmN1cnJlbmNlIChvciBub3QpLg0KDQpUaGFua3MsDQoNCkJpbGwgQ2VydmVueQ0KDQpPbiBBcHIg OCwgMjAxNSwgYXQgMTE6NDAgQU0sIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3 a2lucy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+ PiB3cm90ZToNCg0KSGksIEFsLA0KDQpPbiBUdWUsIEFwciA3LCAyMDE1IGF0IDExOjQ1IEFNLCBN T1JUT04sIEFMRlJFRCBDIChBTCkgPGFjbW9ydG9uQGF0dC5jb208bWFpbHRvOmFjbW9ydG9uQGF0 dC5jb20+PiB3cm90ZToNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IEJyaWFuIEhhYmVybWFuIFttYWlsdG86YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0PG1haWx0bzpi cmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQ+XQ0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAwNywgMjAx NSAxMTo0MSBBTQ0KPiBUbzogU3BlbmNlciBEYXdraW5zIGF0IElFVEYNCj4gQ2M6IE1PUlRPTiwg QUxGUkVEIEMgKEFMKTsgVGhlIElFU0c7IGlwcG0tY2hhaXJzQGlldGYub3JnPG1haWx0bzppcHBt LWNoYWlyc0BpZXRmLm9yZz47IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQo+ IFN1YmplY3Q6IFJlOiBbaXBwbV0gQnJpYW4gSGFiZXJtYW4ncyBEaXNjdXNzIG9uIGRyYWZ0LWll dGYtaXBwbS1pcHNlYy0NCj4gMDk6ICh3aXRoIERJU0NVU1MpDQo+DQo+IEhpIFNwZW5jZXIsDQo+ DQouLi4NCj4gPg0KPiA+IEknbSBoYXBweSB0byBnaXZlIHRoZSBXRyBhIG1vbWVudCB0byBjaGlt ZSBpbiwgYnV0IGp1c3QgdG8gbWFrZSBzdXJlIEkNCj4gPiB1bmRlcnN0YW5kIHlvdXIgcG9pbnQs IGl0J3MgdG8gY3JlYXRlIGEgbm9ybWF0aXZlIGRlcGVuZGVuY3kgb24gdGhlDQo+ID4gY29tcGFu aW9uIGRyYWZ0IGNyZWF0aW5nIHRoZSByZWdpc3RyeSwgc28gdGhhdCBJUHNlYy0wOSBjYW4gYmUN Cj4gPiBhcHByb3ZlZCwgYnV0IHdpbGwgbm90IGJlIHB1Ymxpc2hlZCB1bnRpbCB0aGUgZHJhZnQg Y3JlYXRpbmcgdGhlDQo+ID4gcmVnaXN0cnkgaXMgYXBwcm92ZWQuDQo+ID4NCj4gPiBJcyB0aGF0 IGl0Pw0KPg0KPiBZZXMuICBXZSB3YW50IElQc2VjLTA5IHRvIHNheSB0aGUgcmlnaHQgdGhpbmcg YWJvdXQgT1dBTVAgTW9kZSB2YWx1ZXMuDQo+DQo+IEJyaWFuDQo+DQo+ID4NCj4gPiBUbyB0aGUg V0cgLSBpcyBjcmVhdGluZyBhIHJlZ2lzdHJ5IE9LPyBMZXQncyBzdGFydCB0aGVyZSAuLi4NCj4g Pg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+IFNwZW5jZXINCj4gPg0KDQpUbyBzYXkgIm5vIiB0byBh biBPV0FNUCByZWdpc3RyeSBpcyB0byBzYXkgdGhhdCB0aGUgV0cgZG9lcw0Kbm90IHdhbnQgdG8g ZXh0ZW5kIE9XQU1QLiBUaGUgV0cgaGFzIGFncmVlZCBvbiBhIG5ldyBmZWF0dXJlDQphcHBsaWNh YmxlIHRvIE9XQU1QLCBhbmQgdGhlIHNjb3BlIG9mIHRoZSBJUHNlYyBkcmFmdCBpbmRpY2F0ZXMg dGhlDQpuZWVkIGZvciB0aGUgbmV3IHJlZ2lzdHJ5IHRvIGFsbG93IHRoZSBmZWF0dXJlIHRvIGJl IHVzZWQNCmluIGEgc3RhbmRhcmQgd2F5LiAgU28sIHRoZSBkb2N1bWVudGVkIFdHIGNvbnNlbnN1 cyBpcyB2ZXJ5IGNsb3NlDQp0byAieWVzLCB3ZSBuZWVkIGEgcmVnaXN0cnkiLCBhbmQgaXQncyBz aW1wbGUgdG8gYXNrIGV4cGxpY2l0bHkuDQoNClNvLCB3aGF0IEkgd2FzIGFza2luZyB1bmNsZWFy bHksIHdhcyBpZiBjcmVhdGluZyBhIHJlZ2lzdHJ5IE5PVyBpcyBPSyB3aXRoIHRoZSB3b3JraW5n IGdyb3VwIC4uLg0KDQpCcmlhbiAoVHJhbW1lbGwpIGFuZCBCaWxsLA0KDQpJZiBJUFBNIGlzIGhl YWRlZCB0aGlzIGRpcmVjdGlvbiwgbXkgc3VnZ2VzdGlvbiBpcw0KDQotIEFsIG1ha2VzIHRoZSBJ UHNlYyBkcmFmdCBub3JtYXRpdmVseSBkZXBlbmRlbnQgb24gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbW9ydG9uLWlwcG0tb3dhbXAtcmVnaXN0cnktMDAuICBUaGF0IGNvdWxkIHJl YXNvbmFibHkgY2xlYXIgQnJpYW4gSGFiZXJtYW4ncyBEaXNjdXNzIChvciBub3QsIGRvIHRoZSBy aWdodCB0aGluZykuDQoNCi0gVGhlIGNoYWlycyBkbyB3aGF0ZXZlciBJUFBNIG5vcm1hbCBwcmFj dGljZSBpcywgdG8gYWRvcHQgdGhlIHJlZ2lzdHJ5IGRyYWZ0IGFzIGEgd29ya2luZyBncm91cCBp dGVtLCBkZXRlcm1pbmUgdGhhdCBJUFBNIGhhcyBjb25zZW5zdXMgZm9yIHRoZSBkcmFmdCwgYW5k IHJlcXVlc3QgcHVibGljYXRpb24gb24gdGhlIHJlZ2lzdHJ5IGRyYWZ0Lg0KDQotIFRoZSBJUHNl YyBkcmFmdCBuZWVkcyBmb3VyIG1vcmUgcG9zaXRpb25zLCBzbyBJJ20gbm90IHNlZWluZyBhIHN0 cm9uZyByZWFzb24gdG8geWFuayBpdCBvZmYgdGhpcyB3ZWVrJ3MgdGVsZWNoYXQgYWdlbmRhLiBJ dCBjYW4gc2l0IGluIFJFRi1IT0xEIHVudGlsIHRoZSByZWdpc3RyeSBkcmFmdCBpcyByZWFkeSB0 byBwdWJsaXNoLg0KDQpUaGF0IHdpbGwgc2xvdyB0aGUgSVBzZWMgZHJhZnQgZG93biwgYnV0IGlm IHRoaXMgdGV4dCBiZWxvbmdzIGluIHRoZSByZWdpc3RyeSBkcmFmdCBhbmQgbm90IGluIHRoZSBJ UGVjIGRyYWZ0LCB0aGF0J3Mgd2hhdCBuZWVkcyB0byBoYXBwZW4sIEkgYmVsaWV2ZS4NCg0KRG9l cyB0aGF0IG1ha2Ugc2Vuc2U/DQoNClRoYW5rcywNCg0KU3BlbmNlcg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBsaXN0DQppcHBt QGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHBtDQoNCg== --_000_4AF73AA205019A4C8A1DDD32C034631D016088462CNJFPSRVEXG0re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJs dWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz5IaSBCaWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+UkZDIDU2 MTggSUFOQSBzZWN0aW9uIGlzIHF1aXRlIHNob3J0IGJlY2F1c2Ugd2Ugb25seSA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmFza2VkIHRvIGVzdGFibGlzaCB0aGUgVFdB TVAtTW9kZXMgUmVnaXN0cnkuIExhdGVyLCB3ZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPm5lZWRlZCBhIENvbW1hbmQgTnVtYmVyIFJlZ2lzdHJ5IHRvby7CoCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vcnRvbi1pcHBtLW93YW1wLXJlZ2lzdHJ5LTAwIj5odHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb3J0b24taXBwbS1vd2FtcC1yZWdpc3RyeS0w MDwvYT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ZG9lcyBib3RoIGZvciBPV0FN UC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+SGkgU3BlbmNlciw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnlvdSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPi0gQWwgbWFrZXMgdGhlIElQc2VjIGRyYWZ0IG5vcm1hdGl2 ZWx5IGRlcGVuZGVudCBvbiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1tb3J0b24taXBwbS1vd2FtcC1yZWdpc3RyeS0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbW9ydG9uLWlwcG0tb3dhbXAtcmVnaXN0cnktMDA8L2E+LiZuYnNwOyA8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhdCBjb3VsZCByZWFzb25hYmx5IGNsZWFyIEJy aWFuIEhhYmVybWFuJ3MgRGlzY3VzcyAob3Igbm90LCBkbyB0aGUgcmlnaHQgdGhpbmcpLjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPkkgdGhpbmsgdGhhdOKAmXMgdGhlIHJpZ2h0IHRoaW5nLCBidXQg SSBzaG91bGQgaGF2ZSBjbGFyaWZpZWQgdGhhdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPknigJltIG5vdCBhIGNvLWF1dGhvciBvZiB0aGUgVFdBTVAtSVBTRUMgZHJh ZnQgKGFuZCB0aGV54oCZbGwgaGF2ZSB0byA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPmVkaXQgaWYgdGhleSBhZ3JlZSkuIEkgd2FzIGp1c3QgdHJ5aW5nIHRvIGhlbHAu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkFsPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQn PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBCaWxsIENlcnZlbnkgW21haWx0bzppZXRmQHdq Y2VydmVueS5jb21dIDxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAwOCwgMjAxNSAx OjEwIFBNPGJyPjxiPlRvOjwvYj4gU3BlbmNlciBEYXdraW5zPGJyPjxiPkNjOjwvYj4gTU9SVE9O LCBBTEZSRUQgQyAoQUwpOyBpcHBtLWNoYWlyc0BpZXRmLm9yZzsgVGhlIElFU0c7IGlwcG1AaWV0 Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbaXBwbV0gQnJpYW4gSGFiZXJtYW4ncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wOTogKHdpdGggRElTQ1VTUyk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5IaSBTcGVuY2VyLDxvOnA+PC9vOnA+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPkluIHRyeWluZyB0byBwcm92aWRlIGFuIGluZm9ybWVkIHJlc3BvbnNlLCBJ IGRpZCBzb21lIHJlYWxseSBicmllZiByZXNlYXJjaC4gSSBsb29rZWQgYXQgUkZDIDU2MTgsICZx dW90O01peGVkIFNlY3VyaXR5IE1vZGUgZm9yIHRoZSBUd28tV2F5IEFjdGl2ZSBNZWFzdXJlbWVu dCBQcm90b2NvbCAoVFdBTVAp4oCdLiBUaGlzIGRvY3VtZW50IGluY2x1ZGVkIHRoZSBJQU5BIHRl eHQgdG8gY3JlYXRlIGEgVFdBTVAgcmVnaXN0cnkuIEhvd2V2ZXIsIHRoZXJlIHdlcmUgb25seSAz IHNtYWxsIHNlY3Rpb25zIGRlZmluaW5nIHRoZSBUV0FNUCByZWdpc3RyeS48bzpwPjwvbzpwPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5NeSBzcGluIG9uIHRoaXMgaXMgdGhhdCwgYWxsIHRoaW5ncyBj b25zaWRlcmVkIGVxdWFsLCBzaW5jZSBpdCBpcyBsaWtlbHkgdGhhdCB0aGVyZSB3b3VsZCBiZSBj b25zdW1lcnMgb2YgYSBPV0FNUCByZWdpc3RyeSBvdGhlciB0aGFuIGlwc2VjLCBoYXZpbmcgYSBz ZXBhcmF0ZSBPV0FNUCByZWdpc3RyeSBkb2N1bWVudCB3b3VsZCBrZWVwIHRoZSBpcHNlYyBkb2N1 bWVudCBtb3JlIGNvbmNpc2UgYXMgd2VsbCBhcyBtYWtlIGFuIG93YW1wIHJlZ2lzdHJ5IGRvY3Vt ZW50IGNvbmNpc2UuIEEgZG93bnNpZGUgaXMgaG93IGxvbmcgdGhpcyBtaWdodCBzbG93IGRyYWZ0 LWlldGYtaXBwbS1pcHNlYyBhbmQgd2hhdCBpbXBhY3RzIHNsb3dpbmcgdGhlIGRyYWZ0IHdvdWxk IGhhdmUsIGJ1dCBJ4oCZbSBob3BpbmcgdGhpcyB3b3VsZG7igJl0IGJlIGFuIGlzc3VlLjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNvLCBTcGVuY2VyLCB3aGF0IHlvdSBw cm9wb3NlIG1ha2VzIHNlbnNlIGluIG15IG9waW5pb24uPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+RmluYWxseSwgSeKAmW0gaW50ZXJlc3RlZCBpbiBCcmlhbiBUcmFtbWVs bOKAmXMgY29uY3VycmVuY2UgKG9yIG5vdCkuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkJp bGwgQ2VydmVueTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48YmxvY2txdW90ZSBzdHlsZT0nbWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5PbiBBcHIgOCwgMjAxNSwgYXQgMTE6NDAgQU0sIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGICZs dDs8YSBocmVmPSJtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20iPnNwZW5jZXJk YXdraW5zLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+SGksIEFsLDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFR1ZSwgQXBy IDcsIDIwMTUgYXQgMTE6NDUgQU0sIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFjbW9ydG9uQGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj5hY21vcnRvbkBhdHQuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnI+ Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IEJyaWFuIEhhYmVy bWFuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmJyaWFuQGlubm92YXRpb25zbGFiLm5ldCI+YnJp YW5AaW5ub3ZhdGlvbnNsYWIubmV0PC9hPl08YnI+Jmd0OyBTZW50OiBUdWVzZGF5LCBBcHJpbCAw NywgMjAxNSAxMTo0MSBBTTxicj4mZ3Q7IFRvOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURjxicj4m Z3Q7IENjOiBNT1JUT04sIEFMRlJFRCBDIChBTCk7IFRoZSBJRVNHOyA8YSBocmVmPSJtYWlsdG86 aXBwbS1jaGFpcnNAaWV0Zi5vcmciPmlwcG0tY2hhaXJzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmlwcG1AaWV0Zi5vcmciPmlwcG1AaWV0Zi5vcmc8L2E+PGJyPiZndDsgU3ViamVjdDog UmU6IFtpcHBtXSBCcmlhbiBIYWJlcm1hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1pcHBtLWlw c2VjLTxicj4mZ3Q7IDA5OiAod2l0aCBESVNDVVNTKTxicj4mZ3Q7PGJyPiZndDsgSGkgU3BlbmNl ciw8YnI+Jmd0Ozxicj4uLi48YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBJJ20gaGFwcHkgdG8g Z2l2ZSB0aGUgV0cgYSBtb21lbnQgdG8gY2hpbWUgaW4sIGJ1dCBqdXN0IHRvIG1ha2Ugc3VyZSBJ PGJyPiZndDsgJmd0OyB1bmRlcnN0YW5kIHlvdXIgcG9pbnQsIGl0J3MgdG8gY3JlYXRlIGEgbm9y bWF0aXZlIGRlcGVuZGVuY3kgb24gdGhlPGJyPiZndDsgJmd0OyBjb21wYW5pb24gZHJhZnQgY3Jl YXRpbmcgdGhlIHJlZ2lzdHJ5LCBzbyB0aGF0IElQc2VjLTA5IGNhbiBiZTxicj4mZ3Q7ICZndDsg YXBwcm92ZWQsIGJ1dCB3aWxsIG5vdCBiZSBwdWJsaXNoZWQgdW50aWwgdGhlIGRyYWZ0IGNyZWF0 aW5nIHRoZTxicj4mZ3Q7ICZndDsgcmVnaXN0cnkgaXMgYXBwcm92ZWQuPGJyPiZndDsgJmd0Ozxi cj4mZ3Q7ICZndDsgSXMgdGhhdCBpdD88YnI+Jmd0Ozxicj4mZ3Q7IFllcy4mbmJzcDsgV2Ugd2Fu dCBJUHNlYy0wOSB0byBzYXkgdGhlIHJpZ2h0IHRoaW5nIGFib3V0IE9XQU1QIE1vZGUgdmFsdWVz Ljxicj4mZ3Q7PGJyPiZndDsgQnJpYW48YnI+Jmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7 IFRvIHRoZSBXRyAtIGlzIGNyZWF0aW5nIGEgcmVnaXN0cnkgT0s/IExldCdzIHN0YXJ0IHRoZXJl IC4uLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFRoYW5rcyw8YnI+Jmd0OyAmZ3Q7PGJyPiZn dDsgJmd0OyBTcGVuY2VyPGJyPiZndDsgJmd0Ozxicj48YnI+VG8gc2F5ICZxdW90O25vJnF1b3Q7 IHRvIGFuIE9XQU1QIHJlZ2lzdHJ5IGlzIHRvIHNheSB0aGF0IHRoZSBXRyBkb2VzPGJyPm5vdCB3 YW50IHRvIGV4dGVuZCBPV0FNUC4gVGhlIFdHIGhhcyBhZ3JlZWQgb24gYSBuZXcgZmVhdHVyZTxi cj5hcHBsaWNhYmxlIHRvIE9XQU1QLCBhbmQgdGhlIHNjb3BlIG9mIHRoZSBJUHNlYyBkcmFmdCBp bmRpY2F0ZXMgdGhlPGJyPm5lZWQgZm9yIHRoZSBuZXcgcmVnaXN0cnkgdG8gYWxsb3cgdGhlIGZl YXR1cmUgdG8gYmUgdXNlZDxicj5pbiBhIHN0YW5kYXJkIHdheS4mbmJzcDsgU28sIHRoZSBkb2N1 bWVudGVkIFdHIGNvbnNlbnN1cyBpcyB2ZXJ5IGNsb3NlPGJyPnRvICZxdW90O3llcywgd2UgbmVl ZCBhIHJlZ2lzdHJ5JnF1b3Q7LCBhbmQgaXQncyBzaW1wbGUgdG8gYXNrIGV4cGxpY2l0bHkuPG86 cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U28sIHdoYXQgSSB3YXMgYXNraW5nIHVuY2xl YXJseSwgd2FzIGlmIGNyZWF0aW5nIGEgcmVnaXN0cnkgTk9XIGlzIE9LIHdpdGggdGhlIHdvcmtp bmcgZ3JvdXAgLi4uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QnJpYW4g KFRyYW1tZWxsKSBhbmQgQmlsbCwmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5JZiBJUFBNIGlzIGhlYWRlZCB0aGlzIGRpcmVjdGlvbiwgbXkgc3VnZ2VzdGlvbiBp cyZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0gQWwgbWFrZXMg dGhlIElQc2VjIGRyYWZ0IG5vcm1hdGl2ZWx5IGRlcGVuZGVudCBvbiA8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb3J0b24taXBwbS1vd2FtcC1yZWdpc3RyeS0wMCI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW9ydG9uLWlwcG0tb3dhbXAtcmVnaXN0 cnktMDA8L2E+LiZuYnNwOyBUaGF0IGNvdWxkIHJlYXNvbmFibHkgY2xlYXIgQnJpYW4gSGFiZXJt YW4ncyBEaXNjdXNzIChvciBub3QsIGRvIHRoZSByaWdodCB0aGluZykuPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LSBUaGUgY2hhaXJzIGRvIHdoYXRldmVyIElQUE0gbm9y bWFsIHByYWN0aWNlIGlzLCB0byBhZG9wdCB0aGUgcmVnaXN0cnkgZHJhZnQgYXMgYSB3b3JraW5n IGdyb3VwIGl0ZW0sIGRldGVybWluZSB0aGF0IElQUE0gaGFzIGNvbnNlbnN1cyBmb3IgdGhlIGRy YWZ0LCBhbmQgcmVxdWVzdCBwdWJsaWNhdGlvbiBvbiB0aGUgcmVnaXN0cnkgZHJhZnQuPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+LSBUaGUgSVBzZWMgZHJhZnQgbmVlZHMg Zm91ciBtb3JlIHBvc2l0aW9ucywgc28gSSdtIG5vdCBzZWVpbmcgYSBzdHJvbmcgcmVhc29uIHRv IHlhbmsgaXQgb2ZmIHRoaXMgd2VlaydzIHRlbGVjaGF0IGFnZW5kYS4gSXQgY2FuIHNpdCBpbiBS RUYtSE9MRCB1bnRpbCB0aGUgcmVnaXN0cnkgZHJhZnQgaXMgcmVhZHkgdG8gcHVibGlzaC48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGF0IHdpbGwgc2xvdyB0aGUgSVBz ZWMgZHJhZnQgZG93biwgYnV0IGlmIHRoaXMgdGV4dCBiZWxvbmdzIGluIHRoZSByZWdpc3RyeSBk cmFmdCBhbmQgbm90IGluIHRoZSBJUGVjIGRyYWZ0LCB0aGF0J3Mgd2hhdCBuZWVkcyB0byBoYXBw ZW4sIEkgYmVsaWV2ZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PkRvZXMgdGhhdCBtYWtlIHNlbnNlPzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TcGVuY2Vy PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy PmlwcG0gbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj5pcHBt QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwcG0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwv YT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48 L2h0bWw+ --_000_4AF73AA205019A4C8A1DDD32C034631D016088462CNJFPSRVEXG0re_-- From nobody Wed Apr 8 11:49:29 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB551B3467 for ; Wed, 8 Apr 2015 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfq0TUYOhi-Y for ; Wed, 8 Apr 2015 11:49:26 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id A8AC81B3458 for ; Wed, 8 Apr 2015 11:49:26 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 8BB0C121404; Wed, 8 Apr 2015 15:07:22 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-azure.research.att.com (Postfix) with ESMTP id 5119EE355B; Wed, 8 Apr 2015 14:49:23 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Wed, 8 Apr 2015 14:49:23 -0400 From: "MORTON, ALFRED C (AL)" To: Robert Shearman Date: Wed, 8 Apr 2015 14:49:21 -0400 Thread-Topic: [ippm] Mail regarding draft-elteto-ippm-twamp-mib Thread-Index: AdBx+sZFop/olgY8SLWdDmnBPaDt9gAMQLvQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0160884672@NJFPSRVEXG0.research.att.com> References: <551D4F11.3050702@brocade.com> <7347100B5761DC41A166AC17F22DF1121B93F3EB@eusaamb103.ericsson.se> <5524F488.2060409@brocade.com> In-Reply-To: <5524F488.2060409@brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ippm@ietf.org" Subject: Re: [ippm] Mail regarding draft-elteto-ippm-twamp-mib X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2015 18:49:28 -0000 Hi Rob, > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Robert Shearman > Sent: Wednesday, April 08, 2015 5:28 AM > > ... >=20 > General: >=20 > There is no way to configure more than one test session per control > session via the controller, which is allowable by the protocol and > potentially has good use cases. >=20 > Similarly, on the server side, the ability to group the test sessions by > the control session they belong to would be useful, along with providing > access to properties of the control session, such as the far-end IP > address and far-end TCP port. >=20 Your general issues above are features of the draft YANG model,=20 http://tools.ietf.org/html/draft-cmzrjp-ippm-twamp-yang-00.txt just fyi, Al From nobody Thu Apr 9 06:07:48 2015 Return-Path: X-Original-To: expand-draft-ietf-ippm-ipsec.all@virtual.ietf.org Delivered-To: ippm@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0DBC51B2A5A; Wed, 8 Apr 2015 22:04:15 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ippm-ipsec.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ippm-ipsec.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31911B2A37 for ; Wed, 8 Apr 2015 22:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9SyafHI91Qw for ; Wed, 8 Apr 2015 22:04:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EA51B2A4E for ; Wed, 8 Apr 2015 22:03:55 -0700 (PDT) Received: from usevmg21.ericsson.net ([198.24.6.65]:44576) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yg4d6-00017F-CL for draft-ietf-ippm-ipsec.all@tools.ietf.org; Wed, 08 Apr 2015 22:03:54 -0700 X-AuditID: c6180641-f790b6d000004359-e7-5525a57d0702 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 35.8D.17241.D75A5255; Thu, 9 Apr 2015 00:02:38 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 01:03:42 -0400 From: Meral Shirazipour To: "draft-ietf-ippm-ipsec.all@tools.ietf.org" , "gen-art@ietf.org" Thread-Topic: Gen-ART Telechat Call review of draft-ietf-ippm-ipsec-09 Thread-Index: AdBygU5b9XTnxIAGRRe0ZW+In+S/VQ== Date: Thu, 9 Apr 2015 05:03:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_ABCAA4EF18F17B4FB619EA93DEF7939A3319099Beusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXRPuG7dUtVQg6Zoi5YX69gtrr76zOLA 5LFkyU8mjy+XP7MFMEVx2aSk5mSWpRbp2yVwZXy+dYelYIV8xe7mN0wNjC+luxg5OSQETCRa PrQzQthiEhfurWfrYuTiEBI4yijxaNlfKGcZo8TNxXPAqtgELCS2/37OCpIQEWhhlHj9YgEL SEJYwFHi2/IN7CC2iICbREdrCzOErSexu3MzE4jNIqAiMfXmczYQm1fAV+LA4W9gQxmBVn8/ tQashllAXOLWk/lMECcJSCzZc54ZwhaVePn4HyuErSQx5/U1Zoj6fIl/914xQcwUlDg58wnL BEahWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqWm25kuIkR GA/HJNgcdzAu+GR5iFGAg1GJh/fBEtVQIdbEsuLK3EOM0hwsSuK8ZVcOhggJpCeWpGanphak FsUXleakFh9iZOLglGpgrGOI5/pfc/3KB7Oc+idWOe/VHl/4z9MotrNY4tuV76dXBv+Wl2w/ K13mZ349TMJt88/62j8PU6dN3t/6MKZFQvbPy7TztgoBTef3Vc1d0bROY/2KP97bzyhFPUyZ dUkrQH2mhPyBsLtpqY5KzBb3Xe1Kt39Y1iKZc1ayMOxbbM1Wi2OLn+SdVGIpzkg01GIuKk4E AF+rGHNoAgAA X-SA-Exim-Connect-IP: 198.24.6.65 X-SA-Exim-Rcpt-To: draft-ietf-ippm-ipsec.all@tools.ietf.org X-SA-Exim-Mail-From: meral.shirazipour@ericsson.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-ippm-ipsec.all@ietf.org Resent-Message-Id: <20150409050358.98EA51B2A4E@ietfa.amsl.com> Resent-Date: Wed, 8 Apr 2015 22:03:55 -0700 (PDT) Resent-From: meral.shirazipour@ericsson.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 06:07:47 -0700 Subject: [ippm] Gen-ART Telechat Call review of draft-ietf-ippm-ipsec-09 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 05:04:15 -0000 --_000_ABCAA4EF18F17B4FB619EA93DEF7939A3319099Beusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Document: draft-ietf-ippm-ipsec-09 Reviewer: Meral Shirazipour Review Date: 2015-04-08 IETF LC End Date: 2015-02-09 IESG Telechat date: 2015-04-09 Summary: This draft is ready to be published as a Standards Track RFC. Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com --_000_ABCAA4EF18F17B4FB619EA93DEF7939A3319099Beusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART reviewer for this draft. F= or background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.= org/area/gen/trac/wiki/GenArtfaq>.  

 

Please wait for direction from your document shepher= d or AD before posting a new version of the draft.

 

Document: draft-ietf-ippm-ipsec-09

Reviewer: Meral Shirazipour

Review Date: 2015-04-08

IETF LC End Date: 2015-02-09

IESG Telechat date: 2015-04-09

 

 

Summary: This draft is ready to be published as a St= andards Track RFC.

 

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson

Research

www.ericsson.com

--_000_ABCAA4EF18F17B4FB619EA93DEF7939A3319099Beusaamb107erics_-- From nobody Thu Apr 9 06:07:50 2015 Return-Path: X-Original-To: expand-draft-ietf-ippm-ipsec.all@virtual.ietf.org Delivered-To: ippm@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1159B1B32FF; Thu, 9 Apr 2015 04:04:13 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ippm-ipsec.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ippm-ipsec.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFAA1B331E for ; Thu, 9 Apr 2015 04:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S28WllBEpc9i for ; Thu, 9 Apr 2015 04:04:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E1D1B32FF for ; Thu, 9 Apr 2015 04:04:11 -0700 (PDT) Received: from p130.piuha.net ([193.234.218.130]:53965) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgAFm-0005uP-0g for draft-ietf-ippm-ipsec.all@tools.ietf.org; Thu, 09 Apr 2015 04:04:11 -0700 Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 45C6B2CC6F; Thu, 9 Apr 2015 14:04:04 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjBAondAU4_6; Thu, 9 Apr 2015 14:04:01 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 850162CC5D; Thu, 9 Apr 2015 14:04:01 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_D084EE4C-174F-4C01-94A5-329609C966B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: Date: Thu, 9 Apr 2015 14:03:59 +0300 Message-Id: References: To: Meral Shirazipour X-Mailer: Apple Mail (2.1878.6) X-SA-Exim-Connect-IP: 193.234.218.130 X-SA-Exim-Rcpt-To: draft-ietf-ippm-ipsec.all@tools.ietf.org X-SA-Exim-Mail-From: jari.arkko@piuha.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-ippm-ipsec.all@ietf.org Resent-Message-Id: <20150409110411.A1E1D1B32FF@ietfa.amsl.com> Resent-Date: Thu, 9 Apr 2015 04:04:11 -0700 (PDT) Resent-From: jari.arkko@piuha.net Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 06:07:47 -0700 Cc: "gen-art@ietf.org" , "draft-ietf-ippm-ipsec.all@tools.ietf.org" Subject: Re: [ippm] [Gen-art] Gen-ART Telechat Call review of draft-ietf-ippm-ipsec-09 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 11:04:14 -0000 --Apple-Mail=_D084EE4C-174F-4C01-94A5-329609C966B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for your review, Meral. Jari On 09 Apr 2015, at 08:03, Meral Shirazipour = wrote: > I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = .=20 > =20 > Please wait for direction from your document shepherd or AD before = posting a new version of the draft. > =20 > Document: draft-ietf-ippm-ipsec-09 > Reviewer: Meral Shirazipour > Review Date: 2015-04-08 > IETF LC End Date: 2015-02-09 > IESG Telechat date: 2015-04-09 > =20 > =20 > Summary: This draft is ready to be published as a Standards Track RFC. > =20 > =20 > Best Regards, > Meral > --- > Meral Shirazipour > Ericsson > Research > www.ericsson.com > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_D084EE4C-174F-4C01-94A5-329609C966B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVJlygAAoJEM80gCTQU46qfSkP/ixepZi/bgqm1+aU3L+C7WGG EVofmj+31XMtnKHDV8JYJHUvjFvuBOKKLcgxkibqURxycVt/CgTq7qFYlb76v2fn 4MHnhmgFGvRM0hJKoeLCL+A1wYomBvHaxRSY3644OZEFlruOvEUAvB2wGayooNQS C9B208QnwFa1mEjhFjfH2c8nGKA2KURFQhqqhs4PQFCq9EK1VCZcW3X2WgSXgkU1 4AY4xEJlWOyg7ZdLDGwd/VP/wCzwIuY5zGcL6nziXsBhBN8S7VNDKeX2eTxJM4Pv U4QsTPS1cVFJSQm+21QRQVENxYrO5ggQl4mPXKcOSd/TzuRNq/Vm9Dfzy8LU6UY8 KvNtpom04tKizV3MgQQEXtJpXHgpXNG2Nm6+3HsaGQqr1IAd3r3sX/mehHtXGFO+ J2N8W+N5hdf+X9bp4mY8HDN8pTOdjv43dQRutdUbvyfUTkCDQJYPbwJ6TrWg0Qee Pv7yd6GGNB+DIvz/JTGIn018hJUXE/cKq+mweaIxPC7Mky7u93qso2PZEljj35nf KDMIja0jEahrsnN73zGkA0LCtyqWL3mW7I0mmAk/4WgX3c3G9DROso0DLGxj5Tny 92HF7MCpyw9li5weCfPr1CRKXv+4M6ZZdjyGHE8kk6CAL5869escGHtikDg5cKep 5O9VpCgWlqS4o3X3dqWU =kyO3 -----END PGP SIGNATURE----- --Apple-Mail=_D084EE4C-174F-4C01-94A5-329609C966B6-- From nobody Thu Apr 9 07:32:02 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8068A1A7113; Thu, 9 Apr 2015 07:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVd3xOLXIycH; Thu, 9 Apr 2015 07:31:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AA61A7026; Thu, 9 Apr 2015 07:31:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409143158.8911.86648.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 07:31:58 -0700 Archived-At: Cc: ippm-chairs@ietf.org, ippm@ietf.org Subject: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:31:59 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-ippm-ipsec-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm just holding a Discuss so IANA can recheck whatever we end up doing with the registry conversation (no new actions required). From nobody Thu Apr 9 07:40:10 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30061A86FC; Thu, 9 Apr 2015 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APzgelgKqgAh; Thu, 9 Apr 2015 07:40:03 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 379BD1A86FA; Thu, 9 Apr 2015 07:40:02 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 268561A0111; Thu, 9 Apr 2015 16:39:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BACECF82-2201-4E7B-B5E4-3B1D36F127E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: <20150409143158.8911.86648.idtracker@ietfa.amsl.com> Date: Thu, 9 Apr 2015 16:39:31 +0200 Message-Id: <0FAD7A93-94AB-462E-AF01-0F7ED2A8A267@trammell.ch> References: <20150409143158.8911.86648.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: ippm-chairs@ietf.org, The IESG , ippm@ietf.org Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:40:05 -0000 --Apple-Mail=_BACECF82-2201-4E7B-B5E4-3B1D36F127E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Spencer, Emphatically agreed that the TWAMP-Modes registry at = http://www.iana.org/assignments/twamp-parameters/twamp-parameters.xhtml#tw= amp-modes is very, very weird and should be fixed. Is the most expedient way to do this in the IANA considerations section = of a revised version of this I-D? Cheers, Brian > On 09 Apr 2015, at 16:31, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-ippm-ipsec-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I'm just holding a Discuss so IANA can recheck whatever we end up = doing > with the registry conversation (no new actions required). >=20 >=20 >=20 >=20 --Apple-Mail=_BACECF82-2201-4E7B-B5E4-3B1D36F127E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVJo8jAAoJENt3nsOmbNJcA1sH/j8xZwtdPczMkDtDeQDo7scy pvA0zvMvf+jIIS+SfS+d5papXx5dsx9uqRqnarwI7JS+8s9T/o+7KJqXi8Yyaz46 S+eiLK9s0kuNMINa7WOYOJI+yqAmD9OoPe1+XzOTEk0GwXjvNpXzp4lsciTAeq5g KZJ/09OS7qkzOE2ansSJPKBM1kcwzdXOBkjKFaHdJeXmLEfGhIInmy7EfEcFDMUa 7666givKY9CqHsODRIYb5HZpiW639AcHOVSutsHcZUl1tE0Dxk8cFgH9sK609cPD 8FZM9mIwnJ8lF4FXE84gErusMYLDdL5hPa5fyoLXLjouR7ZKpOjcKELxm2unTxQ= =NpSY -----END PGP SIGNATURE----- --Apple-Mail=_BACECF82-2201-4E7B-B5E4-3B1D36F127E9-- From nobody Thu Apr 9 07:50:37 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555471A8A3D; Thu, 9 Apr 2015 07:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZW_P4ds-tw6; Thu, 9 Apr 2015 07:50:30 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 96F231A89ED; Thu, 9 Apr 2015 07:50:30 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id D62A3121463; Thu, 9 Apr 2015 11:08:28 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id 35E14FBE3E; Thu, 9 Apr 2015 10:50:08 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Thu, 9 Apr 2015 10:50:30 -0400 From: "MORTON, ALFRED C (AL)" To: Brian Trammell , Spencer Dawkins Date: Thu, 9 Apr 2015 10:50:28 -0400 Thread-Topic: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) Thread-Index: AdBy0xtntYinPTSMToOfFS5is46ssgAAF9+Q Message-ID: <4AF73AA205019A4C8A1DDD32C034631D016088473A@NJFPSRVEXG0.research.att.com> References: <20150409143158.8911.86648.idtracker@ietfa.amsl.com> <0FAD7A93-94AB-462E-AF01-0F7ED2A8A267@trammell.ch> In-Reply-To: <0FAD7A93-94AB-462E-AF01-0F7ED2A8A267@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ippm-chairs@ietf.org" , The IESG , "ippm@ietf.org" Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:50:33 -0000 Agree of course, most supporting text could be grabbed from the OWAMP registry draft and the (revised) initial contents=20 of the TWAMP Modes registry should be: Bit Posit. Description Semantics Def Reference 0 Unauthenticated Section 3.1 [RFC4656] 1 Authenticated Section 3.1 [RFC4656] 2 Encrypted Section 3.1 [RFC4656] 3 Unauth. TEST protocol,=20 Encrypted CONTROL Section 3.1 [RFC5618] =09 4 Individual Session=20 Control Section 3.1 [RFC5938] =09 5 Reflect Octets=20 Capability Section 3.1, [RFC6038] =09 6 Symmetrical Size=20 Sender Test Packet Format Section 3.1, [RFC6038] 7 IPsec (this memo) 8-31 Unassigned =09 > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Thursday, April 09, 2015 10:40 AM > To: Spencer Dawkins > Cc: ippm-chairs@ietf.org; The IESG; ippm@ietf.org > Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec- > 09: (with DISCUSS) >=20 > hi Spencer, >=20 > Emphatically agreed that the TWAMP-Modes registry at > http://www.iana.org/assignments/twamp-parameters/twamp- > parameters.xhtml#twamp-modes is very, very weird and should be fixed. >=20 > Is the most expedient way to do this in the IANA considerations section > of a revised version of this I-D? >=20 > Cheers, >=20 > Brian >=20 >=20 > > On 09 Apr 2015, at 16:31, Spencer Dawkins > wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-ippm-ipsec-09: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I'm just holding a Discuss so IANA can recheck whatever we end up > > doing with the registry conversation (no new actions required). > > > > > > > > From nobody Thu Apr 9 08:50:25 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1EC1B2E65; Thu, 9 Apr 2015 08:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GEefqdr94Hm; Thu, 9 Apr 2015 08:50:21 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258B51B2E62; Thu, 9 Apr 2015 08:49:06 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so104252157ieb.0; Thu, 09 Apr 2015 08:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+9Qdv1YGlL3RT91Qq4Eyd654Ih517wbEwqQzyuFnyus=; b=0cW47A4Vy0xpu2QliFZYW6pYfuK7KWIN87Asq+jkl424zdAGwT2HZTJ04wQINFZLkZ MwW+WoqmK6nRLcaWURNch8bb5uj6e7IQSs98yj53T567P1iPT/MF5j4yl0CuaGTKrUrk iiQqLOGkxwJ+luuKlynuQjacNYoIP5INd8fii+TZBbILdnitGgaPwPasaHV58XzKvviQ 1Zmp89/mr1owAnittNesqVcA6LEpaFjZ3D0hPzK0SAjIbtBNuLv6jasx0A3aYJVUGuaF igeaWv20V44QZ6S8EmnDbjT/YkA2EiYJjf+9+2srZWKcuT6WnP19HlPqVpz1d69eHCHa OVkw== MIME-Version: 1.0 X-Received: by 10.107.29.21 with SMTP id d21mr8192076iod.11.1428594545640; Thu, 09 Apr 2015 08:49:05 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Thu, 9 Apr 2015 08:49:05 -0700 (PDT) In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D016088473A@NJFPSRVEXG0.research.att.com> References: <20150409143158.8911.86648.idtracker@ietfa.amsl.com> <0FAD7A93-94AB-462E-AF01-0F7ED2A8A267@trammell.ch> <4AF73AA205019A4C8A1DDD32C034631D016088473A@NJFPSRVEXG0.research.att.com> Date: Thu, 9 Apr 2015 11:49:05 -0400 X-Google-Sender-Auth: 3mdxbM2QDHF1wtPddlaNA7DLQAo Message-ID: From: Barry Leiba To: "MORTON, ALFRED C (AL)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "ippm-chairs@ietf.org" , "ippm@ietf.org" , The IESG Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 15:50:22 -0000 > Agree of course, most supporting text could be grabbed from the OWAMP > registry draft and the (revised) initial contents > of the TWAMP Modes registry should be: > > Bit > Posit. Description Semantics Def Reference > > 0 Unauthenticated Section 3.1 [RFC4656] > 1 Authenticated Section 3.1 [RFC4656] > 2 Encrypted Section 3.1 [RFC4656] > 3 Unauth. TEST protocol, > Encrypted CONTROL Section 3.1 [RFC5618] > > 4 Individual Session > Control Section 3.1 [RFC5938] > > 5 Reflect Octets > Capability Section 3.1, [RFC6038] > > 6 Symmetrical Size > Sender Test Packet Format Section 3.1, [RFC6038] > 7 IPsec (this memo) > 8-31 Unassigned > That way of doing it would work for me. And, yes, the IANA Considerations of this document could make that fix. Barry From nobody Thu Apr 9 10:12:33 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3EB1B2F49; Thu, 9 Apr 2015 10:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO22H8Mq5n8U; Thu, 9 Apr 2015 10:12:23 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A601B2F41; Thu, 9 Apr 2015 10:12:23 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-0d-55265c61532e Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FE.C9.12456.16C56255; Thu, 9 Apr 2015 13:02:57 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 13:12:16 -0400 From: Gregory Mirsky To: Brian Trammell , Spencer Dawkins Thread-Topic: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) Thread-Index: AQHQctMVgSciqsSDNk6hNsTDHOPKp51E5jjg Date: Thu, 9 Apr 2015 17:12:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9445C9@eusaamb103.ericsson.se> References: <20150409143158.8911.86648.idtracker@ietfa.amsl.com> <0FAD7A93-94AB-462E-AF01-0F7ED2A8A267@trammell.ch> In-Reply-To: <0FAD7A93-94AB-462E-AF01-0F7ED2A8A267@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXSPn25ijFqowbMtlhYz/kxkttjY8o7N YvWObjaLngfvmC2WTdnD7MDqsXPWXXaPJUt+Mnk82T+TJYA5issmJTUnsyy1SN8ugSujYeJE toIX/BVdt26zNTBO4+1i5OSQEDCROP7oAROELSZx4d56ti5GLg4hgaOMEqd+TWcFSQgJLGOU uLxWEsRmEzCSeLGxhx3EFhGIkGjsnQjWzCyQJ7Hn3CuwuLBAlMTWyR+haqIlPvXeYISwjSR2 Xz0OVM/BwSKgIvG6WwrE5BXwldi0wxtiU6lE74l9LCA2p4C9xMEDz8FsRqDTvp9aA7VJXOLW k/lQJwtILNlznhnCFpV4+fgfK4StKLGvfzo7RL2OxILdn9ggbG2JZQtfg9XzCghKnJz5hGUC o9gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw2MQIj6ZgEm+4Oxj0vLQ8xCnAwKvHwPlii GirEmlhWXJl7iFGag0VJnHfRg4MhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhijVnG6h+xe yqojo2l5kG9zya5Gn0epJi7L1PUvCq3d0axxv/rDjjsPt4uc4ZVbeTvveo7/mhU3+qJqf/hf XO1Xsok9ouHPJevAj7WH+hncVKJsV3jMuJQ63e7asiVMW5l2ZKwS0Hp/7ZSAnEnm/alZPOt/ vnjUr+9wMPfAAreF+82d71wR3/BIiaU4I9FQi7moOBEAlMbAMYUCAAA= Archived-At: Cc: "ippm-chairs@ietf.org" , The IESG , "ippm@ietf.org" Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:12:29 -0000 Hi Brian, et. al, very likely that then this RFC will be the most referenced IPPM RFC, exactl= y because of it fixing the registry. I can refer to process of fixing IANA = MPLS LSP Ping TLVs and sub-TLVs registry that being undertaken in the dedic= ated draft draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry. Regards, Greg -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell Sent: Thursday, April 09, 2015 7:40 AM To: Spencer Dawkins Cc: ippm-chairs@ietf.org; The IESG; ippm@ietf.org Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (= with DISCUSS) hi Spencer, Emphatically agreed that the TWAMP-Modes registry at http://www.iana.org/as= signments/twamp-parameters/twamp-parameters.xhtml#twamp-modes is very, very= weird and should be fixed. Is the most expedient way to do this in the IANA considerations section of = a revised version of this I-D? Cheers, Brian > On 09 Apr 2015, at 16:31, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-ippm-ipsec-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I'm just holding a Discuss so IANA can recheck whatever we end up=20 > doing with the registry conversation (no new actions required). >=20 >=20 >=20 >=20 From nobody Thu Apr 9 10:55:39 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453DD1B301B; Thu, 9 Apr 2015 10:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE8ptKRxuiVh; Thu, 9 Apr 2015 10:55:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E6B1A8AB2; Thu, 9 Apr 2015 10:55:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409175535.17409.88290.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 10:55:35 -0700 From: IETF Secretariat Archived-At: Subject: [ippm] ID Tracker State Update Notice: X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:55:36 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ From nobody Thu Apr 9 14:01:38 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7D51B32E3; Thu, 9 Apr 2015 14:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2nt8DVxi6M4; Thu, 9 Apr 2015 14:01:32 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E291B32E1; Thu, 9 Apr 2015 14:01:32 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so2521073igb.1; Thu, 09 Apr 2015 14:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qGZjJNoKfPIrLN9mhIh2zhRMJMHreZx+xsR77tjgwpI=; b=veDFyGkgIT5uc5IY/+e/N5r2zIldhabwTJi2lKIvkbGHJk6TcXeADCOohGb2qRy0CR V8K35XkYYR2HUhozNNrq3RxFaar0nzoDHcWaBdJGxsj5ig2mPuVhVMQRBG2eoz8rlfDI WgkPHoqdM552ya0N6XkNQXipz32YfObCT6LLyBNhrpvhBbU52izG8ahUPdAGAS8mOO/z RKMkZoZYgI5upkNuBv+6+s4blT7Iu5aLj4KGlO4b2RT0/3GVwQHQ3xWA4OLxWcX8dC5z 3/m69gAa+/UsF+A1QRNCPDtZJw9xyVLMxJ9zX/mnOBUzDfbVQC1Z0s2WQdQ2+8tL3Zkw NtMg== MIME-Version: 1.0 X-Received: by 10.50.176.196 with SMTP id ck4mr23665839igc.40.1428613292128; Thu, 09 Apr 2015 14:01:32 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Thu, 9 Apr 2015 14:01:32 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B9445C9@eusaamb103.ericsson.se> References: <20150409143158.8911.86648.idtracker@ietfa.amsl.com> <0FAD7A93-94AB-462E-AF01-0F7ED2A8A267@trammell.ch> <7347100B5761DC41A166AC17F22DF1121B9445C9@eusaamb103.ericsson.se> Date: Thu, 9 Apr 2015 17:01:32 -0400 X-Google-Sender-Auth: T4a7jv0o3G782Eqi_o4Mo6Q5lxY Message-ID: From: Barry Leiba To: Gregory Mirsky Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "ippm-chairs@ietf.org" , "ippm@ietf.org" , The IESG Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:01:34 -0000 > very likely that then this RFC will be the most referenced IPPM RFC, exactly > because of it fixing the registry. I can refer to process of fixing IANA MPLS > LSP Ping TLVs and sub-TLVs registry that being undertaken in the dedicated > draft draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry. I don't get what the second sentence means, but as to the first sentence: Actually, I see no reason that the registry needs to point to this document except as the reference for the new value (decimal 128, bit 7). The registry itself is still explained in RFC 5938, and no changes we're talking about making are inconsistent with that. So I think the registry itself will retain [RFC5618][RFC5938] as its references. Barry > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Thursday, April 09, 2015 7:40 AM > To: Spencer Dawkins > Cc: ippm-chairs@ietf.org; The IESG; ippm@ietf.org > Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) > > hi Spencer, > > Emphatically agreed that the TWAMP-Modes registry at http://www.iana.org/assignments/twamp-parameters/twamp-parameters.xhtml#twamp-modes is very, very weird and should be fixed. > > Is the most expedient way to do this in the IANA considerations section of a revised version of this I-D? > > Cheers, > > Brian > > >> On 09 Apr 2015, at 16:31, Spencer Dawkins wrote: >> >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-ippm-ipsec-09: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this introductory paragraph, however.) >> >> >> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I'm just holding a Discuss so IANA can recheck whatever we end up >> doing with the registry conversation (no new actions required). >> From nobody Thu Apr 9 14:20:36 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF211B332D; Thu, 9 Apr 2015 14:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXLBOXBZLVpm; Thu, 9 Apr 2015 14:20:34 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2331B3327; Thu, 9 Apr 2015 14:20:33 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-f1-55268a65f76b Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7C.9F.17241.56A86255; Thu, 9 Apr 2015 16:19:18 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 17:20:31 -0400 From: Gregory Mirsky To: Barry Leiba Thread-Topic: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) Thread-Index: AQHQctMVgSciqsSDNk6hNsTDHOPKp51E5jjggACH5gD//7+F8A== Date: Thu, 9 Apr 2015 21:20:31 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B946AA0@eusaamb103.ericsson.se> References: <20150409143158.8911.86648.idtracker@ietfa.amsl.com> <0FAD7A93-94AB-462E-AF01-0F7ED2A8A267@trammell.ch> <7347100B5761DC41A166AC17F22DF1121B9445C9@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonVjetSy3U4P5KZotDiy+xWsz4M5HZ YmPLOzaL1Tu62Sx6Hrxjtlg2ZQ+zA5tHy6peZo+ds+6yeyxZ8pPJ48n+mSwBLFFcNimpOZll qUX6dglcGZsa/rMXzJGqWHJkA2MD4wXRLkZODgkBE4m/qyexQthiEhfurWfrYuTiEBI4yigx eX4LlLOMUeLGxS3sIFVsAkYSLzb2gNkiApoSzz9PYQIpYhY4xihxecEGsFHCAlESWyd/hCqK lvjUe4MRwnaSWH1yHRuIzSKgIrF72REwm1fAV+L3w1awGiGBBiaJK7+CQWxOgUCJFcfusYDY jEDnfT+1hgnEZhYQl7j1ZD4TxNkCEkv2nGeGsEUlXj7+B/WOosS+/unsEPU6Egt2f2KDsLUl li18zQyxV1Di5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxchRWpxalptuZLiJERhlxyTYHHcw LvhkeYhRgINRiYf3wRLVUCHWxLLiytxDjNIcLErivGVXDoYICaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYJwUfc9z9oS7RyfxGa2onje5JnrnlwcSLBUv3yleXf+x5/kpM29Fjk+BGyfdEtNu mPRHU/y0otal1Ouzo6bd3OOnvcpg5p+Ic2uinboDdk9I23/xzuu9vhdte6eJMl1+H+gtoSAp /lMo+SKvv80/WZayc5PyFWV2uWtpd3Dm3Tr005XbVUxZZLMSS3FGoqEWc1FxIgBb21+HkwIA AA== Archived-At: Cc: "ippm-chairs@ietf.org" , "ippm@ietf.org" , The IESG Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:20:35 -0000 Hi Barry, as I understand, Modes being defined by respective RFCs as values, not as b= it positions. For example, RFC 4656, Section 3.1 states: The following Mode values are meaningful: 1 for unauthenticated, 2 for auth= enticated, and 4 for encrypted. And RFC 5938 only reflected that in Section 6.4. Proposed new registry changes how Mode(s) defined in RFC 4656 and RFC 5938.= I think that any work that introduces new Mode will have to reference RFC = that changes registry format from value to bit position. Regards, Greg -----Original Message----- From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry= Leiba Sent: Thursday, April 09, 2015 2:02 PM To: Gregory Mirsky Cc: Brian Trammell; Spencer Dawkins; ippm-chairs@ietf.org; The IESG; ippm@i= etf.org Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (= with DISCUSS) > very likely that then this RFC will be the most referenced IPPM RFC,=20 > exactly because of it fixing the registry. I can refer to process of=20 > fixing IANA MPLS LSP Ping TLVs and sub-TLVs registry that being=20 > undertaken in the dedicated draft draft-pac-mpls-lsp-ping-tlvs-and-sub-tl= vs-registry. I don't get what the second sentence means, but as to the first sentence: Actually, I see no reason that the registry needs to point to this document= except as the reference for the new value (decimal 128, bit 7). The regis= try itself is still explained in RFC 5938, and no changes we're talking abo= ut making are inconsistent with that. So I think the registry itself will = retain [RFC5618][RFC5938] as its references. Barry > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Thursday, April 09, 2015 7:40 AM > To: Spencer Dawkins > Cc: ippm-chairs@ietf.org; The IESG; ippm@ietf.org > Subject: Re: [ippm] Spencer Dawkins' Discuss on=20 > draft-ietf-ippm-ipsec-09: (with DISCUSS) > > hi Spencer, > > Emphatically agreed that the TWAMP-Modes registry at http://www.iana.org/= assignments/twamp-parameters/twamp-parameters.xhtml#twamp-modes is very, ve= ry weird and should be fixed. > > Is the most expedient way to do this in the IANA considerations section o= f a revised version of this I-D? > > Cheers, > > Brian > > >> On 09 Apr 2015, at 16:31, Spencer Dawkins wrote: >> >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-ippm-ipsec-09: Discuss >> >> When responding, please keep the subject line intact and reply to all=20 >> email addresses included in the To and CC lines. (Feel free to cut=20 >> this introductory paragraph, however.) >> >> >> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ >> >> >> >> --------------------------------------------------------------------- >> - >> DISCUSS: >> --------------------------------------------------------------------- >> - >> >> I'm just holding a Discuss so IANA can recheck whatever we end up=20 >> doing with the registry conversation (no new actions required). >> From nobody Mon Apr 13 09:21:59 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B26E1ACDF4; Mon, 13 Apr 2015 09:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L76rL0R-jZl4; Mon, 13 Apr 2015 09:21:53 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F931A09CF; Mon, 13 Apr 2015 09:21:48 -0700 (PDT) Received: by lagv1 with SMTP id v1so61800099lag.3; Mon, 13 Apr 2015 09:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AWi1k8yWtPOp7PPkpAc5rYP/o086rdxNLHCfxclc9Jo=; b=xiZa7fcsyxqB2E/VchV9eOxUshbYkomQBup9AZX/UYF7vJQIuYd/hBmyoujvuvPxjy uEVnetEtl3D0aIYwyEnRJBvIy3qEQhR8ABJnGNFlB9NluMrZma1QHFNa+09VlntkWUjE kmhWwh96ZEhSVP7qSjbdHhdfSReL6RI4WZOhscjbEIdQBQL/8Y528JPUEpdSXowhQlrT YghCv7siSDoj1apV4KF+WfVNFtagK7gd1mVH0CJQ/hYvpNsqvWeBJpejeICpemtueqqI 8kI4S/zlfIY89waZr9/BhpbnIMqL3Raf6/5dUuSNLBL1rZsQaYFcsKjgp3frtDO7qkvt 4ZYA== MIME-Version: 1.0 X-Received: by 10.112.146.41 with SMTP id sz9mr14325327lbb.77.1428942106637; Mon, 13 Apr 2015 09:21:46 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Mon, 13 Apr 2015 09:21:46 -0700 (PDT) In-Reply-To: References: <20150409143158.8911.86648.idtracker@ietfa.amsl.com> <0FAD7A93-94AB-462E-AF01-0F7ED2A8A267@trammell.ch> <4AF73AA205019A4C8A1DDD32C034631D016088473A@NJFPSRVEXG0.research.att.com> Date: Mon, 13 Apr 2015 11:21:46 -0500 Message-ID: From: Spencer Dawkins at IETF To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b3a8784abbdc905139d822e Archived-At: Cc: "ippm-chairs@ietf.org" , "MORTON, ALFRED C \(AL\)" , "ippm@ietf.org" , The IESG Subject: Re: [ippm] Spencer Dawkins' Discuss on draft-ietf-ippm-ipsec-09: (with DISCUSS) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Apr 2015 16:21:58 -0000 --047d7b3a8784abbdc905139d822e Content-Type: text/plain; charset=UTF-8 Hi, Brian, On Thu, Apr 9, 2015 at 10:49 AM, Barry Leiba wrote: > > Agree of course, most supporting text could be grabbed from the OWAMP > > registry draft and the (revised) initial contents > > of the TWAMP Modes registry should be: > > > > Bit > > Posit. Description Semantics Def Reference > > > > 0 Unauthenticated Section 3.1 [RFC4656] > > 1 Authenticated Section 3.1 [RFC4656] > > 2 Encrypted Section 3.1 [RFC4656] > > 3 Unauth. TEST protocol, > > Encrypted CONTROL Section 3.1 [RFC5618] > > > > 4 Individual Session > > Control Section 3.1 [RFC5938] > > > > 5 Reflect Octets > > Capability Section 3.1, [RFC6038] > > > > 6 Symmetrical Size > > Sender Test Packet Format Section 3.1, [RFC6038] > > 7 IPsec (this memo) > > 8-31 Unassigned > > > It would work for me as well. Spencer That way of doing it would work for me. And, yes, the IANA > Considerations of this document could make that fix. > > Barry > --047d7b3a8784abbdc905139d822e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Brian,

On Thu, Apr 9, 2015 at 10:49 AM, Barry Leiba &l= t;barryleiba@c= omputer.org> wrote:
&= gt; Agree of course, most supporting text could be grabbed from the OWAMP > registry draft and the (revised) initial contents
> of the TWAMP Modes registry should be:
>
> Bit
> Posit.=C2=A0 Description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Semantics D= ef=C2=A0 =C2=A0Reference
>
> 0=C2=A0 =C2=A0 =C2=A0 =C2=A0Unauthenticated=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0Section 3.1=C2=A0 =C2=A0 =C2=A0[RFC4656]
> 1=C2=A0 =C2=A0 =C2=A0 =C2=A0Authenticated=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Section 3.1=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC4656]
> 2=C2=A0 =C2=A0 =C2=A0 =C2=A0Encrypted=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3.1=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[RFC4656]
> 3=C2=A0 =C2=A0 =C2=A0 =C2=A0Unauth. TEST protocol,
>=C2=A0 =C2=A0 =C2=A0 Encrypted CONTROL=C2=A0 =C2=A0 Section 3.1=C2=A0 = =C2=A0 =C2=A0[RFC5618]
>
> 4=C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Session
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Control=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Section 3.1=C2=A0 =C2=A0 =C2=A0 [RFC5938]
>
> 5=C2=A0 =C2=A0 =C2=A0 =C2=A0Reflect Octets
>=C2=A0 =C2=A0 =C2=A0 Capability=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Section 3.1,=C2=A0 =C2=A0 =C2=A0[RFC6038]
>
> 6=C2=A0 =C2=A0 =C2=A0 =C2=A0Symmetrical Size
>=C2=A0 =C2=A0 =C2=A0 Sender Test Packet Format Section 3.1,=C2=A0 [RFC6= 038]
> 7=C2=A0 =C2=A0 =C2=A0 =C2=A0IPsec=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(this memo)
> 8-31=C2=A0 Unassigned
>

=C2=A0It would work for me = as well.=C2=A0

Spencer

That way of doing it would work for me.=C2=A0 And, = yes, the IANA
Considerations of this document could make that fix.

Barry

--047d7b3a8784abbdc905139d822e-- From nobody Tue Apr 14 06:07:54 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F58A1A90B9 for ; Tue, 14 Apr 2015 06:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJP8wsmhaxPs for ; Tue, 14 Apr 2015 06:07:51 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D881A90B2 for ; Tue, 14 Apr 2015 06:07:51 -0700 (PDT) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t3ECptvI027594; Tue, 14 Apr 2015 06:07:50 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1trmug9rp8-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Apr 2015 06:07:50 -0700 Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 14 Apr 2015 06:07:46 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.187.74) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 14 Apr 2015 07:07:46 -0600 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by brm-excashub-2.corp.brocade.com (172.16.187.74) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 14 Apr 2015 07:07:46 -0600 Received: from [172.27.236.49] (172.27.236.49) by imapeu.brocade.com (172.29.18.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 14 Apr 2015 15:07:44 +0200 Message-ID: <552D111F.4030203@brocade.com> Date: Tue, 14 Apr 2015 14:07:43 +0100 From: Robert Shearman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-14_03:2015-04-14,2015-04-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=13 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504140111 Archived-At: Cc: ippm@ietf.org Subject: [ippm] Comments on draft-cmzrjp-ippm-twamp-yang X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 14 Apr 2015 13:07:53 -0000 Hi, Thank you for your great work on defining this model. I have some comments/questions on this draft. I've organised them by the section they best apply to, although in some cases they may have effects on other sections as well. Section 4.1: keys for different Servers. keyId is a UTF-8 string, up to 80 octets in length (if the string is shorter, it is padded with zero octets), that tells the Server which shared secret the Control-Client wishes to use to authenticate or encrypt. The secretKey is the shared secret, an octet string of arbitrary length whose interpretation as a text string is unspecified. In the interest of interoperability, however, the UTF-8 text encoding MUST be used for secretKey. There's no need to specify the encoding of keyId or secretKey because section 9.4 of RFC6020 (YANG) specifies the encoding of the string (presumably along with the top-level XML encoding attribute). There's also no need to specifying how the padding works because YANG strings are variable-sized. Section 4.1: dkLen Intended length in octets of the derived key, a positive integer, at most (2^32 - 1) * hLen. Changing the derived key length from value of 128 bits inferred from section 6.10 of RFC4656 will result in a client that cannot authenticate with a server unless the derived key length in use by the server matches and the value is known to the user/client. Neither RFC4656 nor RFC5357 suggest that this is a parameter that should be configurable. Is there an RFC/draft that suggests this and extends the server greeting to advertise the derived key length? Section 4.1: pmIndex Numerical index value of a Registered Metric in the Performance Metric Registry [I-D.ietf-ippm-metric-registry]. Output Statistics will be specified in the Registry entry. Perhaps I'm missing something fundamental, or some background information, or this is work in progress, but the purpose of I-D.ietf-ippm-metric-registry is stated to be: This document defines the IANA Registry for Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. Whilst I can see the usefulness of abstracting out the definition of a performance metric, how does the index of the registered metric help in retrieval of the output statistics? Section 4.1: What triggers the Control-Client to send the Start-Sessions message? Section 4.1: Should twampSessionRequest expose a property to allow the DSCP to be specified via the Type-P field of the Request-TW-Session message? Section 4.1: Should the behaviour be specified if any of the settable properties of twampSessionRequest aren't set? E.g.: - senderIp - senderUdpPort - reflectorIp - reflectorUdpPort - timeout - paddingLength - startTime - repeat - pmIndex Section 4.2: maxCount If an attacking system sets the maximum value in Count (2**32), then the system under attack would stall for a significant period of time while it attempts to generate keys. Therefore, TWAMP-compliant systems SHOULD have a configuration control to limit the maximum Count value. The default maximum Count value SHOULD be 32768. Was this intended to be a server property? Section 6 of RFC5357 continues to say: If a Control-Client receives a Server-Greeting message with Count greater that its maximum configured value, it SHOULD close the control connection. I.e. this applies to clients. The client never suggests a Count to the server; instead it's the client that needs to validate the count the server has provided. Section 4.2: dscp The DSCP value used in the header of the TCP control packets sent by the Server for this control connection. This will usually be the same value as is configured for twampServer:dscp under the twampServer. However, in the event that the user re-configures twampServer:dscp after this control connection is already in progress, this read-only value will show the actual dscp value in use by this control connection. I support the inclusion of this property despite section 3.1 of RFC5357 saying: The Server SHOULD use the DSCP of the Control- Client's TCP SYN in ALL subsequent packets on that connection (avoiding any ambiguity in case of re-marking). The reasoning being that for practical purposes TWAMP will typically be implemented by using a general purpose TCP stack provided by the underlying operating system. This statement imposes a requirement on the behaviour of the TCP stack which AFAICS isn't specified in standards that directly relate to TCP or DSCP. This means that it's not practical to implement this behaviour in a OS-portable implementation of TWAMP. In addition, there are DoS concerns with allowing a client to control DSCP values on the return path from a server. Configuring the server use a DSCP for control packets it sends mitigates both issues. Section 4.2: dkLen The dkLen value that is in use by this control connection. This will usually be the same value as is configured under twampServer. However, in the event that the user re- configured twampServer:dkLen after this control connection is already in progress, this read-only value will show the actual dkLen that is in use for this control connection. The description here refers to twampServer:dkLen but there is no item named dkLen under twampServer. Such an item under twampServer is required if the client is to have such an option (see above). Section 4.2: The twampServer container items are as follows: ... The following parameters are read-only: salt A parameter used in deriving a key from a shared secret as described in Section 3.1 of [RFC4656]. Salt MUST be generated pseudo-randomly (independently of anything else in the RFC) and is communicated to the Control-Client as part of the Server greeting message. serverIv The Server Initialization Vector (IV) is generated randomly by the server. challenge Challenge is a random sequence of octets generated by the server. As described in Section 4.1 challenge is used by the Control-Client to prove possession of a shared secret. These are all per-connection properties and so should be properties of the twampServerCtrlConnection container. Section 4.3: dscp The DSCP value to be placed in the UDP header of TWAMP- Control packets generated by the Session-Sender. This should say "... UDP header of TWAMP-Test packets ...". Section 4.3: Allowing properties to be changed at will whilst test sessions are in progress may present implementation challenges (i.e. synchronisation with the sending of packets). Do we think this is a valid use case? If not, could text be added to guide implementors as to the expectations? Section 4.4: twampServerCtrlConnection object. This four4-tuple allows the user The "four" should be removed. Section 5.2: leaf serverIp { config "true"; type inet:ip-address; } Nit: the parent list defaults to config being true, so the config statement is unnecessary and leads to questions in the readers' mind as to why other apparently configurable properties in the same list don't have this statement. Section 5.2, list twampClientCtrlConnection: leaf token { config "false"; type string { length "1..64"; } description "64 octets, containing the concatenation of a 16-octet challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication"; } leaf clientIv{ config "false"; type string { length "1..16"; } description "16 octets, Client-IV is generated randomly by the Control-Client."; } Should these be binary types of fixed length instead? Section 5.2, list twampClientCtrlConnection: leaf serverStartTime { config "false"; type uint64; } Should this be exposed in a form more convenient for the operator, such as ietf-yang-types:date-and-time? Section 5.2, container twampServer: leaf salt{ config "false"; type string { length "1..16"; } description "Salt MUST be generated pseudo-randomly"; } leaf serverIv { config "false"; type string { length "1..16"; } description "16 octets, Server-IV is generated randomly by the Control-Client."; } leaf challenge { config "false"; type string { length "1..16"; } description "Challenge is a random sequence of octets generated by the Server"; } Should these be binary types of fixed length instead? Section 7: Is there a use case in mind behind the exposing of values that can be used to derive the session key on both clients and servers? The reason for this question is that such information will need to be restricted to privileged operators and if the implementation of the management interface doesn't support a fine enough grained access control mechanism then it could prevent much of the data in this model from being accessible by ordinary operators. Thanks, Rob From nobody Wed Apr 15 01:20:35 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5AF1B32E5 for ; Wed, 15 Apr 2015 01:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N88xTVJyEGe4 for ; Wed, 15 Apr 2015 01:20:32 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 966401B32DE for ; Wed, 15 Apr 2015 01:20:26 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 776461A03C2 for ; Wed, 15 Apr 2015 10:19:54 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_B0CE9CE8-4B18-43CA-9DE1-48AA012A23D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: <3A3D4A78-EE84-4CFF-A46A-E5E0E3318494@trammell.ch> Date: Wed, 15 Apr 2015 10:19:54 +0200 Message-Id: References: <3A3D4A78-EE84-4CFF-A46A-E5E0E3318494@trammell.ch> To: ippm@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [ippm] WG adoption call for draft-morton-ippm-active-passive X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2015 08:20:34 -0000 --Apple-Mail=_B0CE9CE8-4B18-43CA-9DE1-48AA012A23D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Based on feedback from this adoption call both in Dallas and on the = list, there is clear consensus for adoption of the following milestone: Submit a draft defining terminology for the continuum of passive and = active measurement to the IESG as Informational. and to adopt draft-morton-ippm-active-passive-01 as the basis of this = draft. Authors: please submit draft-ietf-ippm-active-passive-00. Thanks, best regards, Brian (chair hat) > On 27 Mar 2015, at 20:17, Brian Trammell wrote: >=20 > Greetings, all, >=20 > This is a call for adoption for a new milestone under the current IPPM = charter: >=20 > Submit a draft defining terminology for the continuum of passive and = active measurement to the IESG as an Informational draft. >=20 > Under consideration for this milestone is = draft-morton-ippm-active-passive-01. >=20 > Please indicate the following to the list at ippm at ietf.org: >=20 > (a) whether you support the addition of the milestone > and the adoption of the draft as a WG item to fulfill that milestone, = and >=20 > (b) whether you pledge to review the draft during the WG process. >=20 > We note there was clear consensus in the room at the IPPM meeting in = Dallas earlier today for adoption of this milestone, and this draft as a = starting point. >=20 > This call for adoption will continue until Friday 10 April 2014. >=20 > Many thanks, best regards, >=20 > Brian (chair hat) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_B0CE9CE8-4B18-43CA-9DE1-48AA012A23D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVLh8qAAoJENt3nsOmbNJcbG8H/iYVdrBkLr9JP+F2Jluan5eP 2sP6Wub1oKW0APRT45Bt1vZM+WTnFXr6W1n4NspD9fa4OnNbxRhuz/SX9pP66qD3 hg7lTt+kaKvI1D++5yj5tF1+lu+p5W5gGvXJeUeQBtFsw5YlIB2+W43KhoSxS02a SXs8fq9IhNmSZ6AnteTXyDvkwinb3ewyopBHVaR1LHhkxuG03wu5Yx9y6lD9P/oj 7XaMqXOimkEBIXLMtzkrwD6POdonzXp+IGQOUI6eshUMdOoHbTlcFJkUChRxMkqw 4W0du2lQJzqwe6vqMEpnsWlOAfdskTsHDfdHbNz6pNt6DXj5CN9yJ7TUS25gQwI= =itHk -----END PGP SIGNATURE----- --Apple-Mail=_B0CE9CE8-4B18-43CA-9DE1-48AA012A23D3-- From nobody Thu Apr 23 01:17:17 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008B71B2FA2 for ; Thu, 23 Apr 2015 01:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpSsChus--uS for ; Thu, 23 Apr 2015 01:17:15 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id BEC321B2F92 for ; Thu, 23 Apr 2015 01:16:59 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 9A06F1A04F5 for ; Thu, 23 Apr 2015 10:16:58 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_AC865D77-331A-439E-8D79-AB39BBBD739D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: <4456E087-4C40-48CD-B0BC-7CB53EAE4469@trammell.ch> Date: Thu, 23 Apr 2015 10:16:57 +0200 Message-Id: <1C917015-FD21-4F31-8CEE-237F123E7CBB@trammell.ch> References: <4456E087-4C40-48CD-B0BC-7CB53EAE4469@trammell.ch> To: ippm@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [ippm] WGLC on draft-ietf-ippm-model-based-metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 08:17:17 -0000 --Apple-Mail=_AC865D77-331A-439E-8D79-AB39BBBD739D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Seeing no comment on this WGLC, we will extend the WGLC by two weeks, = now to end next Friday, 1 May 2015. *Please* review and comment on the draft to the ippm@ietf.org list. Thanks, best regards, Brian (chair hat) > On 27 Mar 2015, at 17:08, Brian Trammell wrote: >=20 > Greetings, all, >=20 > Working Group Last Call has started on = draft-ietf-ippm-model-based-metrics. Please provide final comments on = this document to the IPPM working group list ippm@ietf.org by Friday, 17 = April 2015. >=20 > (Note, given that many in the room who had read previous revisions of = this document indicated they had not reviewed the latest, this is a = three week WGLC to allow additional reading time.) >=20 > Many thanks, best regards, >=20 > Brian (chair hat) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_AC865D77-331A-439E-8D79-AB39BBBD739D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVOKp6AAoJENt3nsOmbNJc5x4IAMJAlAuRHqB0z3n0GwbOZni4 uDDP1SmJ2Y/WKsQlNL+8Vw4NDpunFVsXVSN6JLSL7r0T4mcGt3HTPKolX3GkiMUa 9mDUdYSs76ErK1rkxdmC0eQ9TC6IgLH4HJx/hAR+xc1nCU+wqAO/zs7MDnIqRezh ecGEfWWawAQQ5fbXhqIgTuHQ1pK1iIzdF9CZfejlfQKX/kaNKB1yY98KanSPw1jc 1v84rjTK+d/xHwpmLvyJVEENDj9uwmRmBiQmT1tR4tuf5AEsuREYKCqPdlUnVZB2 o/3a8Yk0/WuM6iTZfkDPaE6E7q6RYnhjUMl6o55D4MARgeganGIhZsKz4MxMwuo= =OEiD -----END PGP SIGNATURE----- --Apple-Mail=_AC865D77-331A-439E-8D79-AB39BBBD739D-- From nobody Fri Apr 24 08:13:08 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC651A1B25; Fri, 24 Apr 2015 08:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.37 X-Spam-Level: X-Spam-Status: No, score=0.37 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAGbHL75-39I; Fri, 24 Apr 2015 08:13:04 -0700 (PDT) Received: from teledg002ba020.telecomitalia.it (teledg002ba020.telecomitalia.it [156.54.233.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398651A1B47; Fri, 24 Apr 2015 08:13:03 -0700 (PDT) Content-Type: multipart/mixed; boundary="_74f2f749-cfb3-42b1-bae5-39f0c7486e4e_" Received: from TELCAH003BA020.telecomitalia.local (10.188.101.218) by teledg002ba020.telecomitalia.it (10.188.101.211) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Apr 2015 17:12:59 +0200 Received: from TELMBB001BA020.telecomitalia.local ([169.254.2.165]) by telcah003ba020.telecomitalia.local ([10.188.101.218]) with mapi id 14.03.0181.006; Fri, 24 Apr 2015 17:12:58 +0200 From: Fioccola Giuseppe To: "ippm@ietf.org" , "ippm-chairs@ietf.org" Thread-Topic: [ippm] Feedback on draft-tempia-ippm-p3m-00 Thread-Index: AdB9sHoGgVAZb80TSn+XPw9C2NKVRA== Date: Fri, 24 Apr 2015 15:12:58 +0000 Message-ID: <23126F6FC5CA3E44916CF99D4E0B878B43CD09B7@TELMBB001BA020.telecomitalia.local> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.188.101.195] x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Archived-At: Cc: Cociglio Mauro Subject: [ippm] Feedback on draft-tempia-ippm-p3m-00 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 15:13:07 -0000 --_74f2f749-cfb3-42b1-bae5-39f0c7486e4e_ Content-Type: multipart/alternative; boundary="_000_23126F6FC5CA3E44916CF99D4E0B878B43CD09B7TELMBB001BA020t_" --_000_23126F6FC5CA3E44916CF99D4E0B878B43CD09B7TELMBB001BA020t_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi IPPMers, I would like to have your feedback on draft-tempia-ippm-p3m-00. This draft, previously presented in OPSAWG, was the first IETF document des= cribing the alternate marking method for performance monitoring. It is an experimental draft primarily focused on describing the implementat= ion and deployment of the method in Telecom Italia's network. It doesn't co= ntain any standardization proposal. As the applicability of the alternate marking methodology is very general, = the draft is now being referenced by a number of drafts, also in other WGs: draft-chen-ippm-coloring-based-ipfpm-framework-03 draft-morton-ippm-active-passive-01 draft-bryant-mpls-flow-ident-01 draft-bryant-mpls-synonymous-flow-labels-00 draft-bryant-mpls-sfl-control-00 draft-bryant-mpls-rfc6374-over-udp-00 Given this increasing interest, I would like to ask to take the draft into = consideration for WG adoption, in order to consolidate the document as a ge= neral reference for other solutions based on the alternate marking principl= e. At the same time, I would appreciate your comments and/or suggestions to im= prove the document. Best Regards, Giuseppe Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?= necessario. --_000_23126F6FC5CA3E44916CF99D4E0B878B43CD09B7TELMBB001BA020t_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi IPPMers,

 

I would like to have your feedb= ack on draft-tempia-ippm-p3m-00.

This draft, previously presente= d in OPSAWG, was the first IETF document describing the alternate marking m= ethod for performance monitoring.

It is an experimental draft pri= marily focused on describing the implementation and deployment of the metho= d in Telecom Italia's network. It doesn’t contain any standardization= proposal.

 

As the applicability of the alt= ernate marking methodology is very general, the draft is now being referenc= ed by a number of drafts, also in other WGs:

 

draft-chen-ippm-coloring-based-= ipfpm-framework-03

draft-morton-ippm-active-passiv= e-01

draft-bryant-mpls-flow-ident-01=

draft-bryant-mpls-synonymous-fl= ow-labels-00

draft-bryant-mpls-sfl-control-0= 0

draft-bryant-mpls-rfc6374-over-= udp-00

 

Given this increasing interest,= I would like to ask to take the draft into consideration for WG adoption, = in order to consolidate the document as a general reference for other solut= ions based on the alternate marking principle.

At the same time, I would appre= ciate your comments and/or suggestions to improve the document.<= /span>

 

Best Regards,=

 

Giuseppe

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_23126F6FC5CA3E44916CF99D4E0B878B43CD09B7TELMBB001BA020t_-- --_74f2f749-cfb3-42b1-bae5-39f0c7486e4e_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_74f2f749-cfb3-42b1-bae5-39f0c7486e4e_-- From nobody Fri Apr 24 08:43:00 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666781B3061 for ; Fri, 24 Apr 2015 08:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC8QaOKW-h5n for ; Fri, 24 Apr 2015 08:42:57 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C771A92BC for ; Fri, 24 Apr 2015 08:42:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 40F94D9303; Fri, 24 Apr 2015 17:42:55 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id M1qCORLvSLxN; Fri, 24 Apr 2015 17:42:55 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1025DD9302; Fri, 24 Apr 2015 17:42:55 +0200 (MEST) Message-ID: <553A647E.7090808@tik.ee.ethz.ch> Date: Fri, 24 Apr 2015 17:42:54 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ippm@ietf.org, Matt Mathis , acmorton@att.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [ippm] Framework for Model Based Measurements needed? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 15:42:59 -0000 Hi Matt, hi Al, I'm in the process of reviewing draft-ietf-ippm-model-based-metrics-04... and I have to say I'm a little lost... :-( I understand the idea but it's really hard to follow what the document is giving me and what not. In the abstract it says that the doc will define a class of metrics...not sure the document is actually defining metrics... than later (2. half of intro) it says it "describes a framework for deriving traffic patterns and delivery statistics for model based metrics" but don't really think you can talk about a framework here. So from my point of view the document describes (as state above) traffic pattern and to some extent statistics plus gives a little bit of example and a lot of motivational text (which I believe could maybe be organized better). To make my mind up what I'm actually reading I came up with the following drawing: ___________ _______________ | | | | Input Parameter -->| Model | | Measurement |<-- Traffic generator | | | | ----------- --------------- | Test | target values | /---\ | IP metrics ------->| + |<--------- \---/ | \/ pass/fail So in this picture, your document talks about the target values, a little bit about the model (which is simply the TCP model) and about the traffic generation but leaves out a lot of the stuff in the middle. Matt, if you have understood you correctly, you still plan to write a document that describes something similar to my drawing above...? If you actually plan to do this, I think that would be very helpful and should be published before this draft (draft-ietf-ippm-model-based-metrics-04); also because most of the motivation and background text should rather go in that new document from my point of view. And just for the sake of readability, I would even think about splitting up the current draft into potentially 2 documents (model and measurements/tests). I think the most important (actually quite simple) message for this work is: Don't use TCP for measurement traffic generator! However having everything in on document, I afraid that this message simply gets lost... :-( Let me know what you think and if the diagram above is at all similar to what you have in mind! Mirja From nobody Fri Apr 24 12:49:36 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1151A0203 for ; Fri, 24 Apr 2015 12:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHAnNBQsD1bk for ; Fri, 24 Apr 2015 12:49:33 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5543D1A00D6 for ; Fri, 24 Apr 2015 12:49:33 -0700 (PDT) Received: by oign205 with SMTP id n205so49090030oig.2 for ; Fri, 24 Apr 2015 12:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kO3pJoh+Rg8plGggGGqYO7JS5wHd0F4jP2EK2jE8AxY=; b=FSU8hXX29Av13YOfv/435g8HkmmElKkwp7CBniEi7lMelQXoW2DxijwN72p1sVHA52 IWxRkk6Ot0ec4YtctAygRZIrJU4EQOitnNd0G78Jm/aZr6/DNO3if7O6uIHzj3nBmICC evLsB2xuwqw2JNUflkWbAt0cvQRo1ER5SKu6S40B9p/xiXweQEEka+6TpFQwJZTUNQuI +rFVijZ2PWTvSw3GSqRiNikGCKX0TsImYn7MfHYc75N13vKP/F56QPIxd/qAsy1VKAxl AqT+ZAsXxOwLog8Fa/muZU8WJL53Q7FV/8P0y00K9s6Emc1QQKUtTeW4DIEspOu62Rfo XGIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kO3pJoh+Rg8plGggGGqYO7JS5wHd0F4jP2EK2jE8AxY=; b=jeZDJB73nuMM9VZ37pWMudA0CAr4tlL7uBHA9hxPfga+KI8tZaoxWtf+qvmHTyDr5x ptV7Gcdoxktaw3brOgkNHKMcbKqew3YMER9802LhK9bO2S2GeQ90C+1kEf/Urfv5pyqi OQNnm0Z8F5F+OBqmcSSP+QjPY2PFudKmX96ZApX37kLKFIwNDMWaw2RWMKkqdHmEbyd3 F4njHXpcOLx01+EsUwFvxwEbrDtYX0P2K+22RfjmWs3Aji9HlwUMRQuQsrMxl1DIEIrx 9ilpjWdvixJ3n9AWGws8YrpMC2t+AvTUa/2WYk2nvSyXAwh3Yp6MPqddprBULfqZZyn/ IBww== X-Gm-Message-State: ALoCoQkFHEzgP0Z4ewH9+MO9afhhJ47N5AQ95h4h0bC5Okwg4jSyTU1UeETW3QyaBuGghrTfrpZd MIME-Version: 1.0 X-Received: by 10.202.216.87 with SMTP id p84mr1343oig.133.1429904972714; Fri, 24 Apr 2015 12:49:32 -0700 (PDT) Received: by 10.182.31.84 with HTTP; Fri, 24 Apr 2015 12:49:32 -0700 (PDT) In-Reply-To: <553A647E.7090808@tik.ee.ethz.ch> References: <553A647E.7090808@tik.ee.ethz.ch> Date: Fri, 24 Apr 2015 12:49:32 -0700 Message-ID: From: Matt Mathis To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a113d606af6499e05147db195 Archived-At: Cc: Al Morton , "ippm@ietf.org" Subject: Re: [ippm] Framework for Model Based Measurements needed? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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 Apr 2015 19:49:35 -0000 --001a113d606af6499e05147db195 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks. Good comments. If you find it hard to follow, it has serious problems.... :-( :-( A revised version of your diagram would help quite a bit as would other fixes as you suggest. (and very much highlights things that are not clear), The other document would be a step up to the larger problem. E.g. how to wrap MBM in a framework to support independently verifiable large scale measurement that can estimate the probability that users can access the content they want, at the performance needed to make effective use of the content. Re: not using TCP: the real problem is that all throughput maximizing behaviors, by design cause self inflicted congestion which is extremely non-linear and conflated with many other signals. TCP can be used for measurement if you somehow inhibit congestion control and throughput maximizing behaviors, for example by clamping cwnd. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Fri, Apr 24, 2015 at 8:42 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi Matt, hi Al, > > I'm in the process of reviewing draft-ietf-ippm-model-based-metrics-04... > and I have to say I'm a little lost... :-( > > I understand the idea but it's really hard to follow what the document is > giving me and what not. In the abstract it says that the doc will define = a > class of metrics...not sure the document is actually defining metrics... > than later (2. half of intro) it says it "describes a framework for > deriving traffic patterns and delivery statistics for model based metrics= " > but don't really think you can talk about a framework here. So from my > point of view the document describes (as state above) traffic pattern and > to some extent statistics plus gives a little bit of example and a lot of > motivational text (which I believe could maybe be organized better). > > To make my mind up what I'm actually reading I came up with the following > drawing: > > ___________ _______________ > | | | | > Input Parameter -->| Model | | Measurement |<-- Traffic generat= or > | | | | > ----------- --------------- > | Test | > target values | /---\ | IP metrics > ------->| + |<--------- > \---/ > | > \/ > pass/fail > > > So in this picture, your document talks about the target values, a little > bit about the model (which is simply the TCP model) and about the traffic > generation but leaves out a lot of the stuff in the middle. Matt, if you > have understood you correctly, you still plan to write a document that > describes something similar to my drawing above...? If you actually plan = to > do this, I think that would be very helpful and should be published befor= e > this draft (draft-ietf-ippm-model-based-metrics-04); also because most of > the motivation and background text should rather go in that new document > from my point of view. And just for the sake of readability, I would even > think about splitting up the current draft into potentially 2 documents > (model and measurements/tests). > > I think the most important (actually quite simple) message for this work > is: Don't use TCP for measurement traffic generator! However having > everything in on document, I afraid that this message simply gets lost... > :-( > > Let me know what you think and if the diagram above is at all similar to > what you have in mind! > > Mirja > > --001a113d606af6499e05147db195 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks. Good comments. =C2=A0 If you find it hard to follo= w, it has serious problems.... :-( :-(

A revised version= of your diagram would help quite a bit as would other fixes as you suggest.=C2=A0(and very much highligh= ts things that are not clear),=C2=A0

The other doc= ument would be a step up to the larger problem. =C2=A0 E.g. how to wrap MBM= in a framework to support independently verifiable large scale measurement= that can estimate the probability =C2=A0that users can access the content = they want, at the performance needed to make effective use of the content.<= /div>

Re: not usin= g TCP: the real problem is that all throughput maximizing behaviors, by des= ign cause self inflicted congestion which is extremely non-linear and confl= ated with many other signals. =C2=A0 =C2=A0 TCP can be used for measurement= if you somehow inhibit congestion control and=C2=A0throughput maximizing b= ehaviors, for example by clamping cwnd.

=
Thanks,
--MM--
The best way to predict the future is to create= it. =C2=A0- Alan Kay

Privacy matters!=C2=A0 We know from recent eve= nts that people are using our services to speak in defiance of unjust gover= nments. =C2=A0 We treat privacy and security as matters of life and death, = because for some users, they are.

On Fri, Apr 24, 2015 at 8:42 AM, Mirja K=C3= =BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> w= rote:
Hi Matt, hi Al,

I'm in the process of reviewing draft-ietf-ippm-model-based-metrics-04.= .. and I have to say I'm a little lost... :-(

I understand the idea but it's really hard to follow what the document = is giving me and what not. In the abstract it says that the doc will define= a class of metrics...not sure the document is actually defining metrics...= than later (2. half of intro) it says it "describes a framework for d= eriving traffic patterns and delivery statistics for model based metrics&qu= ot; but don't really think you can talk about a framework here. So from= my point of view the document describes (as state above) traffic pattern a= nd to some extent statistics plus gives a little bit of example and a lot o= f motivational text (which I believe could maybe be organized better).

To make my mind up what I'm actually reading I came up with the followi= ng drawing:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0______= _____=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
Input Parameter -->|=C2=A0 Model=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Measurement |<-- Traffic generator
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------= -----=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 Test=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 target values |=C2=A0 =C2=A0 =C2=A0 =C2= =A0/---\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| IP metrics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ------->| + |<---------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \---/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pass/fail


So in this picture, your document talks about the target values, a little b= it about the model (which is simply the TCP model) and about the traffic ge= neration but leaves out a lot of the stuff in the middle. Matt, if you have= understood you correctly, you still plan to write a document that describe= s something similar to my drawing above...? If you actually plan to do this= , I think that would be very helpful and should be published before this dr= aft (draft-ietf-ippm-model-based-metrics-04); also because most of the moti= vation and background text should rather go in that new document from my po= int of view. And just for the sake of readability, I would even think about= splitting up the current draft into potentially 2 documents (model and mea= surements/tests).

I think the most important (actually quite simple) message for this work is= : Don't use TCP for measurement traffic generator! However having every= thing in on document, I afraid that this message simply gets lost... :-(
Let me know what you think and if the diagram above is at all similar to wh= at you have in mind!

Mirja


--001a113d606af6499e05147db195-- From nobody Tue Apr 28 10:42:28 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200C51A88BE for ; Tue, 28 Apr 2015 10:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0PejkIvJ2KJ for ; Tue, 28 Apr 2015 10:42:24 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0083D1A89B1 for ; Tue, 28 Apr 2015 10:42:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0ADC0D931C; Tue, 28 Apr 2015 19:42:20 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6Hj0ioYvP6uQ; Tue, 28 Apr 2015 19:42:19 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C38E7D9319; Tue, 28 Apr 2015 19:42:19 +0200 (MEST) Message-ID: <553FC67B.4080007@tik.ee.ethz.ch> Date: Tue, 28 Apr 2015 19:42:19 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Matt Mathis References: <553A647E.7090808@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Al Morton , "ippm@ietf.org" Subject: Re: [ippm] Framework for Model Based Measurements needed? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2015 17:42:26 -0000 Hi Matt, okay, how should we continue on this? Should I finish my review and provide more detailed feedback or you do want to make another revision first? If this is going to be a larger revision, I'd definitely prefer the second option! :-) If you do a revision now, one more comment: I'd recommend to move the introductional part of section 4 as well section 4.2 (everything except the subsection 4.1) to the beginning of the doc because it a nice read and motivates the problem well. Re-Re: not using TCP: Jup, the message is not use a full TCP. And also if you don't use TCP, bandwidth is not the only metric you need to look at! These points should also be stated at the very beginning of the doc! Mirja On 24.04.2015 21:49, Matt Mathis wrote: > Thanks. Good comments. If you find it hard to follow, it has serious > problems.... :-( :-( > > A revised version of your diagram would help quite a bit as would other fixes as > you suggest. (and very much highlights things that are not clear), > > The other document would be a step up to the larger problem. E.g. how to wrap > MBM in a framework to support independently verifiable large scale measurement > that can estimate the probability that users can access the content they want, > at the performance needed to make effective use of the content. > > Re: not using TCP: the real problem is that all throughput maximizing behaviors, > by design cause self inflicted congestion which is extremely non-linear and > conflated with many other signals. TCP can be used for measurement if you > somehow inhibit congestion control and throughput maximizing behaviors, for > example by clamping cwnd. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our services > to speak in defiance of unjust governments. We treat privacy and security as > matters of life and death, because for some users, they are. > > On Fri, Apr 24, 2015 at 8:42 AM, Mirja Kühlewind > > wrote: > > Hi Matt, hi Al, > > I'm in the process of reviewing draft-ietf-ippm-model-based-metrics-04... > and I have to say I'm a little lost... :-( > > I understand the idea but it's really hard to follow what the document is > giving me and what not. In the abstract it says that the doc will define a > class of metrics...not sure the document is actually defining metrics... > than later (2. half of intro) it says it "describes a framework for deriving > traffic patterns and delivery statistics for model based metrics" but don't > really think you can talk about a framework here. So from my point of view > the document describes (as state above) traffic pattern and to some extent > statistics plus gives a little bit of example and a lot of motivational text > (which I believe could maybe be organized better). > > To make my mind up what I'm actually reading I came up with the following > drawing: > > ___________ _______________ > | | | | > Input Parameter -->| Model | | Measurement |<-- Traffic generator > | | | | > ----------- --------------- > | Test | > target values | /---\ | IP metrics > ------->| + |<--------- > \---/ > | > \/ > pass/fail > > > So in this picture, your document talks about the target values, a little > bit about the model (which is simply the TCP model) and about the traffic > generation but leaves out a lot of the stuff in the middle. Matt, if you > have understood you correctly, you still plan to write a document that > describes something similar to my drawing above...? If you actually plan to > do this, I think that would be very helpful and should be published before > this draft (draft-ietf-ippm-model-based-metrics-04); also because most of > the motivation and background text should rather go in that new document > from my point of view. And just for the sake of readability, I would even > think about splitting up the current draft into potentially 2 documents > (model and measurements/tests). > > I think the most important (actually quite simple) message for this work is: > Don't use TCP for measurement traffic generator! However having everything > in on document, I afraid that this message simply gets lost... :-( > > Let me know what you think and if the diagram above is at all similar to > what you have in mind! > > Mirja > > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Wed Apr 29 08:03:27 2015 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FD81A1A2E for ; Wed, 29 Apr 2015 08:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYn6kOlqpp5M for ; Wed, 29 Apr 2015 08:03:23 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FDC81A1A4E for ; Wed, 29 Apr 2015 08:03:12 -0700 (PDT) Received: by oica37 with SMTP id a37so23882646oic.0 for ; Wed, 29 Apr 2015 08:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jb7/1U5jI8q6bfcEtuY5yWxZcyaPpnS7U/LrIPvF7EQ=; b=KvJyIgegrT1l9tC4lEQJaWLQOg+nHjVetIbjc0veW14ST/+ICZuJVd6LVjIgNpR/eJ KSWcm6Cudfncc7NmUi3qMiB4ZQ8IWrULtjz1XHtWGgaGB+JA2R/8Nv92vhQP5qCxpf0I INcAjjpuK8L9sKKzaFk6xZ5BQbxakPBW6v/U4Ys7H/mGZeNasE7lKbF5uGovWA7Tg3Xc tnYtcpSt9jBwzqgb6dNEDoPsSjbPP8wi7SVXuKeG3RT1QpoM+cC0rsYrP39zVWe5+SmM MIHWhdquPc8pTaw2RvmGixsLya0gvGds5eVFzQvhd24cfRIpIeaz0Q2SAveUI6RwYdCI md/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jb7/1U5jI8q6bfcEtuY5yWxZcyaPpnS7U/LrIPvF7EQ=; b=Ry/lTWPoI5oOWMFiRkmiOBgBQh+UsprBSKVMVD4B4v0hCo/YtCpFd4pJWlm+6QriPq h2l3znn593ibijNeCiA2UXMzUFygYq+/d8QbaqDkNLDSE/WAyjxiCvP4qsGiLuVlV4pd veanQaIAZg1dpMmHM5szyn7HF47M8tRTEPHeZDPjP3u8DhmwJE8ANSkUxtjiXSaWeoij cqRvD8jQqFV4e8NToo+iWcTBuGv2IIVubb37lAZ4hKvpvoHXLVXRq/4l4lBRXHAghF5I 7V9EOu2acIywp8glj8xGKzoVjXmHL0NuauLQ5s1bGHAHHoJ/WeLan9qP0y/6ny0CICRg fGtQ== X-Gm-Message-State: ALoCoQmP1fJMB+jPEAkB5CwJW0BUd3l8nCXgSq6cVKZTpi9TXsIij9aVEp1WlQ0VZexRGwXuJ3Om MIME-Version: 1.0 X-Received: by 10.60.155.42 with SMTP id vt10mr18877085oeb.21.1430319791776; Wed, 29 Apr 2015 08:03:11 -0700 (PDT) Received: by 10.182.31.84 with HTTP; Wed, 29 Apr 2015 08:03:11 -0700 (PDT) In-Reply-To: <553FC67B.4080007@tik.ee.ethz.ch> References: <553A647E.7090808@tik.ee.ethz.ch> <553FC67B.4080007@tik.ee.ethz.ch> Date: Wed, 29 Apr 2015 08:03:11 -0700 Message-ID: From: Matt Mathis To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=047d7bd6bdb41ad2f00514de47ed Archived-At: Cc: Al Morton , "ippm@ietf.org" Subject: Re: [ippm] Framework for Model Based Measurements needed? X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2015 15:03:25 -0000 --047d7bd6bdb41ad2f00514de47ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oops, I missed "in the process of" Are you comfortable with Google docs and hangouts? There is an author's notes doc that I will give you write. (best for staging alternate text and diagrams). I would also be happy to give you comment/suggest permission on the source doc. (But I need a google address for you). Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Apr 28, 2015 at 10:42 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi Matt, > > okay, how should we continue on this? Should I finish my review and > provide more detailed feedback or you do want to make another revision > first? If this is going to be a larger revision, I'd definitely prefer th= e > second option! :-) > > If you do a revision now, one more comment: I'd recommend to move the > introductional part of section 4 as well section 4.2 (everything except t= he > subsection 4.1) to the beginning of the doc because it a nice read and > motivates the problem well. > > Re-Re: not using TCP: Jup, the message is not use a full TCP. And also if > you don't use TCP, bandwidth is not the only metric you need to look at! > These points should also be stated at the very beginning of the doc! > > Mirja > > > On 24.04.2015 21:49, Matt Mathis wrote: > >> Thanks. Good comments. If you find it hard to follow, it has serious >> problems.... :-( :-( >> >> A revised version of your diagram would help quite a bit as would other >> fixes as >> you suggest. (and very much highlights things that are not clear), >> >> The other document would be a step up to the larger problem. E.g. how >> to wrap >> MBM in a framework to support independently verifiable large scale >> measurement >> that can estimate the probability that users can access the content the= y >> want, >> at the performance needed to make effective use of the content. >> >> Re: not using TCP: the real problem is that all throughput maximizing >> behaviors, >> by design cause self inflicted congestion which is extremely non-linear >> and >> conflated with many other signals. TCP can be used for measurement i= f >> you >> somehow inhibit congestion control and throughput maximizing behaviors, >> for >> example by clamping cwnd. >> >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >> >> Privacy matters! We know from recent events that people are using our >> services >> to speak in defiance of unjust governments. We treat privacy and >> security as >> matters of life and death, because for some users, they are. >> >> On Fri, Apr 24, 2015 at 8:42 AM, Mirja K=C3=BChlewind >> > >> wrote: >> >> Hi Matt, hi Al, >> >> I'm in the process of reviewing >> draft-ietf-ippm-model-based-metrics-04... >> and I have to say I'm a little lost... :-( >> >> I understand the idea but it's really hard to follow what the >> document is >> giving me and what not. In the abstract it says that the doc will >> define a >> class of metrics...not sure the document is actually defining >> metrics... >> than later (2. half of intro) it says it "describes a framework for >> deriving >> traffic patterns and delivery statistics for model based metrics" bu= t >> don't >> really think you can talk about a framework here. So from my point o= f >> view >> the document describes (as state above) traffic pattern and to some >> extent >> statistics plus gives a little bit of example and a lot of >> motivational text >> (which I believe could maybe be organized better). >> >> To make my mind up what I'm actually reading I came up with the >> following >> drawing: >> >> ___________ _______________ >> | | | | >> Input Parameter -->| Model | | Measurement |<-- Traffic >> generator >> | | | | >> ----------- --------------- >> | Test | >> target values | /---\ | IP metrics >> ------->| + |<--------- >> \---/ >> | >> \/ >> pass/fail >> >> >> So in this picture, your document talks about the target values, a >> little >> bit about the model (which is simply the TCP model) and about the >> traffic >> generation but leaves out a lot of the stuff in the middle. Matt, if >> you >> have understood you correctly, you still plan to write a document th= at >> describes something similar to my drawing above...? If you actually >> plan to >> do this, I think that would be very helpful and should be published >> before >> this draft (draft-ietf-ippm-model-based-metrics-04); also because >> most of >> the motivation and background text should rather go in that new >> document >> from my point of view. And just for the sake of readability, I would >> even >> think about splitting up the current draft into potentially 2 >> documents >> (model and measurements/tests). >> >> I think the most important (actually quite simple) message for this >> work is: >> Don't use TCP for measurement traffic generator! However having >> everything >> in on document, I afraid that this message simply gets lost... :-( >> >> Let me know what you think and if the diagram above is at all simila= r >> to >> what you have in mind! >> >> Mirja >> >> >> > -- > ------------------------------------------ > Dipl.-Ing. Mirja K=C3=BChlewind > Communication Systems Group > Institute TIK, ETH Z=C3=BCrich > Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland > > Room ETZ G93 > phone: +41 44 63 26932 > email: mirja.kuehlewind@tik.ee.ethz.ch > ------------------------------------------ > --047d7bd6bdb41ad2f00514de47ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oops, I missed "in the process of"

Are you comfortable with Google docs and= hangouts?=C2=A0 There is an author's notes doc that I will give you wr= ite. (best for staging alternate text and diagrams).=C2=A0 I would also be = happy to give you comment/suggest permission on the source doc. =C2=A0(But = I need a google address for you).

Thanks,<= /div>--MM--
The best way to predict the future is to create it. =C2=A0- = Alan Kay

Privacy matters!=C2=A0 We know from recent events that peop= le are using our services to speak in defiance of unjust governments. =C2= =A0 We treat privacy and security as matters of life and death, because for= some users, they are.

On Tue, Apr 28, 2015 at 10:42 AM, Mirja K=C3= =BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> w= rote:
Hi Matt,

okay, how should we continue on this? Should I finish my review and provide= more detailed feedback or you do want to make another revision first? If t= his is going to be a larger revision, I'd definitely prefer the second = option! :-)

If you do a revision now, one more comment: I'd recommend to move the i= ntroductional part of section 4 as well section 4.2 (everything except the = subsection 4.1) to the beginning of the doc because it a nice read and moti= vates the problem well.

Re-Re: not using TCP: Jup, the message is not use a full TCP. And also if y= ou don't use TCP, bandwidth is not the only metric you need to look at!= These points should also be stated at the very beginning of the doc!

Mirja


On 24.04.2015 21:49, Matt Mathis wrote:
Thanks. Good comments.=C2=A0 =C2=A0If you find it hard to follow, it has se= rious
problems.... :-( :-(

A revised version of your diagram would help quite a bit as would other fix= es as
you suggest. (and very much highlights things that are not clear),

The other document would be a step up to the larger problem.=C2=A0 =C2=A0E.= g. how to wrap
MBM in a framework to support independently verifiable large scale measurem= ent
that can estimate the probability=C2=A0 that users can access the content t= hey want,
at the performance needed to make effective use of the content.

Re: not using TCP: the real problem is that all throughput maximizing behav= iors,
by design cause self inflicted congestion which is extremely non-linear and=
conflated with many other signals.=C2=A0 =C2=A0 =C2=A0TCP can be used for m= easurement if you
somehow inhibit congestion control and throughput maximizing behaviors, for=
example by clamping cwnd.

Thanks,
--MM--
The best way to predict the future is to create it.=C2=A0 - Alan Kay

Privacy matters!=C2=A0 We know from recent events that people are using our= services
to speak in defiance of unjust governments.=C2=A0 =C2=A0We treat privacy an= d security as
matters of life and death, because for some users, they are.

On Fri, Apr 24, 2015 at 8:42 AM, Mirja K=C3=BChlewind
<mi= rja.kuehlewind@tik.ee.ethz.ch <mailto:mirja.kuehlewind@tik.ee.ethz.ch&= gt;> wrote:

=C2=A0 =C2=A0 Hi Matt, hi Al,

=C2=A0 =C2=A0 I'm in the process of reviewing draft-ietf-ippm-model-bas= ed-metrics-04...
=C2=A0 =C2=A0 and I have to say I'm a little lost... :-(

=C2=A0 =C2=A0 I understand the idea but it's really hard to follow what= the document is
=C2=A0 =C2=A0 giving me and what not. In the abstract it says that the doc = will define a
=C2=A0 =C2=A0 class of metrics...not sure the document is actually defining= metrics...
=C2=A0 =C2=A0 than later (2. half of intro) it says it "describes a fr= amework for deriving
=C2=A0 =C2=A0 traffic patterns and delivery statistics for model based metr= ics" but don't
=C2=A0 =C2=A0 really think you can talk about a framework here. So from my = point of view
=C2=A0 =C2=A0 the document describes (as state above) traffic pattern and t= o some extent
=C2=A0 =C2=A0 statistics plus gives a little bit of example and a lot of mo= tivational text
=C2=A0 =C2=A0 (which I believe could maybe be organized better).

=C2=A0 =C2=A0 To make my mind up what I'm actually reading I came up wi= th the following
=C2=A0 =C2=A0 drawing:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ___________=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 Input Parameter -->|=C2=A0 Model=C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| Measurement |<-- Traffic generator
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -----------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 Test=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0target values |=C2= =A0 =C2=A0 =C2=A0 =C2=A0/---\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| IP metrics=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------->| + |<---------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\---/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pass/fail


=C2=A0 =C2=A0 So in this picture, your document talks about the target valu= es, a little
=C2=A0 =C2=A0 bit about the model (which is simply the TCP model) and about= the traffic
=C2=A0 =C2=A0 generation but leaves out a lot of the stuff in the middle. M= att, if you
=C2=A0 =C2=A0 have understood you correctly, you still plan to write a docu= ment that
=C2=A0 =C2=A0 describes something similar to my drawing above...? If you ac= tually plan to
=C2=A0 =C2=A0 do this, I think that would be very helpful and should be pub= lished before
=C2=A0 =C2=A0 this draft (draft-ietf-ippm-model-based-metrics-04); also bec= ause most of
=C2=A0 =C2=A0 the motivation and background text should rather go in that n= ew document
=C2=A0 =C2=A0 from my point of view. And just for the sake of readability, = I would even
=C2=A0 =C2=A0 think about splitting up the current draft into potentially 2= documents
=C2=A0 =C2=A0 (model and measurements/tests).

=C2=A0 =C2=A0 I think the most important (actually quite simple) message fo= r this work is:
=C2=A0 =C2=A0 Don't use TCP for measurement traffic generator! However = having everything
=C2=A0 =C2=A0 in on document, I afraid that this message simply gets lost..= . :-(

=C2=A0 =C2=A0 Let me know what you think and if the diagram above is at all= similar to
=C2=A0 =C2=A0 what you have in mind!

=C2=A0 =C2=A0 Mirja



--
------------------------------------------
Dipl.-Ing. Mirja K=C3=BChlewind
Communication Systems Group
Institute TIK, ETH Z=C3=BCrich
Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: mirja.kuehlewind@tik.ee.ethz.ch
------------------------------------------

--047d7bd6bdb41ad2f00514de47ed--