From nobody Thu Mar 1 03:34:36 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989B812E039; Thu, 1 Mar 2018 03:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 iPquNwqF0gQx; Thu, 1 Mar 2018 03:34:31 -0800 (PST) Received: from mx03.telecomitalia.it (mx03.telecomitalia.it [217.169.121.23]) (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 D9F9F12E03E; Thu, 1 Mar 2018 03:34:30 -0800 (PST) X-AuditID: d9a97917-c4dff7000000441d-7e-5a97e544387c Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx03.telecomitalia.it () with SMTP id 0C.52.17437.445E79A5; Thu, 1 Mar 2018 12:34:28 +0100 (CET) From: Fioccola Giuseppe To: "ippm@ietf.org" CC: "ippm-chairs@ietf.org" , "'draft-fioccola-ippm-multipoint-alt-mark@ietf.org'" Thread-Topic: New Version Notification for draft-fioccola-ippm-multipoint-alt-mark-02.txt Thread-Index: AQHTsU7V7rQcb/5470iGpE046yag9qO7PCrA Date: Thu, 1 Mar 2018 11:34:28 +0000 Message-ID: <334a5f46a1fb41c193ba7404817bafe8@TELMBXB02RM001.telecomitalia.local> References: <151990302380.10159.4078315173781040253.idtracker@ietfa.amsl.com> In-Reply-To: <151990302380.10159.4078315173781040253.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.247] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAKsWRmVeSWpSXmKPExsXCxfdHWtfl6fQog9V/NSx2Nkxit1i9o5vN oufBO2YHZo8lS34yBTBGNTDaJObl5ZcklqQqpKQWJ9squWQWJ+ckZuamFimEpOakJufnKilk ptgqGSspFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0td QyW7wNLU4pJ8hdzU4uLE9PTMfIXUhPWCGXfXvmYr2CZdsXHzfZYGxjtSXYycHBICJhLz3y1h 7WLk4hASmMIk0d++kgUkwSZgI3Hw1Qk2EFtEQFmi5dsfRpAiZoF5jBIvF/aAJYQFIiUurr3I DlEULfHxcyeUbSSx6/5asBoWARWJB7tugA3lFQiUWL7xCyOILSTgK3Hmx11WEJtTwE/iVutP sBpGAVmJCbsXgdUwC4hLvJh+gh3iUgGJJXvOM0PYohIvH/9jhbANJLYu3ccCYStKrG6ezwRh y0gsPDIZqIYDaI6mxPpd+hAjFSWmdD9khzhHUOLkzCcsExjFZiHZNguhYxaSjllIOhYwsqxi FM2tMDDWK4FEX2ZJYk5mol5mySZGYLK4ubJSfAdj+0rnQ4wCHIxKPLyNl6dHCbEmlhVX5h5i lOBgVhLhPb19WpQQb0piZVVqUX58UWlOavEhRh9geE1klhJNzgcmsrySeEMTC0tDYwsLI0ML M1McwkrivMsrgWYJpAPTV3ZqakFqEcw4Jg5OqQbGF7x6DoLiq5Q3bAg79bRnBuOhbcrtDe1m K1csEL3geebP5E3bD3t84Ntzy/nS11i9zQv27Xfcz/soaKFIjM6hZgGBrx0Mcouu3+SIWpMh GhznPTfaXrK+XkzGLv5Xe9JaN61LEX6vPP7djahicFq5/jO7zu7PMprLo3LeelT8N7f0Oavg 5MGpxFKckWioxVxUnAgAbWSOCUMDAAA= Archived-At: Subject: [ippm] I: New Version Notification for draft-fioccola-ippm-multipoint-alt-mark-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Mar 2018 11:34:34 -0000 SGkgQWxsLA0KVGhpcyBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQsIGFzIGRldmVsb3BtZW50 IG9mIFJGQyA4MzIxLCBhZGRyZXNzZXMgc29tZSByZWNlaXZlZCBjb21tZW50cy4NCkluIHBh cnRpY3VsYXIgd2UgaGF2ZSBkZXRhaWxlZCBhIHBvc3NpYmxlIGFsZ29yaXRobSBmb3IgQ2x1 c3RlciBwYXJ0aXRpb24gYW5kIGluY2x1ZGVkIHRoZSByZWZlcmVuY2UgdG8gZHJhZnQtYW1m LWlwcG0tcm91dGUgdGhhdCBjYW4gaGVscCB3aXRoIHRoZSBidWlsZGluZyBvZiB0aGUgbW9u aXRvcmluZyBuZXR3b3JrIGdyYXBoLg0KQWxzbywgdGhlIGRlc2NyaXB0aW9uIG9mIGhvdyB0 byB1c2UgUkZDNTQ3NSBjb3VwbGVkIHdpdGggYWx0ZXJuYXRlIG1hcmtpbmcgaGFzIGJlZW4g cmVwb3J0ZWQuDQoNCkZlZWRiYWNrcyBhcmUgYWx3YXlzIHdlbGNvbWUuDQoNCkJlc3QgUmVn YXJkcywNCg0KR2l1c2VwcGUNCg0KLS0tLS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRh OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0KSW52aWF0bzogZ2lvdmVkw6wgMSBtYXJ6byAyMDE4IDEyOjE3DQpBOiBSaWNj YXJkbyBTaXN0bzsgRmlvY2NvbGEgR2l1c2VwcGU7IENvY2lnbGlvIE1hdXJvOyBBbWVkZW8g U2FwaW8NCk9nZ2V0dG86IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmlv Y2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1maW9jY29sYS1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmstMDIu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdpdXNlcHBlIEZpb2Nj b2xhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LWZpb2Njb2xhLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyaw0KUmV2aXNpb246CTAyDQpUaXRs ZToJCU11bHRpcG9pbnQgQWx0ZXJuYXRlIE1hcmtpbmcgbWV0aG9kIGZvciBwYXNzaXZlIGFu ZCBoeWJyaWQgcGVyZm9ybWFuY2UgbW9uaXRvcmluZw0KRG9jdW1lbnQgZGF0ZToJMjAxOC0w My0wMQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTUNClVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt ZmlvY2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrLTAyLnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpb2Njb2xhLWlw cG0tbXVsdGlwb2ludC1hbHQtbWFyay8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZmlvY2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJr LTAyDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1maW9jY29sYS1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmstMDINCkRpZmY6 ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZmlv Y2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrLTAyDQoNCkFic3RyYWN0Og0KICAgVGhl IEFsdGVybmF0ZSBNYXJraW5nIG1ldGhvZCwgYXMgcHJlc2VudGVkIGluIFJGQyA4MzIxIFtS RkM4MzIxXSwgY2FuDQogICBiZSBhcHBsaWVkIG9ubHkgdG8gcG9pbnQtdG8tcG9pbnQgZmxv d3MgYmVjYXVzZSBpdCBhc3N1bWVzIHRoYXQgYWxsDQogICB0aGUgcGFja2V0cyBvZiB0aGUg ZmxvdyBtZWFzdXJlZCBvbiBvbmUgbm9kZSBhcmUgbWVhc3VyZWQgYWdhaW4gYnkgYQ0KICAg c2luZ2xlIHNlY29uZCBub2RlLiAgVGhpcyBkb2N1bWVudCBhaW1zIHRvIGdlbmVyYWxpemUg YW5kIGV4cGFuZCB0aGlzDQogICBtZXRob2RvbG9neSB0byBtZWFzdXJlIGFueSBraW5kIG9m IHVuaWNhc3QgZmxvd3MsIHdob3NlIHBhY2tldHMgY2FuDQogICBmb2xsb3cgc2V2ZXJhbCBk aWZmZXJlbnQgcGF0aHMgaW4gdGhlIG5ldHdvcmssIGluIHdpZGVyIHRlcm1zIGENCiAgIG11 bHRpcG9pbnQtdG8tbXVsdGlwb2ludCBuZXR3b3JrLiAgRm9yIHRoaXMgcmVhc29uIHRoZSB0 ZWNobmlxdWUgaGVyZQ0KICAgZGVzY3JpYmVkIGlzIGNhbGxlZCBNdWx0aXBvaW50IEFsdGVy bmF0ZSBNYXJraW5nLiAgU29tZSBkZWZpbml0aW9ucw0KICAgaGVyZSBpbnRyb2R1Y2VkIGV4 dGVuZCB0aGUgc2NvcGUgb2YgUkZDIDU2NDQgW1JGQzU2NDRdIGluIHRoZSBjb250ZXh0DQog ICBvZiBhbHRlcm5hdGUgbWFya2luZyBzY2hlbWEuDQoNCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9p IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25l IGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlv bmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBz b25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1 ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBk aSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2 ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoNClRoaXMgZS1tYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHku IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVs c2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFu ZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIA0KDQpSaXNw ZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5l Y2Vzc2FyaW8uDQo= From nobody Thu Mar 1 08:01:30 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F314312D72F; Thu, 1 Mar 2018 08:01:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151992008297.10164.1952428993989926884@ietfa.amsl.com> Date: Thu, 01 Mar 2018 08:01:22 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 16:01:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol Authors : Greg Mirsky Guo Jun Henrik Nydell Richard Foote Filename : draft-ietf-ippm-stamp-01.txt Pages : 14 Date : 2018-03-01 Abstract: This document describes a Simple Two-way Active Measurement Protocol which enables measurement of both one-way and round-trip performance metrics like delay, delay variation and packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-01 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 1 08:02:50 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8062812D72F; Thu, 1 Mar 2018 08:02:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151992016848.10035.2261139500604478292@ietfa.amsl.com> Date: Thu, 01 Mar 2018 08:02:48 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-yang-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 16:02:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol (STAMP) Data Model Authors : Greg Mirsky Xiao Min Wei S Luo Filename : draft-ietf-ippm-stamp-yang-01.txt Pages : 35 Date : 2018-03-01 Abstract: This document specifies the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-01 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-yang-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 1 08:39:39 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91D712EB08; Thu, 1 Mar 2018 08:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Whimmh-7syWY; Thu, 1 Mar 2018 08:39:35 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 1CA9D12EB25; Thu, 1 Mar 2018 08:39:35 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id y19so9269949lfd.4; Thu, 01 Mar 2018 08:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ACTKdx9xPsgWS7XlBbAPhsLKPIirupG3qTYdIj78l28=; b=ADg/+NxVM3To6t6cqRIsSd/8PN1i40Elr++PHVTN1LmaOYQ8Ioi4UawvzJo15owAmt bWMGXfHgb6Pq2uJs2dMLXhCghCDmkifPXBy2mLBej+vC+H4LSf48VNydxCEFRz1NaftJ KNTE2hvE7AxW+hW5igpMMrMVj1/gjDKQpxYTbnRoEalzfZoMpuWHjg6K6eaUQOGyNqVB AIEfOGyOOKXbE2H+XimAgG5jgw1jPizUeUflQEf0G58jNrABxKKFP70Z5nkK3tv6cogP oKsGjYeoET31vuthPrrxeHJHKlsxUUTT12p5THAxNMvUyGUXJ8Rz0BSoetPvhQms0iR9 XwzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ACTKdx9xPsgWS7XlBbAPhsLKPIirupG3qTYdIj78l28=; b=KLgdd6q1fGnRDD8S+WUqwXYZBg2a/jcQNNrf5j9HoE1z16wnNfsLzkOxBZ3Ttv1wsr SmMdg5uAPyHCo9mCeCLF15mcAmsKyXJe7MBLlyeqUlzQtTVQRnm5eEQf0vK9bkjdAtwi eUtIUaRcPesuNJ7Kz9o9o5sJ9/h0aymi4sfbsUtLi824taT0ual37GN1OlzfpMU4ELVT RPQ9W+bV+gerBJunQn59HPuSpof4kwoMPRevkEhbMjd8HhjO7uKIqLcGd9CwTBJbBtj0 8TjR2Unhn8HAZn3Po6sifv1bf/1CwxbE0iP5qr7U+vnI7gNdo7lbFgMvMSfd59xw9skW LT8g== X-Gm-Message-State: AElRT7H9dGg5Z3yI0csEROAYru3j4zXu6wlYMq/xNGwhgJ+tj0zuivzP X8TjJxJzKsflJrKxRHliZvxGCMGiZOsxmYAl3IEKzQ== X-Google-Smtp-Source: AG47ELveuRYdG142GuaO98qwpzeh/NrA1gsT9GclCqNuUA+0oCoxC4cD04o3TeFl3kLKYRtUFnVRfxxWHICoaiR+1Mo= X-Received: by 10.25.23.129 with SMTP id 1mr1753130lfx.143.1519922372994; Thu, 01 Mar 2018 08:39:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.145.195 with HTTP; Thu, 1 Mar 2018 08:39:32 -0800 (PST) From: Greg Mirsky Date: Thu, 1 Mar 2018 08:39:32 -0800 Message-ID: To: IPPM Chairs , ippm@ietf.org Content-Type: multipart/alternative; boundary="001a11401f2820ecbf05665c811d" Archived-At: Subject: [ippm] Presentation request for STAMP X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Mar 2018 16:39:37 -0000 --001a11401f2820ecbf05665c811d Content-Type: text/plain; charset="UTF-8" Dear Brian, Bill, et. al, we've updated STAMP base specification and YANG data model drafts and would appreciate the opportunity to present and discuss these changes in London: - STAMP base specification draft-ietf-ippm-stamp presenter: Greg Mirsky time: 10 min - STAMP YANG data model draft-ietf-ippm-stamp-yang presenter: Greg Mirsky time: 15 min We also propose to have STAMP extensions document as separate specification and have prepared the new draft: - STAMP extensions specification draft-mirsky-ippm-stamp-option-tlv presenter: Greg Mirsky time: 10 min Regards, Greg --001a11401f2820ecbf05665c811d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brian, Bill, et. al,
we've updated STAMP base= specification and YANG data model drafts and would appreciate the opportun= ity to present and discuss these changes in London:
  • STAMP= base specification=C2=A0draft-ietf-ippm-stamp=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0presenter:=C2=A0 Greg Mirsky=C2=A0 =C2=A0time: 10 min
  • = STAMP YANG data model=C2=A0draft-ietf-ippm-stamp-yang=C2=A0 presenter:=C2= =A0 Greg Mirsky=C2=A0 =C2=A0 time: 15 min
We also propose to = have STAMP extensions document as separate specification and have prepared = the new draft:
  • STAMP extensions specification=C2=A0= draft-mirsky-ippm-stamp-option-tlv=C2=A0 presenter:=C2=A0 Greg Mirsky=C2=A0= time: 10 min
Regards,
Greg
--001a11401f2820ecbf05665c811d-- From nobody Thu Mar 1 09:25:48 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD01B12EBAF for ; Thu, 1 Mar 2018 09:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 F_Ckd4AB44ka for ; Thu, 1 Mar 2018 09:25:28 -0800 (PST) Received: from cnet.fi.uba.ar (cnet.fi.uba.ar [157.92.58.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0D312EB9E for ; Thu, 1 Mar 2018 09:25:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cnet.fi.uba.ar (Postfix) with ESMTP id AA2E814006C for ; Thu, 1 Mar 2018 14:11:45 -0300 (ART) X-Virus-Scanned: Debian amavisd-new at cnet.fi.uba.ar Received: from cnet.fi.uba.ar ([127.0.0.1]) by localhost (cnet.fi.uba.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMdJCzJdXY-d for ; Thu, 1 Mar 2018 14:11:39 -0300 (ART) Received: from [192.168.1.139] (unknown [157.92.51.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cnet.fi.uba.ar (Postfix) with ESMTPSA id 22ECB140068 for ; Thu, 1 Mar 2018 14:11:39 -0300 (ART) From: J Ignacio Alvarez-Hamelin Content-Type: multipart/alternative; boundary="Apple-Mail=_38977B24-9BD3-44C0-874B-1FDE63F56427" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <9CBFCBAF-EC46-479C-8314-00FF979F9172@cnet.fi.uba.ar> References: <151984058180.5049.12543737229029818799.idtracker@ietfa.amsl.com> To: ippm@ietf.org Date: Thu, 1 Mar 2018 14:25:05 -0300 X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [ippm] Fwd: New Version Notification for draft-alavarez-hamelin-tictoc-sic-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Mar 2018 17:25:32 -0000 --Apple-Mail=_38977B24-9BD3-44C0-874B-1FDE63F56427 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, As some people ask me about this work, I am glad to send this = information. This clock synchronization protocol was conceived to = perform one-way measurements, so I think it is interesting in this = group. Hopefully, I will be in London because the IETF fellowship program, so I = will answer questions if they arise. =20 Best wishes, J. Ignacio _______________________________________________________________ Dr. Ing. Jos=C3=A9 Ignacio Alvarez-Hamelin CONICET and Facultad de Ingenier=C3=ADa, Universidad de Buenos Aires Av. Paseo Col=C3=B3n 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: ihameli@cnet.fi.uba.ar web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-alavarez-hamelin-tictoc-sic-00.txt > Date: 28 February 2018 at 14:56:21 GMT-3 > To: "Jose Alvarez-Hamelin" , "Alfredo Ortega" = , "David Samaniego" , "Jose = Ignacio Alvarez-Hamelin" , "Alfredo A. Ortega" = >=20 >=20 > A new version of I-D, draft-alavarez-hamelin-tictoc-sic-00.txt > has been successfully submitted by Jose Ignacio Alvarez-Hamelin and = posted to the > IETF repository. >=20 > Name: draft-alavarez-hamelin-tictoc-sic > Revision: 00 > Title: Synchronizing Internet Clocks (sic) > Document date: 2018-02-28 > Group: Individual Submission > Pages: 20 > URL: = https://www.ietf.org/internet-drafts/draft-alavarez-hamelin-tictoc-sic-00.= txt > Status: = https://datatracker.ietf.org/doc/draft-alavarez-hamelin-tictoc-sic/ > Htmlized: = https://tools.ietf.org/html/draft-alavarez-hamelin-tictoc-sic-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-alavarez-hamelin-tictoc-sic-00= >=20 >=20 > Abstract: > This memo introduces a new secure method to synchronize difference > clocks on the Internet, assuring smoothness (i.e., frequency > stability) and robustness to man-in-the-middle attacks. This type = of > synchronization is useful for some kind of measurements, like > traffic, load, or relative time measurements. The "sic" proposal is > highly accurate, with an MTIE (Maximum Time Interval Error) less = than > 25 microseconds by a minute for the 90% of the cases, and it is = based > on a regular packets exchange. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat --Apple-Mail=_38977B24-9BD3-44C0-874B-1FDE63F56427 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all,

As some people ask me about this work, = I am glad to send this information. This clock synchronization protocol = was conceived to perform one-way measurements, so I think it is = interesting in this group.
Hopefully, I will be in = London because the IETF fellowship program, so I will answer questions = if they arise.  

Best wishes,

J. Ignacio


_______________________________________________________________=

Dr. Ing. Jos=C3=A9 = Ignacio Alvarez-Hamelin
CONICET and Facultad de Ingenier=C3=ADa, = Universidad de Buenos Aires
Av. Paseo Col=C3=B3n 850 - C1063ACV - Buenos = Aires - Argentina
+54 (11) 5285 0716 = / 5285 0705
e-mail: = ihameli@cnet.fi.uba.ar
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________=



Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-alavarez-hamelin-tictoc-sic-00.txt
Date: = 28 February 2018 at 14:56:21 = GMT-3
To: = "Jose Alvarez-Hamelin" <ihameli@cnet.fi.uba.ar>, "Alfredo Ortega" <ortegaalfredo@gmail.com>, "David Samaniego" <dsamanie@fi.uba.ar>, = "Jose Ignacio Alvarez-Hamelin" <ihameli@cnet.fi.uba.ar>, "Alfredo A. Ortega" <ortegaalfredo@gmail.com>


A new version = of I-D, draft-alavarez-hamelin-tictoc-sic-00.txt
has been = successfully submitted by Jose Ignacio Alvarez-Hamelin and posted to = the
IETF repository.

Name: = draft-alavarez-hamelin-tictoc-sic
Revision: 00
Title:= = Synchronizing Internet Clocks (sic)
Document = date: = 2018-02-28
Group: Individual Submission
Pages:= = 20
URL: =            https://www.ietf.org/internet-drafts/draft-alavarez-hamelin-tic= toc-sic-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-alavarez-hamelin-tictoc-= sic/
Htmlized:       https://tools.ietf.org/html/draft-alavarez-hamelin-tictoc-sic-0= 0
Htmlized:       https://datatracker.ietf.org/doc/html/draft-alavarez-hamelin-ti= ctoc-sic-00


Abstract:
  This memo introduces a new secure method to = synchronize difference
  clocks on the = Internet, assuring smoothness (i.e., frequency
=   stability) and robustness to man-in-the-middle attacks. =  This type of
  synchronization is useful = for some kind of measurements, like
  traffic, = load, or relative time measurements.  The "sic" proposal is
  highly accurate, with an MTIE (Maximum Time = Interval Error) less than
  25 microseconds by = a minute for the 90% of the cases, and it is based
=   on a regular packets exchange.





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

The IETF = Secretariat

= --Apple-Mail=_38977B24-9BD3-44C0-874B-1FDE63F56427-- From nobody Thu Mar 1 11:58:32 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABDD12FA82 for ; Thu, 1 Mar 2018 11:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.onmicrosoft.com 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 YkQfd0uary73 for ; Thu, 1 Mar 2018 11:58:28 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0060.outbound.protection.outlook.com [104.47.40.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1216B12FA71 for ; Thu, 1 Mar 2018 11:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iDSADoXAIsdXCaf5E6lE1/jtQlU3TrJbe2xNvKcQ2TU=; b=UELoQql3EIl+84G9Aux0SSpBl1cdh5oqREG9Bv6rHCQByDwJKr6gqQKQCsGvDKhAZs4RVulDcX66GuCvkvUdaYrK+XuQbB7pMrd9p/Rk9mHqO7E3/UU62JJDQ4redAjduqrb3CF4wdpzTAoqqBUwXEl7wRcxhuQFYOWDjEYv50I= Received: from CY4PR10MB1717.namprd10.prod.outlook.com (10.172.68.144) by CY4PR10MB1287.namprd10.prod.outlook.com (10.169.253.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Thu, 1 Mar 2018 19:58:25 +0000 Received: from CY4PR10MB1717.namprd10.prod.outlook.com ([fe80::88f:1f26:85ab:78ca]) by CY4PR10MB1717.namprd10.prod.outlook.com ([fe80::88f:1f26:85ab:78ca%17]) with mapi id 15.20.0527.022; Thu, 1 Mar 2018 19:58:23 +0000 From: Madhukar Anand To: "ippm@ietf.org" CC: Sanjoy Bardhan , Randy Zhang , Ramesh Subrahmaniam , Radhakrishna Valiveti , Shwetha Bhandari , "Radhakrishna Valiveti" , Carlos Pignataro , Rajiv Asati Thread-Topic: New Version Notification for draft-anand-ippm-po-ioam-00.txt Thread-Index: AQHTry5xgp3FxGSfdESU7KK632lBJaO70Eqw Date: Thu, 1 Mar 2018 19:58:23 +0000 Message-ID: References: <151966920728.21787.3479650063380468990.idtracker@ietfa.amsl.com> In-Reply-To: <151966920728.21787.3479650063380468990.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAnand@infinera.com; x-originating-ip: [8.4.225.31] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR10MB1287; 7:tD7okoBXl2CkSqgFxO2Ra6IpnTowMw2j4JE8dgDffzU1v02RGMb+FMkM/uRZAyUy3SIGjDGW+C4VaB3jcT0e1byygYVKxPzZ/jsybjVU2T26rm/cwEe+NZaEnbL6FGgZRbcR2d1tnC2XEhqbtKnGLwrNt9DS1zyQg4VaQdtRQv6mfgurhYrJ960MjLz00zqgImzj0UtS5G4NYjotLytKQGJfZGuMuHiHAArrSHXgn9YsXHc0sbDkcPzJSYTvwjaU x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(39860400002)(346002)(39380400002)(199004)(189003)(13464003)(377424004)(53754006)(2906002)(15650500001)(99286004)(6306002)(26005)(33656002)(106356001)(9686003)(55016002)(305945005)(6436002)(186003)(5660300001)(74316002)(68736007)(478600001)(4326008)(316002)(6916009)(2950100002)(561944003)(53546011)(105586002)(97736004)(229853002)(25786009)(6506007)(80792005)(102836004)(59450400001)(39060400002)(6246003)(8936002)(8676002)(86362001)(1730700003)(5250100002)(2501003)(5890100001)(2351001)(7696005)(14454004)(53936002)(3846002)(6116002)(81156014)(3280700002)(7736002)(2900100001)(76176011)(66066001)(3660700001)(5640700003)(81166006)(54906003)(72206003)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR10MB1287; H:CY4PR10MB1717.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: c4b3813a-1aad-4fd4-1572-08d57faeca62 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR10MB1287; x-ms-traffictypediagnostic: CY4PR10MB1287: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014)(201166117486090); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231220)(944501224)(93006095)(93001095)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR10MB1287; BCL:0; PCL:0; RULEID:; SRVR:CY4PR10MB1287; x-forefront-prvs: 05986C03E0 received-spf: None (protection.outlook.com: infinera.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ExDC1pg8sXaPZcRDCLZLYTJDM2aGL9G+bH5CmLBsfjDzb/vffnbqfLbb7t1eSi8huQPmaHSQkBYD2H7KkKyGxxeJOhfaLx36u+ucPsDSKfX0d7jWQRZf2PciemUlDtwyWImdFnawvEbLMIOlinwzWUz10ixy+uStCnk+Fkfig6I= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4b3813a-1aad-4fd4-1572-08d57faeca62 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2018 19:58:23.7693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1287 Archived-At: Subject: Re: [ippm] New Version Notification for draft-anand-ippm-po-ioam-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 01 Mar 2018 19:58:30 -0000 SGkgQWxsLA0KDQogUGxlYXNlIGZpbmQgYmVsb3cgYSBwcm9wb3NhbCBmb3IgZXh0ZW5kaW5nIElP QU0gdG8gb3B0aWNhbC90cmFuc3BvcnQgbmV0d29ya3MuIFBsZWFzZSByZXZpZXcgYW5kIGxldCB1 cyBrbm93IG9mIGFueSBjb21tZW50cyBvciBzdWdnZXN0aW9ucyB5b3UgbWF5IGhhdmUuIA0KDQpU aGFua3MsDQpNYWRodWthcg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNiwgMjAxOCAxMDoyMCBBTQ0KVG86IFNh bmpveSBCYXJkaGFuIDxzYmFyZGhhbkBpbmZpbmVyYS5jb20+OyBSYW5keSBaaGFuZyA8cmFuemhh bmdAY2lzY28uY29tPjsgUmFtZXNoIFN1YnJhaG1hbmlhbSA8c3ZyX2ZyZW1vbnRAeWFob28uY29t PjsgTWFkaHVrYXIgQW5hbmQgPE1BbmFuZEBpbmZpbmVyYS5jb20+OyBSYWRoYWtyaXNobmEgVmFs aXZldGkgPHJ2YWxpdmV0aUBpbmZpbmVyYS5jb20+OyBTaHdldGhhIEJoYW5kYXJpIDxzaHdldGhh YkBjaXNjby5jb20+OyBSYWRoYWtyaXNobmEgVmFsaXZldGkgPHJ2YWxpdmV0aUBpbmZpbmVyYS5j b20+OyBDYXJsb3MgUGlnbmF0YXJvIDxjcGlnbmF0YUBjaXNjby5jb20+OyBSYWppdiBBc2F0aSA8 cmFqaXZhQGNpc2NvLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtYW5hbmQtaXBwbS1wby1pb2FtLTAwLnR4dA0KDQpDQVVUSU9OOiBUaGlzIGVtYWlsIG9y aWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBs aW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIg YW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtYW5hbmQtaXBwbS1wby1pb2FtLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IE1hZGh1a2FyIEFuYW5kIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWFuYW5kLWlwcG0tcG8taW9hbQ0KUmV2aXNpb246 ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgSW50ZWdyYXRlZCBQYWNrZXQtT3B0aWNhbCBJbi1T aXR1IE9BTQ0KRG9jdW1lbnQgZGF0ZTogIDIwMTgtMDItMjYNCkdyb3VwOiAgICAgICAgICBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxMg0KVVJMOiAgICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hbmFuZC1pcHBtLXBvLWlv YW0tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtYW5hbmQtaXBwbS1wby1pb2FtLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbmFuZC1pcHBtLXBvLWlvYW0tMDANCkh0bWxpemVkOiAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWFuYW5kLWlw cG0tcG8taW9hbS0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBh IHdheSB0byBleHRlbmQgaW4tc2l0dSBPQU0gdGVjaG5pcXVlcyB0bw0KICAgaW5jbHVkZSBvcGVy YXRpb25hbCBkYXRhIGZyb20gbXVsdGlwbGUgbmV0d29yayBsYXllcnMgd2l0aCBhIHZpZXcgdG8N CiAgIGNyZWF0ZSBhbiBpbnRlZ3JhdGVkIHJlY29yZCBvZiBPQU0gaW5mb3JtYXRpb24gYXMgdGhl IGRhdGEgZmxvd3MNCiAgIGJldHdlZW4gdHdvIG5ldHdvcmsgZW50aXRpZXMuIEFuIGluc3RhbmNl IG9mIHRoaXMgdGVjaG5pcXVlIHRoYXQgaXMNCiAgIGVsYWJvcmF0ZWQgaGVyZSBmb2N1c2VzIG9u IHBhY2tldC1vcHRpY2FsIG5ldHdvcmtzIHRoYXQgYXJlDQogICB0cmFkaXRpb25hbGx5IHRyYW5z cG9ydCBjZW50cmljLiBUaGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgYXJlIGdlbmVyYWwNCiAgIGVu b3VnaCB0byBhbGxvdyBmdXR1cmUgZXh0ZW5zaWJpbGl0eSBvZiBpbi1zaXR1IE9BTSB0ZWNobmlx dWVzIGludG8NCiAgIG90aGVyIG5vbi1wYWNrZXQgZG9tYWlucy4NCg0KDQoNCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Mar 1 13:53:37 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7611201FA; Thu, 1 Mar 2018 13:53:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151994121110.21556.122672381804256020@ietfa.amsl.com> Date: Thu, 01 Mar 2018 13:53:31 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-2330-ipv6-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 21:53:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework Authors : Al Morton Joachim Fabini Nalini Elkins Michael S. Ackermann Vinayak Hegde Filename : draft-ietf-ippm-2330-ipv6-03.txt Pages : 14 Date : 2018-03-01 Abstract: This memo updates the IP Performance Metrics (IPPM) Framework RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets in RFC 2330 to include IPv6 packets, deprecates the definition of minimum standard- formed packet, and augments distinguishing aspects of packets, referred to as Type-P for test packets in RFC 2330. This memo identifies that IPv4-IPv6 co-existence can challenge measurements within the scope of the IPPM Framework. Exemplary use cases include, but are not limited to IPv4-IPv6 translation, NAT, protocol encapsulation, IPv6 header compression, or use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-2330-ipv6-03 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-2330-ipv6-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-2330-ipv6-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 2 13:23:33 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80426124239; Fri, 2 Mar 2018 13:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ojaKctnLKI6L; Fri, 2 Mar 2018 13:23:31 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 9FE2F12025C; Fri, 2 Mar 2018 13:23:30 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id h127so14197538lfg.12; Fri, 02 Mar 2018 13:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=f4gtgCh6JTPtYC3+k+Oxj/atc+ttvVDqLY5x6FpT46E=; b=qsQFcFQqdrCst1efZIMWlh77oyDADOXIenga9GfaAH93VsPpTSCVzxLz/oVhU322CG b0kGnqRKaeL8q2b8qKeaMTyyDELCJKP3wz27NJ6dGHRFgxA4jEA3X5XfTaTKxdcGaqs5 7tfoBEeCiWtBTMYjjYwcGFiamqjAQ+Ci24ZokLLqISkv5sZngE1rx16+hP52BoDdwB7i piACtda8qfFIh/u1Fh0zwIcP55ojnQu3D89KZ6MpzEoiE0XD06pvxMgNGAGErm2HzBnM vP006UgP5IuUfhwZ7/OBaE4RQULG6qzKm+SYE3BmEadOqdjaliUFePADQ/X2q2DGVPY8 d2Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=f4gtgCh6JTPtYC3+k+Oxj/atc+ttvVDqLY5x6FpT46E=; b=UH6mNTuFf3oKho6ML8ZsFQPEyEaLWDdZMRzdvr9eELsSo+4j1a5SiZES600XWSJZWq +X74CKjSL9coE+7vYDrXcfaiG3cf9tDjfHlWx90x/RpeqEXg8Gipse9HY+wLprtnMAaK xThi5X7NytudolZDeSp/qjTClqT9wdC720dEQuJeGAooxMfJpRie5q5ISr+gCWZ24Z7M 6yX4IDsW6uQRxEt16J/dy1qxVf/TjR8IHxtyJC3BD+biqUZjDWfe6LAnRBh36w1ptN0y PvFDPauuHAIOKLiM4dd/H1TYDVD24pzPG3pJLOFEyGFfwzdReINVXOczVFBFBCeAFiMg jQRg== X-Gm-Message-State: APf1xPDusdohk+2wt93UfmfoBjc72xYyvueakD93+GAmcmfM1arVBBoD We4SEX6vdeI0RY6S+s55kbvjBG6sqdzajAkuSdfHVQ== X-Google-Smtp-Source: AG47ELsjdDjcBg0V3w6KQzD//OPWWO0Ycd+6smgSinST2iwuS7oK5qoxcUy39zS6TijdmNQsRUSwShUX5DUhl3myPqs= X-Received: by 10.46.69.85 with SMTP id s82mr4716963lja.19.1520025808637; Fri, 02 Mar 2018 13:23:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.145.195 with HTTP; Fri, 2 Mar 2018 13:23:27 -0800 (PST) From: Greg Mirsky Date: Fri, 2 Mar 2018 13:23:27 -0800 Message-ID: To: IPPM Chairs , ippm@ietf.org Content-Type: multipart/alternative; boundary="001a114b0fce5f94f80566749615" Archived-At: Subject: [ippm] Presentation slot request at IETF-101 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 02 Mar 2018 21:23:32 -0000 --001a114b0fce5f94f80566749615 Content-Type: text/plain; charset="UTF-8" Dear Brian and Bill, would appreciate the opportunity to present and discuss the new hybrid measurement method: Hybrid Two-Step Performance Measurement Method draft-mirsky-ippm-hybrid-two- step presenter: Greg Mirsky time: 10 min Regards, Greg --001a114b0fce5f94f80566749615 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brian and Bill,
would appreciate the opportunity to present and discuss the new hybr= id measurement method:

Hybri= d Two-Step Performance Measurement Method=C2=A0draft-mirsky= -ippm-hybrid-two-step=C2=A0 pr= esenter:=C2=A0 =C2=A0Greg Mirsky=C2=A0 =C2=A0time:=C2=A0 10 min

Regards,
Greg
--001a114b0fce5f94f80566749615-- From nobody Sun Mar 4 03:20:08 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DB3120454; Sun, 4 Mar 2018 03:20:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152016240225.12029.5246578247603798263@ietfa.amsl.com> Date: Sun, 04 Mar 2018 03:20:02 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-metric-registry-14.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 11:20:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Registry for Performance Metrics Authors : Marcelo Bagnulo Benoit Claise Philip Eardley Al Morton Aamer Akhter Filename : draft-ietf-ippm-metric-registry-14.txt Pages : 34 Date : 2018-03-04 Abstract: This document defines the format for the Performance Metrics registry and defines the IANA Registry for Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-metric-registry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-14 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-metric-registry-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-metric-registry-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 4 03:21:23 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8FA120454; Sun, 4 Mar 2018 03:21:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152016248221.12033.11814085195178225678@ietfa.amsl.com> Date: Sun, 04 Mar 2018 03:21:22 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-initial-registry-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 11:21:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Initial Performance Metric Registry Entries Authors : Al Morton Marcelo Bagnulo Philip Eardley Kevin D'Souza Filename : draft-ietf-ippm-initial-registry-06.txt Pages : 93 Date : 2018-03-04 Abstract: This memo defines the Initial Entries for the Performance Metrics Registry. This version includes: * Revised implementation of Passive TCP RTT metrics in section 10 (Adding HandShake metric). * remaining question on DNS measurement method(s) Still need: Add MBM metric entry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-initial-registry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-06 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-initial-registry-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-initial-registry-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 4 14:06:34 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA7C124217; Sun, 4 Mar 2018 14:06:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Trammell To: X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Nevil Brownlee , ippm-chairs@ietf.org, ippm@ietf.org, Brian Trammell , n.brownlee@auckland.ac.nz, iesg-secretary@ietf.org Message-ID: <152020119324.27992.3702596849698320510.idtracker@ietfa.amsl.com> Date: Sun, 04 Mar 2018 14:06:33 -0800 Archived-At: Subject: [ippm] Publication has been requested for draft-ietf-ippm-2330-ipv6-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 22:06:33 -0000 Brian Trammell has requested publication of draft-ietf-ippm-2330-ipv6-03 as Informational on behalf of the IPPM working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/ From nobody Sun Mar 4 20:09:08 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39132126C19 for ; Sun, 4 Mar 2018 20:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 nLbqHK5d0tfy for ; Sun, 4 Mar 2018 20:09:05 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05B1124C27 for ; Sun, 4 Mar 2018 20:09:05 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2C2D820711 for ; Sun, 4 Mar 2018 23:09:05 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 04 Mar 2018 23:09:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:reply-to:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=CmFJDT0Nd41U/mnBs0eUfZLukl/yQquO8DC4BftSI cM=; b=RWGXyd7TrGOLGArVFM1mEULSFUYYSi9xEnwsE0IjPP3tNABqKzfFQfyE/ Njy1TeG81Pzn6oxFoqFjvU28oupDrMn6X9m/pDd+EpyT3YHXsyq4xwob65sINVBU PtahM5+UxHJ4R0h2RtD1frR6TCG9IiKfK3nHW4GB1w+ZhBu/AL1DXW6u1hRMMmIs /1V6B9tA6PQSmu2jeZR0hpnTB7sApXewQOShvOYaYsLyu6GGAPGfmbkp0Z5jwoYW Bxlxbep1fcJ/SLKK+De+PCQ+BgteXRA8PPZ8YYHJ2bhSKvB7yrDshfjfVRcxkKtw JjoOCFe8SpOrEv8MGOaoAEsyQwvyw== X-ME-Sender: Received: from [192.168.1.127] (unknown [97.87.239.43]) by mail.messagingengine.com (Postfix) with ESMTPA id D6770247A9 for ; Sun, 4 Mar 2018 23:09:04 -0500 (EST) From: Bill Cerveny Content-Type: multipart/alternative; boundary="Apple-Mail=_E005F5C9-84A5-4736-B172-EAFE44DEB9D9" Reply-To: IPPM Chairs Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Sun, 4 Mar 2018 23:08:58 -0500 To: IETF IPPM WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [ippm] Draft IPPM agenda for IETF 101 in London X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 04:09:07 -0000 --Apple-Mail=_E005F5C9-84A5-4736-B172-EAFE44DEB9D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have posted the first draft of the IETF 101 (London) IPPM working = group agenda at https://datatracker.ietf.org/doc/agenda-101-ippm/ = Note that time has been allocated for discussion of all working groups = drafts. Talks on all other documents are being presented as lightning = talks (5 minutes enforced as time permits). Best Regards, Bill Cerveny IPPM working group co-chair= --Apple-Mail=_E005F5C9-84A5-4736-B172-EAFE44DEB9D9 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I have posted the first draft of the IETF 101 (London) IPPM working group agenda at https://datatracker.ietf.org/doc/agenda-101-ippm/

Note that time has been allocated for discussion of all working groups drafts. Talks on all other documents are being presented as lightning talks (5 minutes enforced as time permits).

Best Regards,

Bill Cerveny
IPPM working group co-chair
--Apple-Mail=_E005F5C9-84A5-4736-B172-EAFE44DEB9D9-- From nobody Mon Mar 5 01:44:39 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B966128961; Mon, 5 Mar 2018 01:44:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152024306737.27852.3855796339234730917@ietfa.amsl.com> Date: Mon, 05 Mar 2018 01:44:27 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-data-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 09:44:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Data Fields for In-situ OAM Authors : Frank Brockners Shwetha Bhandari Carlos Pignataro Hannes Gredler John Leddy Stephen Youell Tal Mizrahi David Mozes Petr Lapukhov Remy Chang Daniel Bernier John Lemon Filename : draft-ietf-ippm-ioam-data-02.txt Pages : 34 Date : 2018-03-05 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for in-situ OAM. In-situ OAM data fields can be embedded into a variety of transports such as NSH, Segment Routing, Geneve, native IPv6 (via extension header), or IPv4. In-situ OAM can be used to complement OAM mechanisms based on e.g. ICMP or other types of probe packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-02 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-data-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 02:29:32 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF3712783A for ; Mon, 5 Mar 2018 02:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 pDH9YIYBtoJ8 for ; Mon, 5 Mar 2018 02:29:29 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988451241FC for ; Mon, 5 Mar 2018 02:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18544; q=dns/txt; s=iport; t=1520245769; x=1521455369; h=from:to:subject:date:message-id:mime-version; bh=EsU2xvixKSXP07DhzM+3v39MlSlGzd9idD0cMJ+tPEg=; b=VHzKpH+v+vEZCMa1QYLOwY7+sGTluCFar2y9QHeuO+k25dF3uqgrqI4d cmnGCm1rMGG0eNIBransEpZZBnuaBlC6xWoLPw5fC+fYwxPodYf71U8qU kogJ4Mt3xIiyUEpy7LM2ERldOmfYYTjJyWKHuGNJ5BHp8+v3FXqGNkHaN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AACVG51a/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJadmZwKAqNbo14gxiUNIIVCiOHdyE0GAECAQEBAQEBAmsnhVd?= =?us-ascii?q?eAYEAJgEEGxKEHWQQqkKIYoImBYUtgi6BV4FmhlsCgU6GEASONYwtCQKMe4N4j?= =?us-ascii?q?wKRKAIRGQGBLQEeOIFScBWCfYRIdwGLOYEYAQEB?= X-IronPort-AV: E=Sophos; i="5.47,426,1515456000"; d="scan'208,217"; a="78884563" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2018 10:29:25 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w25ATOeS016585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Mar 2018 10:29:24 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 5 Mar 2018 04:29:24 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1320.000; Mon, 5 Mar 2018 04:29:24 -0600 From: "Frank Brockners (fbrockne)" To: IETF IPPM WG Thread-Topic: IOAM drafts on data fields and encapsulation for IETF London Thread-Index: AdO0aZtuZlRcCsq1R3Cdg7VLNIiK9A== Date: Mon, 5 Mar 2018 10:29:24 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.117.7] Content-Type: multipart/alternative; boundary="_000_b2793783b07c400b9944313b6cb28643XCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [ippm] IOAM drafts on data fields and encapsulation for IETF London X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 10:29:31 -0000 --_000_b2793783b07c400b9944313b6cb28643XCHRCD008ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI - A set of new IOAM related drafts have just been posted, including an = updated version of the draft that defines IOAM data fields (draft-ietf-ippm= -ioam-data-02.txt) and a group of drafts which tackle encapsulation of IOAM= data fields into different protocols. We received guidance from the IPPM c= hairs to perform the work on IOAM encapsulation into the different protocol= s initially in the IPPM working group moving forward - as opposed to doing = a tour across the various WGs which "own" the protocols. This should allow = us to keep all the encapsulations consistent and in synch. Once the work is= considered mature by IPPM WG, we'll then ask the different WGs that "own" = the corresponding protocol for a review. The one exception to this process = is NSH where we'll start within SFC WG right away, mostly because the NSH W= G showed a lot of interest in the OAM topic, and OAM is also part of the SF= C WG scope adjustment. Here's the most recent status - with key news/updates highlighted =B7 IOAM data fields (draft-ietf-ippm-ioam-data-02.txt) o Following the discussion we had in Singapore, we introduced a new secti= on on timestamp formats - allowing 1588/NTP/POSIX time stamps and harmonizi= ng timestamp definition across trace and E2E options. o Working on a consistent way to encapsulate IOAM data fields, we arrived= at defining an IOAM-Type data field and associated registry - to represent= our 4 different IOAM types (preallocated trace option, incremental trace o= ption, proof of transit, E2E). With that definition, we typically only need= a single code point from protocols that we encapsulate IOAM data in. This = greatly simplifies the IOAM encap drafts (see below) - because from all th= e encapsulating protocols shown below we really only need a single code poi= nt. =B7 Encapsulation of IOAM data fields o draft-weis-ippm-ioam-gre-00.txt =A7 New document which breaks out the GRE section of the old "draft-brockn= ers-inband-oam-transport" into a dedicated document and reflects the new IO= AM-Type. o draft-brockners-nvo3-ioam-geneve-00.txt =A7 Re-submission of the earlier draft-brockners-nvo3-ioam-geneve-00.txt t= o reflect the move of the discussions to IPPM WG. =A7 Updated to use the new IOAM-Type. o draft-brockners-ippm-ioam-vxlan-gpe-00.txt =A7 Re-submission of the earlier draft-brockners-ioam-vxlan-gpe-00.txt to = reflect the move of the discussions to IPPM WG. =A7 Updated to use the new IOAM-Type. o draft-brockners-sfc-ioam-nsh-01.txt =A7 Updated to use the new IOAM-Type. (Document just mentioned for reasons= of completeness here. Discussion will happen in NSH WG). Thoughts and comments are greatly appreciated. We've already asked the chai= rs to allocated time on the agenda for draft-ietf-ippm-ioam-data-02, draft-= brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-nvo3-ioam-geneve-00, draf= t-weis-ippm-ioam-gre-00. Looking forward to a lively discussion in London. Thanks much, Frank --_000_b2793783b07c400b9944313b6cb28643XCHRCD008ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

FYI – A set of new IOAM r= elated drafts have just been posted, including an updated version of the dr= aft that defines IOAM data fields (draft-ietf-ippm-ioam-data-02.txt) and a = group of drafts which tackle encapsulation of IOAM data fields into different protocols. We received guidance from th= e IPPM chairs to perform the work on IOAM encapsulation into the different = protocols initially in the IPPM working group moving forward – as opp= osed to doing a tour across the various WGs which “own” the protocols. This should allow us to keep al= l the encapsulations consistent and in synch. Once the work is considered m= ature by IPPM WG, we’ll then ask the different WGs that “own= 221; the corresponding protocol for a review. The one exception to this process is NSH where we’ll start within SFC WG right away, m= ostly because the NSH WG showed a lot of interest in the OAM topic, and OAM= is also part of the SFC WG scope adjustment.

 

Here’s the most recent st= atus – with key news/updates highlighted

 

=B7       IOAM data fields (draft-ietf-= ippm-ioam-data-02.txt)

o   Following the discussio= n we had in Singapore, we introduced a new section on timestamp formats = 211; allowing 1588/NTP/POSIX time stamps and harmonizing timestamp definiti= on across trace and E2E options.

o   Working on a consistent= way to encapsulate IOAM data fields, we arrived at defining an IOAM-Type d= ata field and associated registry – to represent our 4 different IOAM= types (preallocated trace option, incremental trace option, proof of transit, E2E). With that definition, we typically o= nly need a single code point from protocols that we encapsulate IOAM data i= n. This greatly simplifies the IOAM encap drafts (see below)  - becaus= e from all the encapsulating protocols shown below we really only need a single code point.

=B7       Encapsulation of IOAM d= ata fields

odraft-wei= s-ippm-ioam-gre-00.txt

=A7  New document which brea= ks out the GRE section of the old “draft-brockners-inband-oam-transpo= rt” into a dedicated document and reflects the new IOAM-Type.

o   draft-brock= ners-nvo3-ioam-geneve-00.txt=

<= span style=3D"mso-list:Ignore">=A7  Re-submission of the ea= rlier draft-brockners-nvo3-ioam-geneve-00.txt to reflect the move of the di= scussions to IPPM WG.

=A7  Updated to use t= he new IOAM-Type.

o   draft= -brockners-ippm-ioam-vxlan-gpe-00.txt

<= span style=3D"mso-list:Ignore">=A7  Re-submission of the ea= rlier draft-brockners-ioam-vxlan-gpe-00.txt to reflect the move of the disc= ussions to IPPM WG.

=A7  Updated to use t= he new IOAM-Type.

o   draft-brockners-sfc= -ioam-nsh-01.txt

=A7  Updated to use t= he new IOAM-Type. (Document just mentioned for reasons of completeness here= . Discussion will happen in NSH WG).

 

Thoughts and comments are great= ly appreciated. We’ve already asked the chairs to allocated time on t= he agenda for draft-ietf-ippm-ioam-data-02, draft-brockners-ippm-ioam-vxlan= -gpe-00, draft-brockners-nvo3-ioam-geneve-00, draft-weis-ippm-ioam-gre-00. Looking forward to a lively discussion in Lon= don.

 

Thanks much, Frank

 

--_000_b2793783b07c400b9944313b6cb28643XCHRCD008ciscocom_-- From nobody Mon Mar 5 16:17:08 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44536126DEE; Mon, 5 Mar 2018 16:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bnEA68ZjSIR7; Mon, 5 Mar 2018 16:17:05 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 326BC120227; Mon, 5 Mar 2018 16:17:05 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id i80so25885965lfg.5; Mon, 05 Mar 2018 16:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Ur8xFVs4prf+DD2hOH9lN4rTn3vQUyseMmAOF8jEm0=; b=nauNyb5QvjgGGyeKHskUeW814QjaceaHDUFh6PF6i0CQVaqk6ZVXm/SWUfQHpGzH2z NwPcjPT9Bmjjy7c0dzuecY7N5ZchlmvzG34jl/7680V6Yp29SpFTAGNjh4a+QOH2tv3i t8Wum3XtZU36Gj1nAatGaZu0Hf8AiVkr2pslBxgZ2P74wW7CE9mP0ABKzEr8qoYnPKa7 ENi37MQMObTLGHOq7PdTuCToyRfKfJ3uAk3x/Uq7IxDynu8j2XF4td3h8MJLMJVVYMSq 5+Ilgt/1Vczj44XSk9DDsuzjbjGJGrbKBJ/RnayfLW1XzTcdsW+Hj0WxbQUcV/yt0fhQ fXwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Ur8xFVs4prf+DD2hOH9lN4rTn3vQUyseMmAOF8jEm0=; b=stByjz/44UHNRmBTrKHpoItDIuTgsBmbGFCmZZaa6HgXihXDGYhOCcuLYYIr0bTRZu 0uZg1xWWtVF+JPFV1pMg3cNa3UYsr8FnN/WfJrpkDnxi0XBJ3sgah3d7Rx+SrI95Dmo3 +HakJZkIPkhaeRlpzK9hDmXDkyupTmqfiw91l5878i/F0ERPfsOsHwVNdaWvi/1o0hv7 FHwvNiobPa0EawLf96wTz/XcxEWqs3Gift6TFwMUPwF21TKUmHkRNb7mfxqEW00fbLKb P8UK4exNJYJls1OWFyx4MgGgWajEm3RhDhIbKB6P3V+keQKd9O32lTJqL6CG4J4UlS/f 3C2Q== X-Gm-Message-State: AElRT7G0EmcFXv+G9sXbp3i1NjAg2Fr0nTZyJ77TFcwK7VL1Hlxu7ovL HYLP0+yutOvBLe07lR+1FcJ/VRG4YNxn5KLb0OA= X-Google-Smtp-Source: AG47ELtsVxVCHzw1CJqzJLS/kMaq7cThxbibsKVTyXNxPaFHbcr3ouB9IJISKl1kZQDQ1IsaGU+d/f8odlKsbF0Ut0E= X-Received: by 10.46.127.4 with SMTP id a4mr10851814ljd.71.1520295423129; Mon, 05 Mar 2018 16:17:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.145.195 with HTTP; Mon, 5 Mar 2018 16:17:02 -0800 (PST) In-Reply-To: References: From: Greg Mirsky Date: Mon, 5 Mar 2018 16:17:02 -0800 Message-ID: To: IPPM Chairs Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="089e082b53a4a6413f0566b35ca4" Archived-At: Subject: Re: [ippm] Draft IPPM agenda for IETF 101 in London X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Mar 2018 00:17:07 -0000 --089e082b53a4a6413f0566b35ca4 Content-Type: text/plain; charset="UTF-8" Hi Bill and Brian, thank you for the most timely update (agenda for IPPM meeting is one the first to be announced). Appreciate your kind consideration of our requests for presentation slots on STAMP work as well as on the new Hybrid two-step measurement method. I have a question about some drafts placed in the Lightning talk section for the meeting. These drafts propose specific data plane encapsulation for telemetry information using iOAM data formats. I couldn't find there any discussion of measurement methodology but only proposed changes to encapsulations defined in various WGs in the Routing Area. As I recall, in the discussion of the new charted for IPPM WG we've agreed that application of the measurement methodology defined in IPPM WG to the particular networking layer will be hosted in the WG that is chartered to work on that network layer. For example, MPLS data plane - MPLS WG, BIER - BIER WG, and so on. Had that been re-visited? How that is related to the new IPPM WG charter? Had the appropriate WGs in the Routing Area agreed to such arrangement? Regards, Greg On Sun, Mar 4, 2018 at 8:08 PM, Bill Cerveny wrote: > I have posted the first draft of the IETF 101 (London) IPPM working group > agenda at https://datatracker.ietf.org/doc/agenda-101-ippm/ > > Note that time has been allocated for discussion of all working groups > drafts. Talks on all other documents are being presented as lightning talks > (5 minutes enforced as time permits). > > Best Regards, > > Bill Cerveny > IPPM working group co-chair > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --089e082b53a4a6413f0566b35ca4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bill and Brian,
thank you for the most timely updat= e (agenda for IPPM meeting is one the first to be announced). Appreciate yo= ur kind consideration of our requests for presentation slots on STAMP work = as well as on the new Hybrid two-step measurement method. I have a question= about some drafts placed in the Lightning talk section for the meeting. Th= ese drafts propose specific data plane encapsulation for telemetry informat= ion using iOAM data formats. I couldn't find there any discussion of me= asurement methodology but only proposed changes to encapsulations defined i= n various WGs in the Routing Area. As I recall, in the discussion of the ne= w charted for IPPM WG we've agreed that application of the measurement = methodology defined in IPPM WG to the particular networking layer will be h= osted in the WG that is chartered to work on that network layer. For exampl= e, MPLS data plane - MPLS WG, BIER - BIER WG, and so on. Had that been re-v= isited? How that is related to the new IPPM WG charter? Had the appropriate= WGs in the Routing Area agreed to such arrangement?

Regards,
Greg

On Sun, Mar 4, 2018 at 8:08 PM, Bill Cerveny <ippm@w= jcerveny.com> wrote:
I have posted th= e first draft of the IETF 101 (London) IPPM working group agenda at=C2=A0https://datatracker.ietf.org/doc/agenda-101-ippm/

Note that time has been allocated for discussion of all working group= s drafts. Talks on all other documents are being presented as lightning tal= ks (5 minutes enforced as time permits).

Best Rega= rds,

Bill Cerveny
IPPM working group co-= chair

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


--089e082b53a4a6413f0566b35ca4-- From nobody Mon Mar 5 23:22:25 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75EB126CE8 for ; Mon, 5 Mar 2018 23:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 zr-UaKhjpljQ for ; Mon, 5 Mar 2018 23:22:22 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 6803B124217 for ; Mon, 5 Mar 2018 23:22:22 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 18FF5F0D368B for ; Tue, 6 Mar 2018 07:22:19 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 6 Mar 2018 07:22:20 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Tue, 6 Mar 2018 15:22:16 +0800 From: Tianran Zhou To: "ippm@ietf.org" Thread-Topic: New Version Notification for draft-zhou-ippm-ioam-yang-00.txt Thread-Index: AQHTtGIN5gBrdt8wCU+Y35Jv3OYzWaPCzl6g Date: Tue, 6 Mar 2018 07:22:16 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] FW: New Version Notification for draft-zhou-ippm-ioam-yang-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Mar 2018 07:22:24 -0000 SGkgRm9sa3MsDQoNCldlIGp1c3Qgc3VibWl0dGVkIHRoZSBmb2xsb3dpbmcgZHJhZnQgaW4gSVBQ TSBXRy4gDQpXZSBwcm9wb3NlZCB0aGUgWUFORyBkYXRhIG1vZGVsIGZvciB0aGUgSU9BTS4NCkFu eSBzdWdnZXN0aW9uIGFuZCBjb21tZW50IGFyZSB3ZWxjb21lLg0KDQpUaGFua3MsDQpUaWFucmFu DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBN YXJjaCAwNSwgMjAxOCA1OjEyIFBNDQpUbzogU3JpaGFyaSBSYWdoYXZhbjsgRnJhbmsgQnJvY2tu ZXJzOyBKYW1lcyBOIEd1aWNoYXJkOyBUaWFucmFuIFpob3UNClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZy0wMC50eHQNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZy0wMC50eHQgaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaWFucmFuIFpob3UgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtemhvdS1pcHBtLWlvYW0teWFu Zw0KUmV2aXNpb246CTAwDQpUaXRsZToJCUEgWUFORyBEYXRhIE1vZGVsIGZvciBJbi1TaXR1IE9B TQ0KRG9jdW1lbnQgZGF0ZToJMjAxOC0wMy0wNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOgkJMTcNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZy0wMC50eHQNClN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aG91LWlwcG0taW9h bS15YW5nLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aG91LWlwcG0taW9hbS15YW5nLTAwDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC16aG91LWlwcG0taW9hbS15YW5nLTAwDQoNCg0K QWJzdHJhY3Q6DQogICBJbi1zaXR1IE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQgTWFp bnRlbmFuY2UgKElPQU0pIHJlY29yZHMNCiAgIG9wZXJhdGlvbmFsIGFuZCB0ZWxlbWV0cnkgaW5m b3JtYXRpb24gaW4gdXNlciBwYWNrZXRzIHdoaWxlIHRoZQ0KICAgcGFja2V0cyB0cmF2ZXJzZSBh IHBhdGggYmV0d2VlbiB0d28gcG9pbnRzIGluIHRoZSBuZXR3b3JrLiAgVGhpcw0KICAgZG9jdW1l bnQgZGVmaW5lcyBhIFlBTkcgbW9kdWxlIGZvciB0aGUgSU9BTSBmdW5jdGlvbi4NCg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Mar 6 00:39:16 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8CE126CF6; Tue, 6 Mar 2018 00:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 69DNNEEyWvze; Tue, 6 Mar 2018 00:39:11 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71184120724; Tue, 6 Mar 2018 00:39:11 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C6693401B7; Tue, 6 Mar 2018 09:39:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.1935); Tue, 6 Mar 2018 09:39:04 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Tue, 6 Mar 2018 09:39:04 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 47422478; Tue, 06 Mar 2018 09:39:04 +0100 From: "Brian Trammell (IETF)" Message-Id: <36D25E2A-5517-4F0E-A969-E5E613B9F670@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_A7234CA2-8958-4E9A-84BD-F373BA570502"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 6 Mar 2018 09:39:03 +0100 In-Reply-To: Cc: IPPM Chairs , IETF IPPM WG To: Greg Mirsky References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ippm] Draft IPPM agenda for IETF 101 in London X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 06 Mar 2018 08:39:15 -0000 --Apple-Mail=_A7234CA2-8958-4E9A-84BD-F373BA570502 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 6 Mar 2018, at 01:17, Greg Mirsky wrote: >=20 > Hi Bill and Brian, > thank you for the most timely update (agenda for IPPM meeting is one = the first to be announced). Appreciate your kind consideration of our = requests for presentation slots on STAMP work as well as on the new = Hybrid two-step measurement method. I have a question about some drafts = placed in the Lightning talk section for the meeting. These drafts = propose specific data plane encapsulation for telemetry information = using iOAM data formats. I couldn't find there any discussion of = measurement methodology but only proposed changes to encapsulations = defined in various WGs in the Routing Area. As I recall, in the = discussion of the new charted for IPPM WG we've agreed that application = of the measurement methodology defined in IPPM WG to the particular = networking layer will be hosted in the WG that is chartered to work on = that network layer. For example, MPLS data plane - MPLS WG, BIER - BIER = WG, and so on. Had that been re-visited? How that is related to the new = IPPM WG charter? Had the appropriate WGs in the Routing Area agreed to = such arrangement? On discussion with the authors, we've decided that it makes sense to run = a process like that we did for RFC8250: the core document is here in = IPPM, interactions with other protocols (in 8250's case, the v6 DO; = here, the encapsulations within other protocols) happen here but are = sent over to the respective working groups on each update). Two reasons = for this: one, IOAM is built around a core data model and shim = specifications to add, and it makes sense for all of these to maintain a = unified design, which suggests they should happen in the same WG. = Second, since the documents to be adopted in each encapsulating WG = really are *just* encapsulations, there can be a lower amount of = interest (and thereby a higher barrier to adoption) than if all are = adopted in the same place. IOW, IOAM over MPLS is a feature of IOAM, which requires review and = assent from the MPLS WG, but the development of the proposal need not = happen there. Should the discussion in each encap WG lead to consensus = in that an encap document should live there, instead, then we can move = the document out. This decision is based on Paragraph 5 of the IPPM charter: "Additional = methods will be defined for the composition and calibration of = IPPM-defined metrics, as well as active, passive and hybrid measurement = methods for these metrics", since, as a hybrid measurement method, IOAM = requires an encapsulation to function. Regards, Brian (as IPPM chair) >=20 > Regards, > Greg >=20 > On Sun, Mar 4, 2018 at 8:08 PM, Bill Cerveny = wrote: > I have posted the first draft of the IETF 101 (London) IPPM working = group agenda at https://datatracker.ietf.org/doc/agenda-101-ippm/ >=20 > Note that time has been allocated for discussion of all working groups = drafts. Talks on all other documents are being presented as lightning = talks (5 minutes enforced as time permits). >=20 > Best Regards, >=20 > Bill Cerveny > IPPM working group co-chair >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_A7234CA2-8958-4E9A-84BD-F373BA570502 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlqeU6cACgkQihK3vwvq RqNpDQ/9FfPUay2L+CdOcV212Q8FowWrMWBwsj9xk066lK8fiCWARSYhlCt5WFeS uhPiV7k4o5CIxFQ11Pt6x9js2bjwUHaJEFS6TrKKADr7mVd0PvFc3ZnC5KWg+kNP LZkZAWu86Wvwaw58xSXrSBpxbT2FzTeliaqo96d4EFC5FPMF3yNlf5pXlBGZFKSM B+XyIhAs6g91ciYWjWuXiZvfsV1jLcir170OgfzAbNhiMDat7LjXeUTLfjbo8huZ 1jB14bGfk+PUNYcp15KZZ+eKk74Y83BENampHjvgDDWZe2odUxsSiYulhPoyqkuM S2T1NTed4GZsllxbAMk64dQP2X7POb1s5QvNfRkPJh8nseL77Pbz+oklYrZ/F+46 CddjY+7fzPf4AjtwX8gJbKailN7OoRNCARvJS++/1rHDkUQDF6GTXRsvJB336oKQ 1htjxgJk/IRC2rpc/CRa2wf423qye/upz8E6MfQHA+XhKyhW/q+dgPNAwxuSTHRR V7dsxIsdkeCpAVqMSHe20r2L/Q/RrRREpLnPKXoAAlgD/1ilaMVxS+O4quuWNOJl RpcPtXWhr/yqWy7BUanU53k/KursFtKr0QB7EQOZO+Us2Bpqjt0Q6q4dz4ewlRRl L//1DRnvwHJ4IHYM/7qE4PCX2vK6H6Hb5KeFCutdxlgCIp/Tgrs= =L/Bb -----END PGP SIGNATURE----- --Apple-Mail=_A7234CA2-8958-4E9A-84BD-F373BA570502-- From nobody Thu Mar 15 01:24:33 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 286EE12D96B; Thu, 15 Mar 2018 01:24:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Trammell To: X-Test-IDTracker: no X-IETF-IDTracker: 6.75.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Nalini Elkins , ippm-chairs@ietf.org, iesg-secretary@ietf.org, nalini.elkins@insidethestack.com, ippm@ietf.org Message-ID: <152110224815.12169.10815437641520038289.idtracker@ietfa.amsl.com> Date: Thu, 15 Mar 2018 01:24:08 -0700 Archived-At: Subject: [ippm] Publication has been requested for draft-ietf-ippm-twamp-yang-06 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 08:24:31 -0000 Brian Trammell has requested publication of draft-ietf-ippm-twamp-yang-06 as Proposed Standard on behalf of the IPPM working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/ From nobody Thu Mar 15 17:09:58 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8804A120713; Thu, 15 Mar 2018 17:09:57 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pL-c1yYZgkh2; Thu, 15 Mar 2018 17:09:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B99124D68; Thu, 15 Mar 2018 17:09:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 74981B80DF2; Thu, 15 Mar 2018 17:09:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ippm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180316000953.74981B80DF2@rfc-editor.org> Date: Thu, 15 Mar 2018 17:09:53 -0700 (PDT) Archived-At: Subject: [ippm] =?utf-8?q?RFC_8337_on_Model-Based_Metrics_for_Bulk_Transpo?= =?utf-8?q?rt_Capacity?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2018 00:09:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8337 Title: Model-Based Metrics for Bulk Transport Capacity Author: M. Mathis, A. Morton Status: Experimental Stream: IETF Date: March 2018 Mailbox: mattmathis@google.com, acmorton@att.com Pages: 55 Characters: 138647 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-model-based-metrics-13.txt URL: https://www.rfc-editor.org/info/rfc8337 DOI: 10.17487/RFC8337 This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance. Model-Based Metrics rely on mathematical models to specify a Targeted IP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path. For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the Target Transport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications. This document is a product of the IP Performance Measurement Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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/retrieve/bulk 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 Fri Mar 16 23:21:18 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17A5127010 for ; Fri, 16 Mar 2018 23:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 lKGfB9aBEbFv for ; Fri, 16 Mar 2018 23:21:13 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 4FD5C120227 for ; Fri, 16 Mar 2018 23:21:13 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id EE4C3A0277283 for ; Sat, 17 Mar 2018 06:21:08 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 17 Mar 2018 06:21:10 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Sat, 17 Mar 2018 14:21:03 +0800 From: Qin Wu To: "ippm@ietf.org" Thread-Topic: comments on draft-fioccola-ippm-multipoint-alt-mark Thread-Index: AdO9t4MlOscgrmUeRh6E5CnHBF7nLw== Date: Sat, 17 Mar 2018 06:21:02 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.62.55] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AD89AF2nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] comments on draft-fioccola-ippm-multipoint-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 06:21:16 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9AD89AF2nkgeml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Giuseppe: Thanks for extending Alternate Marking method mechanism and I have the late= st version of draft-fioccola-ippm-multipoint-alt-mark And have two quick comments: How do you scope multipoint Alternate Marking method in this draft? Does it= apply to point to multipoint MPLS LSP as well? What is the difference between multipoint Alternate Marking method with Net= work Clustering support and mutipoint Alternate Marking method without Netw= ork Clustering support? -Qin --_000_B8F9A780D330094D99AF023C5877DABA9AD89AF2nkgeml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Giuseppe:=

Thanks for extending Alternate Marking method mechanism and I have the latest version of draft-fioccola-ippm-multi= point-alt-mark

And have two quick comments:

How do you scope multipoint Alternate Marking method in this draft? Does it apply to point to multip= oint MPLS LSP as well?

What is the difference between = multipoint Alternate Marking method with Network Clustering s= upport and mutipoint Alternate Marking method without Network Clustering su= pport?

 

-Qin

--_000_B8F9A780D330094D99AF023C5877DABA9AD89AF2nkgeml513mbschi_-- From nobody Sat Mar 17 02:08:52 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377D912741D for ; Sat, 17 Mar 2018 02:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 yawPiYl_1kqy for ; Sat, 17 Mar 2018 02:08:48 -0700 (PDT) Received: from mx03.telecomitalia.it (mx03.telecomitalia.it [217.169.121.23]) (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 C46951200A0 for ; Sat, 17 Mar 2018 02:08:47 -0700 (PDT) X-AuditID: d9a97917-5e1ff70000000b20-54-5aacdb1b82e8 Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx03.telecomitalia.it () with SMTP id CF.97.02848.B1BDCAA5; Sat, 17 Mar 2018 10:08:45 +0100 (CET) From: Fioccola Giuseppe To: Qin Wu , "ippm@ietf.org" Thread-Topic: comments on draft-fioccola-ippm-multipoint-alt-mark Thread-Index: AdO9t4MlOscgrmUeRh6E5CnHBF7nLwAEfy2w Date: Sat, 17 Mar 2018 09:08:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.238] x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_bffe1a2d3c67496dab62d2f45bc72c09TELMBXB02RM001telecomit_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsXCxfdHWlf29poog8+9qhaP5y5gteh58I7Z gcmj5chbVo8lS34yBTBFNTDaJObl5ZcklqQqpKQWJ9squWQWJ+ckZuamFimEpOakJufnKilk ptgqGSspFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0td QyW7wNLU4pJ8hdzU4uLE9PTMfIXUhPWCGTcn7WYv+GxX0XX4B0sD407zLkZODgkBE4lFl8+w dDFycQgJTGGS+HfuFytIgk3ARuLgqxNsILaIgIPEy9lvwWxhAXuJBd3PGbsYOYDijhJHT9RA lBhJXNt0gRnEZhFQlXj/8htYOa9AoMT2+W2MILaQQKjE70fzmUFaOQXCJP53BIOEGQVkJSbs XgRWwiwgLvFi+gl2iNMEJJbsOc8MYYtKvHz8jxXCNpDYunQfC4StKPHx/GZGCFtGYuGRyawQ c/Il3hy4AnWCoMTJmU9YJjCKzEKyYhaSsllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwB I/sqRtHcCgNjvRJITGaWJOZkJupllmxiBKaQmysrxXcwtq90PsQowMGoxMOrfnBNlBBrYllx Ze4hRgkOZiUR3kULgEK8KYmVValF+fFFpTmpxYcYfYABOZFZSjQ5H5je8kriDU0sLA2NLSyM DC3MTHEIK4nznp68KkpIIB2Y1LJTUwtSi2DGMXFwSjUwynOequaf4bv+nXCRAmf1T+d1Tg9Y TfMrn9xd2fsxTbaoa+nWAmZJwQw1RcbwE8oJYRs5taZXNuTfz4iR5/2dmXJw3rO4wvO50o8O bpr4tdj/W3QbS9CeY+vDuFZm37jRtlmCK/TgQ88VOxakWMmKZS4+pH3q86XzMjcbXi5ov+Z7 /3bCMWYFJZbijERDLeai4kQAr/yK204DAAA= Archived-At: Subject: [ippm] R: comments on draft-fioccola-ippm-multipoint-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 09:08:51 -0000 --_000_bffe1a2d3c67496dab62d2f45bc72c09TELMBXB02RM001telecomit_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Qin, Thanks for your review of the draft. You are right, the multipoint alternate marking can be applicable in several= scenarios where we have multipoint to multipoint paths (as for MPLS LSP, VP= N, OTT traffic,...). Regarding the second comment, consider that alternate marking method works b= y definition for multipoint to multipoint paths but network clustering appro= ach is the formalization of how to do that because it allows a flexible and= optimized performance measurement support. Without network clustering, you= can apply alternate marking only for all the network or per single flow. In= stead, with network clustering, you can start without examining in depth, an= d in case there are issues, the network clusters partition can be specified= at different levels to perform a detailed analysis if needed. A typical use= case is an SDN Controller Application that can orchestrate and calibrate ho= w deep the network monitoring is setup. Giuseppe Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Qin Wu Inviato: sabato 17 marzo 2018 07:21 A: ippm@ietf.org Oggetto: [ippm] comments on draft-fioccola-ippm-multipoint-alt-mark Hi, Giuseppe: Thanks for extending Alternate Marking method mechanism and I have the lates= t version of draft-fioccola-ippm-multipoint-alt-mark And have two quick comments: How do you scope multipoint Alternate Marking method in this draft? Does it= apply to point to multipoint MPLS LSP as well? What is the difference between multipoint Alternate Marking method with Netw= ork Clustering support and mutipoint Alternate Marking method without Networ= k Clustering support? -Qin Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. --_000_bffe1a2d3c67496dab62d2f45bc72c09TELMBXB02RM001telecomit_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qin,

Thanks for your review of the draft.

You are right, the multipoint alternate marking can be applicable i= n several scenarios where we have multipoint to multipoint paths (as for MPL= S LSP, VPN, OTT traffic,…).

Regarding the second comment, consider that alternate marking metho= d works by definition for multipoint to multipoint paths but network cluster= ing approach is the formalization of how to do that because it allows a flexible and optimized performance measu= rement support. Without network clustering, you can apply alternate marking= only for all the network or per single flow. Instead, with network clusteri= ng, you can start without examining in depth, and in case there are issues, the network clusters partition can= be specified at different levels to perform a detailed analysis if needed.= A typical use case is an SDN Controller Application that can orchestrate an= d calibrate how deep the network monitoring is setup.

 

Giuseppe

 

Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Qin Wu
Inviato: sabato 17 marzo 2018 07:21
A: ippm@ietf.org
Oggetto: [ippm] comments on draft-fioccola-ippm-multipoint-alt-mark

 <= /o:p>

Hi, Giuseppe:

Thanks for extending Alternate Mark= ing method mechanism and I have the latest= version of draft-fioccola-ippm-multipoint-alt-mark

And have two quick comments:

How do you scope multipoint Alternate Mark= ing method in this dra= ft? Does it apply to point to multipoint MPLS LSP as well?=

What is the difference between multipoint Alternate Mark= ing method with Network Clustering support and mutipoint Alternate Marking m= ethod without Network Clustering support?

 

-Qin=

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle= persone indicate. La diffusione, copia o qualsiasi altra azione derivante d= alla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di da= rne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying,= printing or use by anybody else is unauthorised. If you are not the intende= d recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessa= rio.
--_000_bffe1a2d3c67496dab62d2f45bc72c09TELMBXB02RM001telecomit_-- From nobody Sun Mar 18 05:26:48 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399C3126CB6 for ; Sun, 18 Mar 2018 05:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kFuaub9XUhQn for ; Sun, 18 Mar 2018 05:26:44 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 E098C12778E for ; Sun, 18 Mar 2018 05:26:43 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id t132-v6so21494440lfe.2 for ; Sun, 18 Mar 2018 05:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3i8HgwOMKsCYIqnr6rddlD7rB9nd8Zgco4W3GpUFjUE=; b=LME7g4Ikh9VNXZKV/fMO7FtkeXafgzkwyqi9/Ln02yV7ip6hmPvVBorGgcnH53ljRl PcLUWRgi/JRoK4VszsyD+aOOXNVzs3X8Lr7Nd2/7l2/MFHnOGC24ieXo9pAxc/WgKSu8 LgvYEul/QloXEVJLVOOHxWmKrVxaz+m1EnSWdG72rndqRoZB0xTT9qLDHIpeqsMaFpk/ 4Kc9//OJzPLTbdCpvWreSIwRHO3GOB6bDM+doaMBok+1cYkVmPEOhc4zbe/pdvgKPAZC 5PNPGdTELE2qIqJP94e4gftkx6kMp++s+6TUW2vwxe3oEH8M56jf9ji+iogZ2Sr1GRdM ZLbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3i8HgwOMKsCYIqnr6rddlD7rB9nd8Zgco4W3GpUFjUE=; b=U4zlE8lV/lii7STc7XzBsbCu+XV2vAw2PQ9l/U7YzOfrd7c3exEHQhCfN2Kb7lFttZ BSnZ5mGmifEZpEYWy8Yk2JZaJk12R5f2FlG4LKuXhJ6yo7EDWIQa8m2od7CkaUYi5QQW Gucc1WunOp6tmC2PJM+IojhQ72XzHECNCedXFxsuSgOWf6cop+euH+SOywi9HiGzwZRP WouyLNJzYr2RNqq5jUMKhpaSCg8xB6cEPB0zxWyTjPwbxIUMpAMepe3R1Q03sv6mMl29 lxDqO1cotvvkbxjmmPTxDbbcM0azOnpHusmFFoP0IUObHncE/ItGp1ZwdoxlwD4E2ZyB lxYg== X-Gm-Message-State: AElRT7GdlQVLY4w/2Jv00WTZr4qX3L63uleaX6l8mO38ZBuV3ncdA4B0 YjZasVzb8QZxLfBaFUtoXeuzygltwLRZzb2Mtk0= X-Google-Smtp-Source: AG47ELsFH97ICdAl7zYp/o1iBe4oFwp7BhgFZoRA+rwGtjlaEpL8AsNiz0yDqSbARco/K+M3+zAJCL+Zx18MCrnQt1k= X-Received: by 10.46.129.153 with SMTP id e25mr2884757ljg.69.1521376001846; Sun, 18 Mar 2018 05:26:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.145.195 with HTTP; Sun, 18 Mar 2018 05:26:41 -0700 (PDT) In-Reply-To: <152137493491.30148.10354340169701060496.idtracker@ietfa.amsl.com> References: <152137493491.30148.10354340169701060496.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Sun, 18 Mar 2018 05:26:41 -0700 Message-ID: To: IETF IPPM WG Content-Type: multipart/alternative; boundary="f4f5e80c7dec28f12b0567aef409" Archived-At: Subject: [ippm] Fwd: New Version Notification for draft-ooamdt-rtgwg-ooam-header-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 12:26:46 -0000 --f4f5e80c7dec28f12b0567aef409 Content-Type: text/plain; charset="UTF-8" Dear All, in light of new drafts to be presented this week, would like to point to this earlier work that will be discussed at NVO3 WG meeting this week. Regards, Greg ---------- Forwarded message ---------- From: Date: Sun, Mar 18, 2018 at 5:08 AM Subject: New Version Notification for draft-ooamdt-rtgwg-ooam-header-04.txt To: Nagendra Kumar , Gregory Mirsky < gregimirsky@gmail.com>, Deepak Kumar , Li Yizhou < liyizhou@huawei.com>, David Dolson , Mach Chen < mach.chen@huawei.com> A new version of I-D, draft-ooamdt-rtgwg-ooam-header-04.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ooamdt-rtgwg-ooam-header Revision: 04 Title: OAM Header for use in Overlay Networks Document date: 2018-03-18 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-ooamdt-rtgwg- ooam-header-04.txt Status: https://datatracker.ietf.org/doc/draft-ooamdt-rtgwg-ooam- header/ Htmlized: https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam- header-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-ooamdt-rtgwg- ooam-header Diff: https://www.ietf.org/rfcdiff?url2=draft-ooamdt-rtgwg-ooam- header-04 Abstract: This document introduces Overlay Operations, Administration, and Maintenance (OOAM) Header to be used in overlay networks to create Overlay Associated Channel (OAC) to ensure that OOAM control packets are in-band with user traffic and de-multiplex OOAM protocols. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --f4f5e80c7dec28f12b0567aef409 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
in light of new drafts to be presented this = week, would like to point to this earlier work that will be discussed at NV= O3 WG meeting this week.

Regards,
Greg

---------- Forwarded message ------= ----
From: <internet-drafts@ietf.org>
Date: Sun, Mar 18, 2018 at 5:08 AM
Subject: New Version Notifica= tion for draft-ooamdt-rtgwg-ooam-header-04.txt
To: Nagendra Kumar <naikumar@cisco.com>, Gregory Mir= sky <gregimirsky@gmail.com&= gt;, Deepak Kumar <dekumar@cisco.co= m>, Li Yizhou <liyizhou@hu= awei.com>, David Dolson <= ddolson@sandvine.com>, Mach Chen <mach.chen@huawei.com>



A new version of I-D, draft-ooamdt-rtgwg-ooam-header-04.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ooamdt-rtgwg-ooam-heade= r
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAM Header for use in Overlay Netw= orks
Document date:=C2=A0 2018-03-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ooamdt-= rtgwg-ooam-header-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ooamdt-rtgwg-ooam-hea= der/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-header-04 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ooamdt-rtgwg-ooam= -header
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ooamdt-rtgwg-= ooam-header-04

Abstract:
=C2=A0 =C2=A0This document introduces Overlay Operations, Administration, a= nd
=C2=A0 =C2=A0Maintenance (OOAM) Header to be used in overlay networks to cr= eate
=C2=A0 =C2=A0Overlay Associated Channel (OAC) to ensure that OOAM control p= ackets
=C2=A0 =C2=A0are in-band with user traffic and de-multiplex OOAM protocols.=




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


--f4f5e80c7dec28f12b0567aef409-- From nobody Tue Mar 20 10:13:34 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DA812E741; Tue, 20 Mar 2018 10:13:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152156600428.9772.14914276358342724430@ietfa.amsl.com> Date: Tue, 20 Mar 2018 10:13:24 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-port-twamp-test-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 17:13:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : OWAMP and TWAMP Well-Known Port Assignments Authors : Al Morton Greg Mirsky Filename : draft-ietf-ippm-port-twamp-test-01.txt Pages : 9 Date : 2018-03-20 Abstract: This memo explains the motivation and describes the re-assignment of well-known ports for the OWAMP and TWAMP protocols for control and measurement, and clarifies the meaning and composition of these standards track protocol names for the industry. The memo updates RFC 4656 and RFC 5357, in terms of the UDP well- known port assignments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-port-twamp-test-01 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-port-twamp-test-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-port-twamp-test-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 20 13:43:55 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C39128959 for ; Tue, 20 Mar 2018 13:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rad365.onmicrosoft.com 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 3IDMlSkwR-MI for ; Tue, 20 Mar 2018 13:43:50 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00068.outbound.protection.outlook.com [40.107.0.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EE7124D6C for ; Tue, 20 Mar 2018 13:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m2b+ebwc9SHWAnXLYlTdUrTKxqYS1b5hX5zEF5GMk6c=; b=Ort2BcY/NAQV+QgDgDZv1cDfRxeq3hbWH/PNabqSV+2YUC49eIWsV6NMeuDkGy/2xZ8MRh2h+FqjyHhR4OGAmPE0H9qNSouZDM07ohh/qQ37ibnNQbqYFX3NZvMwIikJh8/xzPv9lD61n0XuHbLrRD/MrFy6savY1Xj1FNKzqd0= Received: from VI1PR03MB1470.eurprd03.prod.outlook.com (10.164.84.16) by VI1SPR01MB328.eurprd03.prod.outlook.com (10.165.198.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Tue, 20 Mar 2018 20:43:46 +0000 Received: from VI1PR03MB1470.eurprd03.prod.outlook.com ([fe80::309a:ea59:7ca8:34e0]) by VI1PR03MB1470.eurprd03.prod.outlook.com ([fe80::309a:ea59:7ca8:34e0%13]) with mapi id 15.20.0588.017; Tue, 20 Mar 2018 20:43:46 +0000 From: Yaakov Stein To: "MORTON, ALFRED C (AL)" , "ippm@ietf.org" Thread-Topic: section 10 of draft-ietf-ippm-initial-registry-06 Thread-Index: AdPAivPtJ2T5gfyoS3296ZE7rJB9PQ== Date: Tue, 20 Mar 2018 20:43:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yaakov_s@rad.com; x-originating-ip: [31.133.144.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1SPR01MB328; 7:sBPstyC/5bvR+zYARaIMXm4sKSMAre/uNqud1rmqs8ePvtkrrHrmZHgkyw4BrDr1/c7XUHU9BNso7qH29Cf32Kbs84DSzioho7+utdUSeOtFr+JC87TgAdeGgmakPy5nJeKAczHzRaQZKqVxT8n+qWhURmGegxRqexPDk96ejKAxO692c3o1CkuJ2dGI152QEaX4I+KGt6U0W4eqG0CxjS7vdYKLJ4vAzIE3z7p7ibvS3nRS/BMhCFG4dblnn3TG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 08930c2e-3eb5-43c7-c9cd-08d58ea346e1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1SPR01MB328; x-ms-traffictypediagnostic: VI1SPR01MB328: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501244)(52105095)(6055026)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:VI1SPR01MB328; BCL:0; PCL:0; RULEID:; SRVR:VI1SPR01MB328; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(39380400002)(396003)(346002)(199004)(189003)(14014004)(66066001)(33656002)(97736004)(316002)(110136005)(106356001)(59450400001)(105586002)(7696005)(2501003)(68736007)(478600001)(5250100002)(2906002)(3280700002)(14454004)(99286004)(6436002)(5660300001)(9686003)(53936002)(55016002)(54896002)(6306002)(790700001)(3846002)(102836004)(6506007)(7736002)(81156014)(81166006)(6116002)(186003)(74316002)(8676002)(26005)(8936002)(86362001)(3660700001)(2900100001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1SPR01MB328; H:VI1PR03MB1470.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rad.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4KNgRgePphrswsd/dp10IcI/000c8hF3OvJUPZ5uqBh84arH31cIYOq/4wfTBfkzr9Y1khsQGL5gDPufyywIBdSHXf1O7kNSujLCYoO1gxg7b7/8zlpnovUq4C4wqcTZ+Hq54KUz/z+15HVOAQ2RT25Lj9jHi8FDDySLq25yrhB31EI6Ahhvi3/OyfovuD+/OHaUeUescL1/sJci8mEQ0OgGfIed7e3Ix47bt4QxsvYbZOb8rCWB4iVETEN9XklON9ti8eyRM5jQJX/Y3XG+C0p5tUlbJH1VOysFrfJte+Wgwcg6pyVaPsSI/5o8RkPCi3yexHjafJjgnhncdXJpmA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR03MB14709B5E38492506F7555274E5AB0VI1PR03MB1470eurp_" MIME-Version: 1.0 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08930c2e-3eb5-43c7-c9cd-08d58ea346e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2018 20:43:46.2183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR01MB328 Archived-At: Subject: [ippm] section 10 of draft-ietf-ippm-initial-registry-06 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2018 20:43:53 -0000 --_000_VI1PR03MB14709B5E38492506F7555274E5AB0VI1PR03MB1470eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Al, I didn't know what I was getting myself into when I volunteered to look ove= r even a small portion of this document. 93 pages ???? So, here are some preliminary remarks, mostly limited to the first half of = section 10 (although some of what I have to say applies to other portions of the docum= ent). RTDelay ... The Observation Point [RFC7011] is assumed to be in the network= at a remote point from the end hosts. -> While TCP runs end-to-end between two hosts, here we consider the measureme= nt of RTDelay based on a single Observation Point located somewhere in the = network. and similarly: RTLoss ... The Observation Point [RFC7011] is assumed to be in the network = at a remote point from the end hosts. -> We consider the measurement of the RTLoss based on a single Observation Poi= nt located somewhere in the network. Cleaner wording: Although there is no RFC that describes passive measurement of Round-Trip D= elay, the parallel definition for Active measurement is given in RFC 2681 [= RFC2681]. (and I saw many more examples of this verbose referencing) With the Observation Point [RFC7011] (OP) located between the hosts part= icipating in the TCP connection, the Round-trip Delay metric requires tw= o individual measurements between the OP and each host, such that the Sp= atial Composition [RFC6049] of the measurements yields a Round-trip Dela= y singleton. Well, actually 7011 never explicitly discusses composition of Round-trip= metrics, only one-way ones. I would simply say It is evident that the Round-trip Delay singleton is obtained by adding the two measurements. (and that would save some text later on how to perfor= m the composition) The direction of SYN transfer is the Forward direction of transmission, -> The direction of SYN transfer is considered the Forward direction of transm= ission, Examples may be found in the TCP timestamp fields. Unclear to me. In fact, the insistence on using the timestamp field is not clear to me. Although the timestamp option is often used, it IS only an option. Since you are working from a single OP, you can get away without the time= stamp. Yes, I saw the comment on packets on only one side of the OP, and am not = convinced that there aren't enough of the contrary case. Note that when OP is located at host A or host B, one of the terms compos= ing RTDelay will be zero or negligible. Since you state that the OP is "in the network" (and explicitly add that it= is remote to the hosts), I guess this is limited to the case where a router itself is the TCP end-po= int. Is that what is meant? In any case, you should either remove this remark, or the statement that th= e OP is remote from the end-point. TCP segments are normally monotonically increasing. I think this should be TCP segments are transmitted with monotonically increasing sequence numbers= , but may these segments may be received out of order. Also, "reordered packets" should be "misordered packets" or "out of order p= ackets". Reordering is what the host does. Packet Losses can be inferred from: ... Duplicate segments: Not only - duplication can occur due to malfunctioning network elements t= oo. Why the requirement for DSCP to be set to zero? Perhaps I am interested in = the RTT for a given DSCP value. (I saw this over and over in the doc) I am not sure why you specify that the TCP checksum must be calculated. That is standard TCP, and does not have to be specified here! If you do want to, then please specify the IP checksum, the TTL, etc. Once again, I am not sure why you insist on the timestamp option. The principal source of RTDelay error is the host processing time Another possibility to combat this is minimum gating (like in NTP). Nits: Examinating -> examining Why Corresponding Packets (capital P) but Qualified packets (small p) ? The Strowes reference is: Strowes, S., "Passively Measuring TCP Round Trip Times", Communications of = the ACM, Vol. 56 No. 10, Pages 57-64. Y(J)S --_000_VI1PR03MB14709B5E38492506F7555274E5AB0VI1PR03MB1470eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Al,

 

I didn't know what I was getting myself i= nto when I volunteered to look over even a small portion of this document.<= o:p>

93 pages ????

 

So, here are some preliminary remarks, mo= stly limited to the first half of section 10

(although some of what I have to say appl= ies to other portions of the document).

 

 

RTDelay … The Observation Point [RF= C7011] is assumed to be in the network at a remote point from the end hosts= .

->

While TCP runs end-to-end between two hos= ts, here we consider the measurement of RTDelay based on a single Observati= on Point located somewhere in the network.

 

and similarly:

RTLoss … The Observation Point [RFC= 7011] is assumed to be in the network at a remote point from the end hosts.

->

We consider the measurement of the RTLoss= based on a single Observation Point located somewhere in the network.=

 

Cleaner wording:

Although there is no RFC that describes p= assive measurement of Round-Trip Delay, the parallel definition for Active = measurement is given in RFC 2681 [RFC2681].

(and I saw many more examples of this ver= bose referencing)

 

With the Observation Point [RFC7011] (OP)= located between the hosts    participating in the TCP conne= ction, the Round-trip Delay metric    requires two individua= l measurements between the OP and each host,    such that the= Spatial Composition [RFC6049] of the measurements yields   = a Round-trip Delay singleton.

   Well, actually 7011 never ex= plicitly discusses composition of Round-trip metrics, only one-way ones. I = would simply say

It is evident that the Round-trip Delay s= ingleton is obtained by adding 

the two measurements. (and that would sav= e some text later on how to perform the composition)

 

The direction of SYN transfer is the Forw= ard direction of transmission,

->

The direction of SYN transfer is consider= ed the Forward direction of transmission,

 

Examples may be found in the TCP timestam= p fields.

  Unclear to me.

  In fact, the insistence on us= ing the timestamp field is not clear to me.

  Although the timestamp option= is often used, it IS only an option.

  Since you are working from a = single OP, you can get away without the timestamp.

  Yes, I saw the comment on packets = on only one side of the OP, and am not convinced that there aren’t en= ough of the contrary case.

 

Note that when OP is located at host A or= host B, one of the terms   composing RTDelay will be zero or neg= ligible.

Since you state that the OP is “in = the network” (and explicitly add that it is remote to the hosts),

I guess this is limited to the case where= a router itself is the TCP end-point. Is that what is meant?

In any case, you should either remove thi= s remark, or the statement that the OP is remote from the end-point.

 

TCP segments are normally monotonically i= ncreasing.

  I think this should be

TCP segments are transmitted with monoton= ically increasing sequence numbers, but may these segments may be received = out of order.

Also, “reordered packets” sho= uld be “misordered packets” or “out of order packets̶= 1;. Reordering is what the host does.

 

Packet Losses can be inferred from: ̷= 0; Duplicate segments:

  Not only - duplication can occur d= ue to malfunctioning network elements too.

 

Why the requirement for DSCP to be set to= zero? Perhaps I am interested in the RTT for a given DSCP value.

(I saw this over and over in the doc)

 

I am not sure why you specify that the TC= P checksum must be calculated.

That is standard TCP, and does not have t= o be specified here!

If you do want to, then please specify th= e IP checksum, the TTL, etc.

 

Once again, I am not sure why you insist = on the timestamp option.

 

The principal source of RTDelay error is = the host processing time

Another possibility to combat this is min= imum gating (like in NTP).

 

Nits:

 

Examinating -> examining

 

Why Corresponding Packets (capital P) but= Qualified packets (small p) ?

 

The Strowes reference is:

Strowes, S., "Passively Measuring TC= P Round Trip Times", Communications of the ACM, Vol. 56 No. 10, Pages = 57-64.

 

 

 

Y(J)S

 

--_000_VI1PR03MB14709B5E38492506F7555274E5AB0VI1PR03MB1470eurp_-- From nobody Wed Mar 21 08:02:35 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C6C12D95C; Wed, 21 Mar 2018 08:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 OK7mZNUL9G7c; Wed, 21 Mar 2018 08:02:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 08121127076; Wed, 21 Mar 2018 08:02:31 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 5EC9B296AD01E; Wed, 21 Mar 2018 15:02:27 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 21 Mar 2018 15:02:29 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Wed, 21 Mar 2018 23:02:14 +0800 From: Tianran Zhou To: "ippm@ietf.org" CC: "draft-zhou-ippm-ioam-yang@ietf.org" , Lizhenbin Thread-Topic: optimize the IOAM YANG data model Thread-Index: AdPBI0IyUlxeasHVSQiE4BAlkODCLQ== Date: Wed, 21 Mar 2018 15:02:14 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.90.40] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21A6D56CF2NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] optimize the IOAM YANG data model X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 15:02:33 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21A6D56CF2NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, Thanks Greg to point out the flexibility of sub-profiles on the meeting. He= re I would like to discuss the way to optimize this point for the IOAM YANG= as described in: https://datatracker.ietf.org/doc/draft-zhou-ippm-ioam-yang/ Although, as suggested, schema mount could help to dynamically mount sub-pr= ofiles to the IOAM configuration, IMHO, it may lead to the fragmentation of= the model, I.e., several modules. And I cannot see the possibility to reus= e the sub-profiles, except to this model. With the same requirement, I would suggest to use "feature" to enable the s= upported IOAM encapsulation types. And use the "enable" within each sub-pro= file to indicate the actual used sub-profile by the instance. Now four encapsulation types are supported according to the latest IOAM dat= a specification. We may augment the model with more sub-profiles. Thoughts? Thanks, Tianran --_000_BBA82579FD347748BEADC4C445EA0F21A6D56CF2NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

Thanks Greg to point out the fl= exibility of sub-profiles on the meeting. Here I would like to discuss the = way to optimize this point for the IOAM YANG as described in:

https://datatracker.ietf.org/doc/d= raft-zhou-ippm-ioam-yang/

 

Although, as suggested, schema = mount could help to dynamically mount sub-profiles to the IOAM configuratio= n, IMHO, it may lead to the fragmentation of the model, I.e., several modul= es. And I cannot see the possibility to reuse the sub-profiles, except to this model.

 

With the same requirement, I wo= uld suggest to use “feature” to enable the supported IOAM encap= sulation types. And use the “enable” within each sub-profile to= indicate the actual used sub-profile by the instance.

 

Now four encapsulation types ar= e supported according to the latest IOAM data specification. We may augment= the model with more sub-profiles.

 

Thoughts?

 

Thanks,

Tianran

--_000_BBA82579FD347748BEADC4C445EA0F21A6D56CF2NKGEML515MBXchi_-- From nobody Sun Mar 25 04:24:12 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA06127599; Sun, 25 Mar 2018 04:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 b09U1ERXGSJQ; Sun, 25 Mar 2018 04:24:08 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767CA120454; Sun, 25 Mar 2018 04:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16968; q=dns/txt; s=iport; t=1521977048; x=1523186648; h=from:to:cc:subject:date:message-id:mime-version; bh=a8lsbFSmsShR3jvfHZ+Y9qqRMtA4ND2c1XHyE0px1C0=; b=S0ylloA9HqR6Qmjm+nOFTv7eBJvZPYciKwSWryQ1nZx0bR3IJVrldrX3 3uXW0n7u2zDwXLytZ06KAEQH8d6f09JLCzbUXAMJOIUBfW2ajAdf3n5CV 0vrrI/fbqN5MrUDhsxzzt7PWtwWvyfjXpvXGJJWEWL+/QKo+U1+vfHrd0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxAQDXhbda/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJNSSthcCgKg1KIAI0NgXSBEY1shGWCBgsjhGIcg1YhNBgBAgE?= =?us-ascii?q?BAQEBAQJrKIUlAQYjVhIBCBEDAQIrAgQwHQoEAQ0FhCpkD6p6giCIP4IVBYdYg?= =?us-ascii?q?VRAgQwigmWDEwIDAYF6gmEwgiQDiAyIPoZ1CAKFUIhfgTCDV4cyiROGPAIREwG?= =?us-ascii?q?BJAEcOIFScBVkAYIYCYMrAQiNE2+PE4EXAQE?= X-IronPort-AV: E=Sophos; i="5.48,358,1517875200"; d="scan'208,217"; a="89089022" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2018 11:24:07 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w2PBO7Jg004209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 25 Mar 2018 11:24:07 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 25 Mar 2018 06:24:06 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Sun, 25 Mar 2018 06:24:06 -0500 From: "Reshad Rahman (rrahman)" To: Tianran Zhou , "ippm@ietf.org" CC: Lizhenbin , "draft-zhou-ippm-ioam-yang@ietf.org" Thread-Topic: [ippm] optimize the IOAM YANG data model Thread-Index: AQHTxCvJHF3cBlu8+0uZUmAURD9UnA== Date: Sun, 25 Mar 2018 11:24:06 +0000 Message-ID: <0D8CA483-D0E6-429D-B410-F5B1F03F46EE@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.44] Content-Type: multipart/alternative; boundary="_000_0D8CA483D0E6429DB410F5B1F03F46EEciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] optimize the IOAM YANG data model X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 11:24:11 -0000 --_000_0D8CA483D0E6429DB410F5B1F03F46EEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGlhbnJhbiBhbmQgR3JlZywNCg0KV2hpbGUgc2NoZW1hLW1vdW50IHdvdWxkIHdvcmssIGl0 IGlzIHJlYWxseSBpbnRlbmRlZCBmb3IgdXNlLWNhc2VzIHdoZXJlIHRoZXJlIGlzIGEgcmVxdWly ZW1lbnQgdG8gYWRkIGEgbW9kdWxlIGluIDIgb3IgbW9yZSBsb2NhdGlvbnMgKGUuZy4gaW50ZXJm YWNlcyBhdCB0b3AtbGV2ZWwsIGluIExORSBhbmQgaW4gTkkpLg0KDQpJ4oCZdmUgdGFrZW4gYSBx dWljayBsb29rIGF0IHRoZSBtb2RlbDoNCg0KICAqICAgVGhlIOKAnGVuYWJsZWTigJ0gbGVhZiBu b2RlIHVuZGVyIGlvYW0tcHJvZmlsZXMgKHZpYSBncm91cGluZyBpb2FtLWFkbWluLWNvbmZpZykg c2F5cyAiV2hlbiB0cnVlLCBJT0FNIGNvbmZpZ3VyYXRpb24gaXMgZW5hYmxlZCBmb3IgdGhlIHN5 c3RlbS4iLiBJIHRoaW5rIGl04oCZZCBtYWtlIG1vcmUgc2Vuc2UgaWYgdGhhdCBlbmFibGVkIGZs YWcgd2FzIHRvIGVuYWJsZS9kaXNhYmxlIElPQU0gZGF0YS1wbGFuZSBmdW5jdGlvbmFsaXR5Lg0K ICAqICAgV291bGQgYmUgYmVzdCB0byB1c2UgeWFuZy12ZXJzaW9uIDEuMSBJTU8uDQogICogICBQ bGVhc2UgdGFrZSBhIGxvb2sgYXQgNjA4N2Jpcy4NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0KRnJv bTogaXBwbSA8aXBwbS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgVGlhbnJhbiBaaG91 IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBNYXJjaCAyMSwgMjAx OCBhdCAzOjAzIFBNDQpUbzogImlwcG1AaWV0Zi5vcmciIDxpcHBtQGlldGYub3JnPg0KQ2M6IExp emhlbmJpbiA8bGl6aGVuYmluQGh1YXdlaS5jb20+LCAiZHJhZnQtemhvdS1pcHBtLWlvYW0teWFu Z0BpZXRmLm9yZyIgPGRyYWZ0LXpob3UtaXBwbS1pb2FtLXlhbmdAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBbaXBwbV0gb3B0aW1pemUgdGhlIElPQU0gWUFORyBkYXRhIG1vZGVsDQoNCkhpIEZvbGtzLA0K DQpUaGFua3MgR3JlZyB0byBwb2ludCBvdXQgdGhlIGZsZXhpYmlsaXR5IG9mIHN1Yi1wcm9maWxl cyBvbiB0aGUgbWVldGluZy4gSGVyZSBJIHdvdWxkIGxpa2UgdG8gZGlzY3VzcyB0aGUgd2F5IHRv IG9wdGltaXplIHRoaXMgcG9pbnQgZm9yIHRoZSBJT0FNIFlBTkcgYXMgZGVzY3JpYmVkIGluOg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhvdS1pcHBtLWlvYW0teWFu Zy8NCg0KQWx0aG91Z2gsIGFzIHN1Z2dlc3RlZCwgc2NoZW1hIG1vdW50IGNvdWxkIGhlbHAgdG8g ZHluYW1pY2FsbHkgbW91bnQgc3ViLXByb2ZpbGVzIHRvIHRoZSBJT0FNIGNvbmZpZ3VyYXRpb24s IElNSE8sIGl0IG1heSBsZWFkIHRvIHRoZSBmcmFnbWVudGF0aW9uIG9mIHRoZSBtb2RlbCwgSS5l Liwgc2V2ZXJhbCBtb2R1bGVzLiBBbmQgSSBjYW5ub3Qgc2VlIHRoZSBwb3NzaWJpbGl0eSB0byBy ZXVzZSB0aGUgc3ViLXByb2ZpbGVzLCBleGNlcHQgdG8gdGhpcyBtb2RlbC4NCg0KV2l0aCB0aGUg c2FtZSByZXF1aXJlbWVudCwgSSB3b3VsZCBzdWdnZXN0IHRvIHVzZSDigJxmZWF0dXJl4oCdIHRv IGVuYWJsZSB0aGUgc3VwcG9ydGVkIElPQU0gZW5jYXBzdWxhdGlvbiB0eXBlcy4gQW5kIHVzZSB0 aGUg4oCcZW5hYmxl4oCdIHdpdGhpbiBlYWNoIHN1Yi1wcm9maWxlIHRvIGluZGljYXRlIHRoZSBh Y3R1YWwgdXNlZCBzdWItcHJvZmlsZSBieSB0aGUgaW5zdGFuY2UuDQoNCk5vdyBmb3VyIGVuY2Fw c3VsYXRpb24gdHlwZXMgYXJlIHN1cHBvcnRlZCBhY2NvcmRpbmcgdG8gdGhlIGxhdGVzdCBJT0FN IGRhdGEgc3BlY2lmaWNhdGlvbi4gV2UgbWF5IGF1Z21lbnQgdGhlIG1vZGVsIHdpdGggbW9yZSBz dWItcHJvZmlsZXMuDQoNClRob3VnaHRzPw0KDQpUaGFua3MsDQpUaWFucmFuDQo= --_000_0D8CA483D0E6429DB410F5B1F03F46EEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4C20D0C49C59FB45842267DDA8761CF7@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXplOjEwLjVwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNt Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6 MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJ Zm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJ Zm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTY0MzM0MzAzODsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTI2NTEyMjkzOCAxODk5Njk0NjIgMjY5MDI1 MjgzIDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5 MDI1MjgzIDI2OTAyNTI4NTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNt O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkg VGlhbnJhbiBhbmQgR3JlZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hpbGUgc2NoZW1hLW1vdW50IHdvdWxkIHdvcmss IGl0IGlzIHJlYWxseSBpbnRlbmRlZCBmb3IgdXNlLWNhc2VzIHdoZXJlIHRoZXJlIGlzIGEgcmVx dWlyZW1lbnQgdG8gYWRkIGEgbW9kdWxlIGluIDIgb3IgbW9yZSBsb2NhdGlvbnMgKGUuZy4gaW50 ZXJmYWNlcyBhdCB0b3AtbGV2ZWwsDQogaW4gTE5FIGFuZCBpbiBOSSkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPknigJl2 ZSB0YWtlbiBhIHF1aWNrIGxvb2sgYXQgdGhlIG1vZGVsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSDigJxlbmFibGVk4oCdIGxlYWYgbm9kZSB1bmRlciBpb2Ft LXByb2ZpbGVzICh2aWEgZ3JvdXBpbmcNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+aW9hbS1hZG1pbi1jb25maWcpIHNheXMgJnF1b3Q7V2hlbiB0cnVl LCBJT0FNIGNvbmZpZ3VyYXRpb24gaXMgZW5hYmxlZCBmb3IgdGhlIHN5c3RlbS4mcXVvdDsuIEkg dGhpbmsgaXTigJlkIG1ha2UgbW9yZSBzZW5zZSBpZiB0aGF0IGVuYWJsZWQgZmxhZyB3YXMgdG8g ZW5hYmxlL2Rpc2FibGUgSU9BTSBkYXRhLXBsYW5lIGZ1bmN0aW9uYWxpdHkuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+V291bGQgYmUgYmVzdCB0byB1c2UgeWFuZy12ZXJzaW9uIDEuMSBJTU8uPG86cD48 L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UGxlYXNl IHRha2UgYSBsb29rIGF0IDYwODdiaXMuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZXNoYWQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+aXBwbSAmbHQ7aXBwbS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhh bGYgb2YgVGlhbnJhbiBaaG91ICZsdDt6aG91dGlhbnJhbkBodWF3ZWkuY29tJmd0Ozxicj4NCjxi PkRhdGU6IDwvYj5XZWRuZXNkYXksIE1hcmNoIDIxLCAyMDE4IGF0IDM6MDMgUE08YnI+DQo8Yj5U bzogPC9iPiZxdW90O2lwcG1AaWV0Zi5vcmcmcXVvdDsgJmx0O2lwcG1AaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5MaXpoZW5iaW4gJmx0O2xpemhlbmJpbkBodWF3ZWkuY29tJmd0OywgJnF1 b3Q7ZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZ0BpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtemhv dS1pcHBtLWlvYW0teWFuZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W2lwcG1d IG9wdGltaXplIHRoZSBJT0FNIFlBTkcgZGF0YSBtb2RlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1V UyI+SGkgRm9sa3MsPC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhh bmtzIEdyZWcgdG8gcG9pbnQgb3V0IHRoZSBmbGV4aWJpbGl0eSBvZiBzdWItcHJvZmlsZXMgb24g dGhlIG1lZXRpbmcuIEhlcmUgSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgdGhlIHdheSB0byBvcHRp bWl6ZSB0aGlzIHBvaW50IGZvciB0aGUgSU9BTSBZQU5HIGFzIGRlc2NyaWJlZCBpbjo8L3NwYW4+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC16aG91LWlwcG0taW9hbS15YW5nLyI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpob3UtaXBwbS1pb2FtLXlhbmcvPC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWx0aG91Z2gsIGFzIHN1Z2dlc3RlZCwg c2NoZW1hIG1vdW50IGNvdWxkIGhlbHAgdG8gZHluYW1pY2FsbHkgbW91bnQgc3ViLXByb2ZpbGVz IHRvIHRoZSBJT0FNIGNvbmZpZ3VyYXRpb24sIElNSE8sIGl0IG1heSBsZWFkIHRvIHRoZSBmcmFn bWVudGF0aW9uIG9mIHRoZSBtb2RlbCwgSS5lLiwgc2V2ZXJhbA0KIG1vZHVsZXMuIEFuZCBJIGNh bm5vdCBzZWUgdGhlIHBvc3NpYmlsaXR5IHRvIHJldXNlIHRoZSBzdWItcHJvZmlsZXMsIGV4Y2Vw dCB0byB0aGlzIG1vZGVsLjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gbGFuZz0iRU4t VVMiPldpdGggdGhlIHNhbWUgcmVxdWlyZW1lbnQsIEkgd291bGQgc3VnZ2VzdCB0byB1c2Ug4oCc ZmVhdHVyZeKAnSB0byBlbmFibGUgdGhlIHN1cHBvcnRlZCBJT0FNIGVuY2Fwc3VsYXRpb24gdHlw ZXMuIEFuZCB1c2UgdGhlIOKAnGVuYWJsZeKAnSB3aXRoaW4gZWFjaCBzdWItcHJvZmlsZSB0byBp bmRpY2F0ZSB0aGUgYWN0dWFsDQogdXNlZCBzdWItcHJvZmlsZSBieSB0aGUgaW5zdGFuY2UuPC9z cGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+Tm93IGZvdXIgZW5jYXBz dWxhdGlvbiB0eXBlcyBhcmUgc3VwcG9ydGVkIGFjY29yZGluZyB0byB0aGUgbGF0ZXN0IElPQU0g ZGF0YSBzcGVjaWZpY2F0aW9uLiBXZSBtYXkgYXVnbWVudCB0aGUgbW9kZWwgd2l0aCBtb3JlIHN1 Yi1wcm9maWxlcy48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aG91Z2h0cz88L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFu a3MsPC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGlhbnJh bjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0D8CA483D0E6429DB410F5B1F03F46EEciscocom_-- From nobody Sun Mar 25 19:04:35 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3694A127010; Sun, 25 Mar 2018 19:04:34 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 4G8Sbthl-9fV; Sun, 25 Mar 2018 19:04:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 B2DDC126E64; Sun, 25 Mar 2018 19:04:31 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0F2B3FC04C788; Mon, 26 Mar 2018 03:04:28 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 26 Mar 2018 03:04:28 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Mon, 26 Mar 2018 10:04:17 +0800 From: Tianran Zhou To: "Reshad Rahman (rrahman)" , "ippm@ietf.org" CC: Lizhenbin , "draft-zhou-ippm-ioam-yang@ietf.org" Thread-Topic: [ippm] optimize the IOAM YANG data model Thread-Index: AQHTxCvJHF3cBlu8+0uZUmAURD9UnKPhwliw Date: Mon, 26 Mar 2018 02:04:17 +0000 Message-ID: References: <0D8CA483-D0E6-429D-B410-F5B1F03F46EE@cisco.com> In-Reply-To: <0D8CA483-D0E6-429D-B410-F5B1F03F46EE@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21A6D59D14NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] optimize the IOAM YANG data model X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 26 Mar 2018 02:04:34 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21A6D59D14NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmVzaGFkLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQpQbGVhc2Ugc2VlIGluIGxp bmUuDQoNCkNoZWVycywNClRpYW5yYW4NCg0KRnJvbTogUmVzaGFkIFJhaG1hbiAocnJhaG1hbikg W21haWx0bzpycmFobWFuQGNpc2NvLmNvbV0NClNlbnQ6IFN1bmRheSwgTWFyY2ggMjUsIDIwMTgg NzoyNCBQTQ0KVG86IFRpYW5yYW4gWmhvdTsgaXBwbUBpZXRmLm9yZw0KQ2M6IExpemhlbmJpbjsg ZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtpcHBtXSBv cHRpbWl6ZSB0aGUgSU9BTSBZQU5HIGRhdGEgbW9kZWwNCg0KSGkgVGlhbnJhbiBhbmQgR3JlZywN Cg0KV2hpbGUgc2NoZW1hLW1vdW50IHdvdWxkIHdvcmssIGl0IGlzIHJlYWxseSBpbnRlbmRlZCBm b3IgdXNlLWNhc2VzIHdoZXJlIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgdG8gYWRkIGEgbW9kdWxl IGluIDIgb3IgbW9yZSBsb2NhdGlvbnMgKGUuZy4gaW50ZXJmYWNlcyBhdCB0b3AtbGV2ZWwsIGlu IExORSBhbmQgaW4gTkkpLg0KDQpbenRyXVllcywgdGhhdOKAmXMgd2hhdCBJIHRob3VnaHQuIFNv IEkgc3VnZ2VzdGVkIHRvIHVzZSDigJxmZWF0dXJl4oCdIHNvIHRoYXQgdGhlIGNhbiBvbmx5IHN1 cHBvcnQgcGFydCBvZiB0aGUgZW5jYXBzdWxhdGlvbiB0eXBlcy4NCg0KSeKAmXZlIHRha2VuIGEg cXVpY2sgbG9vayBhdCB0aGUgbW9kZWw6DQoNCiAgKiAgIFRoZSDigJxlbmFibGVk4oCdIGxlYWYg bm9kZSB1bmRlciBpb2FtLXByb2ZpbGVzICh2aWEgZ3JvdXBpbmcgaW9hbS1hZG1pbi1jb25maWcp IHNheXMgIldoZW4gdHJ1ZSwgSU9BTSBjb25maWd1cmF0aW9uIGlzIGVuYWJsZWQgZm9yIHRoZSBz eXN0ZW0uIi4gSSB0aGluayBpdOKAmWQgbWFrZSBtb3JlIHNlbnNlIGlmIHRoYXQgZW5hYmxlZCBm bGFnIHdhcyB0byBlbmFibGUvZGlzYWJsZSBJT0FNIGRhdGEtcGxhbmUgZnVuY3Rpb25hbGl0eS4N Clt6dHJdWWVzLCB0aGlzIGlzIG1vcmUgY2xlYXIuIEkgd2lsbCBhZGQgdGhlIHdvcmRzIHRvIHRo ZSBkb2N1bWVudC4NCg0KICAqICAgV291bGQgYmUgYmVzdCB0byB1c2UgeWFuZy12ZXJzaW9uIDEu MSBJTU8uDQogICogICBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgNjA4N2Jpcy4NClt6dHJdQ291bGQg eW91IHBsZWFzZSBwb2ludCBvdXQgd2hhdCBwYXJ0IG9mIHRoZSA2MDg3YmlzIEkgbmVlZCB0byBw YXkgYXR0ZW50aW9uPyBBbmQgd2hhdCBpcyBub3QgeWFuZyAxLjE/DQpJIGludGVuZGVkIHRvIGZv bGxvdyB5YW5nIDEuMSBpbmRlZWQuIOKYug0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQpGcm9tOiBp cHBtIDxpcHBtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRv Onpob3V0aWFucmFuQGh1YXdlaS5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBNYXJjaCAyMSwgMjAx OCBhdCAzOjAzIFBNDQpUbzogImlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+IiA8 aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpDYzogTGl6aGVuYmluIDxsaXpo ZW5iaW5AaHVhd2VpLmNvbTxtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20+PiwgImRyYWZ0LXpo b3UtaXBwbS1pb2FtLXlhbmdAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXpob3UtaXBwbS1pb2FtLXlh bmdAaWV0Zi5vcmc+IiA8ZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZ0BpZXRmLm9yZzxtYWlsdG86 ZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZ0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbaXBwbV0gb3B0 aW1pemUgdGhlIElPQU0gWUFORyBkYXRhIG1vZGVsDQoNCkhpIEZvbGtzLA0KDQpUaGFua3MgR3Jl ZyB0byBwb2ludCBvdXQgdGhlIGZsZXhpYmlsaXR5IG9mIHN1Yi1wcm9maWxlcyBvbiB0aGUgbWVl dGluZy4gSGVyZSBJIHdvdWxkIGxpa2UgdG8gZGlzY3VzcyB0aGUgd2F5IHRvIG9wdGltaXplIHRo aXMgcG9pbnQgZm9yIHRoZSBJT0FNIFlBTkcgYXMgZGVzY3JpYmVkIGluOg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZy8NCg0KQWx0aG91 Z2gsIGFzIHN1Z2dlc3RlZCwgc2NoZW1hIG1vdW50IGNvdWxkIGhlbHAgdG8gZHluYW1pY2FsbHkg bW91bnQgc3ViLXByb2ZpbGVzIHRvIHRoZSBJT0FNIGNvbmZpZ3VyYXRpb24sIElNSE8sIGl0IG1h eSBsZWFkIHRvIHRoZSBmcmFnbWVudGF0aW9uIG9mIHRoZSBtb2RlbCwgSS5lLiwgc2V2ZXJhbCBt b2R1bGVzLiBBbmQgSSBjYW5ub3Qgc2VlIHRoZSBwb3NzaWJpbGl0eSB0byByZXVzZSB0aGUgc3Vi LXByb2ZpbGVzLCBleGNlcHQgdG8gdGhpcyBtb2RlbC4NCg0KV2l0aCB0aGUgc2FtZSByZXF1aXJl bWVudCwgSSB3b3VsZCBzdWdnZXN0IHRvIHVzZSDigJxmZWF0dXJl4oCdIHRvIGVuYWJsZSB0aGUg c3VwcG9ydGVkIElPQU0gZW5jYXBzdWxhdGlvbiB0eXBlcy4gQW5kIHVzZSB0aGUg4oCcZW5hYmxl 4oCdIHdpdGhpbiBlYWNoIHN1Yi1wcm9maWxlIHRvIGluZGljYXRlIHRoZSBhY3R1YWwgdXNlZCBz dWItcHJvZmlsZSBieSB0aGUgaW5zdGFuY2UuDQoNCk5vdyBmb3VyIGVuY2Fwc3VsYXRpb24gdHlw ZXMgYXJlIHN1cHBvcnRlZCBhY2NvcmRpbmcgdG8gdGhlIGxhdGVzdCBJT0FNIGRhdGEgc3BlY2lm aWNhdGlvbi4gV2UgbWF5IGF1Z21lbnQgdGhlIG1vZGVsIHdpdGggbW9yZSBzdWItcHJvZmlsZXMu DQoNClRob3VnaHRzPw0KDQpUaGFua3MsDQpUaWFucmFuDQo= --_000_BBA82579FD347748BEADC4C445EA0F21A6D59D14NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5paw5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDkgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDmlrDlrovkvZMiOw0K CXBhbm9zZS0xOjIgMSA2IDkgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVz dGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7 DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJ Zm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7m oLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsO30NCnAuSFRNTFByZWZvcm1hdHRlZCwgbGkuSFRNTFByZWZvcm1hdHRlZCwgZGl2LkhU TUxQcmVmb3JtYXR0ZWQNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlm eTppbnRlci1pZGVvZ3JhcGg7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBw dCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTE3NzQy ODAzNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2MzQ0MDM0NDQ7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUmVzaGFkLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVh c2Ugc2VlIGluIGxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRpYW5y YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pDQog W21haWx0bzpycmFobWFuQGNpc2NvLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWFy Y2ggMjUsIDIwMTggNzoyNCBQTTxicj4NCjxiPlRvOjwvYj4gVGlhbnJhbiBaaG91OyBpcHBtQGll dGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBMaXpoZW5iaW47IGRyYWZ0LXpob3UtaXBwbS1pb2FtLXlh bmdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtpcHBtXSBvcHRpbWl6ZSB0aGUg SU9BTSBZQU5HIGRhdGEgbW9kZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxl ZnQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkhpIFRpYW5yYW4gYW5kIEdyZWcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldoaWxlIHNjaGVtYS1tb3VudCB3 b3VsZCB3b3JrLCBpdCBpcyByZWFsbHkgaW50ZW5kZWQgZm9yIHVzZS1jYXNlcyB3aGVyZSB0aGVy ZSBpcyBhIHJlcXVpcmVtZW50IHRvIGFkZCBhIG1vZHVsZSBpbiAyIG9yIG1vcmUgbG9jYXRpb25z IChlLmcuIGludGVyZmFjZXMgYXQgdG9wLWxldmVsLCBpbiBMTkUgYW5kIGluIE5JKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5benRy XVllcywgdGhhdOKAmXMgd2hhdCBJIHRob3VnaHQuIFNvIEkgc3VnZ2VzdGVkIHRvIHVzZSDigJxm ZWF0dXJl4oCdIHNvIHRoYXQgdGhlIGNhbiBvbmx5IHN1cHBvcnQgcGFydCBvZiB0aGUgZW5jYXBz dWxhdGlvbiB0eXBlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SeKAmXZlIHRha2VuIGEgcXVpY2sgbG9vayBhdCB0aGUgbW9kZWw6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSDigJxlbmFibGVk4oCdIGxlYWYg bm9kZSB1bmRlciBpb2FtLXByb2ZpbGVzICh2aWEgZ3JvdXBpbmcNCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPmlvYW0tYWRtaW4t Y29uZmlnKSBzYXlzICZxdW90O1doZW4gdHJ1ZSwgSU9BTSBjb25maWd1cmF0aW9uIGlzIGVuYWJs ZWQgZm9yIHRoZSBzeXN0ZW0uJnF1b3Q7LiBJIHRoaW5rIGl04oCZZCBtYWtlIG1vcmUgc2Vuc2Ug aWYgdGhhdCBlbmFibGVkIGZsYWcgd2FzIHRvIGVuYWJsZS9kaXNhYmxlIElPQU0gZGF0YS1wbGFu ZSBmdW5jdGlvbmFsaXR5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W3p0cl1ZZXMsIHRoaXMgaXMgbW9yZSBjbGVhci4gSSB3 aWxsIGFkZCB0aGUgd29yZHMgdG8gdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Xb3VsZCBiZSBiZXN0IHRvIHVzZSB5YW5nLXZlcnNp b24gMS4xIElNTy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+UGxlYXNlIHRha2UgYSBsb29rIGF0IDYwODdiaXMuPG86cD48L286 cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj5benRyXUNvdWxkIHlvdSBwbGVhc2UgcG9pbnQgb3V0IHdoYXQgcGFydCBvZiB0aGUgNjA4 N2JpcyBJIG5lZWQgdG8gcGF5IGF0dGVudGlvbj8gQW5kIHdoYXQgaXMgbm90IHlhbmcgMS4xPw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIGludGVuZGVkIHRvIGZvbGxvdyB5YW5nIDEuMSBpbmRlZWQuDQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3 RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVzaGFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmlwcG0gJmx0 OzxhIGhyZWY9Im1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmciPmlwcG0tYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBUaWFucmFuIFpob3UgJmx0OzxhIGhyZWY9Im1haWx0 bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tIj56aG91dGlhbnJhbkBodWF3ZWkuY29tPC9hPiZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBNYXJjaCAyMSwgMjAxOCBhdCAzOjAzIFBNPGJy Pg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyI+aXBwbUBp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj5pcHBt QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPkxpemhlbmJpbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmxpemhlbmJpbkBodWF3ZWkuY29tIj5saXpoZW5iaW5AaHVhd2VpLmNvbTwvYT4mZ3Q7 LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZ0BpZXRmLm9y ZyI+ZHJhZnQtemhvdS1pcHBtLWlvYW0teWFuZ0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpkcmFmdC16aG91LWlwcG0taW9hbS15YW5nQGlldGYub3JnIj5kcmFmdC16aG91 LWlwcG0taW9hbS15YW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W2lw cG1dIG9wdGltaXplIHRoZSBJT0FNIFlBTkcgZGF0YSBtb2RlbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gbGFuZz0iRU4tVVMiPkhpIEZvbGtzLDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgR3Jl ZyB0byBwb2ludCBvdXQgdGhlIGZsZXhpYmlsaXR5IG9mIHN1Yi1wcm9maWxlcyBvbiB0aGUgbWVl dGluZy4gSGVyZSBJIHdvdWxkIGxpa2UgdG8gZGlzY3VzcyB0aGUgd2F5IHRvIG9wdGltaXplIHRo aXMgcG9pbnQgZm9yIHRoZSBJT0FNIFlBTkcgYXMgZGVzY3JpYmVkIGluOjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhvdS1pcHBt LWlvYW0teWFuZy8iPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC16aG91LWlwcG0taW9hbS15YW5nLzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbHRo b3VnaCwgYXMgc3VnZ2VzdGVkLCBzY2hlbWEgbW91bnQgY291bGQgaGVscCB0byBkeW5hbWljYWxs eSBtb3VudCBzdWItcHJvZmlsZXMgdG8gdGhlIElPQU0gY29uZmlndXJhdGlvbiwgSU1ITywgaXQg bWF5IGxlYWQgdG8gdGhlIGZyYWdtZW50YXRpb24gb2YgdGhlIG1vZGVsLCBJLmUuLCBzZXZlcmFs IG1vZHVsZXMuIEFuZCBJIGNhbm5vdCBzZWUgdGhlIHBvc3NpYmlsaXR5DQogdG8gcmV1c2UgdGhl IHN1Yi1wcm9maWxlcywgZXhjZXB0IHRvIHRoaXMgbW9kZWwuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2l0aCB0 aGUgc2FtZSByZXF1aXJlbWVudCwgSSB3b3VsZCBzdWdnZXN0IHRvIHVzZSDigJxmZWF0dXJl4oCd IHRvIGVuYWJsZSB0aGUgc3VwcG9ydGVkIElPQU0gZW5jYXBzdWxhdGlvbiB0eXBlcy4gQW5kIHVz ZSB0aGUg4oCcZW5hYmxl4oCdIHdpdGhpbiBlYWNoIHN1Yi1wcm9maWxlIHRvIGluZGljYXRlIHRo ZSBhY3R1YWwgdXNlZCBzdWItcHJvZmlsZSBieSB0aGUgaW5zdGFuY2UuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Tm93IGZvdXIgZW5jYXBzdWxhdGlvbiB0eXBlcyBhcmUgc3VwcG9ydGVkIGFjY29yZGluZyB0byB0 aGUgbGF0ZXN0IElPQU0gZGF0YSBzcGVjaWZpY2F0aW9uLiBXZSBtYXkgYXVnbWVudCB0aGUgbW9k ZWwgd2l0aCBtb3JlIHN1Yi1wcm9maWxlcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaG91Z2h0cz88L3NwYW4+ PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGFua3MsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGlhbnJhbjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBA82579FD347748BEADC4C445EA0F21A6D59D14NKGEML515MBXchi_-- From nobody Mon Mar 26 08:11:14 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B5B127863 for ; Wed, 21 Mar 2018 10:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.onmicrosoft.com 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 KpM6lY_ptZ2y for ; Wed, 21 Mar 2018 10:31:16 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0052.outbound.protection.outlook.com [104.47.34.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680FD12762F for ; Wed, 21 Mar 2018 10:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Cz34wp4wd2xZWRKI9EZvWgUMEM913Q9sVXcWxaq/UG8=; b=u5VOJGhWuDifxMuulCH5Uu+lyJ+X+uCJOJJqO4dNbIAQQI68o1VVhtSGxtnco3gNPMmqisAP4Lomw94QHNLp1Kt5KABsEiQBkfW4+WiLFulwKvXUjkjHryUvfJZnvbVBOznjMWPe21pfe2mocQ+pqvLkD/ecxZLkmSTzm76f5LY= Received: from BN6PR10MB1955.namprd10.prod.outlook.com (10.175.98.14) by BN6PR10MB1667.namprd10.prod.outlook.com (10.172.18.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.10; Wed, 21 Mar 2018 17:31:13 +0000 Received: from BN6PR10MB1955.namprd10.prod.outlook.com ([10.175.98.14]) by BN6PR10MB1955.namprd10.prod.outlook.com ([10.175.98.14]) with mapi id 15.20.0609.010; Wed, 21 Mar 2018 17:31:12 +0000 From: Madhukar Anand To: "ippm@ietf.org" CC: Sanjoy Bardhan , Randy Zhang , Ramesh Subrahmaniam , Radhakrishna Valiveti , Shwetha Bhandari , "Radhakrishna Valiveti" , Carlos Pignataro , Rajiv Asati , "ietf@trammell.ch" Thread-Topic: New Version Notification for draft-anand-ippm-po-ioam-00.txt Thread-Index: AQHTry5xgp3FxGSfdESU7KK632lBJaO70EqwgB9FTDA= Date: Wed, 21 Mar 2018 17:31:12 +0000 Message-ID: References: <151966920728.21787.3479650063380468990.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAnand@infinera.com; x-originating-ip: [8.4.225.31] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR10MB1667; 7:rAzSTR5c4HKCNxAkFzqkJt1LJhc560Rc/z21J3+WwiANtApBySJcViFf7lrvLQTFIGUEaArsEmD/j5wQKbGw5d34KJv2SPzBYL4KtbHiHIwoyziNL/79EqesQtD2q+5FJ4unuIfFEz+82coaqbxrZzLgzGQkRwJg7kN6XzNh78RrLQJO1cbqAqdbfRZ54txPGLCVNQUbQf94kY4UwgGLxNFTMlF38lMPNBuoQXugWV4QYGfm9ph9mk+ApjkzJICQ x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39380400002)(366004)(39850400004)(13464003)(53754006)(377424004)(189003)(199004)(3846002)(6116002)(68736007)(106356001)(59450400001)(2351001)(6306002)(7736002)(55016002)(9686003)(5640700003)(74316002)(305945005)(561944003)(6246003)(478600001)(966005)(2950100002)(53936002)(6916009)(72206003)(3660700001)(33656002)(15650500001)(316002)(54906003)(2900100001)(6436002)(105586002)(8936002)(80792005)(97736004)(2906002)(8676002)(5660300001)(3280700002)(81166006)(81156014)(76176011)(99286004)(7696005)(1730700003)(25786009)(4326008)(5890100001)(2501003)(39060400002)(14454004)(186003)(26005)(6506007)(53546011)(77096007)(66066001)(102836004)(229853002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR10MB1667; H:BN6PR10MB1955.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: c93c2843-a031-4621-84ed-08d58f518a9e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR10MB1667; x-ms-traffictypediagnostic: BN6PR10MB1667: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014)(201166117486090); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501325)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR10MB1667; BCL:0; PCL:0; RULEID:; SRVR:BN6PR10MB1667; x-forefront-prvs: 0618E4E7E1 received-spf: None (protection.outlook.com: infinera.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: AMF4kzzATxDsORoLHCjplXaqpqRae81KN0wxXxOei6wQZ96MCxXxFi2uThGMj+o/c3XyYxZ7Y/CDYnganRe2SY4cdclXpP28hOyBLgC9PmPb01YHBfw1w1wVYX5PPu6+lafyyLRx0ZyR74ZC8imFWD8ibIogO31Rhn9r/20lAvWrRlodBcGGtfhRivpj+rSWyVUkgTy7FI7QxemER4ur2Za4eFQe4RdofeApL3AY64N2y6rOkRKYOcrHEVfsQuhzd8TwwU0wP8dsDxo0wixQ5/1Z0xoMEb2uYVguT1tSL6Eke5hVLDHDABIQyu7Go7uEa2Gi5FtN8D8jyG4aKxb1/w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-Network-Message-Id: c93c2843-a031-4621-84ed-08d58f518a9e X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2018 17:31:12.1458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1667 Archived-At: X-Mailman-Approved-At: Mon, 26 Mar 2018 08:11:12 -0700 Subject: Re: [ippm] New Version Notification for draft-anand-ippm-po-ioam-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 17:31:19 -0000 VGhhbmsgeW91LCBCcmlhbiwgZm9yIHlvdXIgZmVlZGJhY2suICAgDQoNCkZvbGtzLA0KIEFzIHdl IGhhdmUgcG9pbnRlZCBvdXQgZWFybGllciwgcGxlYXNlIGZpbmQgdGhlIGxpbmsgYmVsb3cgdG8g YSBwcm9wb3NhbCBvbiBleHRlbmRpbmcgSU9BTSB0byBvcHRpY2FsL3RyYW5zcG9ydCBuZXR3b3Jr cy4gUGxlYXNlIHJldmlldyBhbmQgbGV0IHVzIGtub3cgb2YgYW55IGNvbW1lbnRzIG9yIHN1Z2dl c3Rpb25zIHlvdSBtYXkgaGF2ZS4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1hbmFuZC1pcHBtLXBvLWlvYW0tMDAudHh0DQoNClRoYW5rcywNCk1hZGh1a2FyDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hZGh1a2FyIEFuYW5kIA0KU2Vu dDogVGh1cnNkYXksIE1hcmNoIDAxLCAyMDE4IDExOjU4IEFNDQpUbzogJ2lwcG1AaWV0Zi5vcmcn IDxpcHBtQGlldGYub3JnPg0KQ2M6IFNhbmpveSBCYXJkaGFuIDxzYmFyZGhhbkBpbmZpbmVyYS5j b20+OyBSYW5keSBaaGFuZyA8cmFuemhhbmdAY2lzY28uY29tPjsgUmFtZXNoIFN1YnJhaG1hbmlh bSA8c3ZyX2ZyZW1vbnRAeWFob28uY29tPjsgUmFkaGFrcmlzaG5hIFZhbGl2ZXRpIDxydmFsaXZl dGlAaW5maW5lcmEuY29tPjsgU2h3ZXRoYSBCaGFuZGFyaSA8c2h3ZXRoYWJAY2lzY28uY29tPjsg UmFkaGFrcmlzaG5hIFZhbGl2ZXRpIDxydmFsaXZldGlAaW5maW5lcmEuY29tPjsgQ2FybG9zIFBp Z25hdGFybyA8Y3BpZ25hdGFAY2lzY28uY29tPjsgUmFqaXYgQXNhdGkgPHJhaml2YUBjaXNjby5j b20+DQpTdWJqZWN0OiBSRTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbmFu ZC1pcHBtLXBvLWlvYW0tMDAudHh0DQoNCkhpIEFsbCwNCg0KIFBsZWFzZSBmaW5kIGJlbG93IGEg cHJvcG9zYWwgZm9yIGV4dGVuZGluZyBJT0FNIHRvIG9wdGljYWwvdHJhbnNwb3J0IG5ldHdvcmtz LiBQbGVhc2UgcmV2aWV3IGFuZCBsZXQgdXMga25vdyBvZiBhbnkgY29tbWVudHMgb3Igc3VnZ2Vz dGlvbnMgeW91IG1heSBoYXZlLiANCg0KVGhhbmtzLA0KTWFkaHVrYXINCg0KDQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgRmVicnVhcnkg MjYsIDIwMTggMTA6MjAgQU0NClRvOiBTYW5qb3kgQmFyZGhhbiA8c2JhcmRoYW5AaW5maW5lcmEu Y29tPjsgUmFuZHkgWmhhbmcgPHJhbnpoYW5nQGNpc2NvLmNvbT47IFJhbWVzaCBTdWJyYWhtYW5p YW0gPHN2cl9mcmVtb250QHlhaG9vLmNvbT47IE1hZGh1a2FyIEFuYW5kIDxNQW5hbmRAaW5maW5l cmEuY29tPjsgUmFkaGFrcmlzaG5hIFZhbGl2ZXRpIDxydmFsaXZldGlAaW5maW5lcmEuY29tPjsg U2h3ZXRoYSBCaGFuZGFyaSA8c2h3ZXRoYWJAY2lzY28uY29tPjsgUmFkaGFrcmlzaG5hIFZhbGl2 ZXRpIDxydmFsaXZldGlAaW5maW5lcmEuY29tPjsgQ2FybG9zIFBpZ25hdGFybyA8Y3BpZ25hdGFA Y2lzY28uY29tPjsgUmFqaXYgQXNhdGkgPHJhaml2YUBjaXNjby5jb20+DQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFuYW5kLWlwcG0tcG8taW9hbS0wMC50eHQN Cg0KQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3Jn YW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3Mg eW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFuYW5kLWlwcG0tcG8taW9hbS0wMC50eHQg aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNYWRodWthciBBbmFuZCBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1hbmFu ZC1pcHBtLXBvLWlvYW0NClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIEludGVn cmF0ZWQgUGFja2V0LU9wdGljYWwgSW4tU2l0dSBPQU0NCkRvY3VtZW50IGRhdGU6ICAyMDE4LTAy LTI2DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAg ICAgMTINClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYW5hbmQtaXBwbS1wby1pb2FtLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFuYW5kLWlwcG0tcG8taW9hbS8NCkh0 bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYW5hbmQtaXBw bS1wby1pb2FtLTAwDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1hbmFuZC1pcHBtLXBvLWlvYW0tMDANCg0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSB3YXkgdG8gZXh0ZW5kIGluLXNpdHUgT0FNIHRlY2hu aXF1ZXMgdG8NCiAgIGluY2x1ZGUgb3BlcmF0aW9uYWwgZGF0YSBmcm9tIG11bHRpcGxlIG5ldHdv cmsgbGF5ZXJzIHdpdGggYSB2aWV3IHRvDQogICBjcmVhdGUgYW4gaW50ZWdyYXRlZCByZWNvcmQg b2YgT0FNIGluZm9ybWF0aW9uIGFzIHRoZSBkYXRhIGZsb3dzDQogICBiZXR3ZWVuIHR3byBuZXR3 b3JrIGVudGl0aWVzLiBBbiBpbnN0YW5jZSBvZiB0aGlzIHRlY2huaXF1ZSB0aGF0IGlzDQogICBl bGFib3JhdGVkIGhlcmUgZm9jdXNlcyBvbiBwYWNrZXQtb3B0aWNhbCBuZXR3b3JrcyB0aGF0IGFy ZQ0KICAgdHJhZGl0aW9uYWxseSB0cmFuc3BvcnQgY2VudHJpYy4gVGhlIG1lY2hhbmlzbXMgZGVz Y3JpYmVkIGFyZSBnZW5lcmFsDQogICBlbm91Z2ggdG8gYWxsb3cgZnV0dXJlIGV4dGVuc2liaWxp dHkgb2YgaW4tc2l0dSBPQU0gdGVjaG5pcXVlcyBpbnRvDQogICBvdGhlciBub24tcGFja2V0IGRv bWFpbnMuDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Mar 29 13:45:07 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E11129C59; Thu, 29 Mar 2018 13:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9IKhM-nB54_0; Thu, 29 Mar 2018 13:45:01 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 1A55512741D; Thu, 29 Mar 2018 13:45:01 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id r29so2367623ywa.12; Thu, 29 Mar 2018 13:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=g8vJBMAN1AmlcAfX59YUtWNh/Q9gwEPq4ih/wXyv9ss=; b=NJAeFqhaBMVeV8c4J9mGyMrQCH5pHfy544DFifI7+L91EKTysDh+p+GOpTOsuPoncs tCgA8u+XQw0UUZSg9GkpTF0n7Uus5KRx+rRMTUGKkYoVprzAQRCZpPiMGRHM8oRMXAfb 6awtnsguG1DnIKj7IVoTMOGaPqjXgSKVblCt99jkzfmgca78cgY1iHPEP5KwvNG8FJTs W5D+V8MK5dAxwdnm1IKXo1qROZmgysdnVg6EvKvo2tPWRBGe48JEPMZXxv6SpMGYzX8C 3K12rK+MWEFs4Ff644Ja8fJulm3eeXDa4sZGwNoq0GP6e/6kRvGa2x7xFgqw4jYtunkW ubNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=g8vJBMAN1AmlcAfX59YUtWNh/Q9gwEPq4ih/wXyv9ss=; b=UzDCp7R/Rv/5wQrLnG/i6jmXptarztNb+1XfABs6c899DvVie44XmY3njAGUiD99pQ rl9gQPEawErVU8Uu/VnbNyrfNiDpq6NX0U/xPhkAVOInPix7+5xujqzYvG2+Imuit7Id l1MCDxzTdWbf+QO5rVmS7mqSkFiFj9V40LGFBSMNePoxgNXhWQGFXGvzbZX5AKnqpQcc vGkq2YLJ/Zg59cSJ+s95ERjvXHnqyL2nVUTJRHL9Hvuo6vRLDpWXngQhmrkRBXXyrS6w hYz51jx1LxQF6FwPavNMy9SqHpe/b/u266MxylKlZ1/7JY+woAVFnallZeOCaOVJ+0IB J9hg== X-Gm-Message-State: ALQs6tDrlRBTWk/GCqR/FMVD5P8yaKgseLxtdPCNK/WhhujwE0M0NwcC 9PKcTwN2l85VI2wMUb5TJRUQKN8wxeJxH70LldU= X-Google-Smtp-Source: AIpwx49aAE7dHPSjebtFcB1wpKxfeNx0saWl9EEmtMzjejjQykFk+uL/7ckWHWbSS3DTbiJDV85xfpebYNJGWNKXxBQ= X-Received: by 10.129.59.1 with SMTP id i1mr5924427ywa.311.1522356299824; Thu, 29 Mar 2018 13:44:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:e757:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 13:44:59 -0700 (PDT) From: Spencer Dawkins at IETF Date: Thu, 29 Mar 2018 15:44:59 -0500 Message-ID: To: Brian Trammell Cc: Nalini Elkins , ippm-chairs@ietf.org, ippm@ietf.org, draft-ietf-ippm-twamp-yang@ietf.org Content-Type: multipart/alternative; boundary="001a1143e4fe7904950568933200" Archived-At: Subject: [ippm] AD Evaluation of draft-ietf-ippm-twamp-yang-06 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2018 20:45:06 -0000 --001a1143e4fe7904950568933200 Content-Type: text/plain; charset="UTF-8" Dear IPPMers, I apologize for a slow AD Evaluation for this draft. In general, I found this document to be pretty clear, and I liked the multiple levels of detail as a service to readers and implementers. Thank you for that. I have a decent number of questions, but almost none of them are technical observations. I'd expect they'd be easy to consider, before I request IETF Last Call. Please let me know when you're ready to proceed with this draft. Thanks, Spencer In this text, To date, TWAMP implementations do not come with a standard management framework and, as such, configuration depends on proprietary mechanisms developed by the corresponding TWAMP vendor. is it correct to say that there is no standardized configuration mechanism for TWAMP, so that implementers have no choice except to provide proprietary mechanisms? In this text, From an operations perspective, dealing with several vendor-specific TWAMP configuration mechanisms is simply unsustainable in this context. I'm not sure this is true in all cases, because some people just keep doing things that cost money and don't make sense. But would it be correct to say this? From an operations perspective, using several vendor-specific TWAMP configuration mechanisms when one standardized mechanism could provide an alternative is expensive and inefficient. I'm confused by Note to RFC Editor: Please replace the date in the draft of the format 2018-02-13 with the date of publication of this draft. Also, replace reference to draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry with the RFC numbers assigned to the draft. for several reasons. Did you mean "date of publication of this draft", or "date of publication of this draft as an RFC? Either way, saying "in Section 5.2" is probably helpful for the RFC Editor. If there's only two, you could put this note in Section 5.2, which they'd likely appreciate. Did you mean to replace the draft name that appears in draft-ietf-ippm-twamp-yang@tools.ietf.org? You might consider using something like RFCXXX, and asking the RFC editor to replace RFCXXX with the eventual RFC number. I'd say the same thing about draft-ietf-ippm-metric-registry, except that ISTM that you could just use the existing reference to [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right Thing. I note that [I-D.ietf-ippm-metric-registry] is listed as an Informative reference. Could you understand this draft without reading [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I think it might be, the RFC Editor would automatically hold this document until [I-D.ietf-ippm-metric-registry] is published, and then make the usual substitutions. Is there a particular reference for UML that you could provide? I don't happen to have that on my bookshelf. Perhaps other readers would find it useful, too. I note at least one use of RFC 2119 language in lower case ("must"). I'd suggest either shifting any lower-case requirements language to upper case or using https://tools.ietf.org/html/rfc8174 for the definition of requirements language. RFC 2119 was a frequent topic among Gen-ART reviewers when I was part of the review team. I'm not questioning this text, If the user has no network access to the Control-Client device, then the only option is to retrieve all test-session instances from the Session-Reflector device. This could be problematic if a large number of test sessions are currently active on that device. but I am trying to understand what type of problems you're thinking of (delays in starting testing from the Control-Client device, because the Session-Reflector is heavily loaded? Interference with current test sessions? Or something else), and find myself guessing. When I read This section presents a simplified graphical representation of the TWAMP data model using a YANG tree diagram. Readers should keep in mind that the limit of 72 characters per line forces us to introduce artificial line breaks in some tree diagram nodes. I'm not sure how I would know which line breaks are artificial. Is this just about the breaks in the middle of a word on longer lines, so that the word appears to wrap around to the left side of the page, or something else? (As an aside, I haven't done AD evaluations for YANG data models previously, but this data model doesn't seem to be excessively nested or to use excessively long names. Perhaps there's a convention that would indicate continuation more clearly?) I found myself wondering if There are a number of nodes defined in this YANG module which are writeable. These data nodes may be considered sensitive and vulnerable to attacks in some network environments. Ability to write into these nodes without proper protection can have a negative effect on the devices that support this feature. was understated - when are writeable nodes not "sensitive and vulnerable to attacks" without "proper protection"? I see The YANG module defined in Section 5 is designed to be accessed, among other protocols, via NETCONF [RFC6241]. Protocols like NETCONF use a secure transport layer like SSH that is mandatory to implement. a bit further up the page, but would it make sense to prohibit the use of a protocol that doesn't have a mandatory-to-implement secure transport mechanism? This may be well-traveled ground in the YANG community, so the current text could be fine, but I wanted to ask before SECDIR reviewers are doing Last Call reviews ... --001a1143e4fe7904950568933200 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear IPPMers,

I apologize for a slo= w AD Evaluation for this draft.=C2=A0

<= /div>
In general, I found this document to be pre= tty clear, and I liked the multiple levels of detail as a service to reader= s and implementers. Thank you for that.
I have a decent number of questions, but = almost none of them are technical observations. I'd expect they'd b= e easy to consider, before I request IETF Last Call.

Please let me know when you&= #39;re ready to proceed with this draft.
Thanks,
=
Spencer

In this t= ext,

= =C2=A0 =C2=A0To date, TWAMP implementations do not
=C2=A0 =C2=A0come with a standard management framework and, as such= , configuration
=C2=A0 =C2=A0depends on pro= prietary mechanisms developed by the corresponding
=C2=A0 =C2=A0TWAMP vendor.=C2=A0
is it correct to say that there is no st= andardized configuration mechanism for TWAMP, so that implementers have no = choice except to provide proprietary mechanisms?

In this text,

=C2=A0 =C2=A0From an ope= rations
=C2=A0 =C2=A0perspective, dealing w= ith several vendor-specific TWAMP configuration
=C2=A0 =C2=A0mechanisms is simply unsustainable in this context.=C2=A0=

I'= ;m not sure this is true in all cases, because some people just keep doing = things that cost money and don't make sense. But would it be correct to= say this?

=C2=A0 =C2=A0From an operations
=C2=A0= =C2=A0perspective, using several vendor-specific TWAMP configuration
=
=C2=A0 =C2=A0mechanisms when one standardized me= chanism could provide an alternative
=C2=A0= =C2=A0is expensive and inefficient.=C2=A0
=
I'm confused by=C2=A0

=C2=A0 Note to RFC= Editor:

=C2=A0 =C2=A0Please replace the date in the draft of the format 2018-02-= 13 with
=C2=A0 =C2=A0the date of publicatio= n of this draft.=C2=A0 Also, replace reference to
=C2=A0 =C2=A0draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-= registry with
=C2=A0 =C2=A0the RFC numbers = assigned to the draft.

for several reasons.=C2=A0

Did you mean "date of publicatio= n of this draft", or "date of publication of this draft as an RFC= ? Either way, saying "in Section 5.2" is probably helpful for the= RFC Editor. If there's only two, you could put this note in Section 5.= 2, which they'd likely appreciate.

=
Did you mean to replace the draft name tha= t appears in=C2=A0 draft-ietf-ippm-twamp-yang@tools.ietf.org? You might consider usin= g=C2=A0
something like RFCXXX, and asking t= he RFC editor to replace RFCXXX with the eventual RFC number.

I'd say the= same thing about draft-ietf-ippm-metric-registry, except that ISTM that yo= u could just use the existing reference to [I-D.ietf-ippm-metric-registry],= and the RFC editor would Do The Right Thing.

I note that [I-D.ietf-ippm-metric-r= egistry] is listed as an Informative reference. Could you understand this d= raft without reading [I-D.ietf-ippm-metric-registry]? If that draft is as N= ormative as I think it might be, the RFC Editor would automatically hold th= is document until [I-D.ietf-ippm-metric-registry] is published, and then ma= ke the usual substitutions.=C2=A0

Is there a particular reference for UML that yo= u could provide? I don't happen to have that on my bookshelf. Perhaps o= ther readers would find it useful, too.
I note at least one use of RFC 2119 langu= age in lower case ("must"). I'd suggest either shifting any l= ower-case requirements language to upper case or using https://tools.ietf.org/html/rfc8174 for the= definition of requirements language. RFC 2119 was a frequent topic among G= en-ART reviewers when I was part of the review team.

I'm not questioning this= text,

=C2=A0 If the user has no network access to the Control-Client device, the= n
=C2=A0 =C2=A0the only option is to retrie= ve all test-session instances from the
=C2= =A0 =C2=A0Session-Reflector device.=C2=A0 This could be problematic if a la= rge
=C2=A0 =C2=A0number of test sessions ar= e currently active on that device.

but I am trying to understand what type of pro= blems you're thinking of (delays in starting testing from the Control-C= lient device, because the Session-Reflector is heavily loaded? Interference= with current test sessions? Or something else), and find myself guessing.<= /div>

When I= read=C2=A0

=C2=A0 =C2=A0This section presents a simplified graphical representat= ion of the
=C2=A0 =C2=A0TWAMP data model us= ing a YANG tree diagram.=C2=A0 Readers should keep in
=C2=A0 =C2=A0mind that the limit of 72 characters per line force= s us to introduce
=C2=A0 =C2=A0artificial l= ine breaks in some tree diagram nodes.

=
I'm not sure how I would know which li= ne breaks are artificial. Is this just about the breaks in the middle of a = word on longer lines, so that the word appears to wrap around to the left s= ide of the page, or something else?=C2=A0
<= br>
(As an aside, I haven't done AD eva= luations for YANG data models previously, but this data model doesn't s= eem to be excessively nested or to use excessively long names. Perhaps ther= e's a convention that would indicate continuation more clearly?)
<= div class=3D"gmail_extra">
I found myse= lf wondering if=C2=A0

=C2=A0 =C2=A0There are a number of nodes defined in this Y= ANG module which are
=C2=A0 =C2=A0writeable= .=C2=A0 These data nodes may be considered sensitive and
=C2=A0 =C2=A0vulnerable to attacks in some network environmen= ts.=C2=A0 Ability to write
=C2=A0 =C2=A0int= o these nodes without proper protection can have a negative effect
=C2=A0 =C2=A0on the devices that support this featu= re.

wa= s understated - when are writeable nodes not "sensitive and vulnerable= to attacks" without "proper protection"? I see=C2=A0
<= div class=3D"gmail_extra">
=C2=A0 The Y= ANG module defined in Section 5 is designed to be accessed,
=C2=A0 =C2=A0among other protocols, via NETCONF [RFC6241].= =C2=A0 Protocols like NETCONF
=C2=A0 =C2=A0= use a secure transport layer like SSH that is mandatory to implement.
=

a bit furth= er up the page, but would it make sense to prohibit the use of a protocol t= hat doesn't have a mandatory-to-implement secure transport mechanism? T= his may be well-traveled ground in the YANG community, so the current text = could be fine, but I wanted to ask before SECDIR reviewers are doing Last C= all reviews ...
--001a1143e4fe7904950568933200-- From nobody Thu Mar 29 14:24:59 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058C212DA07; Thu, 29 Mar 2018 14:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CZKatt0cYlA8; Thu, 29 Mar 2018 14:24:54 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 D08E812E8A2; Thu, 29 Mar 2018 14:24:51 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id v68so2401567ywg.13; Thu, 29 Mar 2018 14:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=3OaKp5RhA4xcFccSmjFhY0WsRMrNmIwgRGT8d01m6v4=; b=QZohxcjlJ4d+mlFsVC/wzxUhtcz9sqdWvEbb5zGGi3QVrvI80qzrmi+X4Bzmgwbmy+ Xmepp8lEvKjWB56s1e9++udv/6STebDdhh1HnMh7sU5luTC9Ev9PW0u58KrJuQ9UaTXJ raCfOOH92npMKd7poxpNfTN668jlMCNbrYPUYpVX85RYivojGtaBRPPAjfjwQYOlJXYL Sh+Iip5C/4bW7Yuke2FD2VZ820lxqyOyS2rONEVBT7ZzF3zoy3fNH+C1g/uQ6LJrhJEZ 911PsA0/jgXmdm9U4BESkKbzbSNUSMUExF8TsX0qsgLHjLMTiLLYRhcKTODvXOpvctDL lleg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=3OaKp5RhA4xcFccSmjFhY0WsRMrNmIwgRGT8d01m6v4=; b=gKWp0gPY7swLEsG8dZzRFfrQujVBX/V9WqsFCmIZVBoq2+HO4U3VXaMiXDTh+M+Ys7 UdK9bQX42vF4/d1J2O5inORVAebgPVndGEWjzs90vdjXt6wOr5tieH1Hy0srK38N/ieC Ww+BbWvWD2Yu9jsVBwj14zSB24ZIon3/ibPgD15vYy+gPIlx1latKILhSRDvhE+oxzOg lgdTyQhQRt/5nLF+nLaFPWg330v/mOmMHbQj5NtaBsiWBG+dMZVB9DjRkBe/oVKofOXf s+gc1QIqWgs0po4hQuI1dbsA5SgCJSHvrNr1h7fsaX9b05GoeWQS4LJI6cunG8LzaiCr 8gUw== X-Gm-Message-State: AElRT7GuGaH/jttSXxBqSSdmyZCevgzU9/+HQxpI1rZdREyQRHu0myqw Ye+VagcJ199O78tabAZ7HGV517+R/0OkY3473ts= X-Google-Smtp-Source: AIpwx492VLk5Ymoja1o67ITM8hRU9iLwrHqQSDV8jnr3NCNpEajoBMc0FxPkCKAN/gWRmYsYYNPsxt+iIRk4NeqwR9E= X-Received: by 10.129.79.199 with SMTP id d190mr2663343ywb.19.1522358690716; Thu, 29 Mar 2018 14:24:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:e757:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 14:24:50 -0700 (PDT) From: Spencer Dawkins at IETF Date: Thu, 29 Mar 2018 16:24:50 -0500 Message-ID: To: Brian Trammell Cc: Nevil Brownlee , ippm-chairs@ietf.org, ippm@ietf.org, draft-ietf-ippm-2330-ipv6@ietf.org Content-Type: multipart/alternative; boundary="001a114dd9a0fb2140056893c0a6" Archived-At: Subject: [ippm] AD Evaluation for draft-ietf-ippm-2330-ipv6-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2018 21:24:57 -0000 --001a114dd9a0fb2140056893c0a6 Content-Type: text/plain; charset="UTF-8" Dear IPPMers, On Sun, Mar 4, 2018 at 4:06 PM, Brian Trammell wrote: > Brian Trammell has requested publication of draft-ietf-ippm-2330-ipv6-03 > as Informational on behalf of the IPPM working group. > > Please verify the document's state at https://datatracker.ietf.org/ > doc/draft-ietf-ippm-2330-ipv6/ I've completed my AD Evaluation for this draft, and have a few questions. These should be easy to resolve before I request Last Call for the draft. Please let me know when you're ready to proceed. Thanks for this draft. Spencer I wasn't quite sure what to make of this text: We further require that if a packet is described as having a "length of B octets", then 0 <= B <= 65535; and if B is the payload length in octets, then B <= (65535-IP header size in octets, including any Extension Headers). The jumbograms defined in [RFC2675] are not covered by this length analysis. Is the point that jumbograms aren't valid standard-form packets? In this text, [RFC2330] defines the "minimal IP packet from A to B" as a particular type of standard-formed packet often useful to consider. When defining IP metrics no packet smaller or simpler than this can be transmitted over a correctly operating IP network. However, the concept of the minimal IP packet has not been used in the meantime and its practical use is limited. I wonder if "in the meantime" is clear enough. Perhaps "since [RFC2330] was published in 1998", or something like that? ("If it wasn't useful in the first 20 years, it probably won't be useful in the next 20 years" :-) I'm wondering if the upper-case "SHOULD" in If the information constituting Type-P at the Source is found to have changed at the Destination (or at a measurement point between the Source and Destination, as in [RFC5644]), then the modified values SHOULD be noted and reported with the results. is consistent with the lower-case "must" in The definition and execution of measurements within the context of the IPPM Framework is challenged whenever such translation mechanisms are present along the measurement path. In particular use cases like IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header compression may result in modification of the measurement packet's Type-P along the path. All these changes must be reported. ? I'm also wondering if I should suggest https://tools.ietf.org/html/rfc8174 as the reference for requirements language, or ask for a scrub to ensure that requirements language is consistent throughout the document. This text Points that are worthwhile discussing further: handling of large packets in IPv6 (including fragment extension headers, PMTUD, PLPMTUD), extent of coverage for 6LO and IPv6 Header Compression, and the continued need to define a "minimal standard-formed packet". didn't seem consistent with the previous mentions of "minimal standard-formed packet", which I read as deprecating this concept. Does this text say that concept might be coming back? I didn't understand When considering privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques which are within this scope of work. Was the point that people measuring traffic using active measurements know pretty well what they sent, so privacy isn't a concern for those packets, or is something else being talked about? --001a114dd9a0fb2140056893c0a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear IPPMers,

On Sun, Mar 4, 2018 at 4:06 PM, Brian Trammell <ietf@trammell.= ch> wrote:
Brian Trammell has requested publication of draft-ietf-ippm-2330-ipv6-03= as Informational on behalf of the IPPM working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/

I've completed my AD Evaluation for this dra= ft, and have a few questions. These should be easy to resolve before I requ= est Last Call for the draft.

Please let me know wh= en you're ready to proceed.

Thanks for this dr= aft.

Spencer=C2=A0

I= wasn't quite sure what to make of this text:

= =C2=A0 We further require that if a packet is described as having a "l= ength
=C2=A0 =C2=A0of B octets", then 0 <=3D B <=3D 65= 535; and if B is the payload length in
=C2=A0 =C2=A0octets, then = B <=3D (65535-IP header size in octets, including any
=C2=A0 = =C2=A0Extension Headers).=C2=A0 The jumbograms defined in [RFC2675] are not=
=C2=A0 =C2=A0covered by this length analysis.=C2=A0
Is the point that jumbograms aren't valid standard-form pa= ckets?

In this text,

=C2= =A0 [RFC2330] defines the "minimal IP packet from A to B" as a pa= rticular
=C2=A0 =C2=A0type of standard-formed packet often useful= to consider.=C2=A0 When
=C2=A0 =C2=A0defining IP metrics no pack= et smaller or simpler than this can be
=C2=A0 =C2=A0transmitted o= ver a correctly operating IP network.=C2=A0 However, the
=C2=A0 = =C2=A0concept of the minimal IP packet has not been used in the meantime
=C2=A0 =C2=A0and its practical use is limited.=C2=A0

=
I wonder if "in the meantime" is clear enough. Perhaps= "since [RFC2330] was published in 1998", or something like that?= ("If it wasn't useful in the first 20 years, it probably won'= t be useful in the next 20 years" :-)

I'm= wondering if the upper-case "SHOULD" in=C2=A0

=C2=A0 If the information constituting Type-P at the Source is found= to have
=C2=A0 =C2=A0changed at the Destination (or at a measure= ment point between the
=C2=A0 =C2=A0Source and Destination, as in= [RFC5644]), then the modified values
=C2=A0 =C2=A0SHOULD be note= d and reported with the results.

is consistent wit= h the lower-case "must" in=C2=A0

=C2=A0 = The definition and execution of measurements within the context of
=C2=A0 =C2=A0the IPPM Framework is challenged whenever such translation m= echanisms
=C2=A0 =C2=A0are present along the measurement path.=C2= =A0 In particular use cases like
=C2=A0 =C2=A0IPv4-IPv6 translati= on, NAT, protocol encapsulation, or IPv6 header
=C2=A0 =C2=A0comp= ression may result in modification of the measurement packet's
=C2=A0 =C2=A0Type-P along the path.=C2=A0 All these changes must be repor= ted.

? I'm also wondering if I should suggest = https://tools.ietf.org/html= /rfc8174 as the reference for requirements language, or ask for a scrub= to ensure that requirements language is consistent throughout the document= .

This text=C2=A0
=C2=A0 Points that are= worthwhile discussing further: handling of large
=C2=A0 =C2=A0pa= ckets in IPv6 (including fragment extension headers, PMTUD,
=C2= =A0 =C2=A0PLPMTUD), extent of coverage for 6LO and IPv6 Header Compression,= and
=C2=A0 =C2=A0the continued need to define a "minimal st= andard-formed packet".

didn't seem consis= tent with the previous mentions of "minimal standard-formed packet&quo= t;, which I read as deprecating this concept. Does this text say that conce= pt might be coming back?

I didn't understand= =C2=A0

=C2=A0 When considering privacy of those in= volved in measurement or those
=C2=A0 =C2=A0whose traffic is meas= ured, the sensitive information available to
=C2=A0 =C2=A0potenti= al observers is greatly reduced when using active techniques
=C2= =A0 =C2=A0which are within this scope of work.=C2=A0

Was the point that people measuring traffic using active measurements kn= ow pretty well what they sent, so privacy isn't a concern for those pac= kets, or is something else being talked about?
--001a114dd9a0fb2140056893c0a6-- From nobody Thu Mar 29 21:43:55 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B48A126BF7; Thu, 29 Mar 2018 21:43:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Bnh9ssJHWHRw; Thu, 29 Mar 2018 21:43:51 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 A9099120726; Thu, 29 Mar 2018 21:43:51 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id a2so2090509pff.8; Thu, 29 Mar 2018 21:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=baTBB8B7YdqHvjeeDpyNsiye0qAU40Cp76hDPd2e/cc=; b=gDsYTDXWCIVKTJ6+vLNp660uY2AYczzcl+q7zjR3RlJNeBee6MQcGMxlWmcODYqCqH FpeN+GcIi4NJhZe5OX86EAUUtrSJiLsm2HU7cg1hS150D+wYIupxuot+cJEWKwzqq+bH 85EWXETuYPW/RUTCqXOb40M/UxQu27H7dyEBeuEjLdxlsob9m1ARKBfUomEOpd7ot3XE 2bezQRpwa11+8JTxnaxzwyH8DHd14QvWB1XspE2ayNUN0bjCYd3rqIVM75EX/F1kBflN MMyiZjOienEBMW4d+H3f+3Tw9VewmKYnZQhvGjRvFD/9JVc75FpJCMUPBbEHINNJj81t 1eaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=baTBB8B7YdqHvjeeDpyNsiye0qAU40Cp76hDPd2e/cc=; b=Sq5xW6tlX6HUcqJMVOkCged/EVh/zrMofL5Djnfa7EAIE0V7KwtGZ0Xa485Em83Bhf Ys9UL3qaUs6JWN7PttneJPhp4NQJNkH99vriN2JWSHjEPZD7eoj2qc8gSxfo/trsUpwd 5MFXGXgQNsfcphiN3NpCUVYsQOzoOxpkuK9WEdSZcMQMfepdkiQSW4vpXdJNXiQ/UW1A 9WA0Iqr4pdyGDyW01arxICr5Jl9i4hTOIhapb7i7K9QdER5NJXW4FigeCudWBZtEm/77 jVcQ1lGZzuN6BnFEHGi85y/ovfl9UReOzFGqoayxtuuoKKXvrpJA0E+qpShErOWY47sS 7nag== X-Gm-Message-State: AElRT7F+5cgZRrSt0EPaW3I+c1AjgmQVhZtocs1nAhPHULjR9MQ7lcar UU4lS8l+oaCjy6OMRZDWBHvcjCKz X-Google-Smtp-Source: AIpwx4+Bj3anW/tRYDRJNCc+W3vJERwj9rmLBSzX9+JPAUM39Jqx3yxnhTBwCZ3MUlc56KLQ8C90Dw== X-Received: by 10.98.36.76 with SMTP id r73mr6729581pfj.108.1522385030698; Thu, 29 Mar 2018 21:43:50 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:7857:92b6:68a6:33d7? ([2601:647:4700:1280:7857:92b6:68a6:33d7]) by smtp.gmail.com with ESMTPSA id b5sm15913281pfc.87.2018.03.29.21.43.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 21:43:50 -0700 (PDT) To: Spencer Dawkins at IETF , Brian Trammell Cc: Nalini Elkins , ippm-chairs@ietf.org, ippm@ietf.org, draft-ietf-ippm-twamp-yang@ietf.org References: From: Mahesh Jethanandani Message-ID: Date: Thu, 29 Mar 2018 21:45:01 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0973A4EF4DA49695051C369A" Content-Language: en-US Archived-At: Subject: Re: [ippm] AD Evaluation of draft-ietf-ippm-twamp-yang-06 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2018 04:43:54 -0000 This is a multi-part message in MIME format. --------------0973A4EF4DA49695051C369A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Spencer, Let me take a crack at responding to some of the questions you raised. On 3/29/18 1:44 PM, Spencer Dawkins at IETF wrote: > Dear IPPMers, > > I apologize for a slow AD Evaluation for this draft. > > In general, I found this document to be pretty clear, and I liked the > multiple levels of detail as a service to readers and implementers. > Thank you for that. > > I have a decent number of questions, but almost none of them are > technical observations. I'd expect they'd be easy to consider, before > I request IETF Last Call. > > Please let me know when you're ready to proceed with this draft. > > Thanks, > > Spencer > > In this text, > >    To date, TWAMP implementations do not >    come with a standard management framework and, as such, configuration >    depends on proprietary mechanisms developed by the corresponding >    TWAMP vendor. > > is it correct to say that there is no standardized configuration > mechanism for TWAMP, so that implementers have no choice except to > provide proprietary mechanisms? Since we are talking both configuration and monitoring, I would rather say: To date, TWAMP implementations do not come with a standard management framework, and, as such, management depends on proprietary mechanism developed by the corresponding TWAMP vendor. > > In this text, > >    From an operations >    perspective, dealing with several vendor-specific TWAMP configuration >    mechanisms is simply unsustainable in this context. > > I'm not sure this is true in all cases, because some people just keep > doing things that cost money and don't make sense. But would it be > correct to say this? > >    From an operations >    perspective, using several vendor-specific TWAMP configuration >    mechanisms when one standardized mechanism could provide an alternative >    is expensive and inefficient. Fair enough. > > I'm confused by > >   Note to RFC Editor: > >    Please replace the date in the draft of the format 2018-02-13 with >    the date of publication of this draft.  Also, replace reference to >    draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry with >    the RFC numbers assigned to the draft. > > for several reasons. > > Did you mean "date of publication of this draft", or "date of > publication of this draft as an RFC? Yes. > Either way, saying "in Section 5.2" is probably helpful for the RFC > Editor. If there's only two, you could put this note in Section 5.2, > which they'd likely appreciate. We can do that. > > Did you mean to replace the draft name that appears in > draft-ietf-ippm-twamp-yang@tools.ietf.org > ? You might consider > using > something like RFCXXX, and asking the RFC editor to replace RFCXXX > with the eventual RFC number. Ok. > > I'd say the same thing about draft-ietf-ippm-metric-registry, except > that ISTM that you could just use the existing reference to > [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right > Thing. > > I note that [I-D.ietf-ippm-metric-registry] is listed as an > Informative reference. Could you understand this draft without reading > [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I > think it might be, the RFC Editor would automatically hold this > document until [I-D.ietf-ippm-metric-registry] is published, and then > make the usual substitutions. > > Is there a particular reference for UML that you could provide? I > don't happen to have that on my bookshelf. Perhaps other readers would > find it useful, too. We can add that. > > I note at least one use of RFC 2119 language in lower case ("must"). > I'd suggest either shifting any lower-case requirements language to > upper case or using https://tools.ietf.org/html/rfc8174 for the > definition of requirements language. RFC 2119 was a frequent topic > among Gen-ART reviewers when I was part of the review team. There are two lower case "must". These "must" are the normal English language use of must rather than the RFC 2119 version of must. We will therefore update section 1.2 with: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described inBCP 14 [RFC2119 ] [RFC8174 ] when, and only when, they appear in all capitals, as shown here. > > I'm not questioning this text, > >   If the user has no network access to the Control-Client device, then >    the only option is to retrieve all test-session instances from the >    Session-Reflector device.  This could be problematic if a large >    number of test sessions are currently active on that device. > > but I am trying to understand what type of problems you're thinking of > (delays in starting testing from the Control-Client device, because > the Session-Reflector is heavily loaded? Interference with current > test sessions? Or something else), and find myself guessing. Good question. I am going to see if one of my co-authors could answer this question better than me. > > When I read > >    This section presents a simplified graphical representation of the >    TWAMP data model using a YANG tree diagram.  Readers should keep in >    mind that the limit of 72 characters per line forces us to introduce >    artificial line breaks in some tree diagram nodes. > > I'm not sure how I would know which line breaks are artificial. Is > this just about the breaks in the middle of a word on longer lines, so > that the word appears to wrap around to the left side of the page, or > something else? It is the latter. Would it help if we actually put a "\" character at the end of the line to indicate a line break? > > (As an aside, I haven't done AD evaluations for YANG data models > previously, but this data model doesn't seem to be excessively nested > or to use excessively long names. Perhaps there's a convention that > would indicate continuation more clearly?) There isn't a conventions currently. But I have used the "\" character in some of the other models that I have authored. > > I found myself wondering if > >    There are a number of nodes defined in this YANG module which are >    writeable.  These data nodes may be considered sensitive and >    vulnerable to attacks in some network environments.  Ability to write >    into these nodes without proper protection can have a negative effect >    on the devices that support this feature. > > was understated - when are writeable nodes not "sensitive and > vulnerable to attacks" without "proper protection"? I see > >   The YANG module defined in Section 5 is designed to be accessed, >    among other protocols, via NETCONF [RFC6241].  Protocols like NETCONF >    use a secure transport layer like SSH that is mandatory to implement. > > a bit further up the page, but would it make sense to prohibit the use > of a protocol that doesn't have a mandatory-to-implement secure > transport mechanism? This may be well-traveled ground in the YANG > community, so the current text could be fine, but I wanted to ask > before SECDIR reviewers are doing Last Call reviews ... We (as in YANG doctors), have gone several rounds with SECDIR on the language that all YANG modules are supposed to carry as part of Security Considerations, and this was the language we seem to have agreed upon and documented in rfc6087bis. That is not to say that they might not still call it into question. Cheers. Mahesh Jethanandani mjethanandani@gmail.com --------------0973A4EF4DA49695051C369A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Spencer,

Let me take a crack at responding to some of the questions you raised.


On 3/29/18 1:44 PM, Spencer Dawkins at IETF wrote:
Dear IPPMers,

I apologize for a slow AD Evaluation for this draft. 

In general, I found this document to be pretty clear, and I liked the multiple levels of detail as a service to readers and implementers. Thank you for that.

I have a decent number of questions, but almost none of them are technical observations. I'd expect they'd be easy to consider, before I request IETF Last Call.

Please let me know when you're ready to proceed with this draft.

Thanks,

Spencer

In this text,

   To date, TWAMP implementations do not
   come with a standard management framework and, as such, configuration
   depends on proprietary mechanisms developed by the corresponding
   TWAMP vendor. 

is it correct to say that there is no standardized configuration mechanism for TWAMP, so that implementers have no choice except to provide proprietary mechanisms?
Since we are talking both configuration and monitoring, I would rather say:

To date, TWAMP implementations do not come with a standard management framework, and, as such, management depends on proprietary mechanism developed by the corresponding TWAMP vendor.

In this text,

   From an operations
   perspective, dealing with several vendor-specific TWAMP configuration
   mechanisms is simply unsustainable in this context. 

I'm not sure this is true in all cases, because some people just keep doing things that cost money and don't make sense. But would it be correct to say this?

   From an operations
   perspective, using several vendor-specific TWAMP configuration
   mechanisms when one standardized mechanism could provide an alternative
   is expensive and inefficient.
Fair enough.

I'm confused by 

  Note to RFC Editor:

   Please replace the date in the draft of the format 2018-02-13 with
   the date of publication of this draft.  Also, replace reference to
   draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry with
   the RFC numbers assigned to the draft.

for several reasons. 

Did you mean "date of publication of this draft", or "date of publication of this draft as an RFC?
Yes.
Either way, saying "in Section 5.2" is probably helpful for the RFC Editor. If there's only two, you could put this note in Section 5.2, which they'd likely appreciate.
We can do that.

Did you mean to replace the draft name that appears in  draft-ietf-ippm-twamp-yang@tools.ietf.org? You might consider using 
something like RFCXXX, and asking the RFC editor to replace RFCXXX with the eventual RFC number.
Ok.

I'd say the same thing about draft-ietf-ippm-metric-registry, except that ISTM that you could just use the existing reference to [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right Thing.

I note that [I-D.ietf-ippm-metric-registry] is listed as an Informative reference. Could you understand this draft without reading [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I think it might be, the RFC Editor would automatically hold this document until [I-D.ietf-ippm-metric-registry] is published, and then make the usual substitutions. 

Is there a particular reference for UML that you could provide? I don't happen to have that on my bookshelf. Perhaps other readers would find it useful, too.
We can add that.

I note at least one use of RFC 2119 language in lower case ("must"). I'd suggest either shifting any lower-case requirements language to upper case or using https://tools.ietf.org/html/rfc8174 for the definition of requirements language. RFC 2119 was a frequent topic among Gen-ART reviewers when I was part of the review team.
There are two lower case "must". These "must" are the normal English language use of must rather than the RFC 2119 version of must. We will therefore update section 1.2 with:


      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

I'm not questioning this text,

  If the user has no network access to the Control-Client device, then
   the only option is to retrieve all test-session instances from the
   Session-Reflector device.  This could be problematic if a large
   number of test sessions are currently active on that device.

but I am trying to understand what type of problems you're thinking of (delays in starting testing from the Control-Client device, because the Session-Reflector is heavily loaded? Interference with current test sessions? Or something else), and find myself guessing.
Good question. I am going to see if one of my co-authors could answer this question better than me.

When I read 

   This section presents a simplified graphical representation of the
   TWAMP data model using a YANG tree diagram.  Readers should keep in
   mind that the limit of 72 characters per line forces us to introduce
   artificial line breaks in some tree diagram nodes.

I'm not sure how I would know which line breaks are artificial. Is this just about the breaks in the middle of a word on longer lines, so that the word appears to wrap around to the left side of the page, or something else?
It is the latter. Would it help if we actually put a "\" character at the end of the line to indicate a line break?

(As an aside, I haven't done AD evaluations for YANG data models previously, but this data model doesn't seem to be excessively nested or to use excessively long names. Perhaps there's a convention that would indicate continuation more clearly?)
There isn't a conventions currently. But I have used the "\" character in some of the other models that I have authored.

I found myself wondering if 

   There are a number of nodes defined in this YANG module which are
   writeable.  These data nodes may be considered sensitive and
   vulnerable to attacks in some network environments.  Ability to write
   into these nodes without proper protection can have a negative effect
   on the devices that support this feature.

was understated - when are writeable nodes not "sensitive and vulnerable to attacks" without "proper protection"? I see 

  The YANG module defined in Section 5 is designed to be accessed,
   among other protocols, via NETCONF [RFC6241].  Protocols like NETCONF
   use a secure transport layer like SSH that is mandatory to implement.

a bit further up the page, but would it make sense to prohibit the use of a protocol that doesn't have a mandatory-to-implement secure transport mechanism? This may be well-traveled ground in the YANG community, so the current text could be fine, but I wanted to ask before SECDIR reviewers are doing Last Call reviews ...
We (as in YANG doctors), have gone several rounds with SECDIR on the language that all YANG modules are supposed to carry as part of Security Considerations, and this was the language we seem to have agreed upon and documented in rfc6087bis. That is not to say that they might not still call it into question.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com

--------------0973A4EF4DA49695051C369A-- From nobody Fri Mar 30 06:00:58 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D988912D7F1; Fri, 30 Mar 2018 06:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bvn9vnI05hek; Fri, 30 Mar 2018 06:00:54 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 79F2F126C26; Fri, 30 Mar 2018 06:00:54 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id e123-v6so7729402oih.13; Fri, 30 Mar 2018 06:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=0h0t4KjLCt2iL2R9e/QLTKAaANSNh2TwOphodSVlew8=; b=A/Y7U9u6Noiunk+q7lS7Ed/2HtW1sgYqWpJq16ZK/LKhgeMnbWmDRG5u7SJVfbZB4k qV3M073qgrIYUUf9ZHi0smTFwHHsC2wOqBR1c3IewmUERJrpiW0ld2MW6RYqXe4iu7So 2Nzd0ToXDgMNHX0+TOIUwmaUAzm0ssm+OvMPW+w1PIOENfA1yFhS3ZnVh7LjYPgjCGP0 9BMcEnBLC/Jz28X/mxEZ6hA/EtvTthvKbqdXlTiPmEUk6WO4AC0TeJfehPqS9EIOhZ4R NEs+olyXr+PX21yPnXPinqdlqlHPl5x3+TJfGbBVzpF0YvkLNOtbp/JXaFKsqy8CHYjw RyQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=0h0t4KjLCt2iL2R9e/QLTKAaANSNh2TwOphodSVlew8=; b=rVL6xdttFN8ymtc0N/4rpFLdJeVq6Z146+rauYXUM/pupUkKJPlok6sdci//7WQ2JK H+/+GF1cE/INfEDLZuOlmuosd61SIIVIy/9d6+/OjzhJ6gHKop70e23xmYd/VTW8xc6y HFO1f97oLt5mtVJSxrMcRBBOStumnBt//tw3Gx8pINySZkvz2ZBNfS8ldL+nL+rk/SSM PYpdM/+hJN5jJcCASBP9oCfRPxD8pqdJ9IUilJYhrhrWz8jPaoGdJbQ1w/2ac3Gqkm4b MOS79EA5B0WwOZnW9V0MkF6svf/K1bGVwn7MZOHjytvRNufFp5VKnt81POwq4SQIF4Ec n75g== X-Gm-Message-State: AElRT7HGAM5Da7HMcwIUzOVlkDazI3aVHaWkYAFe7N+FdP/QCi/j4hJc pApYbczyMTWrLI4Ep51H5lscA4Gf X-Google-Smtp-Source: AIpwx4+OFWlFg5M90YEGFJuRIXbzMyrG+MMP3Nmb5gUuUr4z5Hbh9PbCKTLvtl42J9kXVAimWI1OMw== X-Received: by 10.202.243.84 with SMTP id r81mr7080719oih.281.1522414852897; Fri, 30 Mar 2018 06:00:52 -0700 (PDT) Received: from [192.168.1.6] (cpe-66-25-210-163.tx.res.rr.com. [66.25.210.163]) by smtp.gmail.com with ESMTPSA id w3-v6sm2882937ote.18.2018.03.30.06.00.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Mar 2018 06:00:52 -0700 (PDT) To: Mahesh Jethanandani , Brian Trammell Cc: Nalini Elkins , ippm-chairs@ietf.org, ippm@ietf.org, draft-ietf-ippm-twamp-yang@ietf.org References: From: Spencer Dawkins Message-ID: Date: Fri, 30 Mar 2018 08:00:49 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A8720F253A3AE5BE00F6D712" Content-Language: en-US Archived-At: Subject: Re: [ippm] AD Evaluation of draft-ietf-ippm-twamp-yang-06 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2018 13:00:57 -0000 This is a multi-part message in MIME format. --------------A8720F253A3AE5BE00F6D712 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Manesh, I had one point below, but all your other responses will be fine. Spencer On 3/29/2018 11:45 PM, Mahesh Jethanandani wrote: > > Spencer, > > Let me take a crack at responding to some of the questions you raised. > > > On 3/29/18 1:44 PM, Spencer Dawkins at IETF wrote: >> Dear IPPMers, >> >> I apologize for a slow AD Evaluation for this draft. >> >> In general, I found this document to be pretty clear, and I liked the >> multiple levels of detail as a service to readers and implementers. >> Thank you for that. >> >> I have a decent number of questions, but almost none of them are >> technical observations. I'd expect they'd be easy to consider, before >> I request IETF Last Call. >> >> Please let me know when you're ready to proceed with this draft. >> >> Thanks, >> >> Spencer >> >> In this text, >> >>    To date, TWAMP implementations do not >>    come with a standard management framework and, as such, configuration >>    depends on proprietary mechanisms developed by the corresponding >>    TWAMP vendor. >> >> is it correct to say that there is no standardized configuration >> mechanism for TWAMP, so that implementers have no choice except to >> provide proprietary mechanisms? > Since we are talking both configuration and monitoring, I would rather > say: > > To date, TWAMP implementations do not come with a standard management > framework, and, as such, management depends on proprietary mechanism > developed by the corresponding TWAMP vendor. If this data model is replacing an existing standardized management framework, I misunderstood. But if it's not replacing an existing standardized management framework, my point was that - there is no existing standardized management framework, so - if an implementer wants to ship a management framework, it will not be a standardized framework ;-) Do the right thing, of course ;-) Spencer >> >> In this text, >> >>    From an operations >>    perspective, dealing with several vendor-specific TWAMP configuration >>    mechanisms is simply unsustainable in this context. >> >> I'm not sure this is true in all cases, because some people just keep >> doing things that cost money and don't make sense. But would it be >> correct to say this? >> >>    From an operations >>    perspective, using several vendor-specific TWAMP configuration >>    mechanisms when one standardized mechanism could provide an >> alternative >>    is expensive and inefficient. > Fair enough. >> >> I'm confused by >> >>   Note to RFC Editor: >> >>    Please replace the date in the draft of the format 2018-02-13 with >>    the date of publication of this draft.  Also, replace reference to >>    draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry with >>    the RFC numbers assigned to the draft. >> >> for several reasons. >> >> Did you mean "date of publication of this draft", or "date of >> publication of this draft as an RFC? > Yes. >> Either way, saying "in Section 5.2" is probably helpful for the RFC >> Editor. If there's only two, you could put this note in Section 5.2, >> which they'd likely appreciate. > We can do that. >> >> Did you mean to replace the draft name that appears in >> draft-ietf-ippm-twamp-yang@tools.ietf.org >> ? You might >> consider using >> something like RFCXXX, and asking the RFC editor to replace RFCXXX >> with the eventual RFC number. > Ok. >> >> I'd say the same thing about draft-ietf-ippm-metric-registry, except >> that ISTM that you could just use the existing reference to >> [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The >> Right Thing. >> >> I note that [I-D.ietf-ippm-metric-registry] is listed as an >> Informative reference. Could you understand this draft without >> reading [I-D.ietf-ippm-metric-registry]? If that draft is as >> Normative as I think it might be, the RFC Editor would automatically >> hold this document until [I-D.ietf-ippm-metric-registry] is >> published, and then make the usual substitutions. >> >> Is there a particular reference for UML that you could provide? I >> don't happen to have that on my bookshelf. Perhaps other readers >> would find it useful, too. > We can add that. >> >> I note at least one use of RFC 2119 language in lower case ("must"). >> I'd suggest either shifting any lower-case requirements language to >> upper case or using https://tools.ietf.org/html/rfc8174 for the >> definition of requirements language. RFC 2119 was a frequent topic >> among Gen-ART reviewers when I was part of the review team. > There are two lower case "must". These "must" are the normal English > language use of must rather than the RFC 2119 version of must. We will > therefore update section 1.2 with: > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > "MAY", and "OPTIONAL" in this document are to be interpreted as > described inBCP 14 [RFC2119 ] [RFC8174 ] when, and only when, they > appear in all capitals, as shown here. >> >> I'm not questioning this text, >> >>   If the user has no network access to the Control-Client device, then >>    the only option is to retrieve all test-session instances from the >>    Session-Reflector device.  This could be problematic if a large >>    number of test sessions are currently active on that device. >> >> but I am trying to understand what type of problems you're thinking >> of (delays in starting testing from the Control-Client device, >> because the Session-Reflector is heavily loaded? Interference with >> current test sessions? Or something else), and find myself guessing. > Good question. I am going to see if one of my co-authors could answer > this question better than me. >> >> When I read >> >>    This section presents a simplified graphical representation of the >>    TWAMP data model using a YANG tree diagram.  Readers should keep in >>    mind that the limit of 72 characters per line forces us to introduce >>    artificial line breaks in some tree diagram nodes. >> >> I'm not sure how I would know which line breaks are artificial. Is >> this just about the breaks in the middle of a word on longer lines, >> so that the word appears to wrap around to the left side of the page, >> or something else? > It is the latter. Would it help if we actually put a "\" character at > the end of the line to indicate a line break? >> >> (As an aside, I haven't done AD evaluations for YANG data models >> previously, but this data model doesn't seem to be excessively nested >> or to use excessively long names. Perhaps there's a convention that >> would indicate continuation more clearly?) > There isn't a conventions currently. But I have used the "\" character > in some of the other models that I have authored. >> >> I found myself wondering if >> >>    There are a number of nodes defined in this YANG module which are >>    writeable.  These data nodes may be considered sensitive and >>    vulnerable to attacks in some network environments.  Ability to write >>    into these nodes without proper protection can have a negative effect >>    on the devices that support this feature. >> >> was understated - when are writeable nodes not "sensitive and >> vulnerable to attacks" without "proper protection"? I see >> >>   The YANG module defined in Section 5 is designed to be accessed, >>    among other protocols, via NETCONF [RFC6241].  Protocols like NETCONF >>    use a secure transport layer like SSH that is mandatory to implement. >> >> a bit further up the page, but would it make sense to prohibit the >> use of a protocol that doesn't have a mandatory-to-implement secure >> transport mechanism? This may be well-traveled ground in the YANG >> community, so the current text could be fine, but I wanted to ask >> before SECDIR reviewers are doing Last Call reviews ... > We (as in YANG doctors), have gone several rounds with SECDIR on the > language that all YANG modules are supposed to carry as part of > Security Considerations, and this was the language we seem to have > agreed upon and documented in rfc6087bis. That is not to say that they > might not still call it into question. > > Cheers. > > Mahesh Jethanandani > mjethanandani@gmail.com > --------------A8720F253A3AE5BE00F6D712 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Manesh,

I had one point below, but all your other responses will be fine.

Spencer

On 3/29/2018 11:45 PM, Mahesh Jethanandani wrote:

Spencer,

Let me take a crack at responding to some of the questions you raised.


On 3/29/18 1:44 PM, Spencer Dawkins at IETF wrote:
Dear IPPMers,

I apologize for a slow AD Evaluation for this draft. 

In general, I found this document to be pretty clear, and I liked the multiple levels of detail as a service to readers and implementers. Thank you for that.

I have a decent number of questions, but almost none of them are technical observations. I'd expect they'd be easy to consider, before I request IETF Last Call.

Please let me know when you're ready to proceed with this draft.

Thanks,

Spencer

In this text,

   To date, TWAMP implementations do not
   come with a standard management framework and, as such, configuration
   depends on proprietary mechanisms developed by the corresponding
   TWAMP vendor. 

is it correct to say that there is no standardized configuration mechanism for TWAMP, so that implementers have no choice except to provide proprietary mechanisms?
Since we are talking both configuration and monitoring, I would rather say:

To date, TWAMP implementations do not come with a standard management framework, and, as such, management depends on proprietary mechanism developed by the corresponding TWAMP vendor.
If this data model is replacing an existing standardized management framework, I misunderstood. But if it's not replacing an existing standardized management framework, my point was that

- there is no existing standardized management framework, so
- if an implementer wants to ship a management framework, it will not be a standardized framework

;-)

Do the right thing, of course ;-)

Spencer

In this text,

   From an operations
   perspective, dealing with several vendor-specific TWAMP configuration
   mechanisms is simply unsustainable in this context. 

I'm not sure this is true in all cases, because some people just keep doing things that cost money and don't make sense. But would it be correct to say this?

   From an operations
   perspective, using several vendor-specific TWAMP configuration
   mechanisms when one standardized mechanism could provide an alternative
   is expensive and inefficient.
Fair enough.

I'm confused by 

  Note to RFC Editor:

   Please replace the date in the draft of the format 2018-02-13 with
   the date of publication of this draft.  Also, replace reference to
   draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry with
   the RFC numbers assigned to the draft.

for several reasons. 

Did you mean "date of publication of this draft", or "date of publication of this draft as an RFC?
Yes.
Either way, saying "in Section 5.2" is probably helpful for the RFC Editor. If there's only two, you could put this note in Section 5.2, which they'd likely appreciate.
We can do that.

Did you mean to replace the draft name that appears in  draft-ietf-ippm-twamp-yang@tools.ietf.org? You might consider using 
something like RFCXXX, and asking the RFC editor to replace RFCXXX with the eventual RFC number.
Ok.

I'd say the same thing about draft-ietf-ippm-metric-registry, except that ISTM that you could just use the existing reference to [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right Thing.

I note that [I-D.ietf-ippm-metric-registry] is listed as an Informative reference. Could you understand this draft without reading [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I think it might be, the RFC Editor would automatically hold this document until [I-D.ietf-ippm-metric-registry] is published, and then make the usual substitutions. 

Is there a particular reference for UML that you could provide? I don't happen to have that on my bookshelf. Perhaps other readers would find it useful, too.
We can add that.

I note at least one use of RFC 2119 language in lower case ("must"). I'd suggest either shifting any lower-case requirements language to upper case or using https://tools.ietf.org/html/rfc8174 for the definition of requirements language. RFC 2119 was a frequent topic among Gen-ART reviewers when I was part of the review team.
There are two lower case "must". These "must" are the normal English language use of must rather than the RFC 2119 version of must. We will therefore update section 1.2 with:


      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

I'm not questioning this text,

  If the user has no network access to the Control-Client device, then
   the only option is to retrieve all test-session instances from the
   Session-Reflector device.  This could be problematic if a large
   number of test sessions are currently active on that device.

but I am trying to understand what type of problems you're thinking of (delays in starting testing from the Control-Client device, because the Session-Reflector is heavily loaded? Interference with current test sessions? Or something else), and find myself guessing.
Good question. I am going to see if one of my co-authors could answer this question better than me.

When I read 

   This section presents a simplified graphical representation of the
   TWAMP data model using a YANG tree diagram.  Readers should keep in
   mind that the limit of 72 characters per line forces us to introduce
   artificial line breaks in some tree diagram nodes.

I'm not sure how I would know which line breaks are artificial. Is this just about the breaks in the middle of a word on longer lines, so that the word appears to wrap around to the left side of the page, or something else?
It is the latter. Would it help if we actually put a "\" character at the end of the line to indicate a line break?

(As an aside, I haven't done AD evaluations for YANG data models previously, but this data model doesn't seem to be excessively nested or to use excessively long names. Perhaps there's a convention that would indicate continuation more clearly?)
There isn't a conventions currently. But I have used the "\" character in some of the other models that I have authored.

I found myself wondering if 

   There are a number of nodes defined in this YANG module which are
   writeable.  These data nodes may be considered sensitive and
   vulnerable to attacks in some network environments.  Ability to write
   into these nodes without proper protection can have a negative effect
   on the devices that support this feature.

was understated - when are writeable nodes not "sensitive and vulnerable to attacks" without "proper protection"? I see 

  The YANG module defined in Section 5 is designed to be accessed,
   among other protocols, via NETCONF [RFC6241].  Protocols like NETCONF
   use a secure transport layer like SSH that is mandatory to implement.

a bit further up the page, but would it make sense to prohibit the use of a protocol that doesn't have a mandatory-to-implement secure transport mechanism? This may be well-traveled ground in the YANG community, so the current text could be fine, but I wanted to ask before SECDIR reviewers are doing Last Call reviews ...
We (as in YANG doctors), have gone several rounds with SECDIR on the language that all YANG modules are supposed to carry as part of Security Considerations, and this was the language we seem to have agreed upon and documented in rfc6087bis. That is not to say that they might not still call it into question.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com


--------------A8720F253A3AE5BE00F6D712-- From nobody Fri Mar 30 09:12:03 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5C01201FA; Fri, 30 Mar 2018 09:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2VFg9RifiF18; Fri, 30 Mar 2018 09:11:59 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B2943126BF0; Fri, 30 Mar 2018 09:11:59 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w2UG764b019417; Fri, 30 Mar 2018 12:11:52 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by mx0a-00191d01.pphosted.com with ESMTP id 2h1qr591xc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Mar 2018 12:11:51 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id w2UGBnw0031150; Fri, 30 Mar 2018 11:11:50 -0500 Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id w2UGBfaV030910; Fri, 30 Mar 2018 11:11:42 -0500 Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id 827DF4000485; Fri, 30 Mar 2018 16:11:41 +0000 (GMT) Received: from tlpd252.dadc.sbc.com (unknown [135.31.184.157]) by zlp30494.vci.att.com (Service) with ESMTP id 551AB4000482; Fri, 30 Mar 2018 16:11:41 +0000 (GMT) Received: from dadc.sbc.com (localhost [127.0.0.1]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id w2UGBfpP119454; Fri, 30 Mar 2018 11:11:41 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id w2UGBWt5119206; Fri, 30 Mar 2018 11:11:32 -0500 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id 9599BF0901; Fri, 30 Mar 2018 12:11:31 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::78d3:43d5:1186:18f5%15]) with mapi id 14.03.0389.001; Fri, 30 Mar 2018 12:11:30 -0400 From: "MORTON, ALFRED C (AL)" To: Spencer Dawkins at IETF , Brian Trammell CC: Nevil Brownlee , "ippm-chairs@ietf.org" , "ippm@ietf.org" , "draft-ietf-ippm-2330-ipv6@ietf.org" Thread-Topic: AD Evaluation for draft-ietf-ippm-2330-ipv6-03 Thread-Index: AQHTx6RrfbPdaFH1TE66yAUqLNkcm6Po6dmA Date: Fri, 30 Mar 2018 16:11:29 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF4A8E0A39@njmtexg5.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [65.123.255.137] Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF4A8E0A39njmtexg5researc_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803300168 Archived-At: Subject: Re: [ippm] AD Evaluation for draft-ietf-ippm-2330-ipv6-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2018 16:12:02 -0000 --_000_4D7F4AD313D3FC43A053B309F97543CF4A8E0A39njmtexg5researc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3BlbmNlciwgcGxlYXNlIHNlZSByZXBsaWVzIGluLWxpbmUuDQpUaGFua3MgZm9yIHlvdXIg cmV2aWV3IQ0KQWwNCg0KRnJvbTogU3BlbmNlciBEYXdraW5zIGF0IElFVEYgW21haWx0bzpzcGVu Y2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyOSwgMjAx OCA1OjI1IFBNDQpUbzogQnJpYW4gVHJhbW1lbGwgPGlldGZAdHJhbW1lbGwuY2g+DQpDYzogTmV2 aWwgQnJvd25sZWUgPG4uYnJvd25sZWVAYXVja2xhbmQuYWMubno+OyBpcHBtLWNoYWlyc0BpZXRm Lm9yZzsgaXBwbUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pcHBtLTIzMzAtaXB2NkBpZXRmLm9yZw0K U3ViamVjdDogQUQgRXZhbHVhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pcHBtLTIzMzAtaXB2Ni0wMw0K DQpEZWFyIElQUE1lcnMsDQoNCk9uIFN1biwgTWFyIDQsIDIwMTggYXQgNDowNiBQTSwgQnJpYW4g VHJhbW1lbGwgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PiB3cm90 ZToNCkJyaWFuIFRyYW1tZWxsIGhhcyByZXF1ZXN0ZWQgcHVibGljYXRpb24gb2YgZHJhZnQtaWV0 Zi1pcHBtLTIzMzAtaXB2Ni0wMyBhcyBJbmZvcm1hdGlvbmFsIG9uIGJlaGFsZiBvZiB0aGUgSVBQ TSB3b3JraW5nIGdyb3VwLg0KDQpQbGVhc2UgdmVyaWZ5IHRoZSBkb2N1bWVudCdzIHN0YXRlIGF0 IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXBwbS0yMzMwLWlw djYvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f ZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGlwcG0tMkQyMzMwLTJEaXB2 Nl8mZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9T2ZzU3U4a1RJbHRWeUQxb0w3 MmNCdyZtPVl4RF9FZnhGMldjS0FhWFhVYzZIQk8wbnBoeTlWMjBjMHU2RVJucGRDblUmcz1YWllJ SGxsVWtKSWZzNjNNelYxR2Y1Um81Zk5KU2lBQUNiN3Qyc0VBNG80JmU9Pg0KDQpJJ3ZlIGNvbXBs ZXRlZCBteSBBRCBFdmFsdWF0aW9uIGZvciB0aGlzIGRyYWZ0LCBhbmQgaGF2ZSBhIGZldyBxdWVz dGlvbnMuIFRoZXNlIHNob3VsZCBiZSBlYXN5IHRvIHJlc29sdmUgYmVmb3JlIEkgcmVxdWVzdCBM YXN0IENhbGwgZm9yIHRoZSBkcmFmdC4NCg0KUGxlYXNlIGxldCBtZSBrbm93IHdoZW4geW91J3Jl IHJlYWR5IHRvIHByb2NlZWQuDQoNClRoYW5rcyBmb3IgdGhpcyBkcmFmdC4NCg0KU3BlbmNlcg0K DQpJIHdhc24ndCBxdWl0ZSBzdXJlIHdoYXQgdG8gbWFrZSBvZiB0aGlzIHRleHQ6DQoNCiAgV2Ug ZnVydGhlciByZXF1aXJlIHRoYXQgaWYgYSBwYWNrZXQgaXMgZGVzY3JpYmVkIGFzIGhhdmluZyBh ICJsZW5ndGgNCiAgIG9mIEIgb2N0ZXRzIiwgdGhlbiAwIDw9IEIgPD0gNjU1MzU7IGFuZCBpZiBC IGlzIHRoZSBwYXlsb2FkIGxlbmd0aCBpbg0KICAgb2N0ZXRzLCB0aGVuIEIgPD0gKDY1NTM1LUlQ IGhlYWRlciBzaXplIGluIG9jdGV0cywgaW5jbHVkaW5nIGFueQ0KICAgRXh0ZW5zaW9uIEhlYWRl cnMpLiAgVGhlIGp1bWJvZ3JhbXMgZGVmaW5lZCBpbiBbUkZDMjY3NV0gYXJlIG5vdA0KICAgY292 ZXJlZCBieSB0aGlzIGxlbmd0aCBhbmFseXNpcy4NCg0KSXMgdGhlIHBvaW50IHRoYXQganVtYm9n cmFtcyBhcmVuJ3QgdmFsaWQgc3RhbmRhcmQtZm9ybSBwYWNrZXRzPw0KW2FjbV0NCk5vLCB0aGF0 IElQdjYgSnVtYm9ncmFtcyBpbiAyNjc1IGNhbiBiZSBldmUgbG9uZ2VyIQ0KZnJvbSAyNjc1Og0K ICAgQSAianVtYm9ncmFtIiBpcyBhbiBJUHY2IHBhY2tldCBjb250YWluaW5nIGEgcGF5bG9hZCBs b25nZXIgdGhhbg0KICAgNjUsNTM1IG9jdGV0cy4NClByYWN0aWNhbCBNVFVzIGtlZXAgYWxsIHRo aXMgZnJvbSBiZWNvbWluZyBhIHBvaW50DQpvZiBjb250ZW50aW9uLCBhcyB3ZSBleHBsYWluLg0K DQpJbiB0aGlzIHRleHQsDQoNCiAgW1JGQzIzMzBdIGRlZmluZXMgdGhlICJtaW5pbWFsIElQIHBh Y2tldCBmcm9tIEEgdG8gQiIgYXMgYSBwYXJ0aWN1bGFyDQogICB0eXBlIG9mIHN0YW5kYXJkLWZv cm1lZCBwYWNrZXQgb2Z0ZW4gdXNlZnVsIHRvIGNvbnNpZGVyLiAgV2hlbg0KICAgZGVmaW5pbmcg SVAgbWV0cmljcyBubyBwYWNrZXQgc21hbGxlciBvciBzaW1wbGVyIHRoYW4gdGhpcyBjYW4gYmUN CiAgIHRyYW5zbWl0dGVkIG92ZXIgYSBjb3JyZWN0bHkgb3BlcmF0aW5nIElQIG5ldHdvcmsuICBI b3dldmVyLCB0aGUNCiAgIGNvbmNlcHQgb2YgdGhlIG1pbmltYWwgSVAgcGFja2V0IGhhcyBub3Qg YmVlbiB1c2VkIGluIHRoZSBtZWFudGltZQ0KICAgYW5kIGl0cyBwcmFjdGljYWwgdXNlIGlzIGxp bWl0ZWQuDQoNCkkgd29uZGVyIGlmICJpbiB0aGUgbWVhbnRpbWUiIGlzIGNsZWFyIGVub3VnaC4g UGVyaGFwcyAic2luY2UgW1JGQzIzMzBdIHdhcyBwdWJsaXNoZWQgaW4gMTk5OCIsIG9yIHNvbWV0 aGluZyBsaWtlIHRoYXQ/ICgiSWYgaXQgd2Fzbid0IHVzZWZ1bCBpbiB0aGUgZmlyc3QgMjAgeWVh cnMsIGl0IHByb2JhYmx5IHdvbid0IGJlIHVzZWZ1bCBpbiB0aGUgbmV4dCAyMCB5ZWFycyIgOi0p DQpbYWNtXQ0KSSBhZ3JlZSwgd2UgY291bGQgZXhwbGFpbiB0aGF0IGEgbGl0dGxlIGJldHRlci4N CkhvdyBhYm91dDoNCkhvd2V2ZXIsIHRoZSBjb25jZXB0IG9mIHRoZSBtaW5pbWFsIElQIHBhY2tl dCBoYXMgbm90IGJlZW4NCmVtcGxveWVkIChzaW5jZSB0eXBpY2FsIGFjdGl2ZSBtZWFzdXJlbWVu dCBzeXN0ZW1zIGVtcGxveSBhDQp0cmFuc3BvcnQgbGF5ZXIgYW5kIGEgcGF5bG9hZCkgYW5kIGl0 cyBwcmFjdGljYWwgdXNlIGlzIGxpbWl0ZWQuDQpUaGVyZWZvcmUsIHRoaXMgbWVtbyBkZXByZWNh dGVzIHRoZSBjb25jZXB0IG9mIHRoZSAibWluaW1hbCBJUCBwYWNrZXQgZnJvbSBBIHRvIEIiLg0K DQpJJ20gd29uZGVyaW5nIGlmIHRoZSB1cHBlci1jYXNlICJTSE9VTEQiIGluDQoNCiAgSWYgdGhl IGluZm9ybWF0aW9uIGNvbnN0aXR1dGluZyBUeXBlLVAgYXQgdGhlIFNvdXJjZSBpcyBmb3VuZCB0 byBoYXZlDQogICBjaGFuZ2VkIGF0IHRoZSBEZXN0aW5hdGlvbiAob3IgYXQgYSBtZWFzdXJlbWVu dCBwb2ludCBiZXR3ZWVuIHRoZQ0KICAgU291cmNlIGFuZCBEZXN0aW5hdGlvbiwgYXMgaW4gW1JG QzU2NDRdKSwgdGhlbiB0aGUgbW9kaWZpZWQgdmFsdWVzDQogICBTSE9VTEQgYmUgbm90ZWQgYW5k IHJlcG9ydGVkIHdpdGggdGhlIHJlc3VsdHMuDQoNCmlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgbG93 ZXItY2FzZSAibXVzdCIgaW4NCg0KICBUaGUgZGVmaW5pdGlvbiBhbmQgZXhlY3V0aW9uIG9mIG1l YXN1cmVtZW50cyB3aXRoaW4gdGhlIGNvbnRleHQgb2YNCiAgIHRoZSBJUFBNIEZyYW1ld29yayBp cyBjaGFsbGVuZ2VkIHdoZW5ldmVyIHN1Y2ggdHJhbnNsYXRpb24gbWVjaGFuaXNtcw0KICAgYXJl IHByZXNlbnQgYWxvbmcgdGhlIG1lYXN1cmVtZW50IHBhdGguICBJbiBwYXJ0aWN1bGFyIHVzZSBj YXNlcyBsaWtlDQogICBJUHY0LUlQdjYgdHJhbnNsYXRpb24sIE5BVCwgcHJvdG9jb2wgZW5jYXBz dWxhdGlvbiwgb3IgSVB2NiBoZWFkZXINCiAgIGNvbXByZXNzaW9uIG1heSByZXN1bHQgaW4gbW9k aWZpY2F0aW9uIG9mIHRoZSBtZWFzdXJlbWVudCBwYWNrZXQncw0KICAgVHlwZS1QIGFsb25nIHRo ZSBwYXRoLiAgQWxsIHRoZXNlIGNoYW5nZXMgbXVzdCBiZSByZXBvcnRlZC4NCg0KPyBJJ20gYWxz byB3b25kZXJpbmcgaWYgSSBzaG91bGQgc3VnZ2VzdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjODE3NDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjODE3NCZkPUR3TUZhUSZjPUxGWVotbzlfSFVN ZU1UU1FpY3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3Jm09WXhEX0VmeEYyV2NLQWFYWFVj NkhCTzBucGh5OVYyMGMwdTZFUm5wZENuVSZzPV9PQTNQSzBVT05QajVTNWxFaVd3QUIzSzN1SGpC dFI0U0lUUDVYa2dLS0UmZT0+IGFzIHRoZSByZWZlcmVuY2UgZm9yIHJlcXVpcmVtZW50cyBsYW5n dWFnZSwgb3IgYXNrIGZvciBhIHNjcnViIHRvIGVuc3VyZSB0aGF0IHJlcXVpcmVtZW50cyBsYW5n dWFnZSBpcyBjb25zaXN0ZW50IHRocm91Z2hvdXQgdGhlIGRvY3VtZW50Lg0KW2FjbV0NCkdvb2Qg Y2F0Y2gsIGJvdGggdGhlIGFib3ZlIG5lZWQgdG8gYmUgTVVTVC4NCkkgZGlkIGEgc2NydWIgb2Yg 4oCcbXVzdOKAnSBhbmQg4oCcc2hvdWxk4oCdLCBhbmQgZml4ZWQgYSBmZXcNCmNhc2VzLg0KDQpU aGlzIHRleHQNCiAgUG9pbnRzIHRoYXQgYXJlIHdvcnRod2hpbGUgZGlzY3Vzc2luZyBmdXJ0aGVy OiBoYW5kbGluZyBvZiBsYXJnZQ0KICAgcGFja2V0cyBpbiBJUHY2IChpbmNsdWRpbmcgZnJhZ21l bnQgZXh0ZW5zaW9uIGhlYWRlcnMsIFBNVFVELA0KICAgUExQTVRVRCksIGV4dGVudCBvZiBjb3Zl cmFnZSBmb3IgNkxPIGFuZCBJUHY2IEhlYWRlciBDb21wcmVzc2lvbiwgYW5kDQogICB0aGUgY29u dGludWVkIG5lZWQgdG8gZGVmaW5lIGEgIm1pbmltYWwgc3RhbmRhcmQtZm9ybWVkIHBhY2tldCIu DQoNCmRpZG4ndCBzZWVtIGNvbnNpc3RlbnQgd2l0aCB0aGUgcHJldmlvdXMgbWVudGlvbnMgb2Yg Im1pbmltYWwgc3RhbmRhcmQtZm9ybWVkIHBhY2tldCIsIHdoaWNoIEkgcmVhZCBhcyBkZXByZWNh dGluZyB0aGlzIGNvbmNlcHQuIERvZXMgdGhpcyB0ZXh0IHNheSB0aGF0IGNvbmNlcHQgbWlnaHQg YmUgY29taW5nIGJhY2s/DQpbYWNtXQ0KVWdoLCBUaGlzIHNlZW1zIHRvIGJlIGEgbGlzdCBvZiBv cGVuIGlzc3VlcyB3aGljaCB3ZSBoYXZlIGFkZHJlc3NlZCwNCkJ1dCBzb21laG93IHRoaXMgdGV4 dCB3YXMgbGVmdCBiZWhpbmQuIFNvcnJ5IQ0KDQpJIGRpZG4ndCB1bmRlcnN0YW5kDQoNCiAgV2hl biBjb25zaWRlcmluZyBwcml2YWN5IG9mIHRob3NlIGludm9sdmVkIGluIG1lYXN1cmVtZW50IG9y IHRob3NlDQogICB3aG9zZSB0cmFmZmljIGlzIG1lYXN1cmVkLCB0aGUgc2Vuc2l0aXZlIGluZm9y bWF0aW9uIGF2YWlsYWJsZSB0bw0KICAgcG90ZW50aWFsIG9ic2VydmVycyBpcyBncmVhdGx5IHJl ZHVjZWQgd2hlbiB1c2luZyBhY3RpdmUgdGVjaG5pcXVlcw0KICAgd2hpY2ggYXJlIHdpdGhpbiB0 aGlzIHNjb3BlIG9mIHdvcmsuDQoNCldhcyB0aGUgcG9pbnQgdGhhdCBwZW9wbGUgbWVhc3VyaW5n IHRyYWZmaWMgdXNpbmcgYWN0aXZlIG1lYXN1cmVtZW50cyBrbm93IHByZXR0eSB3ZWxsIHdoYXQg dGhleSBzZW50LCBzbyBwcml2YWN5IGlzbid0IGEgY29uY2VybiBmb3IgdGhvc2UgcGFja2V0cywg b3IgaXMgc29tZXRoaW5nIGVsc2UgYmVpbmcgdGFsa2VkIGFib3V0Pw0KW2FjbV0NClllcywgZXZl biB3aGVuIHVzZXJzIGxhdW5jaCB0aGVpciBvd24gYWN0aXZlIG1lYXN1cmVtZW50IHRyYWZmaWMs DQp0aGUgcGFja2V0cyB3aWxsIGJlYXIgdGhlaXIgSVAgYWRkcmVzc2VzIGFuZCB0aGF04oCZcyB1 bmF2b2lkYWJsZSwNCmJ1dCBubyBvdGhlciBzZW5zaXRpdmUgaW5mbyB3b3VsZCBub3JtYWxseSBh cHBlYXIuDQoNCknigJlsbCBwdXNoIGEgcmV2aXNlZCB2ZXJzaW9uIGZvciBhdXRob3JzIHRvIGNo ZWNrIHNob3J0bHkuDQrigKYNCg0K --_000_4D7F4AD313D3FC43A053B309F97543CF4A8E0A39njmtexg5researc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhp IFNwZW5jZXIsIHBsZWFzZSBzZWUgcmVwbGllcyBpbi1saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MgZm9y IHlvdXIgcmV2aWV3ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIFttYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFp bC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDI5LCAyMDE4IDU6MjUg UE08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIFRyYW1tZWxsICZsdDtpZXRmQHRyYW1tZWxsLmNoJmd0 Ozxicj4NCjxiPkNjOjwvYj4gTmV2aWwgQnJvd25sZWUgJmx0O24uYnJvd25sZWVAYXVja2xhbmQu YWMubnomZ3Q7OyBpcHBtLWNoYWlyc0BpZXRmLm9yZzsgaXBwbUBpZXRmLm9yZzsgZHJhZnQtaWV0 Zi1pcHBtLTIzMzAtaXB2NkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBBRCBFdmFsdWF0 aW9uIGZvciBkcmFmdC1pZXRmLWlwcG0tMjMzMC1pcHY2LTAzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgSVBQTWVycyw8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE1hciA0LCAyMDE4IGF0IDQ6MDYg UE0sIEJyaWFuIFRyYW1tZWxsICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaCIg dGFyZ2V0PSJfYmxhbmsiPmlldGZAdHJhbW1lbGwuY2g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbiBUcmFtbWVsbCBo YXMgcmVxdWVzdGVkIHB1YmxpY2F0aW9uIG9mIGRyYWZ0LWlldGYtaXBwbS0yMzMwLWlwdjYtMDMg YXMgSW5mb3JtYXRpb25hbCBvbiBiZWhhbGYgb2YgdGhlIElQUE0gd29ya2luZyBncm91cC48YnI+ DQo8YnI+DQpQbGVhc2UgdmVyaWZ5IHRoZSBkb2N1bWVudCdzIHN0YXRlIGF0IDxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRy YWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGlwcG0tMkQyMzMwLTJEaXB2Nl8mYW1w O2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9T2ZzU3U4a1RJbHRW eUQxb0w3MmNCdyZhbXA7bT1ZeERfRWZ4RjJXY0tBYVhYVWM2SEJPMG5waHk5VjIwYzB1NkVSbnBk Q25VJmFtcDtzPVhaWUlIbGxVa0pJZnM2M016VjFHZjVSbzVmTkpTaUFBQ2I3dDJzRUE0bzQmYW1w O2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWlwcG0tMjMzMC1pcHY2LzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkndmUgY29tcGxldGVkIG15IEFEIEV2 YWx1YXRpb24gZm9yIHRoaXMgZHJhZnQsIGFuZCBoYXZlIGEgZmV3IHF1ZXN0aW9ucy4gVGhlc2Ug c2hvdWxkIGJlIGVhc3kgdG8gcmVzb2x2ZSBiZWZvcmUgSSByZXF1ZXN0IExhc3QgQ2FsbCBmb3Ig dGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5QbGVhc2UgbGV0IG1lIGtub3cgd2hlbiB5b3UncmUgcmVhZHkgdG8gcHJvY2VlZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh bmtzIGZvciB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TcGVuY2VyJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhc24ndCBxdWl0ZSBzdXJlIHdo YXQgdG8gbWFrZSBvZiB0aGlzIHRleHQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBXZSBmdXJ0aGVyIHJlcXVpcmUgdGhhdCBpZiBh IHBhY2tldCBpcyBkZXNjcmliZWQgYXMgaGF2aW5nIGEgJnF1b3Q7bGVuZ3RoPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7b2Yg QiBvY3RldHMmcXVvdDssIHRoZW4gMCAmbHQ7PSBCICZsdDs9IDY1NTM1OyBhbmQgaWYgQiBpcyB0 aGUgcGF5bG9hZCBsZW5ndGggaW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtvY3RldHMsIHRoZW4gQiAmbHQ7PSAoNjU1MzUt SVAgaGVhZGVyIHNpemUgaW4gb2N0ZXRzLCBpbmNsdWRpbmcgYW55PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7RXh0ZW5zaW9u IEhlYWRlcnMpLiZuYnNwOyBUaGUganVtYm9ncmFtcyBkZWZpbmVkIGluIFtSRkMyNjc1XSBhcmUg bm90PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7Y292ZXJlZCBieSB0aGlzIGxlbmd0aCBhbmFseXNpcy4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhlIHBv aW50IHRoYXQganVtYm9ncmFtcyBhcmVuJ3QgdmFsaWQgc3RhbmRhcmQtZm9ybSBwYWNrZXRzPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlthY21dDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPk5vLCB0aGF0IElQdjYgSnVtYm9ncmFtcyBpbiAyNjc1IGNhbiBiZSBldmUgbG9uZ2VyITxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5mcm9t IDI2NzU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBBICZxdW90O2p1bWJvZ3JhbSZxdW90OyBpcyBhbiBJUHY2IHBhY2tl dCBjb250YWluaW5nIGEgcGF5bG9hZCBsb25nZXIgdGhhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgNjUsNTM1IG9jdGV0 cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5QcmFjdGljYWwgTVRVcyBrZWVwIGFsbCB0aGlzIGZyb20gYmVjb21pbmcg YSBwb2ludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5vZiBjb250ZW50aW9uLCBhcyB3ZSBleHBsYWluLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhp cyB0ZXh0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgW1JGQzIzMzBdIGRlZmluZXMgdGhlICZxdW90O21pbmltYWwgSVAgcGFja2V0 IGZyb20gQSB0byBCJnF1b3Q7IGFzIGEgcGFydGljdWxhcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3R5cGUgb2Ygc3RhbmRh cmQtZm9ybWVkIHBhY2tldCBvZnRlbiB1c2VmdWwgdG8gY29uc2lkZXIuJm5ic3A7IFdoZW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDtkZWZpbmluZyBJUCBtZXRyaWNzIG5vIHBhY2tldCBzbWFsbGVyIG9yIHNpbXBsZXIgdGhh biB0aGlzIGNhbiBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwO3RyYW5zbWl0dGVkIG92ZXIgYSBjb3JyZWN0bHkgb3BlcmF0 aW5nIElQIG5ldHdvcmsuJm5ic3A7IEhvd2V2ZXIsIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2NvbmNlcHQgb2YgdGhl IG1pbmltYWwgSVAgcGFja2V0IGhhcyBub3QgYmVlbiB1c2VkIGluIHRoZSBtZWFudGltZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwO2FuZCBpdHMgcHJhY3RpY2FsIHVzZSBpcyBsaW1pdGVkLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvbmRlciBpZiAmcXVv dDtpbiB0aGUgbWVhbnRpbWUmcXVvdDsgaXMgY2xlYXIgZW5vdWdoLiBQZXJoYXBzICZxdW90O3Np bmNlIFtSRkMyMzMwXSB3YXMgcHVibGlzaGVkIGluIDE5OTgmcXVvdDssIG9yIHNvbWV0aGluZyBs aWtlIHRoYXQ/ICgmcXVvdDtJZiBpdCB3YXNuJ3QgdXNlZnVsIGluIHRoZSBmaXJzdCAyMCB5ZWFy cywgaXQgcHJvYmFibHkgd29uJ3QgYmUgdXNlZnVsIGluIHRoZSBuZXh0IDIwIHllYXJzJnF1b3Q7 IDotKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPlthY21dDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkkgYWdyZWUsIHdlIGNvdWxkIGV4cGxhaW4gdGhhdCBhIGxpdHRsZSBiZXR0ZXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkhvdyBhYm91dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NC44cHQ7dGV4dC1pbmRlbnQ6MzEuMnB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+SG93ZXZlciwgdGhlIGNvbmNlcHQgb2YgdGhlIG1pbmltYWwgSVAg cGFja2V0IGhhcyBub3QgYmVlbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQuOHB0O3RleHQtaW5kZW50OjMxLjJwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPmVtcGxveWVkIChzaW5jZSB0eXBpY2FsIGFjdGl2ZSBtZWFzdXJl bWVudCBzeXN0ZW1zIGVtcGxveSBhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NC44cHQ7dGV4dC1pbmRlbnQ6MzEuMnB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+dHJhbnNwb3J0IGxheWVyIGFuZCBhIHBheWxvYWQpIGFuZCBp dHMgcHJhY3RpY2FsIHVzZSBpcyBsaW1pdGVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQuOHB0O3RleHQtaW5kZW50OjMx LjJwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoZXJlZm9yZSwgdGhpcyBtZW1vIGRlcHJlY2F0 ZXMgdGhlIGNvbmNlcHQgb2YgdGhlICZxdW90O21pbmltYWwgSVAgcGFja2V0IGZyb20gQSB0byBC JnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSdtIHdvbmRlcmluZyBpZiB0aGUgdXBwZXItY2FzZSAmcXVvdDtTSE9VTEQm cXVvdDsgaW4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7IElmIHRoZSBpbmZvcm1hdGlvbiBjb25zdGl0dXRpbmcgVHlwZS1Q IGF0IHRoZSBTb3VyY2UgaXMgZm91bmQgdG8gaGF2ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2NoYW5nZWQgYXQgdGhlIERl c3RpbmF0aW9uIChvciBhdCBhIG1lYXN1cmVtZW50IHBvaW50IGJldHdlZW4gdGhlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 U291cmNlIGFuZCBEZXN0aW5hdGlvbiwgYXMgaW4gW1JGQzU2NDRdKSwgdGhlbiB0aGUgbW9kaWZp ZWQgdmFsdWVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7U0hPVUxEIGJlIG5vdGVkIGFuZCByZXBvcnRlZCB3aXRoIHRoZSBy ZXN1bHRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5pcyBjb25zaXN0ZW50IHdpdGggdGhlIGxvd2VyLWNhc2UgJnF1b3Q7bXVzdCZxdW90OyBp biZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgVGhlIGRlZmluaXRpb24gYW5kIGV4ZWN1dGlvbiBvZiBtZWFzdXJlbWVudHMg d2l0aGluIHRoZSBjb250ZXh0IG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dGhlIElQUE0gRnJhbWV3b3JrIGlzIGNoYWxs ZW5nZWQgd2hlbmV2ZXIgc3VjaCB0cmFuc2xhdGlvbiBtZWNoYW5pc21zPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7YXJlIHBy ZXNlbnQgYWxvbmcgdGhlIG1lYXN1cmVtZW50IHBhdGguJm5ic3A7IEluIHBhcnRpY3VsYXIgdXNl IGNhc2VzIGxpa2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDtJUHY0LUlQdjYgdHJhbnNsYXRpb24sIE5BVCwgcHJvdG9jb2wg ZW5jYXBzdWxhdGlvbiwgb3IgSVB2NiBoZWFkZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtjb21wcmVzc2lvbiBtYXkgcmVz dWx0IGluIG1vZGlmaWNhdGlvbiBvZiB0aGUgbWVhc3VyZW1lbnQgcGFja2V0J3M8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtU eXBlLVAgYWxvbmcgdGhlIHBhdGguJm5ic3A7IEFsbCB0aGVzZSBjaGFuZ2VzIG11c3QgYmUgcmVw b3J0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPj8gSSdtIGFsc28gd29uZGVyaW5nIGlmIEkgc2hvdWxkIHN1Z2dlc3QgPGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5p ZXRmLm9yZ19odG1sX3JmYzgxNzQmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1Fp Y3ZqSWcmYW1wO3I9T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZhbXA7bT1ZeERfRWZ4RjJXY0tBYVhY VWM2SEJPMG5waHk5VjIwYzB1NkVSbnBkQ25VJmFtcDtzPV9PQTNQSzBVT05QajVTNWxFaVd3QUIz SzN1SGpCdFI0U0lUUDVYa2dLS0UmYW1wO2U9Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM4MTc0PC9hPiBhcyB0aGUgcmVmZXJlbmNlIGZvciByZXF1aXJlbWVudHMgbGFuZ3VhZ2Us IG9yIGFzayBmb3IgYSBzY3J1YiB0byBlbnN1cmUgdGhhdCByZXF1aXJlbWVudHMgbGFuZ3VhZ2Ug aXMgY29uc2lzdGVudCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bYWNtXQ0KPC9z cGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Hb29kIGNhdGNoLCBi b3RoIHRoZSBhYm92ZSBuZWVkIHRvIGJlIE1VU1QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgZGlkIGEgc2NydWIgb2Yg 4oCcbXVzdOKAnSBhbmQg4oCcc2hvdWxk4oCdLCBhbmQgZml4ZWQgYSBmZXc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Y2Fz ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlzIHRleHQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBQb2ludHMgdGhhdCBhcmUgd29ydGh3aGlsZSBkaXNj dXNzaW5nIGZ1cnRoZXI6IGhhbmRsaW5nIG9mIGxhcmdlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cGFja2V0cyBpbiBJUHY2 IChpbmNsdWRpbmcgZnJhZ21lbnQgZXh0ZW5zaW9uIGhlYWRlcnMsIFBNVFVELDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1BM UE1UVUQpLCBleHRlbnQgb2YgY292ZXJhZ2UgZm9yIDZMTyBhbmQgSVB2NiBIZWFkZXIgQ29tcHJl c3Npb24sIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwO3RoZSBjb250aW51ZWQgbmVlZCB0byBkZWZpbmUgYSAmcXVvdDtt aW5pbWFsIHN0YW5kYXJkLWZvcm1lZCBwYWNrZXQmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRpZG4ndCBzZWVtIGNvbnNpc3RlbnQg d2l0aCB0aGUgcHJldmlvdXMgbWVudGlvbnMgb2YgJnF1b3Q7bWluaW1hbCBzdGFuZGFyZC1mb3Jt ZWQgcGFja2V0JnF1b3Q7LCB3aGljaCBJIHJlYWQgYXMgZGVwcmVjYXRpbmcgdGhpcyBjb25jZXB0 LiBEb2VzIHRoaXMgdGV4dCBzYXkgdGhhdCBjb25jZXB0IG1pZ2h0IGJlIGNvbWluZyBiYWNrPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPlthY21dDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5VZ2gsIFRoaXMgc2VlbXMgdG8gYmUgYSBs aXN0IG9mIG9wZW4gaXNzdWVzIHdoaWNoIHdlIGhhdmUgYWRkcmVzc2VkLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5CdXQg c29tZWhvdyB0aGlzIHRleHQgd2FzIGxlZnQgYmVoaW5kLiBTb3JyeSE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkbid0IHVu ZGVyc3RhbmQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7IFdoZW4gY29uc2lkZXJpbmcgcHJpdmFjeSBvZiB0aG9zZSBpbnZv bHZlZCBpbiBtZWFzdXJlbWVudCBvciB0aG9zZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3dob3NlIHRyYWZmaWMgaXMgbWVh c3VyZWQsIHRoZSBzZW5zaXRpdmUgaW5mb3JtYXRpb24gYXZhaWxhYmxlIHRvPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cG90 ZW50aWFsIG9ic2VydmVycyBpcyBncmVhdGx5IHJlZHVjZWQgd2hlbiB1c2luZyBhY3RpdmUgdGVj aG5pcXVlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO3doaWNoIGFyZSB3aXRoaW4gdGhpcyBzY29wZSBvZiB3b3JrLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X YXMgdGhlIHBvaW50IHRoYXQgcGVvcGxlIG1lYXN1cmluZyB0cmFmZmljIHVzaW5nIGFjdGl2ZSBt ZWFzdXJlbWVudHMga25vdyBwcmV0dHkgd2VsbCB3aGF0IHRoZXkgc2VudCwgc28gcHJpdmFjeSBp c24ndCBhIGNvbmNlcm4gZm9yIHRob3NlIHBhY2tldHMsIG9yIGlzIHNvbWV0aGluZyBlbHNlIGJl aW5nIHRhbGtlZCBhYm91dD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bYWNtXQ0KPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5ZZXMsIGV2ZW4gd2hlbiB1c2VycyBsYXVuY2ggdGhlaXIg b3duIGFjdGl2ZSBtZWFzdXJlbWVudCB0cmFmZmljLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj50aGUgcGFja2V0cyB3aWxs IGJlYXIgdGhlaXIgSVAgYWRkcmVzc2VzIGFuZCB0aGF04oCZcyB1bmF2b2lkYWJsZSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+YnV0IG5vIG90aGVyIHNlbnNpdGl2ZSBpbmZvIHdvdWxkIG5vcm1hbGx5IGFwcGVhci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPknigJlsbCBwdXNoIGEgcmV2aXNlZCB2ZXJzaW9uIGZvciBh dXRob3JzIHRvIGNoZWNrIHNob3J0bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPuKApjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4D7F4AD313D3FC43A053B309F97543CF4A8E0A39njmtexg5researc_-- From nobody Fri Mar 30 14:55:11 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A29C126CE8; Fri, 30 Mar 2018 14:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TisGJBxVh7Xj; Fri, 30 Mar 2018 14:55:06 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::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 3BC42127286; Fri, 30 Mar 2018 14:55:06 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id x72-v6so3359992ybe.8; Fri, 30 Mar 2018 14:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CNPFVPn2SowZ1BLPMgdQlOalB1MG1uHOQyMLa9hkcP8=; b=KfB7JxKBqg/xY5mU7e4NfJ15XF47pwY2bZDjhzgrvp/qjoPx0JyUSzfQba86JR4GXk DuEglHlqGk1LhvZyThHJ6MzWwb8Ymp0ZabpVyaydl6zmghLbJaXGZ4Ot3BbBJM3bAcbh 07PfwCr0GoOcnnrCjKrdkJS0rBk1jweH7PxgXhh7rSjzAChYBGARnfrVnikNm4y7jp+J 6ntfH1fGPNLr35ZmrCugpRzfWxwOh1+2wRkdO7Jibb+1W+e4jYxZgmN8/0A8363f4Muc yMM0nQoL5YYdJPGX/qMaYTuGWttZs2ML1g00cjKd962mOqusF3AZYa55TWz2Syryq2zk dNNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CNPFVPn2SowZ1BLPMgdQlOalB1MG1uHOQyMLa9hkcP8=; b=BXBcasWfpU5P9qcuLLvgbLJrXLK2tHM4koeAeRL6qrq1wY5V1TSvJdnUFHajBuZ4xX el+VACFpQVVnmHxFXQ68Qq+BgGL25HrITf+DE5Si/1tGtFYSDyx/9tgqVrS5cd4zcDit lVGfIFpDPwvM68AOap08zEDQ4lUb/fhaVSrp1b5lM4JTI4FGT+2hr+ZpRcMU/e06b4gL 6X4dJtyIhxPm148e0g0MSJUkW7pBWmttqIMcEV6g7zYNHq5ZcNkroIcjEmxitoH5bA8d kh3ov7956GvoDMSV0yQ8l7vQfHTms0iFtkQ5xz2id9sGGdSMG7DMAsqtyDW4B2mUsIE0 l3Xg== X-Gm-Message-State: AElRT7GEBG7ay8Y5CfLbh+2ylh2atRvyd2HLlNs0I/1y5jhTvKvtrqoV Jy7lPHFRrRYTAg9ug496BaVGyxhMuM62Bqjqsh0= X-Google-Smtp-Source: AIpwx49abUOS30BXC16Jrn5KS+FdxWa9EF/FxGevltFEWp3kd/jTBeRZwlhmfrZQYifegtTqqFcJJDGUNp5WtNtQqHI= X-Received: by 2002:a25:888c:: with SMTP id d12-v6mr410271ybl.110.1522446905185; Fri, 30 Mar 2018 14:55:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:e757:0:0:0:0:0 with HTTP; Fri, 30 Mar 2018 14:55:04 -0700 (PDT) In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF4A8E0A39@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF4A8E0A39@njmtexg5.research.att.com> From: Spencer Dawkins at IETF Date: Fri, 30 Mar 2018 16:55:04 -0500 Message-ID: To: "MORTON, ALFRED C (AL)" Cc: Brian Trammell , Nevil Brownlee , "ippm-chairs@ietf.org" , "ippm@ietf.org" , "draft-ietf-ippm-2330-ipv6@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f925b40568a84ab5" Archived-At: Subject: Re: [ippm] AD Evaluation for draft-ietf-ippm-2330-ipv6-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2018 21:55:10 -0000 --000000000000f925b40568a84ab5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Al, On Fri, Mar 30, 2018 at 11:11 AM, MORTON, ALFRED C (AL) wrote: > Hi Spencer, please see replies in-line. > I have one item below that I'm still not clear on, but I think we are in sync everywhere else. > Thanks for your review! > > Al > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > *Sent:* Thursday, March 29, 2018 5:25 PM > *To:* Brian Trammell > *Cc:* Nevil Brownlee ; ippm-chairs@ietf.org; > ippm@ietf.org; draft-ietf-ippm-2330-ipv6@ietf.org > *Subject:* AD Evaluation for draft-ietf-ippm-2330-ipv6-03 > > > > Dear IPPMers, > > > > On Sun, Mar 4, 2018 at 4:06 PM, Brian Trammell wrote: > > Brian Trammell has requested publication of draft-ietf-ippm-2330-ipv6-03 > as Informational on behalf of the IPPM working group. > > Please verify the document's state at https://datatracker.ietf.org/ > doc/draft-ietf-ippm-2330-ipv6/ > > > > > I've completed my AD Evaluation for this draft, and have a few questions. > These should be easy to resolve before I request Last Call for the draft. > > > > Please let me know when you're ready to proceed. > > > > Thanks for this draft. > > > > Spencer > > > > I wasn't quite sure what to make of this text: > > > > We further require that if a packet is described as having a "length > > of B octets", then 0 <=3D B <=3D 65535; and if B is the payload length= in > > octets, then B <=3D (65535-IP header size in octets, including any > > Extension Headers). The jumbograms defined in [RFC2675] are not > > covered by this length analysis. > > > > Is the point that jumbograms aren't valid standard-form packets? > > *[acm] * > > No, that IPv6 Jumbograms in 2675 can be eve longer! > > from 2675: > > A "jumbogram" is an IPv6 packet containing a payload longer than > > 65,535 octets. > > Practical MTUs keep all this from becoming a point > > of contention, as we explain. > Right, but what I'm not lacing together is - I have an IPv6 packet with 65,536 bytes - Let's say that It would be a valid standard-form packet if it was one byte shorter - am I understanding that it is not a valid standard-form packet? - or is the point that we basically never see IPv6 jumbograms because they would take up at least 40 maximum-length Ethernet packets, so we don't care whether they would be valid standard-form packets if we ever did see one? Thanks for clues, Spencer > > > In this text, > > > > [RFC2330] defines the "minimal IP packet from A to B" as a particular > > type of standard-formed packet often useful to consider. When > > defining IP metrics no packet smaller or simpler than this can be > > transmitted over a correctly operating IP network. However, the > > concept of the minimal IP packet has not been used in the meantime > > and its practical use is limited. > > > > I wonder if "in the meantime" is clear enough. Perhaps "since [RFC2330] > was published in 1998", or something like that? ("If it wasn't useful in > the first 20 years, it probably won't be useful in the next 20 years" :-) > > *[acm] * > > I agree, we could explain that a little better. > > How about: > > However, the concept of the minimal IP packet has not been > > employed (since typical active measurement systems employ a > > transport layer and a payload) and its practical use is limited. > > Therefore, this memo deprecates the concept of the "minimal IP packet fro= m > A to B". > > > > I'm wondering if the upper-case "SHOULD" in > > > > If the information constituting Type-P at the Source is found to have > > changed at the Destination (or at a measurement point between the > > Source and Destination, as in [RFC5644]), then the modified values > > SHOULD be noted and reported with the results. > > > > is consistent with the lower-case "must" in > > > > The definition and execution of measurements within the context of > > the IPPM Framework is challenged whenever such translation mechanisms > > are present along the measurement path. In particular use cases like > > IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header > > compression may result in modification of the measurement packet's > > Type-P along the path. All these changes must be reported. > > > > ? I'm also wondering if I should suggest https://tools.ietf.org/html/ > rfc8174 > > as the reference for requirements language, or ask for a scrub to ensure > that requirements language is consistent throughout the document. > > *[acm] * > > Good catch, both the above need to be MUST. > > I did a scrub of =E2=80=9Cmust=E2=80=9D and =E2=80=9Cshould=E2=80=9D, and= fixed a few > > cases. > > > > This text > > Points that are worthwhile discussing further: handling of large > > packets in IPv6 (including fragment extension headers, PMTUD, > > PLPMTUD), extent of coverage for 6LO and IPv6 Header Compression, and > > the continued need to define a "minimal standard-formed packet". > > > > didn't seem consistent with the previous mentions of "minimal > standard-formed packet", which I read as deprecating this concept. Does > this text say that concept might be coming back? > > *[acm] * > > Ugh, This seems to be a list of open issues which we have addressed, > > But somehow this text was left behind. Sorry! > > > > I didn't understand > > > > When considering privacy of those involved in measurement or those > > whose traffic is measured, the sensitive information available to > > potential observers is greatly reduced when using active techniques > > which are within this scope of work. > > > > Was the point that people measuring traffic using active measurements kno= w > pretty well what they sent, so privacy isn't a concern for those packets, > or is something else being talked about? > > *[acm] * > > Yes, even when users launch their own active measurement traffic, > > the packets will bear their IP addresses and that=E2=80=99s unavoidable, > > but no other sensitive info would normally appear. > > > > I=E2=80=99ll push a revised version for authors to check shortly. > > =E2=80=A6 > > > --000000000000f925b40568a84ab5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Al,=C2=A0

On Fri, Mar 30, 2018 at 11:11 AM, MORTON, ALFRED C (AL) <acmor= ton@att.com> wrote:

Hi Spencer, please see replies in-line.=


I have one item below that= I'm still not clear on, but I think we are in sync everywhere else.
=C2=A0

Thanks for your review!

Al

<= span style=3D"font-size:11.0pt;font-family:"Courier New";color:bl= ack">=C2=A0

From: Spencer Dawkins at IETF [mailt= o:spence= rdawkins.ietf@gmail.com]
Sent: Thursday, March 29, 2018 5:25 PM
To: Brian Trammell <ietf@trammell.ch>
Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>; ippm-chairs@ietf.org; ippm@ietf.org; draft-ietf-ippm-2330-= ipv6@ietf.org
Subject: AD Evaluation for draft-ietf-ippm-2330-ipv6-03

=C2=A0

Dear IPPMers,

=C2=A0

On Sun, Mar 4, 2018 at 4:06 PM, Brian Trammell <<= a href=3D"mailto:ietf@trammell.ch" target=3D"_blank">ietf@trammell.ch&g= t; wrote:

Brian Trammell has requested publication of draft-ie= tf-ippm-2330-ipv6-03 as Informational on behalf of the IPPM working group.<= br>
Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/=

=C2=A0

I've completed my AD Evaluation for this draft, = and have a few questions. These should be easy to resolve before I request = Last Call for the draft.

=C2=A0

Please let me know when you're ready to proceed.=

=C2=A0

Thanks for this draft.

=C2=A0

Spencer=C2=A0

=C2=A0

I wasn't quite sure what to make of this text:

=C2=A0

=C2=A0 We further require that if a packet is descri= bed as having a "length

=C2=A0 =C2=A0of B octets", then 0 <=3D B <= ;=3D 65535; and if B is the payload length in

=C2=A0 =C2=A0octets, then B <=3D (65535-IP header= size in octets, including any

=C2=A0 =C2=A0Extension Headers).=C2=A0 The jumbogram= s defined in [RFC2675] are not

=C2=A0 =C2=A0covered by this length analysis.=C2=A0<= u>

=C2=A0

Is the point that jumbograms aren't valid standa= rd-form packets?

[acm]

No, that IPv6 Jumbograms in 2675 can be eve lo= nger!

from 2675:

=C2=A0=C2=A0 A "jumbogram" is an IPv6 packet con= taining a payload longer than

=C2=A0=C2=A0 65,535 octets.

Practical MTUs keep all this from becoming a p= oint

of contention, as we explain.

=

= Right, but what I'm not lacing together is=C2=A0

- I have an IPv6 packet with 65,536 bytes
- Let's say that= It would be a valid standard-form packet if it was one byte shorter
<= div>- am I understanding that it is not a valid standard-form packet?
=
- or is the point that we basically never see IPv6 jumbograms because = they would take up at least 40 maximum-length Ethernet packets, so we don&#= 39;t care whether they would be valid standard-form packets if we ever did = see one?

Thanks for clues,

Spencer
=C2=A0

=

=C2=A0

In this text,

=C2=A0

=C2=A0 [RFC2330] defines the "minimal IP packet= from A to B" as a particular

=C2=A0 =C2=A0type of standard-formed packet often us= eful to consider.=C2=A0 When

=C2=A0 =C2=A0defining IP metrics no packet smaller o= r simpler than this can be

=C2=A0 =C2=A0transmitted over a correctly operating = IP network.=C2=A0 However, the

=C2=A0 =C2=A0concept of the minimal IP packet has no= t been used in the meantime

=C2=A0 =C2=A0and its practical use is limited.=C2=A0=

=C2=A0

I wonder if "in the meantime" is clear eno= ugh. Perhaps "since [RFC2330] was published in 1998", or somethin= g like that? ("If it wasn't useful in the first 20 years, it proba= bly won't be useful in the next 20 years" :-)

[acm]

I agree, we could explain that a little better= .

How about:

However, the concept of the minimal IP packet has not been

employed (since typical active measurement systems employ a

transport layer and a payload) and its practical use is limited.

Therefore, this memo deprecates the concept of the "minimal IP packet= from A to B".

=C2=A0

I'm wondering if the upper-case "SHOULD&quo= t; in=C2=A0

=C2=A0

=C2=A0 If the information constituting Type-P at the= Source is found to have

=C2=A0 =C2=A0changed at the Destination (or at a mea= surement point between the

=C2=A0 =C2=A0Source and Destination, as in [RFC5644]= ), then the modified values

=C2=A0 =C2=A0SHOULD be noted and reported with the r= esults.

=C2=A0

is consistent with the lower-case "must" i= n=C2=A0

=C2=A0

=C2=A0 The definition and execution of measurements = within the context of

=C2=A0 =C2=A0the IPPM Framework is challenged whenev= er such translation mechanisms

=C2=A0 =C2=A0are present along the measurement path.= =C2=A0 In particular use cases like

=C2=A0 =C2=A0IPv4-IPv6 translation, NAT, protocol en= capsulation, or IPv6 header

=C2=A0 =C2=A0compression may result in modification = of the measurement packet's

=C2=A0 =C2=A0Type-P along the path.=C2=A0 All these = changes must be reported.

=C2=A0

? I'm also wondering if I should suggest https://tools.ietf.org/html/rfc8174 as the reference for requireme= nts language, or ask for a scrub to ensure that requirements language is co= nsistent throughout the document.

[acm]

Good catch, both the above need to be MUST.=

I did a scrub of =E2=80=9Cmust=E2=80=9D and = =E2=80=9Cshould=E2=80=9D, and fixed a few

cases.

=C2=A0

This text=C2=A0

=C2=A0 Points that are worthwhile discussing further= : handling of large

=C2=A0 =C2=A0packets in IPv6 (including fragment ext= ension headers, PMTUD,

=C2=A0 =C2=A0PLPMTUD), extent of coverage for 6LO an= d IPv6 Header Compression, and

=C2=A0 =C2=A0the continued need to define a "mi= nimal standard-formed packet".

=C2=A0

didn't seem consistent with the previous mention= s of "minimal standard-formed packet", which I read as deprecatin= g this concept. Does this text say that concept might be coming back?

[acm]

Ugh, This seems to be a list of open issues wh= ich we have addressed,

But somehow this text was left behind. Sorry!<= u>

=C2=A0

I didn't understand=C2=A0

=C2=A0

=C2=A0 When considering privacy of those involved in= measurement or those

=C2=A0 =C2=A0whose traffic is measured, the sensitiv= e information available to

=C2=A0 =C2=A0potential observers is greatly reduced = when using active techniques

=C2=A0 =C2=A0which are within this scope of work.=C2= =A0

=C2=A0

Was the point that people measuring traffic using ac= tive measurements know pretty well what they sent, so privacy isn't a c= oncern for those packets, or is something else being talked about?

[acm]

Yes, even when users launch their own active m= easurement traffic,

the packets will bear their IP addresses and t= hat=E2=80=99s unavoidable,

but no other sensitive info would normally app= ear.

=C2=A0

I=E2=80=99ll push a revised version for author= s to check shortly.

=E2=80=A6

=C2=A0


--000000000000f925b40568a84ab5-- From nobody Sat Mar 31 09:14:23 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE3B1270A0; Sat, 31 Mar 2018 09:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MhtlpwCinLTF; Sat, 31 Mar 2018 09:14:18 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 A92C6126B72; Sat, 31 Mar 2018 09:14:18 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id t10so6811175pgv.8; Sat, 31 Mar 2018 09:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=onbxnDfDtUubidTMWzlnjJQXZtycoKeKGqxC1QykYMs=; b=O+dDhJ+/uvAI+wkN5alUJOgBOqFbuNq1jQQBHdy0CHxSBrLc1q49p5K+f8Y7x+kXum CUkGHgJI0zxX6deAVotG99FypSN7qA2md4sOEXkGbwp0bDqEpUniCnWeIHU3BVOH83JP RVYrxIZmUx+slf5HyzGu7DlyLdP11x6MZcmhCfs2YpZwbJGSrYql8KOcuLIY7NeVEBq1 dU76PB8PLrN1K6bIzW4Dq5oC7rX/6fos4cYhwZ3KjGDS/CkwwbYmJIhhefChtMq0DxC2 Y0xFCghhpxb+o82xrxp3BCIVxjkw65OOA9HXPJy/y4YueK7vxolg7gemFeMeWUklVk2t ubng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=onbxnDfDtUubidTMWzlnjJQXZtycoKeKGqxC1QykYMs=; b=rYlbcbWJSSv2rYEBOpIYF6ioEjcRUX0W58Km3nK/4krjLz4dmZgsEXMUCKftrIX+wx z6/Wx5ewz/Z3iyjr4ZBf2Go34t6PZLwWPqGU8zp1tmYRkZQICZFKYVIdS+wm0GgHXSsd yqo4bAwov3eDtpVb695IR5PiNW5Z7ncf3R+Ill3+l1WQYr1P2ODIW3SponuEJUI+rsqN YJeQNLAJIW8ytc0/CFphB+1qFnQmnkb9xzJBfFlEDMkwtIj9JUCAYFI17OmaLK0yrf+n ADCDZDrlOZp7nM56IJI+46rX5HUnfVRufo7FpW2OskLU2RwnKEZvyr7fVYKsXD/sF8uP L2cQ== X-Gm-Message-State: AElRT7FLB6OKtnaBUzs3aj0NtD8tsavEc5LfSjUwUODAitLcvewtk85Q OsYxhmps6k9zfIv5A0CLK/Qo68Tt X-Google-Smtp-Source: AIpwx4+HGpqmJmjoJFSOt5lKsmWuiWtuckKI7hjhNlK7zvcYEs+45SVl9Y9UXvzYrZs7a7zyOq947w== X-Received: by 10.99.188.9 with SMTP id q9mr2123738pge.381.1522512858140; Sat, 31 Mar 2018 09:14:18 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:584d:efc2:e613:bf2? ([2601:647:4700:1280:584d:efc2:e613:bf2]) by smtp.gmail.com with ESMTPSA id t137sm12035034pgc.16.2018.03.31.09.14.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Mar 2018 09:14:16 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <0B93059A-1588-40F2-9825-6D4C94016B80@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B6D15C2-50EB-4BC7-B5EA-4833DFC8C824" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 31 Mar 2018 09:15:35 -0700 In-Reply-To: Cc: Brian Trammell , Nalini Elkins , ippm-chairs@ietf.org, ippm@ietf.org, draft-ietf-ippm-twamp-yang@ietf.org To: Spencer Dawkins References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ippm] AD Evaluation of draft-ietf-ippm-twamp-yang-06 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 16:14:22 -0000 --Apple-Mail=_8B6D15C2-50EB-4BC7-B5EA-4833DFC8C824 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Spencer, > On Mar 30, 2018, at 6:00 AM, Spencer Dawkins = wrote: >=20 > Hi, Manesh, >=20 > I had one point below, but all your other responses will be fine.=20 > Spencer > On 3/29/2018 11:45 PM, Mahesh Jethanandani wrote: >> Spencer, >>=20 >> Let me take a crack at responding to some of the questions you = raised. >>=20 >>=20 >> On 3/29/18 1:44 PM, Spencer Dawkins at IETF wrote: >>> Dear IPPMers, >>>=20 >>> I apologize for a slow AD Evaluation for this draft.=20 >>>=20 >>> In general, I found this document to be pretty clear, and I liked = the multiple levels of detail as a service to readers and implementers. = Thank you for that. >>>=20 >>> I have a decent number of questions, but almost none of them are = technical observations. I'd expect they'd be easy to consider, before I = request IETF Last Call. >>>=20 >>> Please let me know when you're ready to proceed with this draft. >>>=20 >>> Thanks, >>>=20 >>> Spencer >>>=20 >>> In this text, >>>=20 >>> To date, TWAMP implementations do not >>> come with a standard management framework and, as such, = configuration >>> depends on proprietary mechanisms developed by the corresponding >>> TWAMP vendor.=20 >>>=20 >>> is it correct to say that there is no standardized configuration = mechanism for TWAMP, so that implementers have no choice except to = provide proprietary mechanisms? >> Since we are talking both configuration and monitoring, I would = rather say: >>=20 >> To date, TWAMP implementations do not come with a standard management = framework, and, as such, management depends on proprietary mechanism = developed by the corresponding TWAMP vendor. > If this data model is replacing an existing standardized management = framework, I misunderstood. But if it's not replacing an existing = standardized management framework, my point was that >=20 > - there is no existing standardized management framework, so > - if an implementer wants to ship a management framework, it will not = be a standardized framework You are right. We are not replacing an existing standardized management = framework. How does this sound? OLD: To date, TWAMP implementations do not come with a standard management framework and, as such, configuration depends on proprietary mechanisms developed by the corresponding TWAMP vendor. NEW: To date, TWAMP implementations do not come with a standard management framework, and, as such, implementors have no choice except to provide a proprietary mechanism. Cheers >=20 > ;-) >=20 > Do the right thing, of course ;-) >=20 > Spencer >=20 >>>=20 >>> In this text, >>>=20 >>> =46rom an operations >>> perspective, dealing with several vendor-specific TWAMP = configuration >>> mechanisms is simply unsustainable in this context.=20 >>>=20 >>> I'm not sure this is true in all cases, because some people just = keep doing things that cost money and don't make sense. But would it be = correct to say this? >>>=20 >>> =46rom an operations >>> perspective, using several vendor-specific TWAMP configuration >>> mechanisms when one standardized mechanism could provide an = alternative >>> is expensive and inefficient.=20 >> Fair enough. >>>=20 >>> I'm confused by=20 >>>=20 >>> Note to RFC Editor: >>>=20 >>> Please replace the date in the draft of the format 2018-02-13 = with >>> the date of publication of this draft. Also, replace reference = to >>> draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry = with >>> the RFC numbers assigned to the draft. >>>=20 >>> for several reasons.=20 >>>=20 >>> Did you mean "date of publication of this draft", or "date of = publication of this draft as an RFC? >> Yes. >>> Either way, saying "in Section 5.2" is probably helpful for the RFC = Editor. If there's only two, you could put this note in Section 5.2, = which they'd likely appreciate. >> We can do that. >>>=20 >>> Did you mean to replace the draft name that appears in = draft-ietf-ippm-twamp-yang@tools.ietf.org = ? You might consider = using=20 >>> something like RFCXXX, and asking the RFC editor to replace RFCXXX = with the eventual RFC number. >> Ok. >>>=20 >>> I'd say the same thing about draft-ietf-ippm-metric-registry, except = that ISTM that you could just use the existing reference to = [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right = Thing. >>>=20 >>> I note that [I-D.ietf-ippm-metric-registry] is listed as an = Informative reference. Could you understand this draft without reading = [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I = think it might be, the RFC Editor would automatically hold this document = until [I-D.ietf-ippm-metric-registry] is published, and then make the = usual substitutions.=20 >>>=20 >>> Is there a particular reference for UML that you could provide? I = don't happen to have that on my bookshelf. Perhaps other readers would = find it useful, too. >> We can add that. >>>=20 >>> I note at least one use of RFC 2119 language in lower case ("must"). = I'd suggest either shifting any lower-case requirements language to = upper case or using https://tools.ietf.org/html/rfc8174 = for the definition of requirements = language. RFC 2119 was a frequent topic among Gen-ART reviewers when I = was part of the review team. >> There are two lower case "must". These "must" are the normal English = language use of must rather than the RFC 2119 version of must. We will = therefore update section 1.2 with: >>=20 >>=20 >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", >> "MAY", and "OPTIONAL" in this document are to be interpreted as >> described in BCP 14 = [RFC2119 ] [RFC8174 = ] when, and only when, they >> appear in all capitals, as shown here. >>>=20 >>> I'm not questioning this text, >>>=20 >>> If the user has no network access to the Control-Client device, = then >>> the only option is to retrieve all test-session instances from = the >>> Session-Reflector device. This could be problematic if a large >>> number of test sessions are currently active on that device. >>>=20 >>> but I am trying to understand what type of problems you're thinking = of (delays in starting testing from the Control-Client device, because = the Session-Reflector is heavily loaded? Interference with current test = sessions? Or something else), and find myself guessing. >> Good question. I am going to see if one of my co-authors could answer = this question better than me. >>>=20 >>> When I read=20 >>>=20 >>> This section presents a simplified graphical representation of = the >>> TWAMP data model using a YANG tree diagram. Readers should keep = in >>> mind that the limit of 72 characters per line forces us to = introduce >>> artificial line breaks in some tree diagram nodes. >>>=20 >>> I'm not sure how I would know which line breaks are artificial. Is = this just about the breaks in the middle of a word on longer lines, so = that the word appears to wrap around to the left side of the page, or = something else?=20 >> It is the latter. Would it help if we actually put a "\" character at = the end of the line to indicate a line break? >>>=20 >>> (As an aside, I haven't done AD evaluations for YANG data models = previously, but this data model doesn't seem to be excessively nested or = to use excessively long names. Perhaps there's a convention that would = indicate continuation more clearly?) >> There isn't a conventions currently. But I have used the "\" = character in some of the other models that I have authored. >>>=20 >>> I found myself wondering if=20 >>>=20 >>> There are a number of nodes defined in this YANG module which are >>> writeable. These data nodes may be considered sensitive and >>> vulnerable to attacks in some network environments. Ability to = write >>> into these nodes without proper protection can have a negative = effect >>> on the devices that support this feature. >>>=20 >>> was understated - when are writeable nodes not "sensitive and = vulnerable to attacks" without "proper protection"? I see=20 >>>=20 >>> The YANG module defined in Section 5 is designed to be accessed, >>> among other protocols, via NETCONF [RFC6241]. Protocols like = NETCONF >>> use a secure transport layer like SSH that is mandatory to = implement. >>>=20 >>> a bit further up the page, but would it make sense to prohibit the = use of a protocol that doesn't have a mandatory-to-implement secure = transport mechanism? This may be well-traveled ground in the YANG = community, so the current text could be fine, but I wanted to ask before = SECDIR reviewers are doing Last Call reviews ... >> We (as in YANG doctors), have gone several rounds with SECDIR on the = language that all YANG modules are supposed to carry as part of Security = Considerations, and this was the language we seem to have agreed upon = and documented in rfc6087bis. That is not to say that they might not = still call it into question. >>=20 >> Cheers. >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_8B6D15C2-50EB-4BC7-B5EA-4833DFC8C824 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Spencer,


On Mar 30, 2018, at 6:00 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

Hi, Manesh,

I had one point below, but all your other responses will be fine.

Spencer

On 3/29/2018 11:45 PM, Mahesh Jethanandani wrote:

Spencer,

Let me take a crack at responding to some of the questions you raised.


On 3/29/18 1:44 PM, Spencer Dawkins at IETF wrote:
Dear IPPMers,

I apologize for a slow AD Evaluation for this draft. 

In general, I found this document to be pretty clear, and I liked the multiple levels of detail as a service to readers and implementers. Thank you for that.

I have a decent number of questions, but almost none of them are technical observations. I'd expect they'd be easy to consider, before I request IETF Last Call.

Please let me know when you're ready to proceed with this draft.

Thanks,

Spencer

In this text,

   To date, TWAMP implementations do not
   come with a standard management framework and, as such, configuration
   depends on proprietary mechanisms developed by the corresponding
   TWAMP vendor. 

is it correct to say that there is no standardized configuration mechanism for TWAMP, so that implementers have no choice except to provide proprietary mechanisms?
Since we are talking both configuration and monitoring, I would rather say:

To date, TWAMP implementations do not come with a standard management framework, and, as such, management depends on proprietary mechanism developed by the corresponding TWAMP vendor.
If this data model is replacing an existing standardized management framework, I misunderstood. But if it's not replacing an existing standardized management framework, my point was that

- there is no existing standardized management framework, so
- if an implementer wants to ship a management framework, it will not be a standardized framework

You are right. We are not replacing an existing standardized management framework.

How does this sound?

OLD:

   To date, TWAMP implementations do not
   come with a standard management framework and, as such, configuration
   depends on proprietary mechanisms developed by the corresponding
   TWAMP vendor.

NEW:

   To date, TWAMP implementations do not
   come with a standard management framework, and, as such, implementors
   have no choice except to provide a proprietary mechanism.

Cheers


;-)

Do the right thing, of course ;-)

Spencer

In this text,

   From an operations
   perspective, dealing with several vendor-specific TWAMP configuration
   mechanisms is simply unsustainable in this context. 

I'm not sure this is true in all cases, because some people just keep doing things that cost money and don't make sense. But would it be correct to say this?

   From an operations
   perspective, using several vendor-specific TWAMP configuration
   mechanisms when one standardized mechanism could provide an alternative
   is expensive and inefficient.
Fair enough.

I'm confused by 

  Note to RFC Editor:

   Please replace the date in the draft of the format 2018-02-13 with
   the date of publication of this draft.  Also, replace reference to
   draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry with
   the RFC numbers assigned to the draft.

for several reasons. 

Did you mean "date of publication of this draft", or "date of publication of this draft as an RFC?
Yes.
Either way, saying "in Section 5.2" is probably helpful for the RFC Editor. If there's only two, you could put this note in Section 5.2, which they'd likely appreciate.
We can do that.

Did you mean to replace the draft name that appears in  draft-ietf-ippm-twamp-yang@tools.ietf.org? You might consider using 
something like RFCXXX, and asking the RFC editor to replace RFCXXX with the eventual RFC number.
Ok.

I'd say the same thing about draft-ietf-ippm-metric-registry, except that ISTM that you could just use the existing reference to [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right Thing.

I note that [I-D.ietf-ippm-metric-registry] is listed as an Informative reference. Could you understand this draft without reading [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I think it might be, the RFC Editor would automatically hold this document until [I-D.ietf-ippm-metric-registry] is published, and then make the usual substitutions. 

Is there a particular reference for UML that you could provide? I don't happen to have that on my bookshelf. Perhaps other readers would find it useful, too.
We can add that.

I note at least one use of RFC 2119 language in lower case ("must"). I'd suggest either shifting any lower-case requirements language to upper case or using https://tools.ietf.org/html/rfc8174 for the definition of requirements language. RFC 2119 was a frequent topic among Gen-ART reviewers when I was part of the review team.
There are two lower case "must". These "must" are the normal English language use of must rather than the RFC 2119 version of must. We will therefore update section 1.2 with:


      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

I'm not questioning this text,

  If the user has no network access to the Control-Client device, then
   the only option is to retrieve all test-session instances from the
   Session-Reflector device.  This could be problematic if a large
   number of test sessions are currently active on that device.

but I am trying to understand what type of problems you're thinking of (delays in starting testing from the Control-Client device, because the Session-Reflector is heavily loaded? Interference with current test sessions? Or something else), and find myself guessing.
Good question. I am going to see if one of my co-authors could answer this question better than me.

When I read 

   This section presents a simplified graphical representation of the
   TWAMP data model using a YANG tree diagram.  Readers should keep in
   mind that the limit of 72 characters per line forces us to introduce
   artificial line breaks in some tree diagram nodes.

I'm not sure how I would know which line breaks are artificial. Is this just about the breaks in the middle of a word on longer lines, so that the word appears to wrap around to the left side of the page, or something else?
It is the latter. Would it help if we actually put a "\" character at the end of the line to indicate a line break?

(As an aside, I haven't done AD evaluations for YANG data models previously, but this data model doesn't seem to be excessively nested or to use excessively long names. Perhaps there's a convention that would indicate continuation more clearly?)
There isn't a conventions currently. But I have used the "\" character in some of the other models that I have authored.

I found myself wondering if 

   There are a number of nodes defined in this YANG module which are
   writeable.  These data nodes may be considered sensitive and
   vulnerable to attacks in some network environments.  Ability to write
   into these nodes without proper protection can have a negative effect
   on the devices that support this feature.

was understated - when are writeable nodes not "sensitive and vulnerable to attacks" without "proper protection"? I see 

  The YANG module defined in Section 5 is designed to be accessed,
   among other protocols, via NETCONF [RFC6241].  Protocols like NETCONF
   use a secure transport layer like SSH that is mandatory to implement.

a bit further up the page, but would it make sense to prohibit the use of a protocol that doesn't have a mandatory-to-implement secure transport mechanism? This may be well-traveled ground in the YANG community, so the current text could be fine, but I wanted to ask before SECDIR reviewers are doing Last Call reviews ...
We (as in YANG doctors), have gone several rounds with SECDIR on the language that all YANG modules are supposed to carry as part of Security Considerations, and this was the language we seem to have agreed upon and documented in rfc6087bis. That is not to say that they might not still call it into question.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com



Mahesh Jethanandani

--Apple-Mail=_8B6D15C2-50EB-4BC7-B5EA-4833DFC8C824-- From nobody Sat Mar 31 14:08:29 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979241241F3; Sat, 31 Mar 2018 14:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LcNVaKVRz-kI; Sat, 31 Mar 2018 14:08:25 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 E3933120227; Sat, 31 Mar 2018 14:08:24 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v68so3932413ywg.13; Sat, 31 Mar 2018 14:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9h2hxcRtXadwf3vUnBvd1Jto7tpHmh6pAWpvt/WDo8Y=; b=e/JoavVKXbVRLA2X800t2JfkYob563WYhWoGJxeCItUftvylW2DWJN6kndljfgkmAi BWNlmZ+BVQIsE1pBLzu1Eq+1HHtkDIHJva+OKdwCBnOltfUSKlr1p1esKYoExGfZlZ4+ VwVnbADH1pnLiq78hYMgKrMDQ/f2DAzhniGS5Klb0rO2FgEM/jmKM1FNI22Oz+/CGVBk yqauZ/624R/2qm7F84iPJ68VHH6etmLnczMoeVWlB7uJs0uZrnmcrRsyqXdbu5wR+1Og YRgx93hCD0MNFklliP+5GmUmM+/ki5nlddSf5IX9HPffi1XzkuxKrqjyFrztQlucuXbD kP7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9h2hxcRtXadwf3vUnBvd1Jto7tpHmh6pAWpvt/WDo8Y=; b=TMIS6UVTqb05lM030cLdIG2RGKiqW0TMsWyH+yoS9aQTa3GwjavO4ZqQYq1d6PeR46 SOCipsaG1LBBphd0NAzv7xXAcdotfw5dgUJLzZGvaMEUykamnTWrG5VJ9KdAt089CrU8 S79JyPxBxYsnpFZVsWkOmhArNJIYyVHHJonwin338hsWluQg49RNIpt1KVtUIntFvpkV +vyYZMDrAWBehTrJs+0I6o9s/14P4Qo++pRWpD82/3k6vMjTTCO5zyzpao/SMHBweTRq EsUxJlLC0VldS9+3AWbD/5PeoO4RNNsQ+ZoNgYBjkAzUjjsqWti6qbUgEDRhR0figfUQ n9uQ== X-Gm-Message-State: AElRT7GyA7j7dgmz8+B1pzkCGdEVr5CH1n8xgJgZ1Iir4JeP6y0/R/Va Z9St4MnuAbGckx8FRHdOwAc2j3UWbqjdwbfLjBM= X-Google-Smtp-Source: AIpwx4+0tnfWoiEFNfqo7zImyzSW1dRhmc7hkTZb50NZ7EQU4NsTFIufbBQnMdiBT4m7IlM7miGU6VpeZPJtHDlRaN4= X-Received: by 10.13.192.198 with SMTP id b189mr2275225ywd.52.1522530503910; Sat, 31 Mar 2018 14:08:23 -0700 (PDT) MIME-Version: 1.0 References: <0B93059A-1588-40F2-9825-6D4C94016B80@gmail.com> In-Reply-To: <0B93059A-1588-40F2-9825-6D4C94016B80@gmail.com> From: Spencer Dawkins at IETF Date: Sat, 31 Mar 2018 21:08:13 +0000 Message-ID: To: Mahesh Jethanandani Cc: Brian Trammell , Nalini Elkins , ippm-chairs@ietf.org, ippm@ietf.org, draft-ietf-ippm-twamp-yang@ietf.org Content-Type: multipart/alternative; boundary="001a114e6f62d86b0f0568bbc1e5" Archived-At: Subject: Re: [ippm] AD Evaluation of draft-ietf-ippm-twamp-yang-06 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 21:08:28 -0000 --001a114e6f62d86b0f0568bbc1e5 Content-Type: text/plain; charset="UTF-8" Hi, Manesh, Top posting - this is close enough for Last Call of your next version. Thanks for the quick responses. Spencer On Sat, Mar 31, 2018, 11:14 Mahesh Jethanandani wrote: > Spencer, > > > On Mar 30, 2018, at 6:00 AM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > > Hi, Manesh, > > I had one point below, but all your other responses will be fine. > > Spencer > On 3/29/2018 11:45 PM, Mahesh Jethanandani wrote: > > Spencer, > > Let me take a crack at responding to some of the questions you raised. > > On 3/29/18 1:44 PM, Spencer Dawkins at IETF wrote: > > Dear IPPMers, > > I apologize for a slow AD Evaluation for this draft. > > In general, I found this document to be pretty clear, and I liked the > multiple levels of detail as a service to readers and implementers. Thank > you for that. > > I have a decent number of questions, but almost none of them are technical > observations. I'd expect they'd be easy to consider, before I request IETF > Last Call. > > Please let me know when you're ready to proceed with this draft. > > Thanks, > > Spencer > > In this text, > > To date, TWAMP implementations do not > come with a standard management framework and, as such, configuration > depends on proprietary mechanisms developed by the corresponding > TWAMP vendor. > > is it correct to say that there is no standardized configuration mechanism > for TWAMP, so that implementers have no choice except to provide > proprietary mechanisms? > > Since we are talking both configuration and monitoring, I would rather say: > > To date, TWAMP implementations do not come with a standard management > framework, and, as such, management depends on proprietary mechanism > developed by the corresponding TWAMP vendor. > > If this data model is replacing an existing standardized management > framework, I misunderstood. But if it's not replacing an existing > standardized management framework, my point was that > > - there is no existing standardized management framework, so > - if an implementer wants to ship a management framework, it will not be a > standardized framework > > > You are right. We are not replacing an existing standardized management > framework. > > How does this sound? > > OLD: > > To date, TWAMP implementations do not > come with a standard management framework and, as such, configuration > depends on proprietary mechanisms developed by the corresponding > TWAMP vendor. > > > NEW: > > To date, TWAMP implementations do not > come with a standard management framework, and, as such, implementors > > have no choice except to provide a proprietary mechanism. > > > Cheers > > > ;-) > > Do the right thing, of course ;-) > > Spencer > > > In this text, > > From an operations > perspective, dealing with several vendor-specific TWAMP configuration > mechanisms is simply unsustainable in this context. > > I'm not sure this is true in all cases, because some people just keep > doing things that cost money and don't make sense. But would it be correct > to say this? > > From an operations > perspective, using several vendor-specific TWAMP configuration > mechanisms when one standardized mechanism could provide an alternative > is expensive and inefficient. > > Fair enough. > > > I'm confused by > > Note to RFC Editor: > > Please replace the date in the draft of the format 2018-02-13 with > the date of publication of this draft. Also, replace reference to > draft-ietf-ippm-twamp-yang, and draft-ietf-ippm-metric-registry with > the RFC numbers assigned to the draft. > > for several reasons. > > Did you mean "date of publication of this draft", or "date of publication > of this draft as an RFC? > > Yes. > > Either way, saying "in Section 5.2" is probably helpful for the RFC > Editor. If there's only two, you could put this note in Section 5.2, which > they'd likely appreciate. > > We can do that. > > > Did you mean to replace the draft name that appears in > draft-ietf-ippm-twamp-yang@tools.ietf.org? You might consider using > something like RFCXXX, and asking the RFC editor to replace RFCXXX with > the eventual RFC number. > > Ok. > > > I'd say the same thing about draft-ietf-ippm-metric-registry, except that > ISTM that you could just use the existing reference to > [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right > Thing. > > I note that [I-D.ietf-ippm-metric-registry] is listed as an Informative > reference. Could you understand this draft without reading > [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I think > it might be, the RFC Editor would automatically hold this document until > [I-D.ietf-ippm-metric-registry] is published, and then make the usual > substitutions. > > Is there a particular reference for UML that you could provide? I don't > happen to have that on my bookshelf. Perhaps other readers would find it > useful, too. > > We can add that. > > > I note at least one use of RFC 2119 language in lower case ("must"). I'd > suggest either shifting any lower-case requirements language to upper case > or using https://tools.ietf.org/html/rfc8174 for the definition of > requirements language. RFC 2119 was a frequent topic among Gen-ART > reviewers when I was part of the review team. > > There are two lower case "must". These "must" are the normal English > language use of must rather than the RFC 2119 version of must. We will > therefore update section 1.2 with: > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > "MAY", and "OPTIONAL" in this document are to be interpreted as > described in BCP 14 [RFC2119 ] [RFC8174 ] when, and only when, they > appear in all capitals, as shown here. > > > I'm not questioning this text, > > If the user has no network access to the Control-Client device, then > the only option is to retrieve all test-session instances from the > Session-Reflector device. This could be problematic if a large > number of test sessions are currently active on that device. > > but I am trying to understand what type of problems you're thinking of > (delays in starting testing from the Control-Client device, because the > Session-Reflector is heavily loaded? Interference with current test > sessions? Or something else), and find myself guessing. > > Good question. I am going to see if one of my co-authors could answer this > question better than me. > > > When I read > > This section presents a simplified graphical representation of the > TWAMP data model using a YANG tree diagram. Readers should keep in > mind that the limit of 72 characters per line forces us to introduce > artificial line breaks in some tree diagram nodes. > > I'm not sure how I would know which line breaks are artificial. Is this > just about the breaks in the middle of a word on longer lines, so that the > word appears to wrap around to the left side of the page, or something > else? > > It is the latter. Would it help if we actually put a "\" character at the > end of the line to indicate a line break? > > > (As an aside, I haven't done AD evaluations for YANG data models > previously, but this data model doesn't seem to be excessively nested or to > use excessively long names. Perhaps there's a convention that would > indicate continuation more clearly?) > > There isn't a conventions currently. But I have used the "\" character in > some of the other models that I have authored. > > > I found myself wondering if > > There are a number of nodes defined in this YANG module which are > writeable. These data nodes may be considered sensitive and > vulnerable to attacks in some network environments. Ability to write > into these nodes without proper protection can have a negative effect > on the devices that support this feature. > > was understated - when are writeable nodes not "sensitive and vulnerable > to attacks" without "proper protection"? I see > > The YANG module defined in Section 5 is designed to be accessed, > among other protocols, via NETCONF [RFC6241]. Protocols like NETCONF > use a secure transport layer like SSH that is mandatory to implement. > > a bit further up the page, but would it make sense to prohibit the use of > a protocol that doesn't have a mandatory-to-implement secure transport > mechanism? This may be well-traveled ground in the YANG community, so the > current text could be fine, but I wanted to ask before SECDIR reviewers are > doing Last Call reviews ... > > We (as in YANG doctors), have gone several rounds with SECDIR on the > language that all YANG modules are supposed to carry as part of Security > Considerations, and this was the language we seem to have agreed upon and > documented in rfc6087bis. That is not to say that they might not still call > it into question. > > Cheers. > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > Mahesh Jethanandani > mjethanandani@gmail.com > > --001a114e6f62d86b0f0568bbc1e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Manesh,

Top posting - this is close enough for Last Call of your next ve= rsion.

Thanks for the qu= ick responses.

Spencer
On Sat, Mar = 31, 2018, 11:14 Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Spencer,


On = Mar 30, 2018, at 6:00 AM, Spencer Dawkins <spencerdawkins.iet= f@gmail.com> wrote:

=20 =20 =20

Hi, Manesh,

I had one = point below, but all your other responses will be fine.

Spencer

On 3/29/2018 11:45 PM, Mahesh Jethanandani wrote:

Spencer,

Let me t= ake a crack at responding to some of the questions you raised.


On 3/29/18 1:44 = PM, Spencer Dawkins at IETF wrote:
Dear IPPMers,

I apologize for a slow AD Evaluation for this draft.=C2=A0

In general, I found this document to be pretty clear, and I liked the multiple levels of detail as a service to readers and implementers. Thank you for that.

I have a decent number of questions, but almost none of them are technical observations. I'd expect they'd be easy to consider, before I request IETF Last Call.

Please let me know when you're rea= dy to proceed with this draft.

Thanks,

Spencer

In this text,

=C2=A0 =C2=A0To date, TWAMP implemen= tations do not
=C2=A0 =C2=A0come with a standard ma= nagement framework and, as such, configuration
=C2=A0 =C2=A0depends on proprietary mechanisms developed by the corresponding
=C2=A0 =C2=A0TWAMP vendor.=C2=A0

is it correct to say that there is no standardized configuration mechanism for TWAMP, so that implementers have no choice except to provide proprietary mechanisms?
Since we are talking both configuration and monitoring, I would rather say:

To date, TWAMP implementations do not come with a standard management framework, and, as such, management depends on proprietary mechanism developed by the corresponding TWAMP vendor.
If this data model is replacing an existing standardized management framework, I misunderstood. But if it's not replacing an existing standardized management framework, my point was that

- there is no existing standardized management framework, so
- if an implementer wants to ship a management framework, it will not be a standardized framework

You are right. We are not replacing an existing standardized m= anagement framework.

How does this sound?

OLD:

   To date, TWAMP implementations do not
   come with a standard management framework and, as such, configuration
   depends on proprietary mechanisms developed by the corresponding
   TWAMP vendor.

NEW:

To date, TWA= MP implementations do not come with a standard management framework, and, as such, implementors
   have n=
o choice except to provide a proprietary mechanism.

Cheers


;-)

Do the right thing, of course ;-)

Spencer

In this text,

=C2=A0 =C2=A0From an operations
=C2=A0 =C2=A0perspective, dealing wi= th several vendor-specific TWAMP configuration
=C2=A0 =C2=A0mechanisms is simply unsustainable in this context.=C2=A0

I'm not sure this is true in all cases, because some people just keep doing things that cost money and don't make sense. But would it be correct to say this?

=C2=A0 =C2=A0From an operations
=C2=A0 =C2=A0perspective, using seve= ral vendor-specific TWAMP configuration
=C2=A0 =C2=A0mechanisms when one sta= ndardized mechanism could provide an alternative
=C2=A0 =C2=A0is expensive and ineffi= cient.
Fair enough.

I'm confused by=C2=A0

=C2=A0 Note to RFC Editor:

=C2=A0 =C2=A0Please replace the date= in the draft of the format 2018-02-13 with
=C2=A0 =C2=A0the date of publication= of this draft.=C2=A0 Also, replace reference to
=C2=A0 =C2=A0draft-ietf-ippm-twamp-y= ang, and draft-ietf-ippm-metric-registry with
=C2=A0 =C2=A0the RFC numbers assigne= d to the draft.

for several reasons.=C2=A0

Did you mean "date of publicati= on of this draft", or "date of publication of this dra= ft as an RFC?
Yes.
Either way, saying "in Section = 5.2" is probably helpful for the RFC Editor. If there's only two, you could put this note in Section 5.2, which they'd likely appreciate.
We can do that.

Did you mean to replace the draft name that appears in=C2=A0 draft-ietf-= ippm-twamp-yang@tools.ietf.org? You might consider using=C2=A0
something like RFCXXX, and asking the RFC editor to replace RFCXXX with the eventual RFC number.
Ok.

I'd say the same thing about draft-ietf-ippm-metric-registry, except that ISTM that you could just use the existing reference to [I-D.ietf-ippm-metric-registry], and the RFC editor would Do The Right Thing.

I note that [I-D.ietf-ippm-metric-registry] is listed as an Informative reference. Could you understand this draft without reading [I-D.ietf-ippm-metric-registry]? If that draft is as Normative as I think it might be, the RFC Editor would automatically hold this document until [I-D.ietf-ippm-metric-registry] is published, and then make the usual substitutions.=C2=A0

Is there a particular reference for UML that you could provide? I don't happen to have that o= n my bookshelf. Perhaps other readers would find it useful, too.
We can add that.

I note at least one use of RFC 2119 language in lower case ("must"). I'd suggest ei= ther shifting any lower-case requirements language to upper case or using https://tools.ietf.org/html/rfc8174 for the definition of requirements language. RFC 2119 was a frequent topic among Gen-ART reviewers when I was part of the review team.
There are two lower case "must". These &q= uot;must" are the normal English language use of must rather than the RFC 2119 version of must. We will therefore update section 1.2 with:


     =
 The key words "MUST", "MUST NOT", "REQUIRED"=
, "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMEN=
DED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be =
interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

I'm not questioning this text,

=C2=A0 If the user has no network ac= cess to the Control-Client device, then
=C2=A0 =C2=A0the only option is to r= etrieve all test-session instances from the
=C2=A0 =C2=A0Session-Reflector devic= e.=C2=A0 This could be problematic if a large
=C2=A0 =C2=A0number of test sessions= are currently active on that device.

but I am trying to understand what type of problems you're thinking of (delays in starting testing from the Control-Client device, because the Session-Reflector is heavily loaded? Interference with current test sessions? Or something else), and find myself guessing.
Good question. I am going to see if one of my co-authors could answer this question better than me.

When I read=C2=A0

=C2=A0 =C2=A0This section presents a simplified graphical representation of the
=C2=A0 =C2=A0TWAMP data model using = a YANG tree diagram.=C2=A0 Readers should keep in
=C2=A0 =C2=A0mind that the limit of = 72 characters per line forces us to introduce
=C2=A0 =C2=A0artificial line breaks = in some tree diagram nodes.

I'm not sure how I would know wh= ich line breaks are artificial. Is this just about the breaks in the middle of a word on longer lines, so that the word appears to wrap around to the left side of the page, or something else?
It is the latter. Would it help if we actually put a "\" character at the end of the line to indicate a line= break?

(As an aside, I haven't done AD evaluations for YANG data models previously, but this data model doesn't seem to be excessively nested or to use excessively long names. Perhaps there's a convention that would indicate continuation more clearly?)
There isn't a conventions currently. But I have used the "\" character in some of the other models that I= have authored.

I found myself wondering if=C2=A0

=C2=A0 =C2=A0There are a number of n= odes defined in this YANG module which are
=C2=A0 =C2=A0writeable.=C2=A0 These = data nodes may be considered sensitive and
=C2=A0 =C2=A0vulnerable to attacks i= n some network environments.=C2=A0 Ability to write
=C2=A0 =C2=A0into these nodes withou= t proper protection can have a negative effect
=C2=A0 =C2=A0on the devices that sup= port this feature.

was understated - when are writeable nodes not "sensitive and vulnerable to attacks= " without "proper protection"? I see=C2=A0

=C2=A0 The YANG module defined in Section 5 is designed to be accessed,
=C2=A0 =C2=A0among other protocols, = via NETCONF [RFC6241].=C2=A0 Protocols like NETCONF
=C2=A0 =C2=A0use a secure transport = layer like SSH that is mandatory to implement.

a bit further up the page, but would it make sense to prohibit the use of a protocol that doesn't have a mandatory-to-implement secure transport mechanism? This may be well-traveled ground in the YANG community, so the current text could be fine, but I wanted to ask before SECDIR reviewers are doing Last Call reviews ...
We (as in YANG doctors), have gone several rounds with SECDIR on the language that all YANG modules are supposed to carry as part of Security Considerations, and this was the language we seem to have agreed upon and documented in rfc6087bis. That is not to say that they might not still call it into question.

Cheers.

Mahesh Jethanandani
mjeth= anandani@gmail.com



Mahesh Jethanandani

--001a114e6f62d86b0f0568bbc1e5--