From nobody Tue Apr 4 21:14:29 2017 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 8844D126C25 for ; Tue, 4 Apr 2017 21:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 ptp868AWis6l for ; Tue, 4 Apr 2017 21:14:26 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 83FE9128B4E for ; Tue, 4 Apr 2017 21:14:21 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id r137so325299pfr.3 for ; Tue, 04 Apr 2017 21:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=u0WxwHaxTYMeJYhxxJg+r03S9HjuGW0YHTSypLfhb7M=; b=e9D2/MZUzzDzHO5DpWEh4iTV0mBlr6++5/DuUlaU2e3vOqbwt6LwF3sogwmyeVMtEk KM7kQ7AlqFaIbTv5s2BaW8yl8J/UzGr4biSIWkIFTVNuUx3SCQG2HWkAv2Md2SrBZsNL t0eEXtgc2Es62GhOT5ubuK8tJgYXCZcMuc1qL4Qc6ilZgB+EBv62mvyCnWCIAK8KDqrD S65eAo2CdpNIeNuV3Eqq/mcDcyvxIUYSg/cQZHGCUmy7p9jqOFbnDlbWoJ8zgS8kj71e weeqSiBCsoiqYmDkkUDJEeORpmqUmuwGj0BcLDAJbXimLiNzyOdP69bz3Ha1eYW49pXn m2dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=u0WxwHaxTYMeJYhxxJg+r03S9HjuGW0YHTSypLfhb7M=; b=L95Fg4aYewojWfMBJLv76OuZqyogAE07s89BqLd3eEA2ZibomntAeJTzf5dyc6GD2o s3fOz51m7H6OyTD04yjn5Qza4U91Lmh86KJMHPpTOjtCritTZyPSvCDaBlrDJbn0I7I7 1CyXBL25AvBjgXYmtGkyf2K19b2AuJqNOY4AOwXQmv8znOGHugPAIZrBYxXbUVzyLWwG B90z27q18hGWL+50XQPHQVULLZwxz1wUO4G3IXmjNAWejfcA53zeRfMw5XgSS13DCFay bY5HOYdgKZZBQOZvta976O00UG3IVJTbwUwMx2HmlAIx+2uzhU0zQSKs28bs/i5JX7XX usfQ== X-Gm-Message-State: AFeK/H3cAjB5cbMdnifqrD20yLi1SYR3kdGD88H0RvrgqC2CCf+5qKAlmEGs/EX3HOEN0Q== X-Received: by 10.98.76.140 with SMTP id e12mr26454282pfj.82.1491365660904; Tue, 04 Apr 2017 21:14:20 -0700 (PDT) Received: from DESKTOP125KEKC ([2602:306:3970:94c0:d56a:3183:6545:f51d]) by smtp.gmail.com with ESMTPSA id n65sm8402616pga.8.2017.04.04.21.14.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 21:14:20 -0700 (PDT) From: "ram krishnan" To: , , , Cc: , "'Diego R. Lopez'" Date: Tue, 4 Apr 2017 21:14:18 -0700 Message-ID: <018501d2adc3$192181e0$4b6485a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0186_01D2AD88.6CC39440" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKtlp8exMlZkWlZRyqIgNi66z+swA== Content-Language: en-us Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 05 Apr 2017 04:14:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0186_01D2AD88.6CC39440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Very good in person discussion on the topic of microservices with Frank and its applicability to inband-oam, please see summary and next steps below. IETF 98 NFVRG slides on this topic -- https://www.ietf.org/proceedings/98/slides/slides-98-nfvrg-sessa-01-microser vices-on-the-edge-the-infrastructure-impact-04.pdf -- most relevant would be the slides on HW Acceleration Resource Modelling. A low-latency RDMA based interconnect is critical to the success of microservice based deployments for delivering low-latency services. In this context, in-band monitoring of RDMA based lossless protocols such as RoCE is needed. These lossless protocols use priority flow control (PFC) besides congestion management techniques such as ECN. From an underlay switch monitoring perspective, an important additional data field which would be needed is the switch buffer pool(s) - for example Broadcom Trident family has a single buffer pool whereas the Tomahawk family has multiple buffer pools. In addition, the relation between the buffer pools utilization and queue depth needs to be articulated. Plan is to bring the use case and the relevant data fields in the upcoming version of the draft. Thanks, Ramki Thanks for the suggestions and comments. We've posted a new revision of draft-brockners-inband-oam-data. https://www.ietf.org/id/draft-brockners-inband-oam-data-04.txt includes section 3 on Scope, Applicability, and Assumptions, capturing the discussion we had in the WG meeting and on the list. We've also updated the introduction to refer to RFC7799 and classify in-situ OAM appropriately as hybrid, type-1 OAM. For everyone's benefit, here is a quote of the new section 3: 3. Scope, Applicability, and Assumptions In-situ OAM deployment assumes a set of contraints, requirements, and guiding principles which are described in this section. Scope: This document defines the data fields and associated data types for in-situ OAM. The in-situ OAM data field can be transported by a variety of transport protocols, including NSH, Segment Routing, VXLAN-GPE, Geneve, IPv6, or IPv4. Encapsulation details for these different transport protocols are outside the scope of this document. Deployment domain (or scope) of in-situ OAM deployment: IOAM is a network domain focused feature, with "network domain" being a set of network devices or entities within a single administration. For example, a network domain can include an enterprise campus using physical connections between devices or an overlay network using virtual connections / tunnels for connectivity between said devices. A network domain is defined by its perimiter or edge. The operator of such a domain MUST put provisions in place to ensure that in-situ OAM data stays within the specific domain only (i.e., does not leak beyond the edge) and consider potential impact of IOAM to ECMP processing, path MTU and ICMP message handling. In-situ OAM control points: IOAM data fields are added to or removed from the live user traffic by the devices which form the edge of a domain. Devices within an IOAM domain can update and/or add IOAM data-fields. Domain edge devices can be hosts or network devices. Traffic-sets that in-situ OAM is applied to: IOAM can be deployed on all or only on subsets of the live user traffic. It SHOULD be possible to enable in-situ OAM on a selected set of traffic (e.g., per interface, based on an access control list or flow specification defining a specific set of traffic, etc.) The selected set of traffic can also be all traffic. Encapsulation independence: Data formats for in-situ OAM SHOULD be defined in a transport-independent manner. In-situ OAM applies to a variety of encapsulating protocols. A definition of how IOAM data fields are carried by different transport protocols is outside the scope of this document. Layering: If several encapsulation protocols (e.g., in case of tunneling) are stacked on top of each other, in-situ OAM data-records could be present at every layer. The behavior follows the ships-in- the-night model. Combination with active OAM mechanisms: In-situ OAM SHOULD be usable for active network probing, enabling for example a customized version of traceroute. Decapsulating in-situ OAM nodes may have an ability to send the in-situ OAM information retrieved from the packet back to the source address of the packet or to the encapsulating node. Im-situ OAM implementation: The IOAM data-field definitions take the specifics of devices with hardware data-plane and software data-plane into account. Thoughts/comments? With these changes, are we able to kick-off an adoption call? Thanks, Frank ------=_NextPart_000_0186_01D2AD88.6CC39440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Very =
good in person discussion on the topic of microservices with Frank and =
its applicability to inband-oam, please see summary and next steps =
below. 
 
IETF 98 NFVRG =
slides on this topic -- https://www.ietf.org/proceedings/98/slides/slides-98-nf=
vrg-sessa-01-microservices-on-the-edge-the-infrastructure-impact-04.pdf -– most relevant would be the slides on HW Acceleration =
Resource Modelling. A low-latency RDMA based interconnect is critical to =
the success of microservice based deployments for delivering low-latency =
services. In this context, in-band monitoring of RDMA based lossless =
protocols such as RoCE is needed. These lossless protocols use priority =
flow control (PFC) besides congestion management techniques such as ECN. =
>From an underlay switch monitoring perspective, an important additional =
data field which would be needed is the switch buffer pool(s) – =
for example Broadcom Trident family has a single buffer pool whereas the =
Tomahawk family has multiple buffer pools. In addition, the relation =
between the buffer pools utilization and queue depth needs to be =
articulated.
 
Plan is to =
bring the use case and the relevant data fields in the upcoming version =
of the =
draft.
 
Thanks,
Ramki
 
Thanks=
 for the suggestions and comments. We've posted a new revision of =
draft-brockners-inband-oam-data.
h=
ttps://www.ietf.org/id/draft-brockners-inband-oam-data-04.txt =
includes section 3 on Scope, Applicability, and Assumptions, capturing =
the discussion we had in the WG meeting and on the list. We've also =
updated the introduction to refer to RFC7799 and classify in-situ OAM =
appropriately as hybrid, type-1 =
OAM.
 
For everyone's =
benefit, here is a quote of the new section =
3:
 
3.  Scope, =
Applicability, and =
Assumptions
 
  =
 In-situ OAM deployment assumes a set of contraints, requirements, =
and
   guiding principles which are =
described in this =
section.
 
   =
Scope: This document defines the data fields and associated =
data
   types for in-situ OAM.  The =
in-situ OAM data field can be =
transported
   by a variety of transport =
protocols, including NSH, Segment =
Routing,
   VXLAN-GPE, Geneve, IPv6, or =
IPv4.  Encapsulation details for =
these
   different transport protocols =
are outside the scope of this =
document.
 
   =
Deployment domain (or scope) of in-situ OAM deployment: IOAM is =
a
   network domain focused feature, with =
"network domain" being a set =
of
   network devices or entities within =
a single administration.  For
   =
example, a network domain can include an enterprise campus =
using
   physical connections between =
devices or an overlay network using
   =
virtual connections / tunnels for connectivity between said =
devices.
   A network domain is defined =
by its perimiter or edge.  The =
operator
   of such a domain MUST put =
provisions in place to ensure that =
in-situ
   OAM data stays within the =
specific domain only (i.e., does not =
leak
   beyond the edge) and consider =
potential impact of IOAM to ECMP
   =
processing, path MTU and ICMP message =
handling.
 
   =
In-situ OAM control points: IOAM data fields are added to or =
removed
   from the live user traffic by =
the devices which form the edge of a
   =
domain.  Devices within an IOAM domain can update and/or add =
IOAM
   data-fields.  Domain edge =
devices can be hosts or network =
devices.
 
   =
Traffic-sets that in-situ OAM is applied to: IOAM can be deployed =
on
   all or only on subsets of the live =
user traffic.  It SHOULD be
   =
possible to enable in-situ OAM on a selected set of traffic =
(e.g.,
   per interface, based on an =
access control list or flow =
specification
   defining a specific set =
of traffic, etc.)  The selected set =
of
   traffic can also be all =
traffic.
 
   =
Encapsulation independence: Data formats for in-situ OAM SHOULD =
be
   defined in a transport-independent =
manner.  In-situ OAM applies to a
   =
variety of encapsulating protocols.  A definition of how IOAM =
data
   fields are carried by different =
transport protocols is outside the
   =
scope of this =
document.
 
   =
Layering: If several encapsulation protocols (e.g., in case =
of
   tunneling) are stacked on top of =
each other, in-situ OAM data-records
   =
could be present at every layer.  The behavior follows the =
ships-in-
   the-night =
model.
 
   =
Combination with active OAM mechanisms: In-situ OAM SHOULD be =
usable
   for active network probing, =
enabling for example a customized =
version
   of traceroute.  =
Decapsulating in-situ OAM nodes may have an =
ability
   to send the in-situ OAM =
information retrieved from the packet back =
to
   the source address of the packet or =
to the encapsulating =
node.
 
   =
Im-situ OAM implementation: The IOAM data-field definitions take =
the
   specifics of devices with hardware =
data-plane and software data-plane
   =
into =
account.
 
Thoughts/commen=
ts? With these changes, are we able to kick-off an adoption =
call?
 
Thanks, =
Frank

 

------=_NextPart_000_0186_01D2AD88.6CC39440-- From nobody Thu Apr 6 18:58:45 2017 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 D28E7120724; Thu, 6 Apr 2017 18:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, 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 JJIwMr4pwSRQ; Thu, 6 Apr 2017 18:58:39 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 E429F129551; Thu, 6 Apr 2017 18:58:38 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v371sr3q039972; Thu, 6 Apr 2017 21:58:35 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 29nvgbyt9f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 21:58:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v371wYV0004920; Thu, 6 Apr 2017 21:58:34 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v371wNuq004774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 21:58:26 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 7 Apr 2017 01:58:05 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v371w58T030260; Thu, 6 Apr 2017 20:58:05 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v371vvjW029907; Thu, 6 Apr 2017 20:57:57 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id 4030FEF831; Thu, 6 Apr 2017 21:57:57 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Thu, 6 Apr 2017 21:57:56 -0400 From: "MORTON, ALFRED C (AL)" To: "Frank Brockners (fbrockne)" , "adrian@olddog.co.uk" , "'Brian Trammell (IETF)'" CC: "'IPPM Chairs'" , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ANywb7w7Y7CUWYR5PjBqbNA6GqudOAgAAD3QCAAAfSAIAAIx6AgAA2hgCAAPdoAIAAaFWAgAAcNwD//8lsgIAC5LeAgAnqg5A= Date: Fri, 7 Apr 2017 01:57:55 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F6BD2A@njmtexg5.research.att.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.178.187.36] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-07_01:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704070014 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 07 Apr 2017 01:58:43 -0000 VGhlIG5ldyBTY29wZSsgc2VjdGlvbiBtZWV0cyBteSBuZWVkcywNCml0IHdpbGwgYmUgZ29vZCB0 byBoZWFyIGZyb20gdGhvc2Ugd2hvDQpodW1tZWQgYWdhaW5zdCB0aGlzIHdvcmsuDQoNCkFsDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRnJhbmsgQnJvY2tuZXJzIChm YnJvY2tuZSkgW21haWx0bzpmYnJvY2tuZUBjaXNjby5jb21dDQo+IFNlbnQ6IEZyaWRheSwgTWFy Y2ggMzEsIDIwMTcgMTA6MjggQU0NCj4gVG86IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTsgYWRyaWFu QG9sZGRvZy5jby51azsgJ0JyaWFuIFRyYW1tZWxsIChJRVRGKScNCj4gQ2M6ICdJUFBNIENoYWly cyc7IGlwcG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtpcHBtXSBWb3RlIGF0IElQUE0gc2Vz c2lvbg0KPiANCj4gVGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzLiBXZSd2 ZSBwb3N0ZWQgYSBuZXcgcmV2aXNpb24gb2YNCj4gZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0t ZGF0YS4NCj4gDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19pZF9kcmFmdC0yRGJyb2NrbmVycy0yRGluYmFuZC0y RG9hbS0yRGRhdGEtDQo+IDJEMDQudHh0JmQ9RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1Fp Y3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3Jm09b290U0k5X0NqRUNvbHJoQ0ZLRVZQZzVQ Wjc3DQo+IE5PRU1nenRzRUFJMGtaRncmcz1DNHdTd1ppOGNVbUZmWWpmblVrZkY3cXJKVFFXNWhf U05KZ3Q5R1ctUi1ZJmU9DQo+IGluY2x1ZGVzIHNlY3Rpb24gMyBvbiBTY29wZSwgQXBwbGljYWJp bGl0eSwgYW5kIEFzc3VtcHRpb25zLCBjYXB0dXJpbmcNCj4gdGhlIGRpc2N1c3Npb24gd2UgaGFk IGluIHRoZSBXRyBtZWV0aW5nIGFuZCBvbiB0aGUgbGlzdC4gV2UndmUgYWxzbw0KPiB1cGRhdGVk IHRoZSBpbnRyb2R1Y3Rpb24gdG8gcmVmZXIgdG8gUkZDNzc5OSBhbmQgY2xhc3NpZnkgaW4tc2l0 dSBPQU0NCj4gYXBwcm9wcmlhdGVseSBhcyBoeWJyaWQsIHR5cGUtMSBPQU0uDQo+IA0KPiANCj4g DQo+IEZvciBldmVyeW9uZSdzIGJlbmVmaXQsIGhlcmUgaXMgYSBxdW90ZSBvZiB0aGUgbmV3IHNl Y3Rpb24gMzoNCj4gDQo+IA0KPiANCj4gMy4gIFNjb3BlLCBBcHBsaWNhYmlsaXR5LCBhbmQgQXNz dW1wdGlvbnMNCj4gDQo+IA0KPiANCj4gICAgSW4tc2l0dSBPQU0gZGVwbG95bWVudCBhc3N1bWVz IGEgc2V0IG9mIGNvbnRyYWludHMsIHJlcXVpcmVtZW50cywgYW5kDQo+IA0KPiAgICBndWlkaW5n IHByaW5jaXBsZXMgd2hpY2ggYXJlIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24uDQo+IA0KPiAN Cj4gDQo+ICAgIFNjb3BlOiBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGRhdGEgZmllbGRzIGFu ZCBhc3NvY2lhdGVkIGRhdGENCj4gDQo+ICAgIHR5cGVzIGZvciBpbi1zaXR1IE9BTS4gIFRoZSBp bi1zaXR1IE9BTSBkYXRhIGZpZWxkIGNhbiBiZSB0cmFuc3BvcnRlZA0KPiANCj4gICAgYnkgYSB2 YXJpZXR5IG9mIHRyYW5zcG9ydCBwcm90b2NvbHMsIGluY2x1ZGluZyBOU0gsIFNlZ21lbnQgUm91 dGluZywNCj4gDQo+ICAgIFZYTEFOLUdQRSwgR2VuZXZlLCBJUHY2LCBvciBJUHY0LiAgRW5jYXBz dWxhdGlvbiBkZXRhaWxzIGZvciB0aGVzZQ0KPiANCj4gICAgZGlmZmVyZW50IHRyYW5zcG9ydCBw cm90b2NvbHMgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiAN Cj4gDQo+ICAgIERlcGxveW1lbnQgZG9tYWluIChvciBzY29wZSkgb2YgaW4tc2l0dSBPQU0gZGVw bG95bWVudDogSU9BTSBpcyBhDQo+IA0KPiAgICBuZXR3b3JrIGRvbWFpbiBmb2N1c2VkIGZlYXR1 cmUsIHdpdGggIm5ldHdvcmsgZG9tYWluIiBiZWluZyBhIHNldCBvZg0KPiANCj4gICAgbmV0d29y ayBkZXZpY2VzIG9yIGVudGl0aWVzIHdpdGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGlvbi4gIEZv cg0KPiANCj4gICAgZXhhbXBsZSwgYSBuZXR3b3JrIGRvbWFpbiBjYW4gaW5jbHVkZSBhbiBlbnRl cnByaXNlIGNhbXB1cyB1c2luZw0KPiANCj4gICAgcGh5c2ljYWwgY29ubmVjdGlvbnMgYmV0d2Vl biBkZXZpY2VzIG9yIGFuIG92ZXJsYXkgbmV0d29yayB1c2luZw0KPiANCj4gICAgdmlydHVhbCBj b25uZWN0aW9ucyAvIHR1bm5lbHMgZm9yIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIHNhaWQgZGV2aWNl cy4NCj4gDQo+ICAgIEEgbmV0d29yayBkb21haW4gaXMgZGVmaW5lZCBieSBpdHMgcGVyaW1pdGVy IG9yIGVkZ2UuICBUaGUgb3BlcmF0b3INCj4gDQo+ICAgIG9mIHN1Y2ggYSBkb21haW4gTVVTVCBw dXQgcHJvdmlzaW9ucyBpbiBwbGFjZSB0byBlbnN1cmUgdGhhdCBpbi1zaXR1DQo+IA0KPiAgICBP QU0gZGF0YSBzdGF5cyB3aXRoaW4gdGhlIHNwZWNpZmljIGRvbWFpbiBvbmx5IChpLmUuLCBkb2Vz IG5vdCBsZWFrDQo+IA0KPiAgICBiZXlvbmQgdGhlIGVkZ2UpIGFuZCBjb25zaWRlciBwb3RlbnRp YWwgaW1wYWN0IG9mIElPQU0gdG8gRUNNUA0KPiANCj4gICAgcHJvY2Vzc2luZywgcGF0aCBNVFUg YW5kIElDTVAgbWVzc2FnZSBoYW5kbGluZy4NCj4gDQo+IA0KPiANCj4gICAgSW4tc2l0dSBPQU0g Y29udHJvbCBwb2ludHM6IElPQU0gZGF0YSBmaWVsZHMgYXJlIGFkZGVkIHRvIG9yIHJlbW92ZWQN Cj4gDQo+ICAgIGZyb20gdGhlIGxpdmUgdXNlciB0cmFmZmljIGJ5IHRoZSBkZXZpY2VzIHdoaWNo IGZvcm0gdGhlIGVkZ2Ugb2YgYQ0KPiANCj4gICAgZG9tYWluLiAgRGV2aWNlcyB3aXRoaW4gYW4g SU9BTSBkb21haW4gY2FuIHVwZGF0ZSBhbmQvb3IgYWRkIElPQU0NCj4gDQo+ICAgIGRhdGEtZmll bGRzLiAgRG9tYWluIGVkZ2UgZGV2aWNlcyBjYW4gYmUgaG9zdHMgb3IgbmV0d29yayBkZXZpY2Vz Lg0KPiANCj4gDQo+IA0KPiAgICBUcmFmZmljLXNldHMgdGhhdCBpbi1zaXR1IE9BTSBpcyBhcHBs aWVkIHRvOiBJT0FNIGNhbiBiZSBkZXBsb3llZCBvbg0KPiANCj4gICAgYWxsIG9yIG9ubHkgb24g c3Vic2V0cyBvZiB0aGUgbGl2ZSB1c2VyIHRyYWZmaWMuICBJdCBTSE9VTEQgYmUNCj4gDQo+ICAg IHBvc3NpYmxlIHRvIGVuYWJsZSBpbi1zaXR1IE9BTSBvbiBhIHNlbGVjdGVkIHNldCBvZiB0cmFm ZmljIChlLmcuLA0KPiANCj4gICAgcGVyIGludGVyZmFjZSwgYmFzZWQgb24gYW4gYWNjZXNzIGNv bnRyb2wgbGlzdCBvciBmbG93IHNwZWNpZmljYXRpb24NCj4gDQo+ICAgIGRlZmluaW5nIGEgc3Bl Y2lmaWMgc2V0IG9mIHRyYWZmaWMsIGV0Yy4pICBUaGUgc2VsZWN0ZWQgc2V0IG9mDQo+IA0KPiAg ICB0cmFmZmljIGNhbiBhbHNvIGJlIGFsbCB0cmFmZmljLg0KPiANCj4gDQo+IA0KPiAgICBFbmNh cHN1bGF0aW9uIGluZGVwZW5kZW5jZTogRGF0YSBmb3JtYXRzIGZvciBpbi1zaXR1IE9BTSBTSE9V TEQgYmUNCj4gDQo+ICAgIGRlZmluZWQgaW4gYSB0cmFuc3BvcnQtaW5kZXBlbmRlbnQgbWFubmVy LiAgSW4tc2l0dSBPQU0gYXBwbGllcyB0byBhDQo+IA0KPiAgICB2YXJpZXR5IG9mIGVuY2Fwc3Vs YXRpbmcgcHJvdG9jb2xzLiAgQSBkZWZpbml0aW9uIG9mIGhvdyBJT0FNIGRhdGENCj4gDQo+ICAg IGZpZWxkcyBhcmUgY2FycmllZCBieSBkaWZmZXJlbnQgdHJhbnNwb3J0IHByb3RvY29scyBpcyBv dXRzaWRlIHRoZQ0KPiANCj4gICAgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCj4gDQo+IA0KPiAN Cj4gICAgTGF5ZXJpbmc6IElmIHNldmVyYWwgZW5jYXBzdWxhdGlvbiBwcm90b2NvbHMgKGUuZy4s IGluIGNhc2Ugb2YNCj4gDQo+ICAgIHR1bm5lbGluZykgYXJlIHN0YWNrZWQgb24gdG9wIG9mIGVh Y2ggb3RoZXIsIGluLXNpdHUgT0FNIGRhdGEtcmVjb3Jkcw0KPiANCj4gICAgY291bGQgYmUgcHJl c2VudCBhdCBldmVyeSBsYXllci4gIFRoZSBiZWhhdmlvciBmb2xsb3dzIHRoZSBzaGlwcy1pbi0N Cj4gDQo+ICAgIHRoZS1uaWdodCBtb2RlbC4NCj4gDQo+IA0KPiANCj4gICAgQ29tYmluYXRpb24g d2l0aCBhY3RpdmUgT0FNIG1lY2hhbmlzbXM6IEluLXNpdHUgT0FNIFNIT1VMRCBiZSB1c2FibGUN Cj4gDQo+ICAgIGZvciBhY3RpdmUgbmV0d29yayBwcm9iaW5nLCBlbmFibGluZyBmb3IgZXhhbXBs ZSBhIGN1c3RvbWl6ZWQgdmVyc2lvbg0KPiANCj4gICAgb2YgdHJhY2Vyb3V0ZS4gIERlY2Fwc3Vs YXRpbmcgaW4tc2l0dSBPQU0gbm9kZXMgbWF5IGhhdmUgYW4gYWJpbGl0eQ0KPiANCj4gICAgdG8g c2VuZCB0aGUgaW4tc2l0dSBPQU0gaW5mb3JtYXRpb24gcmV0cmlldmVkIGZyb20gdGhlIHBhY2tl dCBiYWNrIHRvDQo+IA0KPiAgICB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBvciB0 byB0aGUgZW5jYXBzdWxhdGluZyBub2RlLg0KPiANCj4gDQo+IA0KPiAgICBJbS1zaXR1IE9BTSBp bXBsZW1lbnRhdGlvbjogVGhlIElPQU0gZGF0YS1maWVsZCBkZWZpbml0aW9ucyB0YWtlIHRoZQ0K PiANCj4gICAgc3BlY2lmaWNzIG9mIGRldmljZXMgd2l0aCBoYXJkd2FyZSBkYXRhLXBsYW5lIGFu ZCBzb2Z0d2FyZSBkYXRhLXBsYW5lDQo+IA0KPiAgICBpbnRvIGFjY291bnQuDQo+IA0KPiANCj4g DQo+IFRob3VnaHRzL2NvbW1lbnRzPyBXaXRoIHRoZXNlIGNoYW5nZXMsIGFyZSB3ZSBhYmxlIHRv IGtpY2stb2ZmIGFuDQo+IGFkb3B0aW9uIGNhbGw/DQo+IA0KPiANCj4gDQo+IFRoYW5rcywgRnJh bmsNCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gDQo+IEZyb206 IE1PUlRPTiwgQUxGUkVEIEMgKEFMKSBbbWFpbHRvOmFjbW9ydG9uQGF0dC5jb21dDQo+IA0KPiBT ZW50OiBNaXR0d29jaCwgMjkuIE3DpHJ6IDIwMTcgMTg6MTENCj4gDQo+IFRvOiBhZHJpYW5Ab2xk ZG9nLmNvLnVrOyAnQnJpYW4gVHJhbW1lbGwgKElFVEYpJyA8aWV0ZkB0cmFtbWVsbC5jaD47DQo+ IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb20+DQo+IA0KPiBD YzogJ0lQUE0gQ2hhaXJzJyA8aXBwbS1jaGFpcnNAaWV0Zi5vcmc+OyBpcHBtQGlldGYub3JnDQo+ IA0KPiBTdWJqZWN0OiBSRTogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uDQo+IA0KPiANCj4g DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gDQo+ID4gRnJvbTogaXBwbSBbbWFp bHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNCj4g DQo+ID4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyOSwgMjAxNyA1OjMyIFBNDQo+IA0KPiA+IFRv OiAnQnJpYW4gVHJhbW1lbGwgKElFVEYpJzsgJ0ZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpJw0K PiANCj4gPiBDYzogJ0lQUE0gQ2hhaXJzJzsgaXBwbUBpZXRmLm9yZw0KPiANCj4gPiBTdWJqZWN0 OiBSZTogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uDQo+IA0KPiA+DQo+IA0KPiA+ID4gPiBU aGVyZSB3ZXJlIHNldmVyYWwgcXVlc3Rpb25zIHJlbGF0ZWQgdG8gc2NvcGUgYW5kIGFwcGxpY2Fi aWxpdHkgaW4NCj4gDQo+ID4gPiA+IHRoZSBXRw0KPiANCj4gPiA+IGRpc2N1c3Npb24g4oCTIGFu ZCBldmVuIG1vcmUgcmVjZW50bHkgb24gdGhlIGxpc3QuIFRob3NlIGNhbiBlYXNpbHkgYmUNCj4g DQo+ID4gPiBhZGRyZXNzZWQgYnkgYWRkaW5nIHBhcmFncmFwaCBvbiBhcHBsaWNhYmlsaXR5IHRv DQo+IA0KPiA+ID4gZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSDigJMgdGhlcmUgaXNu 4oCZdCBhIG5lZWQgZm9yIGEgZGVkaWNhdGVkDQo+IHJlcXVpcmVtZW50cyBkb2N1bWVudC4NCj4g DQo+ID4gPg0KPiANCj4gPiA+IEkgdGVuZCB0byBhZ3JlZSB3aXRoIHRoaXMsIGFsdGhvdWdoICJh IHBhcmFncmFwaCIgc2VlbXMgYSBsaXR0bGUNCj4gDQo+ID4gPiB0aGluIHRvIG1lLiBJIHRoaW5r IHRoZXJlIHdlcmUgc29tZSB2YWxpZCBwb2ludHMgbWFkZSBpbiB0aGF0DQo+IA0KPiA+ID4gZGlz Y3Vzc2lvbiBhYm91dCB0aGUgc2NvcGUgb2YgdGhlIHByb3Bvc2FsIHRoYXQgc2hvdWxkIGJlIGFk ZHJlc3NlZDoNCj4gDQo+ID4gPiBpcyBJT0FNIG1lYW50IGZvciB1c2UgdHVubmVsLWVuZC0gdG8t dHVubmVsLSBlbmQgZW52aXJvbm1lbnQsDQo+IA0KPiA+ID4gZW5kLWhvc3QtdG8tZW5kLWhvc3Qs IHdpdGhpbiBhIHNpbmdsZSBuZXR3b3JrIGFuZC9vciBhY3Jvc3MgdGhlDQo+IA0KPiA+ID4gSW50 ZXJuZXQuICBXaGF0IEkgd291bGQgc3VnZ2VzdCBpcyBhZGRpbmcgYSBzZWN0aW9uIHRvIHRoZSBk YXRhDQo+IA0KPiA+ID4gbW9kZWwgZHJhZnQgb24gYXBwbGljYWJpbGl0eSBhbmQgYXNzdW1wdGlv bnMgYWJvdXQgdGhlIGVudmlyb25tZW50DQo+IA0KPiA+ID4gLS0gYm90aCBhYm91dCB0aGUgZGV2 aWNlcyBhZGRpbmcgSU9BTSBzaWduYWxzIHRvIHRyYWZmaWMgYXMgd2VsbCBhcw0KPiANCj4gPiA+ IHRob3NlIGNvbnN1bWluZyB0aGVzZSBzaWduYWxzIGZyb20gdGhlIHdpcmUgYW5kIGFuYWx5emlu ZyB0aGVtDQo+IA0KPiA+ID4gKHBvc3NpYmx5IHdpdGggdGhlIGNvb3BlcmF0aW9uIG9mIGRldmlj ZXMgbm90IG9uIHRoZQ0KPiANCj4gPiA+IHdpcmUpIC0tIHN1Ym1pdHRpbmcgYSBuZXcgcmV2aXNp b24sIGFuZCB3ZSBjYW4gcnVuIGEgbW9yZSBmb3JtYWwNCj4gDQo+ID4gPiBhZG9wdGlvbiBjYWxs IG9uIHRoYXQuDQo+IA0KPiA+DQo+IA0KPiA+IEFsdGhvdWdoIEkgd2FzIG9uZSBvZiB0aGUgcGVv cGxlIHJhaXNpbmcgdGhlICJuZWVkIiBmb3IgdGhlIHNjb3BlIGFuZA0KPiANCj4gPiByZXF1aXJl bWVudHMsIEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBsZWFkaW5nIG9uIHdoZXRoZXIgdGhpcyBuZWVk cyB0bw0KPiANCj4gPiBiZSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IG9uIGZvbGRlZCBpbnRvIHRo ZSBkYXRhIGZvcm1hdCBkb2N1bWVudC4gU28NCj4gDQo+ID4gQnJpYW4ncyBwcm9wb3NhbCB3b3Vs ZCB3b3JrIGZvciBtZS4NCj4gDQo+ID4NCj4gDQo+ID4gVGh1cywgSSdkIGxvdmUgdG8gc2VlIHRo aXMgc2NvcGluZyB0ZXh0IGRyYWZ0ZWQgYW5kIGZsb2F0ZWQgdG8gdGhlDQo+IA0KPiA+IGxpc3Qg YXMgYW4gZW1haWwgb3IgaW4gYSByZXZpc2lvbiBvZiB0aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQu DQo+IA0KPiA+DQo+IA0KPiA+IENoZWVycywNCj4gDQo+ID4gQWRyaWFuDQo+IA0KPiBbQUNNXQ0K PiANCj4gDQo+IA0KPiArMSBmb3IgYWRkaW5nIGEgU2NvcGUgc2VjdGlvbiB0bw0KPiANCj4gaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fdG9v bHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGJyb2NrbmVycy0yRGluYmFuZC0yRG9hbS0yRGRhdGEt DQo+IDJEMDImZD1Ed0lHYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtU SWx0VnlEMW9MNzJjQncmbT1vb3RTSTlfQ2pFQ29scmhDRktFVlBnNVBaNzcNCj4gTk9FTWd6dHNF QUkwa1pGdyZzPVNpaTBKdWxTRWNMeWlRYjdFSHNQa0N5LW4tbWs1TS00QkMxcVYweUplMDAmZT0N Cj4gDQo+IA0KPiANCj4gSSBmZWx0IHRoYXQgSSB1bmRlcnN0b29kIHRoZSBzY29wZSBnb2luZyBp bnRvIHRoZSBkaXNjdXNzaW9uIE1vbmRheSBhbmQNCj4gdGhlIGFwcGxpY2FibGUgKHJlc3RyaWN0 ZWQpIGRvbWFpbiAoSSBkaWQgdGhlIGhvbWV3b3JrLCB0aGUgc2luZ2xlIGRyYWZ0DQo+IEZyYW5r IGludHJvZHVjZWQgb24gdGhlIG1haWxpbmcgbGlzdCB3YXMgWzBdICkuDQo+IA0KPiANCj4gDQo+ IFNvbWUgYWRkaXRpb25hbCBxdWVzdGlvbnMgaGF2ZSBiZWVuIHJhaXNlZCAoZS5nLiwgIndoZXJl IHdpbGwgT0FNIGJlDQo+IGluc2VydGVkIGFuZCByZW1vdmVkPyIpIGFuZCBJJ2QgbGlrZSB0byBz ZWUgdGhvc2UgaXRlbXMgc29ydGVkLW91dA0KPiBiZWZvcmUgd2UgZ28gdmVyeSBmYXIgKHRoZSBh ZHZhbnRhZ2Ugb2Ygd2lkZXIgcmV2aWV3KS4NCj4gDQo+IA0KPiANCj4gVGhlIHJlcXVpcmVtZW50 cyBkcmFmdCBvbmx5IGNhbWUtdXAgd2hlbiBJIGFza2VkIHNvbWUgcXVlc3Rpb25zIG9uIHRoZQ0K PiBsaXN0LiBGcmFuayBtZW50aW9uZWQgdGhhdCB0aGUgb3VyIGxpc3QgZGlzY3Vzc2lvbiBvbiBl cXVpdmFsZW50DQo+IHRyZWF0bWVudCBvZiBPQU0gJiBub24tT0FNIHBhY2tldHMgKCJjbGFzcyBD Iikgd2FzIGFkZGVkIHRvIHRoZQ0KPiByZXF1aXJlbWVudHMgZG9jdW1lbnQsIGFuZCB0aGF0IHNo b3VsZCBtb3ZlIHRvIC1vYW0tZGF0YS0gdG9vLg0KPiANCj4gDQo+IA0KPiBJdCB3b3VsZCBiZSBn b29kIHRvIGhhdmUgYSB2ZXJzaW9uIG9mIHRoZSBzY29wZSB0byByZXZpZXcgQVNBUC4NCj4gDQo+ IA0KPiANCj4gdGhhbmtzIGFuZCByZWdhcmRzLA0KPiANCj4gQWwNCj4gDQo+IA0KPiANCj4gWzBd IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0Ff X3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRicm9ja25lcnMtMkRpbmJhbmQtMkRvYW0tMkRk YXRhLQ0KPiAyRDAyJmQ9RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNT dThrVElsdFZ5RDFvTDcyY0J3Jm09b290U0k5X0NqRUNvbHJoQ0ZLRVZQZzVQWjc3DQo+IE5PRU1n enRzRUFJMGtaRncmcz1TaWkwSnVsU0VjTHlpUWI3RUhzUGtDeS1uLW1rNU0tNEJDMXFWMHlKZTAw JmU9DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiA+DQo+IA0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiA+IGlwcG0gbWFpbGlu ZyBsaXN0DQo+IA0KPiA+IGlwcG1AaWV0Zi5vcmcNCj4gDQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiANCj4gPiAzQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9faXBwbSZkPUR3SUdhUSZjPUxGWVotDQo+IA0KPiA+IG85X0hVTWVN VFNRaWN2aklnJnI9T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZtPUdhcXVjenRLNTdmVGozdnlZY01u SEc5WUsNCj4gDQo+ID4gTDEgdFZrQVNRNUMzS2g2M29vQSZzPU1lc002QkZaeUVrVlBxc0dxMkhv NExLU19BNG50ZjVYNWhMMFN4MFJzZGMmZT0NCg0K From nobody Thu Apr 6 19:02:57 2017 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 D2FB1120724; Thu, 6 Apr 2017 19:02:53 -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 Q6xq4rWV8Eq0; Thu, 6 Apr 2017 19:02:50 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283AA1294A2; Thu, 6 Apr 2017 19:02:50 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id d2so71758715oig.1; Thu, 06 Apr 2017 19:02:50 -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=meIPStmsxm/eIgyIr0gLk4H2BvWQ4NBueRjSChXQ3v0=; b=HhQt7SVIuQDBo/xF2USUf/ZQGUgsvpAe2qkeM53onjH6pKBFkfbRAvNfAfhDnoqm+Y E40hxniDR2uqsR9g9sdNQJw3FAmyHbVIFUb3fTPh8Jzg1Fht1NH58yEOkHex5qAdINJm tQGEtZJu3TCbQnhPDfP6bpKI4tM8lpGIiDsJ2x7+rSTSBitsAFfu+KUGFq40DKN1m+HL AoqaIpokVPXuXaFPTs3AKQZnq/dKX8V6og9vnXsf0kmx/g4KZevXB+h/r3tMuWMLsGen txH1oPK+NoAXYC5gE2tl/Ea1VL0G1vfk+hfxBCEK1PF1MHIXKeBe6jI9hjRO9dBuWKBY 2mXw== 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=meIPStmsxm/eIgyIr0gLk4H2BvWQ4NBueRjSChXQ3v0=; b=J4j4/H2/vyCguTuA+03/huYDqYi8A8ARAeGsSQUkv/em/uJk0JqifyS5G2eWXmnDzK VtdS1FT5YzhynAPcwOJLV9FfANQuMQN4R1oswJXn/R6OqqosRcuDZf6pyiNGkbPBk8K0 JZXQ6lrAMCTDLXWm4QxTb+jr+tXsdFoR0I40Kyq7KsDiwr4H4WZ0i9fYaTN9fNqbnEiY XyvVkKGOSPP50TX6pHMeQ5D3KLbOdEYVudxIhTl4uqsqqTNON+ZpJW+TnvgsaMPiS7OV tsL8FfbBKz6kWO/ER8ovCt1ziHREGjnwh4RPCe/KRBEwpyimp3BSJMBrfO4nuRzmto62 eh2A== X-Gm-Message-State: AFeK/H2dZK5yQybBBAyRwT+HIBrFmpRZbjE3/o1lstg3Zc0S6/X4pckIxkayp08KizJH0dpA2IiZtO4vFUsoTg== X-Received: by 10.157.39.161 with SMTP id c30mr14939097otb.118.1491530569420; Thu, 06 Apr 2017 19:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Thu, 6 Apr 2017 19:02:48 -0700 (PDT) In-Reply-To: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> From: Greg Mirsky Date: Thu, 6 Apr 2017 19:02:48 -0700 Message-ID: To: "Frank Brockners (fbrockne)" Cc: "MORTON, ALFRED C (AL)" , "adrian@olddog.co.uk" , "Brian Trammell (IETF)" , IPPM Chairs , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c04f8e2c3168c054c8a0505 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 07 Apr 2017 02:02:54 -0000 --94eb2c04f8e2c3168c054c8a0505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Frank, thank you for the most expedient update. You've stated: Devices within an IOAM domain can update and/or add IOAM data-fields. Then, correct if I misunderstand, transient nodes in the domain in fact allowed to add data thus enlarging the packet. How the edge would control the packet size? Regards, Greg On Fri, Mar 31, 2017 at 7:27 AM, Frank Brockners (fbrockne) < fbrockne@cisco.com> wrote: > Thanks for the suggestions and comments. We've posted a new revision of > draft-brockners-inband-oam-data. > https://www.ietf.org/id/draft-brockners-inband-oam-data-04.txt includes > section 3 on Scope, Applicability, and Assumptions, capturing the > discussion we had in the WG meeting and on the list. We've also updated t= he > introduction to refer to RFC7799 and classify in-situ OAM appropriately a= s > hybrid, type-1 OAM. > > For everyone's benefit, here is a quote of the new section 3: > > 3. Scope, Applicability, and Assumptions > > In-situ OAM deployment assumes a set of contraints, requirements, and > guiding principles which are described in this section. > > Scope: This document defines the data fields and associated data > types for in-situ OAM. The in-situ OAM data field can be transported > by a variety of transport protocols, including NSH, Segment Routing, > VXLAN-GPE, Geneve, IPv6, or IPv4. Encapsulation details for these > different transport protocols are outside the scope of this document. > > Deployment domain (or scope) of in-situ OAM deployment: IOAM is a > network domain focused feature, with "network domain" being a set of > network devices or entities within a single administration. For > example, a network domain can include an enterprise campus using > physical connections between devices or an overlay network using > virtual connections / tunnels for connectivity between said devices. > A network domain is defined by its perimiter or edge. The operator > of such a domain MUST put provisions in place to ensure that in-situ > OAM data stays within the specific domain only (i.e., does not leak > beyond the edge) and consider potential impact of IOAM to ECMP > processing, path MTU and ICMP message handling. > > In-situ OAM control points: IOAM data fields are added to or removed > from the live user traffic by the devices which form the edge of a > domain. Devices within an IOAM domain can update and/or add IOAM > data-fields. Domain edge devices can be hosts or network devices. > > Traffic-sets that in-situ OAM is applied to: IOAM can be deployed on > all or only on subsets of the live user traffic. It SHOULD be > possible to enable in-situ OAM on a selected set of traffic (e.g., > per interface, based on an access control list or flow specification > defining a specific set of traffic, etc.) The selected set of > traffic can also be all traffic. > > Encapsulation independence: Data formats for in-situ OAM SHOULD be > defined in a transport-independent manner. In-situ OAM applies to a > variety of encapsulating protocols. A definition of how IOAM data > fields are carried by different transport protocols is outside the > scope of this document. > > Layering: If several encapsulation protocols (e.g., in case of > tunneling) are stacked on top of each other, in-situ OAM data-records > could be present at every layer. The behavior follows the ships-in- > the-night model. > > Combination with active OAM mechanisms: In-situ OAM SHOULD be usable > for active network probing, enabling for example a customized version > of traceroute. Decapsulating in-situ OAM nodes may have an ability > to send the in-situ OAM information retrieved from the packet back to > the source address of the packet or to the encapsulating node. > > Im-situ OAM implementation: The IOAM data-field definitions take the > specifics of devices with hardware data-plane and software data-plane > into account. > > Thoughts/comments? With these changes, are we able to kick-off an adoptio= n > call? > > Thanks, Frank > > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Mittwoch, 29. M=C3=A4rz 2017 18:11 > To: adrian@olddog.co.uk; 'Brian Trammell (IETF)' ; > Frank Brockners (fbrockne) > Cc: 'IPPM Chairs' ; ippm@ietf.org > Subject: RE: [ippm] Vote at IPPM session > > > -----Original Message----- > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Wednesday, March 29, 2017 5:32 PM > > To: 'Brian Trammell (IETF)'; 'Frank Brockners (fbrockne)' > > Cc: 'IPPM Chairs'; ippm@ietf.org > > Subject: Re: [ippm] Vote at IPPM session > > > > > > There were several questions related to scope and applicability in > > > > the WG > > > discussion =E2=80=93 and even more recently on the list. Those can ea= sily be > > > addressed by adding paragraph on applicability to > > > draft-brockners-inband-oam-data =E2=80=93 there isn=E2=80=99t a need = for a dedicated > requirements document. > > > > > > I tend to agree with this, although "a paragraph" seems a little > > > thin to me. I think there were some valid points made in that > > > discussion about the scope of the proposal that should be addressed: > > > is IOAM meant for use tunnel-end- to-tunnel- end environment, > > > end-host-to-end-host, within a single network and/or across the > > > Internet. What I would suggest is adding a section to the data > > > model draft on applicability and assumptions about the environment > > > -- both about the devices adding IOAM signals to traffic as well as > > > those consuming these signals from the wire and analyzing them > > > (possibly with the cooperation of devices not on the > > > wire) -- submitting a new revision, and we can run a more formal > > > adoption call on that. > > > > Although I was one of the people raising the "need" for the scope and > > requirements, I don't have a strong leading on whether this needs to > > be in a separate document on folded into the data format document. So > > Brian's proposal would work for me. > > > > Thus, I'd love to see this scoping text drafted and floated to the > > list as an email or in a revision of the data format document. > > > > Cheers, > > Adrian > [ACM] > > +1 for adding a Scope section to > https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 > > I felt that I understood the scope going into the discussion Monday and > the applicable (restricted) domain (I did the homework, the single draft > Frank introduced on the mailing list was [0] ). > > Some additional questions have been raised (e.g., "where will OAM be > inserted and removed?") and I'd like to see those items sorted-out before > we go very far (the advantage of wider review). > > The requirements draft only came-up when I asked some questions on the > list. Frank mentioned that the our list discussion on equivalent treatmen= t > of OAM & non-OAM packets ("class C") was added to the requirements > document, and that should move to -oam-data- too. > > It would be good to have a version of the scope to review ASAP. > > thanks and regards, > Al > > [0] https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 > > > > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIGaQ&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DGaqucztK57fTj3vyYcMnHG= 9YK > > L1 tVkASQ5C3Kh63ooA&s=3DMesM6BFZyEkVPqsGq2Ho4LKS_A4ntf5X5hL0Sx0Rsdc&e= =3D > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --94eb2c04f8e2c3168c054c8a0505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Frank,
thank you for the most expedient update. You= 've stated:
Devices within an IOAM doma= in can update and/or add IOAM=C2=A0= data-fields.
Then= , correct if I misunderstand, transient nodes in the domain in fact allowed= to add data thus enlarging the packet. How the edge would control the pack= et size?

= Regards,
Greg

On Fri, Mar 31, 2017 at 7:27 AM, Frank Brockners (fb= rockne) <fbrockne@cisco.com> wrote:
Thanks for the suggestions and comments. We've posted a n= ew revision of draft-brockners-inband-oam-data.
https://www.ietf.org/id/draft-bro= ckners-inband-oam-data-04.txt includes section 3 on Scope, Applica= bility, and Assumptions, capturing the discussion we had in the WG meeting = and on the list. We've also updated the introduction to refer to RFC779= 9 and classify in-situ OAM appropriately as hybrid, type-1 OAM.

For everyone's benefit, here is a quote of the new section 3:

3.=C2=A0 Scope, Applicability, and Assumptions

=C2=A0 =C2=A0In-situ OAM deployment assumes a set of contraints, requiremen= ts, and
=C2=A0 =C2=A0guiding principles which are described in this section.

=C2=A0 =C2=A0Scope: This document defines the data fields and associated da= ta
=C2=A0 =C2=A0types for in-situ OAM.=C2=A0 The in-situ OAM data field can be= transported
=C2=A0 =C2=A0by a variety of transport protocols, including NSH, Segment Ro= uting,
=C2=A0 =C2=A0VXLAN-GPE, Geneve, IPv6, or IPv4.=C2=A0 Encapsulation details = for these
=C2=A0 =C2=A0different transport protocols are outside the scope of this do= cument.

=C2=A0 =C2=A0Deployment domain (or scope) of in-situ OAM deployment: IOAM i= s a
=C2=A0 =C2=A0network domain focused feature, with "network domain"= ; being a set of
=C2=A0 =C2=A0network devices or entities within a single administration.=C2= =A0 For
=C2=A0 =C2=A0example, a network domain can include an enterprise campus usi= ng
=C2=A0 =C2=A0physical connections between devices or an ov= erlay network using
=C2=A0 =C2=A0virtual connections / tunnels for connectivity between = said devices.
=C2=A0 =C2=A0A network domain is defined by its perimiter or edge.=C2=A0 Th= e operator
=C2=A0 =C2=A0of such a domain MUST put provisions in place to ensure that i= n-situ
=C2=A0 =C2=A0OAM data stays within the specific domain only (i.e., does not= leak
=C2=A0 =C2=A0beyond the edge) and consider potential impact of IOAM to ECMP=
=C2=A0 =C2=A0processing, path MTU and ICMP message handling.

=C2=A0 =C2=A0In-situ OAM control points: IOAM data fields are added to or r= emoved
=C2=A0 =C2=A0from the live user traffic by the devices which form the edge = of a
=C2=A0 =C2=A0domain.=C2=A0 Devices within an IOAM domain can update and/or = add IOAM
=C2=A0 =C2=A0data-fields.=C2=A0 Domain edge devices can be hosts or network= devices.

=C2=A0 =C2=A0Traffic-sets that in-situ OAM is applied to: IOAM can be deplo= yed on
=C2=A0 =C2=A0all or only on subsets of the live user traffic.=C2=A0 It SHOU= LD be
=C2=A0 =C2=A0possible to enable in-situ OAM on a selected set of traffic (e= .g.,
=C2=A0 =C2=A0per interface, based on an access control list or flow specifi= cation
=C2=A0 =C2=A0defining a specific set of traffic, etc.)=C2=A0 The selected s= et of
=C2=A0 =C2=A0traffic can also be all traffic.

=C2=A0 =C2=A0Encapsulation independence: Data formats for in-situ OAM SHOUL= D be
=C2=A0 =C2=A0defined in a transport-independent manner.=C2=A0 In-situ OAM a= pplies to a
=C2=A0 =C2=A0variety of encapsulating protocols.=C2=A0 A definition of how = IOAM data
=C2=A0 =C2=A0fields are carried by different transport protocols is outside= the
=C2=A0 =C2=A0scope of this document.

=C2=A0 =C2=A0Layering: If several encapsulation protocols (e.g., in case of=
=C2=A0 =C2=A0tunneling) are stacked on top of each other, in-situ OAM data-= records
=C2=A0 =C2=A0could be present at every layer.=C2=A0 The behavior follows th= e ships-in-
=C2=A0 =C2=A0the-night model.

=C2=A0 =C2=A0Combination with active OAM mechanisms: In-situ OAM SHOULD be = usable
=C2=A0 =C2=A0for active network probing, enabling for example a customized = version
=C2=A0 =C2=A0of traceroute.=C2=A0 Decapsulating in-situ OAM nodes may have = an ability
=C2=A0 =C2=A0to send the in-situ OAM information retrieved from the packet = back to
=C2=A0 =C2=A0the source address of the packet or to the encapsulating node.=

=C2=A0 =C2=A0Im-situ OAM implementation: The IOAM data-field definitions ta= ke the
=C2=A0 =C2=A0specifics of devices with hardware data-plane and software dat= a-plane
=C2=A0 =C2=A0into account.

Thoughts/comments? With these changes, are we able to kick-off an adoption = call?

Thanks, Frank

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:acm= orton@att.com]
Sent: Mittwoch, 29. M=C3=A4rz 2017 18:11
To: adrian@olddog.co.uk; 'Br= ian Trammell (IETF)' <ietf@tramm= ell.ch>; Frank Brockners (fbrockne) <fbrockne@cisco.com>
Cc: 'IPPM Chairs' <ippm-= chairs@ietf.org>; ippm@ietf.org=
Subject: RE: [ippm] Vote at IPPM session

> -----Original Message-----
> From: ippm [mailto:ippm-bounc= es@ietf.org] On Behalf Of Adrian Farrel
> Sent: Wednesday, March 29, 2017 5:32 PM
> To: 'Brian Trammell (IETF)'; 'Frank Brockners (fbrockne)&#= 39;
> Cc: 'IPPM Chairs'; ippm@ietf.= org
> Subject: Re: [ippm] Vote at IPPM session
>
> > > There were several questions related to scope and applicabil= ity in
> > > the WG
> > discussion =E2=80=93 and even more recently on the list. Those ca= n easily be
> > addressed by adding paragraph on applicability to
> > draft-brockners-inband-oam-data =E2=80=93 there isn=E2=80=99= t a need for a dedicated requirements document.
> >
> > I tend to agree with this, although "a paragraph" seems= a little
> > thin to me. I think there were some valid points made in that
> > discussion about the scope of the proposal that should be address= ed:
> > is IOAM meant for use tunnel-end- to-tunnel- end environment,
> > end-host-to-end-host, within a single network and/or across the > > Internet.=C2=A0 What I would suggest is adding a section to the d= ata
> > model draft on applicability and assumptions about the environmen= t
> > -- both about the devices adding IOAM signals to traffic as well = as
> > those consuming these signals from the wire and analyzing them > > (possibly with the cooperation of devices not on the
> > wire) -- submitting a new revision, and we can run a more formal<= br> > > adoption call on that.
>
> Although I was one of the people raising the "need" for the = scope and
> requirements, I don't have a strong leading on whether this needs = to
> be in a separate document on folded into the data format document. So<= br> > Brian's proposal would work for me.
>
> Thus, I'd love to see this scoping text drafted and floated to the=
> list as an email or in a revision of the data format document.
>
> Cheers,
> Adrian
[ACM]

+1 for adding a Scope section to
https://tools.ietf.org/html/draft= -brockners-inband-oam-data-02

I felt that I understood the scope going into the discussion Monday and the= applicable (restricted) domain (I did the homework, the single draft Frank= introduced on the mailing list was [0] ).

Some additional questions have been raised (e.g., "where will OAM be i= nserted and removed?") and I'd like to see those items sorted-out = before we go very far (the advantage of wider review).

The requirements draft only came-up when I asked some questions on the list= . Frank mentioned that the our list discussion on equivalent treatment of O= AM & non-OAM packets ("class C") was added to the requirement= s document, and that should move to -oam-data- too.

It would be good to have a version of the scope to review ASAP.

thanks and regards,
Al

[0] https://tools.ietf.org/html/d= raft-brockners-inband-oam-data-02



>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://urldefense.proofpoint.com/v2/ur= l?u=3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIGaQ&c=3DLFY= Z-
> o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DGaq= ucztK57fTj3vyYcMnHG9YK
> L1 tVkASQ5C3Kh63ooA&s=3DMesM6BFZyEkVPqsGq2Ho4LKS_= A4ntf5X5hL0Sx0Rsdc&e=3D
______________________________= _________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

--94eb2c04f8e2c3168c054c8a0505-- From nobody Thu Apr 6 20:01:09 2017 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 48B9E12709D; Thu, 6 Apr 2017 20:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 oHJF09ttyOH4; Thu, 6 Apr 2017 20:01:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F3A127071; Thu, 6 Apr 2017 20:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11664; q=dns/txt; s=iport; t=1491534064; x=1492743664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=79o/Z4tcSoWKKFpQDCbinzaoFSvqY0ld1r2dimv8FZE=; b=LBCiB1Au00EGkVmqRs8O2UQ6LMF1s4NTNJi7y+zum+CYF/1aNnLqTyWT y3ttCd2OzXH8taQcSv3kvGvizr1dD6Z5ZViQkcd6jToxryvY/o/9YE2kf rM1/pDdzypbgUvvAZjYayuTo/nmWwaWvU1XEsz9trJirI8M/R6DDWttFV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQCS/+ZY/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHjXCRQIgajTyCDx8LgkKDNgIagy4/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBASERMwcLBQcEAgEIEQQBAQECAhESAwICAh8GCxQBCAgCBA4FG?= =?us-ascii?q?4lcAw0IDqlbgiaHMw2DNAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQ4IFgmu?= =?us-ascii?q?CUUaBEREBHD+CRy6CMQWJKpMPOwGGfocchDqBfo8/iF+CHYh8AR84fQhbFUERA?= =?us-ascii?q?YRJHYFjdQGHCYEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,162,1488844800"; d="scan'208";a="219513297" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2017 03:01:02 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v37312qc014217 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 03:01:02 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 23:01:01 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 23:01:00 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "Frank Brockners (fbrockne)" , IPPM Chairs , Al Morton , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSqBXsR2UglBUivky7lwWMt8jJvaGsFiIAgABoVYCAABw3AIAAG56AgAKShYCACjAtAIAAEEMA Date: Fri, 7 Apr 2017 03:01:00 +0000 Message-ID: <4E4FA300-FA2D-489C-B1D6-EAF9AB3E4C4B@cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.240.148] Content-Type: text/plain; charset="utf-8" Content-ID: <95F08E94C99E7246A6A94D6A4B09FFE8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 07 Apr 2017 03:01:07 -0000 R3JlZywNCg0KDQo+IE9uIEFwciA2LCAyMDE3LCBhdCAxMDowMiBQTSwgR3JlZyBNaXJza3kgPGdy ZWdpbWlyc2t5QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBGcmFuaywNCj4gdGhhbmsgeW91 IGZvciB0aGUgbW9zdCBleHBlZGllbnQgdXBkYXRlLiBZb3UndmUgc3RhdGVkOg0KPiBEZXZpY2Vz IHdpdGhpbiBhbiBJT0FNIGRvbWFpbiBjYW4gdXBkYXRlIGFuZC9vciBhZGQgSU9BTSBkYXRhLWZp ZWxkcy4NCj4gVGhlbiwgY29ycmVjdCBpZiBJIG1pc3VuZGVyc3RhbmQsIHRyYW5zaWVudCBub2Rl cyBpbiB0aGUgZG9tYWluIGluIGZhY3QgYWxsb3dlZCB0byBhZGQgZGF0YSB0aHVzIGVubGFyZ2lu ZyB0aGUgcGFja2V0LiBIb3cgdGhlIGVkZ2Ugd291bGQgY29udHJvbCB0aGUgcGFja2V0IHNpemU/ DQoNCllvdSBtaXNzZWQgdGhlIHByaW9yIHNlbnRlbmNlIHRoYXQgcmVhZHM6DQoNCiAgYW5kIGNv bnNpZGVyIHBvdGVudGlhbCBpbXBhY3Qgb2YgSU9BTSB0byBFQ01QDQogIHByb2Nlc3NpbmcsIHBh dGggTVRVIGFuZCBJQ01QIG1lc3NhZ2UgaGFuZGxpbmcuDQoNClRoZSBTY29wZSBhbmQgQXBwbGlj YWJpbGl0eSBzZWN0aW9uIHNob3VsZCBub3QgYmUgbXVkZGllZCBhbmQgb3Zlcmx5IGNvbXBsaWNh dGVkIHdpdGggc29sdXRpb25zLiBGb3IgcmVmZXJlbmNlLCB0aGUgLXJlcXVpcmVtZW50cyBkb2N1 bWVudCB0YWxrcyBhYm91dCB0aGlzIHRvcGljIGluIG11Y2ggbW9yZSBkZXRhaWwuDQoNClRoYW5r cywNCg0K4oCUIENhcmxvcy4NCg0KPiANCj4gUmVnYXJkcywNCj4gR3JlZw0KPiANCj4gT24gRnJp LCBNYXIgMzEsIDIwMTcgYXQgNzoyNyBBTSwgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZi cm9ja25lQGNpc2NvLmNvbT4gd3JvdGU6DQo+IFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb25zIGFu ZCBjb21tZW50cy4gV2UndmUgcG9zdGVkIGEgbmV3IHJldmlzaW9uIG9mIGRyYWZ0LWJyb2NrbmVy cy1pbmJhbmQtb2FtLWRhdGEuDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJyb2Nr bmVycy1pbmJhbmQtb2FtLWRhdGEtMDQudHh0IGluY2x1ZGVzIHNlY3Rpb24gMyBvbiBTY29wZSwg QXBwbGljYWJpbGl0eSwgYW5kIEFzc3VtcHRpb25zLCBjYXB0dXJpbmcgdGhlIGRpc2N1c3Npb24g d2UgaGFkIGluIHRoZSBXRyBtZWV0aW5nIGFuZCBvbiB0aGUgbGlzdC4gV2UndmUgYWxzbyB1cGRh dGVkIHRoZSBpbnRyb2R1Y3Rpb24gdG8gcmVmZXIgdG8gUkZDNzc5OSBhbmQgY2xhc3NpZnkgaW4t c2l0dSBPQU0gYXBwcm9wcmlhdGVseSBhcyBoeWJyaWQsIHR5cGUtMSBPQU0uDQo+IA0KPiBGb3Ig ZXZlcnlvbmUncyBiZW5lZml0LCBoZXJlIGlzIGEgcXVvdGUgb2YgdGhlIG5ldyBzZWN0aW9uIDM6 DQo+IA0KPiAzLiAgU2NvcGUsIEFwcGxpY2FiaWxpdHksIGFuZCBBc3N1bXB0aW9ucw0KPiANCj4g ICAgSW4tc2l0dSBPQU0gZGVwbG95bWVudCBhc3N1bWVzIGEgc2V0IG9mIGNvbnRyYWludHMsIHJl cXVpcmVtZW50cywgYW5kDQo+ICAgIGd1aWRpbmcgcHJpbmNpcGxlcyB3aGljaCBhcmUgZGVzY3Jp YmVkIGluIHRoaXMgc2VjdGlvbi4NCj4gDQo+ICAgIFNjb3BlOiBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgdGhlIGRhdGEgZmllbGRzIGFuZCBhc3NvY2lhdGVkIGRhdGENCj4gICAgdHlwZXMgZm9yIGlu LXNpdHUgT0FNLiAgVGhlIGluLXNpdHUgT0FNIGRhdGEgZmllbGQgY2FuIGJlIHRyYW5zcG9ydGVk DQo+ICAgIGJ5IGEgdmFyaWV0eSBvZiB0cmFuc3BvcnQgcHJvdG9jb2xzLCBpbmNsdWRpbmcgTlNI LCBTZWdtZW50IFJvdXRpbmcsDQo+ICAgIFZYTEFOLUdQRSwgR2VuZXZlLCBJUHY2LCBvciBJUHY0 LiAgRW5jYXBzdWxhdGlvbiBkZXRhaWxzIGZvciB0aGVzZQ0KPiAgICBkaWZmZXJlbnQgdHJhbnNw b3J0IHByb3RvY29scyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCj4g DQo+ICAgIERlcGxveW1lbnQgZG9tYWluIChvciBzY29wZSkgb2YgaW4tc2l0dSBPQU0gZGVwbG95 bWVudDogSU9BTSBpcyBhDQo+ICAgIG5ldHdvcmsgZG9tYWluIGZvY3VzZWQgZmVhdHVyZSwgd2l0 aCAibmV0d29yayBkb21haW4iIGJlaW5nIGEgc2V0IG9mDQo+ICAgIG5ldHdvcmsgZGV2aWNlcyBv ciBlbnRpdGllcyB3aXRoaW4gYSBzaW5nbGUgYWRtaW5pc3RyYXRpb24uICBGb3INCj4gICAgZXhh bXBsZSwgYSBuZXR3b3JrIGRvbWFpbiBjYW4gaW5jbHVkZSBhbiBlbnRlcnByaXNlIGNhbXB1cyB1 c2luZw0KPiAgICBwaHlzaWNhbCBjb25uZWN0aW9ucyBiZXR3ZWVuIGRldmljZXMgb3IgYW4gb3Zl cmxheSBuZXR3b3JrIHVzaW5nDQo+ICAgIHZpcnR1YWwgY29ubmVjdGlvbnMgLyB0dW5uZWxzIGZv ciBjb25uZWN0aXZpdHkgYmV0d2VlbiBzYWlkIGRldmljZXMuDQo+ICAgIEEgbmV0d29yayBkb21h aW4gaXMgZGVmaW5lZCBieSBpdHMgcGVyaW1pdGVyIG9yIGVkZ2UuICBUaGUgb3BlcmF0b3INCj4g ICAgb2Ygc3VjaCBhIGRvbWFpbiBNVVNUIHB1dCBwcm92aXNpb25zIGluIHBsYWNlIHRvIGVuc3Vy ZSB0aGF0IGluLXNpdHUNCj4gICAgT0FNIGRhdGEgc3RheXMgd2l0aGluIHRoZSBzcGVjaWZpYyBk b21haW4gb25seSAoaS5lLiwgZG9lcyBub3QgbGVhaw0KPiAgICBiZXlvbmQgdGhlIGVkZ2UpIGFu ZCBjb25zaWRlciBwb3RlbnRpYWwgaW1wYWN0IG9mIElPQU0gdG8gRUNNUA0KPiAgICBwcm9jZXNz aW5nLCBwYXRoIE1UVSBhbmQgSUNNUCBtZXNzYWdlIGhhbmRsaW5nLg0KPiANCj4gICAgSW4tc2l0 dSBPQU0gY29udHJvbCBwb2ludHM6IElPQU0gZGF0YSBmaWVsZHMgYXJlIGFkZGVkIHRvIG9yIHJl bW92ZWQNCj4gICAgZnJvbSB0aGUgbGl2ZSB1c2VyIHRyYWZmaWMgYnkgdGhlIGRldmljZXMgd2hp Y2ggZm9ybSB0aGUgZWRnZSBvZiBhDQo+ICAgIGRvbWFpbi4gIERldmljZXMgd2l0aGluIGFuIElP QU0gZG9tYWluIGNhbiB1cGRhdGUgYW5kL29yIGFkZCBJT0FNDQo+ICAgIGRhdGEtZmllbGRzLiAg RG9tYWluIGVkZ2UgZGV2aWNlcyBjYW4gYmUgaG9zdHMgb3IgbmV0d29yayBkZXZpY2VzLg0KPiAN Cj4gICAgVHJhZmZpYy1zZXRzIHRoYXQgaW4tc2l0dSBPQU0gaXMgYXBwbGllZCB0bzogSU9BTSBj YW4gYmUgZGVwbG95ZWQgb24NCj4gICAgYWxsIG9yIG9ubHkgb24gc3Vic2V0cyBvZiB0aGUgbGl2 ZSB1c2VyIHRyYWZmaWMuICBJdCBTSE9VTEQgYmUNCj4gICAgcG9zc2libGUgdG8gZW5hYmxlIGlu LXNpdHUgT0FNIG9uIGEgc2VsZWN0ZWQgc2V0IG9mIHRyYWZmaWMgKGUuZy4sDQo+ICAgIHBlciBp bnRlcmZhY2UsIGJhc2VkIG9uIGFuIGFjY2VzcyBjb250cm9sIGxpc3Qgb3IgZmxvdyBzcGVjaWZp Y2F0aW9uDQo+ICAgIGRlZmluaW5nIGEgc3BlY2lmaWMgc2V0IG9mIHRyYWZmaWMsIGV0Yy4pICBU aGUgc2VsZWN0ZWQgc2V0IG9mDQo+ICAgIHRyYWZmaWMgY2FuIGFsc28gYmUgYWxsIHRyYWZmaWMu DQo+IA0KPiAgICBFbmNhcHN1bGF0aW9uIGluZGVwZW5kZW5jZTogRGF0YSBmb3JtYXRzIGZvciBp bi1zaXR1IE9BTSBTSE9VTEQgYmUNCj4gICAgZGVmaW5lZCBpbiBhIHRyYW5zcG9ydC1pbmRlcGVu ZGVudCBtYW5uZXIuICBJbi1zaXR1IE9BTSBhcHBsaWVzIHRvIGENCj4gICAgdmFyaWV0eSBvZiBl bmNhcHN1bGF0aW5nIHByb3RvY29scy4gIEEgZGVmaW5pdGlvbiBvZiBob3cgSU9BTSBkYXRhDQo+ ICAgIGZpZWxkcyBhcmUgY2FycmllZCBieSBkaWZmZXJlbnQgdHJhbnNwb3J0IHByb3RvY29scyBp cyBvdXRzaWRlIHRoZQ0KPiAgICBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gICAgTGF5 ZXJpbmc6IElmIHNldmVyYWwgZW5jYXBzdWxhdGlvbiBwcm90b2NvbHMgKGUuZy4sIGluIGNhc2Ug b2YNCj4gICAgdHVubmVsaW5nKSBhcmUgc3RhY2tlZCBvbiB0b3Agb2YgZWFjaCBvdGhlciwgaW4t c2l0dSBPQU0gZGF0YS1yZWNvcmRzDQo+ICAgIGNvdWxkIGJlIHByZXNlbnQgYXQgZXZlcnkgbGF5 ZXIuICBUaGUgYmVoYXZpb3IgZm9sbG93cyB0aGUgc2hpcHMtaW4tDQo+ICAgIHRoZS1uaWdodCBt b2RlbC4NCj4gDQo+ICAgIENvbWJpbmF0aW9uIHdpdGggYWN0aXZlIE9BTSBtZWNoYW5pc21zOiBJ bi1zaXR1IE9BTSBTSE9VTEQgYmUgdXNhYmxlDQo+ICAgIGZvciBhY3RpdmUgbmV0d29yayBwcm9i aW5nLCBlbmFibGluZyBmb3IgZXhhbXBsZSBhIGN1c3RvbWl6ZWQgdmVyc2lvbg0KPiAgICBvZiB0 cmFjZXJvdXRlLiAgRGVjYXBzdWxhdGluZyBpbi1zaXR1IE9BTSBub2RlcyBtYXkgaGF2ZSBhbiBh YmlsaXR5DQo+ICAgIHRvIHNlbmQgdGhlIGluLXNpdHUgT0FNIGluZm9ybWF0aW9uIHJldHJpZXZl ZCBmcm9tIHRoZSBwYWNrZXQgYmFjayB0bw0KPiAgICB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhl IHBhY2tldCBvciB0byB0aGUgZW5jYXBzdWxhdGluZyBub2RlLg0KPiANCj4gICAgSW0tc2l0dSBP QU0gaW1wbGVtZW50YXRpb246IFRoZSBJT0FNIGRhdGEtZmllbGQgZGVmaW5pdGlvbnMgdGFrZSB0 aGUNCj4gICAgc3BlY2lmaWNzIG9mIGRldmljZXMgd2l0aCBoYXJkd2FyZSBkYXRhLXBsYW5lIGFu ZCBzb2Z0d2FyZSBkYXRhLXBsYW5lDQo+ICAgIGludG8gYWNjb3VudC4NCj4gDQo+IFRob3VnaHRz L2NvbW1lbnRzPyBXaXRoIHRoZXNlIGNoYW5nZXMsIGFyZSB3ZSBhYmxlIHRvIGtpY2stb2ZmIGFu IGFkb3B0aW9uIGNhbGw/DQo+IA0KPiBUaGFua3MsIEZyYW5rDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNT1JUT04sIEFMRlJFRCBDIChBTCkgW21haWx0bzphY21v cnRvbkBhdHQuY29tXQ0KPiBTZW50OiBNaXR0d29jaCwgMjkuIE3DpHJ6IDIwMTcgMTg6MTENCj4g VG86IGFkcmlhbkBvbGRkb2cuY28udWs7ICdCcmlhbiBUcmFtbWVsbCAoSUVURiknIDxpZXRmQHRy YW1tZWxsLmNoPjsgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25lQGNpc2NvLmNv bT4NCj4gQ2M6ICdJUFBNIENoYWlycycgPGlwcG0tY2hhaXJzQGlldGYub3JnPjsgaXBwbUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSRTogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uDQo+IA0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogaXBwbSBbbWFpbHRvOmlwcG0t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNCj4gPiBTZW50OiBX ZWRuZXNkYXksIE1hcmNoIDI5LCAyMDE3IDU6MzIgUE0NCj4gPiBUbzogJ0JyaWFuIFRyYW1tZWxs IChJRVRGKSc7ICdGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKScNCj4gPiBDYzogJ0lQUE0gQ2hh aXJzJzsgaXBwbUBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbaXBwbV0gVm90ZSBhdCBJUFBN IHNlc3Npb24NCj4gPg0KPiA+ID4gPiBUaGVyZSB3ZXJlIHNldmVyYWwgcXVlc3Rpb25zIHJlbGF0 ZWQgdG8gc2NvcGUgYW5kIGFwcGxpY2FiaWxpdHkgaW4NCj4gPiA+ID4gdGhlIFdHDQo+ID4gPiBk aXNjdXNzaW9uIOKAkyBhbmQgZXZlbiBtb3JlIHJlY2VudGx5IG9uIHRoZSBsaXN0LiBUaG9zZSBj YW4gZWFzaWx5IGJlDQo+ID4gPiBhZGRyZXNzZWQgYnkgYWRkaW5nIHBhcmFncmFwaCBvbiBhcHBs aWNhYmlsaXR5IHRvDQo+ID4gPiBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhIOKAkyB0 aGVyZSBpc27igJl0IGEgbmVlZCBmb3IgYSBkZWRpY2F0ZWQgcmVxdWlyZW1lbnRzIGRvY3VtZW50 Lg0KPiA+ID4NCj4gPiA+IEkgdGVuZCB0byBhZ3JlZSB3aXRoIHRoaXMsIGFsdGhvdWdoICJhIHBh cmFncmFwaCIgc2VlbXMgYSBsaXR0bGUNCj4gPiA+IHRoaW4gdG8gbWUuIEkgdGhpbmsgdGhlcmUg d2VyZSBzb21lIHZhbGlkIHBvaW50cyBtYWRlIGluIHRoYXQNCj4gPiA+IGRpc2N1c3Npb24gYWJv dXQgdGhlIHNjb3BlIG9mIHRoZSBwcm9wb3NhbCB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQ6DQo+ ID4gPiBpcyBJT0FNIG1lYW50IGZvciB1c2UgdHVubmVsLWVuZC0gdG8tdHVubmVsLSBlbmQgZW52 aXJvbm1lbnQsDQo+ID4gPiBlbmQtaG9zdC10by1lbmQtaG9zdCwgd2l0aGluIGEgc2luZ2xlIG5l dHdvcmsgYW5kL29yIGFjcm9zcyB0aGUNCj4gPiA+IEludGVybmV0LiAgV2hhdCBJIHdvdWxkIHN1 Z2dlc3QgaXMgYWRkaW5nIGEgc2VjdGlvbiB0byB0aGUgZGF0YQ0KPiA+ID4gbW9kZWwgZHJhZnQg b24gYXBwbGljYWJpbGl0eSBhbmQgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGVudmlyb25tZW50DQo+ ID4gPiAtLSBib3RoIGFib3V0IHRoZSBkZXZpY2VzIGFkZGluZyBJT0FNIHNpZ25hbHMgdG8gdHJh ZmZpYyBhcyB3ZWxsIGFzDQo+ID4gPiB0aG9zZSBjb25zdW1pbmcgdGhlc2Ugc2lnbmFscyBmcm9t IHRoZSB3aXJlIGFuZCBhbmFseXppbmcgdGhlbQ0KPiA+ID4gKHBvc3NpYmx5IHdpdGggdGhlIGNv b3BlcmF0aW9uIG9mIGRldmljZXMgbm90IG9uIHRoZQ0KPiA+ID4gd2lyZSkgLS0gc3VibWl0dGlu ZyBhIG5ldyByZXZpc2lvbiwgYW5kIHdlIGNhbiBydW4gYSBtb3JlIGZvcm1hbA0KPiA+ID4gYWRv cHRpb24gY2FsbCBvbiB0aGF0Lg0KPiA+DQo+ID4gQWx0aG91Z2ggSSB3YXMgb25lIG9mIHRoZSBw ZW9wbGUgcmFpc2luZyB0aGUgIm5lZWQiIGZvciB0aGUgc2NvcGUgYW5kDQo+ID4gcmVxdWlyZW1l bnRzLCBJIGRvbid0IGhhdmUgYSBzdHJvbmcgbGVhZGluZyBvbiB3aGV0aGVyIHRoaXMgbmVlZHMg dG8NCj4gPiBiZSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IG9uIGZvbGRlZCBpbnRvIHRoZSBkYXRh IGZvcm1hdCBkb2N1bWVudC4gU28NCj4gPiBCcmlhbidzIHByb3Bvc2FsIHdvdWxkIHdvcmsgZm9y IG1lLg0KPiA+DQo+ID4gVGh1cywgSSdkIGxvdmUgdG8gc2VlIHRoaXMgc2NvcGluZyB0ZXh0IGRy YWZ0ZWQgYW5kIGZsb2F0ZWQgdG8gdGhlDQo+ID4gbGlzdCBhcyBhbiBlbWFpbCBvciBpbiBhIHJl dmlzaW9uIG9mIHRoZSBkYXRhIGZvcm1hdCBkb2N1bWVudC4NCj4gPg0KPiA+IENoZWVycywNCj4g PiBBZHJpYW4NCj4gW0FDTV0NCj4gDQo+ICsxIGZvciBhZGRpbmcgYSBTY29wZSBzZWN0aW9uIHRv DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtaW5iYW5kLW9h bS1kYXRhLTAyDQo+IA0KPiBJIGZlbHQgdGhhdCBJIHVuZGVyc3Rvb2QgdGhlIHNjb3BlIGdvaW5n IGludG8gdGhlIGRpc2N1c3Npb24gTW9uZGF5IGFuZCB0aGUgYXBwbGljYWJsZSAocmVzdHJpY3Rl ZCkgZG9tYWluIChJIGRpZCB0aGUgaG9tZXdvcmssIHRoZSBzaW5nbGUgZHJhZnQgRnJhbmsgaW50 cm9kdWNlZCBvbiB0aGUgbWFpbGluZyBsaXN0IHdhcyBbMF0gKS4NCj4gDQo+IFNvbWUgYWRkaXRp b25hbCBxdWVzdGlvbnMgaGF2ZSBiZWVuIHJhaXNlZCAoZS5nLiwgIndoZXJlIHdpbGwgT0FNIGJl IGluc2VydGVkIGFuZCByZW1vdmVkPyIpIGFuZCBJJ2QgbGlrZSB0byBzZWUgdGhvc2UgaXRlbXMg c29ydGVkLW91dCBiZWZvcmUgd2UgZ28gdmVyeSBmYXIgKHRoZSBhZHZhbnRhZ2Ugb2Ygd2lkZXIg cmV2aWV3KS4NCj4gDQo+IFRoZSByZXF1aXJlbWVudHMgZHJhZnQgb25seSBjYW1lLXVwIHdoZW4g SSBhc2tlZCBzb21lIHF1ZXN0aW9ucyBvbiB0aGUgbGlzdC4gRnJhbmsgbWVudGlvbmVkIHRoYXQg dGhlIG91ciBsaXN0IGRpc2N1c3Npb24gb24gZXF1aXZhbGVudCB0cmVhdG1lbnQgb2YgT0FNICYg bm9uLU9BTSBwYWNrZXRzICgiY2xhc3MgQyIpIHdhcyBhZGRlZCB0byB0aGUgcmVxdWlyZW1lbnRz IGRvY3VtZW50LCBhbmQgdGhhdCBzaG91bGQgbW92ZSB0byAtb2FtLWRhdGEtIHRvby4NCj4gDQo+ IEl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIHZlcnNpb24gb2YgdGhlIHNjb3BlIHRvIHJldmll dyBBU0FQLg0KPiANCj4gdGhhbmtzIGFuZCByZWdhcmRzLA0KPiBBbA0KPiANCj4gWzBdIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhLTAy DQo+IA0KPiANCj4gDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IGlwcG0gbWFpbGluZyBsaXN0DQo+ID4gaXBwbUBpZXRmLm9yZw0K PiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4g PiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faXBwbSZkPUR3SUdhUSZjPUxGWVot DQo+ID4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3Jm09R2FxdWN6 dEs1N2ZUajN2eVljTW5IRzlZSw0KPiA+IEwxIHRWa0FTUTVDM0toNjNvb0Emcz1NZXNNNkJGWnlF a1ZQcXNHcTJIbzRMS1NfQTRudGY1WDVoTDBTeDBSc2RjJmU9DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlw cG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBt DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBpcHBtIG1haWxpbmcgbGlzdA0KPiBpcHBtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KDQo= From nobody Thu Apr 6 20:05:00 2017 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 E3CC8127077; Thu, 6 Apr 2017 20:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 06VR0NfpNgHZ; Thu, 6 Apr 2017 20:04:54 -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 39F511286B1; Thu, 6 Apr 2017 20:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36100; q=dns/txt; s=iport; t=1491534294; x=1492743894; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fppTUFz1K5VGneCnEOgpUt59qwUCtSbIG0T6+06wZU4=; b=bxfrBmU3ywL+lbu4hzzpm8dhRNva/t3rzJ/v9Cz2EygV298dpnTZJAOC dFUJMbWhPwMsmLZNSFamtTGGx6kUeOY1K/qut3LPoAiBoaYlT0c2O/p1p 0hGBlI6gJuSGwdLG5gZbI4rWOAbZ9r41IDEa93eyZ8kqyVm6jjNp8Uv45 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQD5AOdY/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm46K2GBCweNcJFAiBqNPIIPHwEKgkKDNgIagy4/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAgEBASFEBwsFBwQCAQgRAwEBARYLBwMCAgIfBgsUCQgCBAENB?= =?us-ascii?q?Yl3Aw0IDqlpgiYrhwgNgzQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZOggWCa4J?= =?us-ascii?q?RRoEREQE8FgmCRy6CMQWJKoxdhjI7AYZ+hxyEOoF+iiOFHIhfgh2IfAEfOH0IW?= =?us-ascii?q?xVBEQGERgMdgWN1AYcJgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,162,1488844800"; d="scan'208,217";a="405841007" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 03:04:52 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3734qN1019824 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 03:04:52 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 22:04:51 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 22:04:51 -0500 From: "Shwetha Bhandari (shwethab)" To: Greg Mirsky , "Frank Brockners (fbrockne)" CC: IPPM Chairs , "MORTON, ALFRED C (AL)" , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ALR2UglBUivky7lwWMt8jJvaGqypeAgAAD3ACAAAfTAIAAIx6AgAA2hgCAAPdoAIAAaFSAgAAcNwCAABufgIACkoWAgAowLACAAG2HgA== Date: Fri, 7 Apr 2017 03:04:51 +0000 Message-ID: <7BD774C3-9BA2-4B7E-A297-3925AB719DA4@cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.196.84.39] Content-Type: multipart/alternative; boundary="_000_7BD774C39BA24B7EA2973925AB719DA4ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 07 Apr 2017 03:04:59 -0000 --_000_7BD774C39BA24B7EA2973925AB719DA4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KPiB0cmFuc2llbnQgbm9kZXMgaW4gdGhlIGRvbWFpbiBpbiBmYWN0IGFsbG93ZWQg dG8gYWRkIGRhdGEgdGh1cyBlbmxhcmdpbmcgdGhlIHBhY2tldC4gSG93IHRoZSBlZGdlIHdvdWxk IGNvbnRyb2wgdGhlIHBhY2tldCBzaXplPw0KDQoNCg0KSU9BTSBkZWZpbmVkIOKAnEluY3JlbWVu dGFsIFRyYWNlIE9wdGlvbuKAnSBbMV0gYWxsb3dzIGZvciB0cmFuc2llbnQgbm9kZXMgdG8gYWRk IHRoZSB0cmFjZSBkYXRhIHRoZXJlIGJ5IGluY3JlYXNpbmcgdGhlIHBhY2tldCBzaXplLiBUaGUg bWF4aW11bSBzaXplIHRoZSBwYWNrZXQgY2FuIGdyb3cgdG8gaXMgY29udHJvbGxlZCBieSDigJxN YXhpbXVtIExlbmd0aOKAnSBmaWVsZCB3aXRoaW4gdGhpcyBvcHRpb24uDQoNCk1heGltdW0gTGVu Z3RoOiAgOC1iaXQgdW5zaWduZWQgaW50ZWdlci4gIFRoaXMgZmllbGQgc3BlY2lmaWVzIHRoZQ0K ICAgICAgbWF4aW11bSBsZW5ndGggb2YgdGhlIG5vZGUgZGF0YSBsaXN0IGluIG9jdGV0cy4gIEdp dmVuIHRoYXQgdGhlDQogICAgICBzZW5kZXIga25vd3MgdGhlIG1pbmltdW0gcGF0aCBNVFUsIHRo ZSBzZW5kZXIgY2FuIHNldCB0aGUgbWF4aW11bQ0KICAgICAgb2Ygbm9kZSBkYXRhIGJ5dGVzIGFs bG93ZWQgYmVmb3JlIGV4Y2VlZGluZyB0aGUgTVRVLiAgVGh1cywgYQ0KICAgICAgc2ltcGxlIGNv bXBhcmlzb24gYmV0d2VlbiAiT3B0IGRhdGEgTGVuIiBhbmQgIk1heCBMZW5ndGgiIGFsbG93cw0K ICAgICAgdG8gZGVjaWRlIHdoZXRoZXIgb3Igbm90IGRhdGEgY291bGQgYmUgYWRkZWQuDQoNCg0K VGhhbmtzLA0KDQpTaHdldGhhDQoNCg0KDQpbMV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wNC50eHQ6IFNlY3Rpb24gNC4xLjINCg0KRnJv bTogaXBwbSA8aXBwbS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgR3JlZyBNaXJza3kg PGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NCkRhdGU6IEZyaWRheSwgQXByaWwgNywgMjAxNyBhdCA3 OjMyIEFNDQpUbzogIkZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIiA8ZmJyb2NrbmVAY2lzY28u Y29tPg0KQ2M6IElQUE0gQ2hhaXJzIDxpcHBtLWNoYWlyc0BpZXRmLm9yZz4sICJNT1JUT04sIEFM RlJFRCBDIChBTCkiIDxhY21vcnRvbkBhdHQuY29tPiwgImlwcG1AaWV0Zi5vcmciIDxpcHBtQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtpcHBtXSBWb3RlIGF0IElQUE0gc2Vzc2lvbg0KDQpIaSBG cmFuaywNCnRoYW5rIHlvdSBmb3IgdGhlIG1vc3QgZXhwZWRpZW50IHVwZGF0ZS4gWW91J3ZlIHN0 YXRlZDoNCkRldmljZXMgd2l0aGluIGFuIElPQU0gZG9tYWluIGNhbiB1cGRhdGUgYW5kL29yIGFk ZCBJT0FNIGRhdGEtZmllbGRzLg0KVGhlbiwgY29ycmVjdCBpZiBJIG1pc3VuZGVyc3RhbmQsIHRy YW5zaWVudCBub2RlcyBpbiB0aGUgZG9tYWluIGluIGZhY3QgYWxsb3dlZCB0byBhZGQgZGF0YSB0 aHVzIGVubGFyZ2luZyB0aGUgcGFja2V0LiBIb3cgdGhlIGVkZ2Ugd291bGQgY29udHJvbCB0aGUg cGFja2V0IHNpemU/DQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIEZyaSwgTWFyIDMxLCAyMDE3IGF0 IDc6MjcgQU0sIEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb208 bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB0aGUgc3VnZ2Vz dGlvbnMgYW5kIGNvbW1lbnRzLiBXZSd2ZSBwb3N0ZWQgYSBuZXcgcmV2aXNpb24gb2YgZHJhZnQt YnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0 LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDQudHh0IGluY2x1ZGVzIHNlY3Rpb24gMyBvbiBT Y29wZSwgQXBwbGljYWJpbGl0eSwgYW5kIEFzc3VtcHRpb25zLCBjYXB0dXJpbmcgdGhlIGRpc2N1 c3Npb24gd2UgaGFkIGluIHRoZSBXRyBtZWV0aW5nIGFuZCBvbiB0aGUgbGlzdC4gV2UndmUgYWxz byB1cGRhdGVkIHRoZSBpbnRyb2R1Y3Rpb24gdG8gcmVmZXIgdG8gUkZDNzc5OSBhbmQgY2xhc3Np ZnkgaW4tc2l0dSBPQU0gYXBwcm9wcmlhdGVseSBhcyBoeWJyaWQsIHR5cGUtMSBPQU0uDQoNCkZv ciBldmVyeW9uZSdzIGJlbmVmaXQsIGhlcmUgaXMgYSBxdW90ZSBvZiB0aGUgbmV3IHNlY3Rpb24g MzoNCg0KMy4gIFNjb3BlLCBBcHBsaWNhYmlsaXR5LCBhbmQgQXNzdW1wdGlvbnMNCg0KICAgSW4t c2l0dSBPQU0gZGVwbG95bWVudCBhc3N1bWVzIGEgc2V0IG9mIGNvbnRyYWludHMsIHJlcXVpcmVt ZW50cywgYW5kDQogICBndWlkaW5nIHByaW5jaXBsZXMgd2hpY2ggYXJlIGRlc2NyaWJlZCBpbiB0 aGlzIHNlY3Rpb24uDQoNCiAgIFNjb3BlOiBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGRhdGEg ZmllbGRzIGFuZCBhc3NvY2lhdGVkIGRhdGENCiAgIHR5cGVzIGZvciBpbi1zaXR1IE9BTS4gIFRo ZSBpbi1zaXR1IE9BTSBkYXRhIGZpZWxkIGNhbiBiZSB0cmFuc3BvcnRlZA0KICAgYnkgYSB2YXJp ZXR5IG9mIHRyYW5zcG9ydCBwcm90b2NvbHMsIGluY2x1ZGluZyBOU0gsIFNlZ21lbnQgUm91dGlu ZywNCiAgIFZYTEFOLUdQRSwgR2VuZXZlLCBJUHY2LCBvciBJUHY0LiAgRW5jYXBzdWxhdGlvbiBk ZXRhaWxzIGZvciB0aGVzZQ0KICAgZGlmZmVyZW50IHRyYW5zcG9ydCBwcm90b2NvbHMgYXJlIG91 dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIERlcGxveW1lbnQgZG9tYWlu IChvciBzY29wZSkgb2YgaW4tc2l0dSBPQU0gZGVwbG95bWVudDogSU9BTSBpcyBhDQogICBuZXR3 b3JrIGRvbWFpbiBmb2N1c2VkIGZlYXR1cmUsIHdpdGggIm5ldHdvcmsgZG9tYWluIiBiZWluZyBh IHNldCBvZg0KICAgbmV0d29yayBkZXZpY2VzIG9yIGVudGl0aWVzIHdpdGhpbiBhIHNpbmdsZSBh ZG1pbmlzdHJhdGlvbi4gIEZvcg0KICAgZXhhbXBsZSwgYSBuZXR3b3JrIGRvbWFpbiBjYW4gaW5j bHVkZSBhbiBlbnRlcnByaXNlIGNhbXB1cyB1c2luZw0KICAgcGh5c2ljYWwgY29ubmVjdGlvbnMg YmV0d2VlbiBkZXZpY2VzIG9yIGFuIG92ZXJsYXkgbmV0d29yayB1c2luZw0KICAgdmlydHVhbCBj b25uZWN0aW9ucyAvIHR1bm5lbHMgZm9yIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIHNhaWQgZGV2aWNl cy4NCiAgIEEgbmV0d29yayBkb21haW4gaXMgZGVmaW5lZCBieSBpdHMgcGVyaW1pdGVyIG9yIGVk Z2UuICBUaGUgb3BlcmF0b3INCiAgIG9mIHN1Y2ggYSBkb21haW4gTVVTVCBwdXQgcHJvdmlzaW9u cyBpbiBwbGFjZSB0byBlbnN1cmUgdGhhdCBpbi1zaXR1DQogICBPQU0gZGF0YSBzdGF5cyB3aXRo aW4gdGhlIHNwZWNpZmljIGRvbWFpbiBvbmx5IChpLmUuLCBkb2VzIG5vdCBsZWFrDQogICBiZXlv bmQgdGhlIGVkZ2UpIGFuZCBjb25zaWRlciBwb3RlbnRpYWwgaW1wYWN0IG9mIElPQU0gdG8gRUNN UA0KICAgcHJvY2Vzc2luZywgcGF0aCBNVFUgYW5kIElDTVAgbWVzc2FnZSBoYW5kbGluZy4NCg0K ICAgSW4tc2l0dSBPQU0gY29udHJvbCBwb2ludHM6IElPQU0gZGF0YSBmaWVsZHMgYXJlIGFkZGVk IHRvIG9yIHJlbW92ZWQNCiAgIGZyb20gdGhlIGxpdmUgdXNlciB0cmFmZmljIGJ5IHRoZSBkZXZp Y2VzIHdoaWNoIGZvcm0gdGhlIGVkZ2Ugb2YgYQ0KICAgZG9tYWluLiAgRGV2aWNlcyB3aXRoaW4g YW4gSU9BTSBkb21haW4gY2FuIHVwZGF0ZSBhbmQvb3IgYWRkIElPQU0NCiAgIGRhdGEtZmllbGRz LiAgRG9tYWluIGVkZ2UgZGV2aWNlcyBjYW4gYmUgaG9zdHMgb3IgbmV0d29yayBkZXZpY2VzLg0K DQogICBUcmFmZmljLXNldHMgdGhhdCBpbi1zaXR1IE9BTSBpcyBhcHBsaWVkIHRvOiBJT0FNIGNh biBiZSBkZXBsb3llZCBvbg0KICAgYWxsIG9yIG9ubHkgb24gc3Vic2V0cyBvZiB0aGUgbGl2ZSB1 c2VyIHRyYWZmaWMuICBJdCBTSE9VTEQgYmUNCiAgIHBvc3NpYmxlIHRvIGVuYWJsZSBpbi1zaXR1 IE9BTSBvbiBhIHNlbGVjdGVkIHNldCBvZiB0cmFmZmljIChlLmcuLA0KICAgcGVyIGludGVyZmFj ZSwgYmFzZWQgb24gYW4gYWNjZXNzIGNvbnRyb2wgbGlzdCBvciBmbG93IHNwZWNpZmljYXRpb24N CiAgIGRlZmluaW5nIGEgc3BlY2lmaWMgc2V0IG9mIHRyYWZmaWMsIGV0Yy4pICBUaGUgc2VsZWN0 ZWQgc2V0IG9mDQogICB0cmFmZmljIGNhbiBhbHNvIGJlIGFsbCB0cmFmZmljLg0KDQogICBFbmNh cHN1bGF0aW9uIGluZGVwZW5kZW5jZTogRGF0YSBmb3JtYXRzIGZvciBpbi1zaXR1IE9BTSBTSE9V TEQgYmUNCiAgIGRlZmluZWQgaW4gYSB0cmFuc3BvcnQtaW5kZXBlbmRlbnQgbWFubmVyLiAgSW4t c2l0dSBPQU0gYXBwbGllcyB0byBhDQogICB2YXJpZXR5IG9mIGVuY2Fwc3VsYXRpbmcgcHJvdG9j b2xzLiAgQSBkZWZpbml0aW9uIG9mIGhvdyBJT0FNIGRhdGENCiAgIGZpZWxkcyBhcmUgY2Fycmll ZCBieSBkaWZmZXJlbnQgdHJhbnNwb3J0IHByb3RvY29scyBpcyBvdXRzaWRlIHRoZQ0KICAgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgTGF5ZXJpbmc6IElmIHNldmVyYWwgZW5jYXBzdWxh dGlvbiBwcm90b2NvbHMgKGUuZy4sIGluIGNhc2Ugb2YNCiAgIHR1bm5lbGluZykgYXJlIHN0YWNr ZWQgb24gdG9wIG9mIGVhY2ggb3RoZXIsIGluLXNpdHUgT0FNIGRhdGEtcmVjb3Jkcw0KICAgY291 bGQgYmUgcHJlc2VudCBhdCBldmVyeSBsYXllci4gIFRoZSBiZWhhdmlvciBmb2xsb3dzIHRoZSBz aGlwcy1pbi0NCiAgIHRoZS1uaWdodCBtb2RlbC4NCg0KICAgQ29tYmluYXRpb24gd2l0aCBhY3Rp dmUgT0FNIG1lY2hhbmlzbXM6IEluLXNpdHUgT0FNIFNIT1VMRCBiZSB1c2FibGUNCiAgIGZvciBh Y3RpdmUgbmV0d29yayBwcm9iaW5nLCBlbmFibGluZyBmb3IgZXhhbXBsZSBhIGN1c3RvbWl6ZWQg dmVyc2lvbg0KICAgb2YgdHJhY2Vyb3V0ZS4gIERlY2Fwc3VsYXRpbmcgaW4tc2l0dSBPQU0gbm9k ZXMgbWF5IGhhdmUgYW4gYWJpbGl0eQ0KICAgdG8gc2VuZCB0aGUgaW4tc2l0dSBPQU0gaW5mb3Jt YXRpb24gcmV0cmlldmVkIGZyb20gdGhlIHBhY2tldCBiYWNrIHRvDQogICB0aGUgc291cmNlIGFk ZHJlc3Mgb2YgdGhlIHBhY2tldCBvciB0byB0aGUgZW5jYXBzdWxhdGluZyBub2RlLg0KDQogICBJ bS1zaXR1IE9BTSBpbXBsZW1lbnRhdGlvbjogVGhlIElPQU0gZGF0YS1maWVsZCBkZWZpbml0aW9u cyB0YWtlIHRoZQ0KICAgc3BlY2lmaWNzIG9mIGRldmljZXMgd2l0aCBoYXJkd2FyZSBkYXRhLXBs YW5lIGFuZCBzb2Z0d2FyZSBkYXRhLXBsYW5lDQogICBpbnRvIGFjY291bnQuDQoNClRob3VnaHRz L2NvbW1lbnRzPyBXaXRoIHRoZXNlIGNoYW5nZXMsIGFyZSB3ZSBhYmxlIHRvIGtpY2stb2ZmIGFu IGFkb3B0aW9uIGNhbGw/DQoNClRoYW5rcywgRnJhbmsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE1PUlRPTiwgQUxGUkVEIEMgKEFMKSBbbWFpbHRvOmFjbW9ydG9uQGF0dC5j b208bWFpbHRvOmFjbW9ydG9uQGF0dC5jb20+XQ0KU2VudDogTWl0dHdvY2gsIDI5LiBNw6RyeiAy MDE3IDE4OjExDQpUbzogYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5j by51az47ICdCcmlhbiBUcmFtbWVsbCAoSUVURiknIDxpZXRmQHRyYW1tZWxsLmNoPG1haWx0bzpp ZXRmQHRyYW1tZWxsLmNoPj47IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBj aXNjby5jb208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+DQpDYzogJ0lQUE0gQ2hhaXJzJyA8 aXBwbS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmlwcG0tY2hhaXJzQGlldGYub3JnPj47IGlwcG1A aWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW2lwcG1dIFZvdGUg YXQgSVBQTSBzZXNzaW9uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog aXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aXBwbS1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNCj4gU2VudDogV2VkbmVzZGF5LCBN YXJjaCAyOSwgMjAxNyA1OjMyIFBNDQo+IFRvOiAnQnJpYW4gVHJhbW1lbGwgKElFVEYpJzsgJ0Zy YW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpJw0KPiBDYzogJ0lQUE0gQ2hhaXJzJzsgaXBwbUBpZXRm Lm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtpcHBtXSBWb3RlIGF0 IElQUE0gc2Vzc2lvbg0KPg0KPiA+ID4gVGhlcmUgd2VyZSBzZXZlcmFsIHF1ZXN0aW9ucyByZWxh dGVkIHRvIHNjb3BlIGFuZCBhcHBsaWNhYmlsaXR5IGluDQo+ID4gPiB0aGUgV0cNCj4gPiBkaXNj dXNzaW9uIOKAkyBhbmQgZXZlbiBtb3JlIHJlY2VudGx5IG9uIHRoZSBsaXN0LiBUaG9zZSBjYW4g ZWFzaWx5IGJlDQo+ID4gYWRkcmVzc2VkIGJ5IGFkZGluZyBwYXJhZ3JhcGggb24gYXBwbGljYWJp bGl0eSB0bw0KPiA+IGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEg4oCTIHRoZXJlIGlz buKAmXQgYSBuZWVkIGZvciBhIGRlZGljYXRlZCByZXF1aXJlbWVudHMgZG9jdW1lbnQuDQo+ID4N Cj4gPiBJIHRlbmQgdG8gYWdyZWUgd2l0aCB0aGlzLCBhbHRob3VnaCAiYSBwYXJhZ3JhcGgiIHNl ZW1zIGEgbGl0dGxlDQo+ID4gdGhpbiB0byBtZS4gSSB0aGluayB0aGVyZSB3ZXJlIHNvbWUgdmFs aWQgcG9pbnRzIG1hZGUgaW4gdGhhdA0KPiA+IGRpc2N1c3Npb24gYWJvdXQgdGhlIHNjb3BlIG9m IHRoZSBwcm9wb3NhbCB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQ6DQo+ID4gaXMgSU9BTSBtZWFu dCBmb3IgdXNlIHR1bm5lbC1lbmQtIHRvLXR1bm5lbC0gZW5kIGVudmlyb25tZW50LA0KPiA+IGVu ZC1ob3N0LXRvLWVuZC1ob3N0LCB3aXRoaW4gYSBzaW5nbGUgbmV0d29yayBhbmQvb3IgYWNyb3Nz IHRoZQ0KPiA+IEludGVybmV0LiAgV2hhdCBJIHdvdWxkIHN1Z2dlc3QgaXMgYWRkaW5nIGEgc2Vj dGlvbiB0byB0aGUgZGF0YQ0KPiA+IG1vZGVsIGRyYWZ0IG9uIGFwcGxpY2FiaWxpdHkgYW5kIGFz c3VtcHRpb25zIGFib3V0IHRoZSBlbnZpcm9ubWVudA0KPiA+IC0tIGJvdGggYWJvdXQgdGhlIGRl dmljZXMgYWRkaW5nIElPQU0gc2lnbmFscyB0byB0cmFmZmljIGFzIHdlbGwgYXMNCj4gPiB0aG9z ZSBjb25zdW1pbmcgdGhlc2Ugc2lnbmFscyBmcm9tIHRoZSB3aXJlIGFuZCBhbmFseXppbmcgdGhl bQ0KPiA+IChwb3NzaWJseSB3aXRoIHRoZSBjb29wZXJhdGlvbiBvZiBkZXZpY2VzIG5vdCBvbiB0 aGUNCj4gPiB3aXJlKSAtLSBzdWJtaXR0aW5nIGEgbmV3IHJldmlzaW9uLCBhbmQgd2UgY2FuIHJ1 biBhIG1vcmUgZm9ybWFsDQo+ID4gYWRvcHRpb24gY2FsbCBvbiB0aGF0Lg0KPg0KPiBBbHRob3Vn aCBJIHdhcyBvbmUgb2YgdGhlIHBlb3BsZSByYWlzaW5nIHRoZSAibmVlZCIgZm9yIHRoZSBzY29w ZSBhbmQNCj4gcmVxdWlyZW1lbnRzLCBJIGRvbid0IGhhdmUgYSBzdHJvbmcgbGVhZGluZyBvbiB3 aGV0aGVyIHRoaXMgbmVlZHMgdG8NCj4gYmUgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBvbiBmb2xk ZWQgaW50byB0aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQuIFNvDQo+IEJyaWFuJ3MgcHJvcG9zYWwg d291bGQgd29yayBmb3IgbWUuDQo+DQo+IFRodXMsIEknZCBsb3ZlIHRvIHNlZSB0aGlzIHNjb3Bp bmcgdGV4dCBkcmFmdGVkIGFuZCBmbG9hdGVkIHRvIHRoZQ0KPiBsaXN0IGFzIGFuIGVtYWlsIG9y IGluIGEgcmV2aXNpb24gb2YgdGhlIGRhdGEgZm9ybWF0IGRvY3VtZW50Lg0KPg0KPiBDaGVlcnMs DQo+IEFkcmlhbg0KW0FDTV0NCg0KKzEgZm9yIGFkZGluZyBhIFNjb3BlIHNlY3Rpb24gdG8NCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRh LTAyDQoNCkkgZmVsdCB0aGF0IEkgdW5kZXJzdG9vZCB0aGUgc2NvcGUgZ29pbmcgaW50byB0aGUg ZGlzY3Vzc2lvbiBNb25kYXkgYW5kIHRoZSBhcHBsaWNhYmxlIChyZXN0cmljdGVkKSBkb21haW4g KEkgZGlkIHRoZSBob21ld29yaywgdGhlIHNpbmdsZSBkcmFmdCBGcmFuayBpbnRyb2R1Y2VkIG9u IHRoZSBtYWlsaW5nIGxpc3Qgd2FzIFswXSApLg0KDQpTb21lIGFkZGl0aW9uYWwgcXVlc3Rpb25z IGhhdmUgYmVlbiByYWlzZWQgKGUuZy4sICJ3aGVyZSB3aWxsIE9BTSBiZSBpbnNlcnRlZCBhbmQg cmVtb3ZlZD8iKSBhbmQgSSdkIGxpa2UgdG8gc2VlIHRob3NlIGl0ZW1zIHNvcnRlZC1vdXQgYmVm b3JlIHdlIGdvIHZlcnkgZmFyICh0aGUgYWR2YW50YWdlIG9mIHdpZGVyIHJldmlldykuDQoNClRo ZSByZXF1aXJlbWVudHMgZHJhZnQgb25seSBjYW1lLXVwIHdoZW4gSSBhc2tlZCBzb21lIHF1ZXN0 aW9ucyBvbiB0aGUgbGlzdC4gRnJhbmsgbWVudGlvbmVkIHRoYXQgdGhlIG91ciBsaXN0IGRpc2N1 c3Npb24gb24gZXF1aXZhbGVudCB0cmVhdG1lbnQgb2YgT0FNICYgbm9uLU9BTSBwYWNrZXRzICgi Y2xhc3MgQyIpIHdhcyBhZGRlZCB0byB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50LCBhbmQgdGhh dCBzaG91bGQgbW92ZSB0byAtb2FtLWRhdGEtIHRvby4NCg0KSXQgd291bGQgYmUgZ29vZCB0byBo YXZlIGEgdmVyc2lvbiBvZiB0aGUgc2NvcGUgdG8gcmV2aWV3IEFTQVAuDQoNCnRoYW5rcyBhbmQg cmVnYXJkcywNCkFsDQoNClswXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJv Y2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wMg0KDQoNCg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpcHBtIG1haWxpbmcgbGlzdA0KPiBpcHBt QGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KPiBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19pcHBtJmQ9RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNT dThrVElsdFZ5RDFvTDcyY0J3Jm09R2FxdWN6dEs1N2ZUajN2eVljTW5IRzlZSw0KPiBMMSB0VmtB U1E1QzNLaDYzb29BJnM9TWVzTTZCRlp5RWtWUHFzR3EySG80TEtTX0E0bnRmNVg1aEwwU3gwUnNk YyZlPQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlw cG0gbWFpbGluZyBsaXN0DQppcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg== --_000_7BD774C39BA24B7EA2973925AB719DA4ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8D36D47D74481D418C134AC57050E2B2@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJcGFub3NlLTE6MiAy IDUgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9y OnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5HcmVnLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mZ3Q7PC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPg0KdHJhbnNpZW50IG5vZGVzIGluIHRoZSBkb21haW4gaW4gZmFjdCBh bGxvd2VkIHRvIGFkZCBkYXRhIHRodXMgZW5sYXJnaW5nIHRoZSBwYWNrZXQuIEhvdyB0aGUgZWRn ZSB3b3VsZCBjb250cm9sIHRoZSBwYWNrZXQgc2l6ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklPQU0gZGVmaW5l ZCDigJw8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkluY3JlbWVudGFsIFRyYWNlIE9wdGlvbuKA nSBbMV0gYWxsb3dzIGZvciB0cmFuc2llbnQgbm9kZXMgdG8gYWRkIHRoZSB0cmFjZSBkYXRhIHRo ZXJlIGJ5IGluY3JlYXNpbmcgdGhlIHBhY2tldCBzaXplLiBUaGUgbWF4aW11bSBzaXplIHRoZSBw YWNrZXQgY2FuIGdyb3cgdG8gaXMgY29udHJvbGxlZCBieSDigJxNYXhpbXVtIExlbmd0aOKAnSBm aWVsZCB3aXRoaW4gdGhpcyBvcHRpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3ByZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+TWF4aW11bSBMZW5ndGg6Jm5ic3A7IDgtYml0IHVuc2lnbmVkIGludGVnZXIuJm5ic3A7IFRo aXMgZmllbGQgc3BlY2lmaWVzIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgbWF4aW11bSBsZW5ndGggb2YgdGhlIG5vZGUgZGF0YSBsaXN0IGluIG9jdGV0cy4mbmJz cDsgR2l2ZW4gdGhhdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHNlbmRlciBrbm93cyB0aGUgbWluaW11bSBwYXRoIE1UVSwgdGhlIHNlbmRlciBjYW4gc2V0IHRo ZSBtYXhpbXVtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiBub2Rl IGRhdGEgYnl0ZXMgYWxsb3dlZCBiZWZvcmUgZXhjZWVkaW5nIHRoZSBNVFUuJm5ic3A7IFRodXMs IGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpbXBsZSBjb21wYXJp c29uIGJldHdlZW4gJnF1b3Q7T3B0IGRhdGEgTGVuJnF1b3Q7IGFuZCAmcXVvdDtNYXggTGVuZ3Ro JnF1b3Q7IGFsbG93czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8g ZGVjaWRlIHdoZXRoZXIgb3Igbm90IGRhdGEgY291bGQgYmUgYWRkZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5TaHdldGhhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PlsxXSA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1icm9ja25lcnMtaW5i YW5kLW9hbS1kYXRhLTA0LnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYnJvY2tu ZXJzLWluYmFuZC1vYW0tZGF0YS0wNC50eHQ8L2E+OiBTZWN0aW9uIDQuMS4yPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0K PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5pcHBtICZs dDtpcHBtLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBHcmVnIE1pcnNreSAmbHQ7 Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEFwcmls IDcsIDIwMTcgYXQgNzozMiBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7RnJhbmsgQnJvY2tuZXJz IChmYnJvY2tuZSkmcXVvdDsgJmx0O2Zicm9ja25lQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzog PC9iPklQUE0gQ2hhaXJzICZsdDtpcHBtLWNoYWlyc0BpZXRmLm9yZyZndDssICZxdW90O01PUlRP TiwgQUxGUkVEIEMgKEFMKSZxdW90OyAmbHQ7YWNtb3J0b25AYXR0LmNvbSZndDssICZxdW90O2lw cG1AaWV0Zi5vcmcmcXVvdDsgJmx0O2lwcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbaXBwbV0gVm90ZSBhdCBJUFBNIHNlc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEZyYW5rLCA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFuayB5b3UgZm9yIHRoZSBt b3N0IGV4cGVkaWVudCB1cGRhdGUuIFlvdSd2ZSBzdGF0ZWQ6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+RGV2aWNlcyB3aXRoaW4gYW4gSU9BTSBkb21haW4gY2FuIHVwZGF0ZSBhbmQvb3IgYWRk IElPQU0mbmJzcDtkYXRhLWZpZWxkcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPlRoZW4sIGNvcnJlY3QgaWYgSSBtaXN1bmRlcnN0YW5kLCB0cmFuc2llbnQgbm9kZXMg aW4gdGhlIGRvbWFpbiBpbiBmYWN0IGFsbG93ZWQgdG8gYWRkIGRhdGEgdGh1cyBlbmxhcmdpbmcg dGhlIHBhY2tldC4gSG93IHRoZSBlZGdlIHdvdWxkIGNvbnRyb2wgdGhlIHBhY2tldCBzaXplPzwv c3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0Ij5HcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE1hciAzMSwgMjAxNyBhdCA3OjI3IEFNLCBGcmFu ayBCcm9ja25lcnMgKGZicm9ja25lKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZicm9ja25lQGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZicm9ja25lQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBm b3IgdGhlIHN1Z2dlc3Rpb25zIGFuZCBjb21tZW50cy4gV2UndmUgcG9zdGVkIGEgbmV3IHJldmlz aW9uIG9mIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEuPGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wNC50 eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1icm9ja25l cnMtaW5iYW5kLW9hbS1kYXRhLTA0LnR4dDwvYT4gaW5jbHVkZXMgc2VjdGlvbiAzIG9uIFNjb3Bl LCBBcHBsaWNhYmlsaXR5LCBhbmQgQXNzdW1wdGlvbnMsIGNhcHR1cmluZyB0aGUgZGlzY3Vzc2lv biB3ZSBoYWQgaW4gdGhlIFdHDQogbWVldGluZyBhbmQgb24gdGhlIGxpc3QuIFdlJ3ZlIGFsc28g dXBkYXRlZCB0aGUgaW50cm9kdWN0aW9uIHRvIHJlZmVyIHRvIFJGQzc3OTkgYW5kIGNsYXNzaWZ5 IGluLXNpdHUgT0FNIGFwcHJvcHJpYXRlbHkgYXMgaHlicmlkLCB0eXBlLTEgT0FNLjxicj4NCjxi cj4NCkZvciBldmVyeW9uZSdzIGJlbmVmaXQsIGhlcmUgaXMgYSBxdW90ZSBvZiB0aGUgbmV3IHNl Y3Rpb24gMzo8YnI+DQo8YnI+DQozLiZuYnNwOyBTY29wZSwgQXBwbGljYWJpbGl0eSwgYW5kIEFz c3VtcHRpb25zPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0luLXNpdHUgT0FNIGRlcGxveW1lbnQg YXNzdW1lcyBhIHNldCBvZiBjb250cmFpbnRzLCByZXF1aXJlbWVudHMsIGFuZDxicj4NCiZuYnNw OyAmbmJzcDtndWlkaW5nIHByaW5jaXBsZXMgd2hpY2ggYXJlIGRlc2NyaWJlZCBpbiB0aGlzIHNl Y3Rpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1Njb3BlOiBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgdGhlIGRhdGEgZmllbGRzIGFuZCBhc3NvY2lhdGVkIGRhdGE8YnI+DQombmJzcDsgJm5ic3A7 dHlwZXMgZm9yIGluLXNpdHUgT0FNLiZuYnNwOyBUaGUgaW4tc2l0dSBPQU0gZGF0YSBmaWVsZCBj YW4gYmUgdHJhbnNwb3J0ZWQ8YnI+DQombmJzcDsgJm5ic3A7YnkgYSB2YXJpZXR5IG9mIHRyYW5z cG9ydCBwcm90b2NvbHMsIGluY2x1ZGluZyBOU0gsIFNlZ21lbnQgUm91dGluZyw8YnI+DQombmJz cDsgJm5ic3A7VlhMQU4tR1BFLCBHZW5ldmUsIElQdjYsIG9yIElQdjQuJm5ic3A7IEVuY2Fwc3Vs YXRpb24gZGV0YWlscyBmb3IgdGhlc2U8YnI+DQombmJzcDsgJm5ic3A7ZGlmZmVyZW50IHRyYW5z cG9ydCBwcm90b2NvbHMgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwO0RlcGxveW1lbnQgZG9tYWluIChvciBzY29wZSkgb2YgaW4t c2l0dSBPQU0gZGVwbG95bWVudDogSU9BTSBpcyBhPGJyPg0KJm5ic3A7ICZuYnNwO25ldHdvcmsg ZG9tYWluIGZvY3VzZWQgZmVhdHVyZSwgd2l0aCAmcXVvdDtuZXR3b3JrIGRvbWFpbiZxdW90OyBi ZWluZyBhIHNldCBvZjxicj4NCiZuYnNwOyAmbmJzcDtuZXR3b3JrIGRldmljZXMgb3IgZW50aXRp ZXMgd2l0aGluIGEgc2luZ2xlIGFkbWluaXN0cmF0aW9uLiZuYnNwOyBGb3I8YnI+DQombmJzcDsg Jm5ic3A7ZXhhbXBsZSwgYSBuZXR3b3JrIGRvbWFpbiBjYW4gaW5jbHVkZSBhbiBlbnRlcnByaXNl IGNhbXB1cyB1c2luZzxicj4NCiZuYnNwOyAmbmJzcDtwaHlzaWNhbCBjb25uZWN0aW9ucyBiZXR3 ZWVuIGRldmljZXMgb3IgYW4gb3ZlcmxheSBuZXR3b3JrIHVzaW5nPGJyPg0KJm5ic3A7ICZuYnNw O3ZpcnR1YWwgY29ubmVjdGlvbnMgLyB0dW5uZWxzIGZvciBjb25uZWN0aXZpdHkgYmV0d2VlbiBz YWlkIGRldmljZXMuPGJyPg0KJm5ic3A7ICZuYnNwO0EgbmV0d29yayBkb21haW4gaXMgZGVmaW5l ZCBieSBpdHMgcGVyaW1pdGVyIG9yIGVkZ2UuJm5ic3A7IFRoZSBvcGVyYXRvcjxicj4NCiZuYnNw OyAmbmJzcDtvZiBzdWNoIGEgZG9tYWluIE1VU1QgcHV0IHByb3Zpc2lvbnMgaW4gcGxhY2UgdG8g ZW5zdXJlIHRoYXQgaW4tc2l0dTxicj4NCiZuYnNwOyAmbmJzcDtPQU0gZGF0YSBzdGF5cyB3aXRo aW4gdGhlIHNwZWNpZmljIGRvbWFpbiBvbmx5IChpLmUuLCBkb2VzIG5vdCBsZWFrPGJyPg0KJm5i c3A7ICZuYnNwO2JleW9uZCB0aGUgZWRnZSkgYW5kIGNvbnNpZGVyIHBvdGVudGlhbCBpbXBhY3Qg b2YgSU9BTSB0byBFQ01QPGJyPg0KJm5ic3A7ICZuYnNwO3Byb2Nlc3NpbmcsIHBhdGggTVRVIGFu ZCBJQ01QIG1lc3NhZ2UgaGFuZGxpbmcuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0luLXNpdHUg T0FNIGNvbnRyb2wgcG9pbnRzOiBJT0FNIGRhdGEgZmllbGRzIGFyZSBhZGRlZCB0byBvciByZW1v dmVkPGJyPg0KJm5ic3A7ICZuYnNwO2Zyb20gdGhlIGxpdmUgdXNlciB0cmFmZmljIGJ5IHRoZSBk ZXZpY2VzIHdoaWNoIGZvcm0gdGhlIGVkZ2Ugb2YgYTxicj4NCiZuYnNwOyAmbmJzcDtkb21haW4u Jm5ic3A7IERldmljZXMgd2l0aGluIGFuIElPQU0gZG9tYWluIGNhbiB1cGRhdGUgYW5kL29yIGFk ZCBJT0FNPGJyPg0KJm5ic3A7ICZuYnNwO2RhdGEtZmllbGRzLiZuYnNwOyBEb21haW4gZWRnZSBk ZXZpY2VzIGNhbiBiZSBob3N0cyBvciBuZXR3b3JrIGRldmljZXMuPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwO1RyYWZmaWMtc2V0cyB0aGF0IGluLXNpdHUgT0FNIGlzIGFwcGxpZWQgdG86IElPQU0g Y2FuIGJlIGRlcGxveWVkIG9uPGJyPg0KJm5ic3A7ICZuYnNwO2FsbCBvciBvbmx5IG9uIHN1YnNl dHMgb2YgdGhlIGxpdmUgdXNlciB0cmFmZmljLiZuYnNwOyBJdCBTSE9VTEQgYmU8YnI+DQombmJz cDsgJm5ic3A7cG9zc2libGUgdG8gZW5hYmxlIGluLXNpdHUgT0FNIG9uIGEgc2VsZWN0ZWQgc2V0 IG9mIHRyYWZmaWMgKGUuZy4sPGJyPg0KJm5ic3A7ICZuYnNwO3BlciBpbnRlcmZhY2UsIGJhc2Vk IG9uIGFuIGFjY2VzcyBjb250cm9sIGxpc3Qgb3IgZmxvdyBzcGVjaWZpY2F0aW9uPGJyPg0KJm5i c3A7ICZuYnNwO2RlZmluaW5nIGEgc3BlY2lmaWMgc2V0IG9mIHRyYWZmaWMsIGV0Yy4pJm5ic3A7 IFRoZSBzZWxlY3RlZCBzZXQgb2Y8YnI+DQombmJzcDsgJm5ic3A7dHJhZmZpYyBjYW4gYWxzbyBi ZSBhbGwgdHJhZmZpYy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7RW5jYXBzdWxhdGlvbiBpbmRl cGVuZGVuY2U6IERhdGEgZm9ybWF0cyBmb3IgaW4tc2l0dSBPQU0gU0hPVUxEIGJlPGJyPg0KJm5i c3A7ICZuYnNwO2RlZmluZWQgaW4gYSB0cmFuc3BvcnQtaW5kZXBlbmRlbnQgbWFubmVyLiZuYnNw OyBJbi1zaXR1IE9BTSBhcHBsaWVzIHRvIGE8YnI+DQombmJzcDsgJm5ic3A7dmFyaWV0eSBvZiBl bmNhcHN1bGF0aW5nIHByb3RvY29scy4mbmJzcDsgQSBkZWZpbml0aW9uIG9mIGhvdyBJT0FNIGRh dGE8YnI+DQombmJzcDsgJm5ic3A7ZmllbGRzIGFyZSBjYXJyaWVkIGJ5IGRpZmZlcmVudCB0cmFu c3BvcnQgcHJvdG9jb2xzIGlzIG91dHNpZGUgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO3Njb3BlIG9m IHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0xheWVyaW5nOiBJZiBzZXZl cmFsIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2xzIChlLmcuLCBpbiBjYXNlIG9mPGJyPg0KJm5ic3A7 ICZuYnNwO3R1bm5lbGluZykgYXJlIHN0YWNrZWQgb24gdG9wIG9mIGVhY2ggb3RoZXIsIGluLXNp dHUgT0FNIGRhdGEtcmVjb3Jkczxicj4NCiZuYnNwOyAmbmJzcDtjb3VsZCBiZSBwcmVzZW50IGF0 IGV2ZXJ5IGxheWVyLiZuYnNwOyBUaGUgYmVoYXZpb3IgZm9sbG93cyB0aGUgc2hpcHMtaW4tPGJy Pg0KJm5ic3A7ICZuYnNwO3RoZS1uaWdodCBtb2RlbC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 Q29tYmluYXRpb24gd2l0aCBhY3RpdmUgT0FNIG1lY2hhbmlzbXM6IEluLXNpdHUgT0FNIFNIT1VM RCBiZSB1c2FibGU8YnI+DQombmJzcDsgJm5ic3A7Zm9yIGFjdGl2ZSBuZXR3b3JrIHByb2Jpbmcs IGVuYWJsaW5nIGZvciBleGFtcGxlIGEgY3VzdG9taXplZCB2ZXJzaW9uPGJyPg0KJm5ic3A7ICZu YnNwO29mIHRyYWNlcm91dGUuJm5ic3A7IERlY2Fwc3VsYXRpbmcgaW4tc2l0dSBPQU0gbm9kZXMg bWF5IGhhdmUgYW4gYWJpbGl0eTxicj4NCiZuYnNwOyAmbmJzcDt0byBzZW5kIHRoZSBpbi1zaXR1 IE9BTSBpbmZvcm1hdGlvbiByZXRyaWV2ZWQgZnJvbSB0aGUgcGFja2V0IGJhY2sgdG88YnI+DQom bmJzcDsgJm5ic3A7dGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBwYWNrZXQgb3IgdG8gdGhlIGVu Y2Fwc3VsYXRpbmcgbm9kZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7SW0tc2l0dSBPQU0gaW1w bGVtZW50YXRpb246IFRoZSBJT0FNIGRhdGEtZmllbGQgZGVmaW5pdGlvbnMgdGFrZSB0aGU8YnI+ DQombmJzcDsgJm5ic3A7c3BlY2lmaWNzIG9mIGRldmljZXMgd2l0aCBoYXJkd2FyZSBkYXRhLXBs YW5lIGFuZCBzb2Z0d2FyZSBkYXRhLXBsYW5lPGJyPg0KJm5ic3A7ICZuYnNwO2ludG8gYWNjb3Vu dC48YnI+DQo8YnI+DQpUaG91Z2h0cy9jb21tZW50cz8gV2l0aCB0aGVzZSBjaGFuZ2VzLCBhcmUg d2UgYWJsZSB0byBraWNrLW9mZiBhbiBhZG9wdGlvbiBjYWxsPzxicj4NCjxicj4NClRoYW5rcywg RnJhbms8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IE1P UlRPTiwgQUxGUkVEIEMgKEFMKSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphY21vcnRvbkBhdHQu Y29tIj5hY21vcnRvbkBhdHQuY29tPC9hPl08YnI+DQpTZW50OiBNaXR0d29jaCwgMjkuIE3DpHJ6 IDIwMTcgMTg6MTE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6UE1pbmdMaVUiPjxicj4NCjwvc3Bh bj5UbzogPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlhbkBvbGRkb2cu Y28udWs8L2E+OyAnQnJpYW4gVHJhbW1lbGwgKElFVEYpJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmll dGZAdHJhbW1lbGwuY2giPmlldGZAdHJhbW1lbGwuY2g8L2E+Jmd0OzsgRnJhbmsgQnJvY2tuZXJz IChmYnJvY2tuZSkgJmx0OzxhIGhyZWY9Im1haWx0bzpmYnJvY2tuZUBjaXNjby5jb20iPmZicm9j a25lQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6ICdJUFBNIENoYWlycycgJmx0OzxhIGhyZWY9 Im1haWx0bzppcHBtLWNoYWlyc0BpZXRmLm9yZyI+aXBwbS1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0 OzsNCjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj5pcHBtQGlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWJqZWN0OiBS RTogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogaXBwbSBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmciPmlwcG0tYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u IEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIE1hcmNo IDI5LCAyMDE3IDU6MzIgUE08YnI+DQomZ3Q7IFRvOiAnQnJpYW4gVHJhbW1lbGwgKElFVEYpJzsg J0ZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpJzxicj4NCiZndDsgQ2M6ICdJUFBNIENoYWlycyc7 IDxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj5pcHBtQGlldGYub3JnPC9hPjxicj4NCiZn dDsgU3ViamVjdDogUmU6IFtpcHBtXSBWb3RlIGF0IElQUE0gc2Vzc2lvbjxicj4NCiZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyBUaGVyZSB3ZXJlIHNldmVyYWwgcXVlc3Rpb25zIHJlbGF0ZWQgdG8g c2NvcGUgYW5kIGFwcGxpY2FiaWxpdHkgaW48YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGUgV0c8YnI+ DQomZ3Q7ICZndDsgZGlzY3Vzc2lvbiDigJMgYW5kIGV2ZW4gbW9yZSByZWNlbnRseSBvbiB0aGUg bGlzdC4gVGhvc2UgY2FuIGVhc2lseSBiZTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpQTWluZ0xp VSI+PGJyPg0KPC9zcGFuPiZndDsgJmd0OyBhZGRyZXNzZWQgYnkgYWRkaW5nIHBhcmFncmFwaCBv biBhcHBsaWNhYmlsaXR5IHRvPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQt b2FtLWRhdGEg4oCTIHRoZXJlIGlzbuKAmXQgYSBuZWVkIGZvciBhIGRlZGljYXRlZCByZXF1aXJl bWVudHMgZG9jdW1lbnQuPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlBNaW5nTGlVIj48YnI+DQo8 L3NwYW4+Jmd0OyAmZ3Q7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlBNaW5nTGlVIj48YnI+DQo8 L3NwYW4+Jmd0OyAmZ3Q7IEkgdGVuZCB0byBhZ3JlZSB3aXRoIHRoaXMsIGFsdGhvdWdoICZxdW90 O2EgcGFyYWdyYXBoJnF1b3Q7IHNlZW1zIGEgbGl0dGxlPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OlBNaW5nTGlVIj48YnI+DQo8L3NwYW4+Jmd0OyAmZ3Q7IHRoaW4gdG8gbWUuIEkgdGhpbmsgdGhl cmUgd2VyZSBzb21lIHZhbGlkIHBvaW50cyBtYWRlIGluIHRoYXQ8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6UE1pbmdMaVUiPjxicj4NCjwvc3Bhbj4mZ3Q7ICZndDsgZGlzY3Vzc2lvbiBhYm91dCB0 aGUgc2NvcGUgb2YgdGhlIHByb3Bvc2FsIHRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZDo8YnI+DQom Z3Q7ICZndDsgaXMgSU9BTSBtZWFudCBmb3IgdXNlIHR1bm5lbC1lbmQtIHRvLXR1bm5lbC0gZW5k IGVudmlyb25tZW50LDxicj4NCiZndDsgJmd0OyBlbmQtaG9zdC10by1lbmQtaG9zdCwgd2l0aGlu IGEgc2luZ2xlIG5ldHdvcmsgYW5kL29yIGFjcm9zcyB0aGU8YnI+DQomZ3Q7ICZndDsgSW50ZXJu ZXQuJm5ic3A7IFdoYXQgSSB3b3VsZCBzdWdnZXN0IGlzIGFkZGluZyBhIHNlY3Rpb24gdG8gdGhl IGRhdGE8YnI+DQomZ3Q7ICZndDsgbW9kZWwgZHJhZnQgb24gYXBwbGljYWJpbGl0eSBhbmQgYXNz dW1wdGlvbnMgYWJvdXQgdGhlIGVudmlyb25tZW50PGJyPg0KJmd0OyAmZ3Q7IC0tIGJvdGggYWJv dXQgdGhlIGRldmljZXMgYWRkaW5nIElPQU0gc2lnbmFscyB0byB0cmFmZmljIGFzIHdlbGwgYXM8 YnI+DQomZ3Q7ICZndDsgdGhvc2UgY29uc3VtaW5nIHRoZXNlIHNpZ25hbHMgZnJvbSB0aGUgd2ly ZSBhbmQgYW5hbHl6aW5nIHRoZW08YnI+DQomZ3Q7ICZndDsgKHBvc3NpYmx5IHdpdGggdGhlIGNv b3BlcmF0aW9uIG9mIGRldmljZXMgbm90IG9uIHRoZTxicj4NCiZndDsgJmd0OyB3aXJlKSAtLSBz dWJtaXR0aW5nIGEgbmV3IHJldmlzaW9uLCBhbmQgd2UgY2FuIHJ1biBhIG1vcmUgZm9ybWFsPGJy Pg0KJmd0OyAmZ3Q7IGFkb3B0aW9uIGNhbGwgb24gdGhhdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBB bHRob3VnaCBJIHdhcyBvbmUgb2YgdGhlIHBlb3BsZSByYWlzaW5nIHRoZSAmcXVvdDtuZWVkJnF1 b3Q7IGZvciB0aGUgc2NvcGUgYW5kPGJyPg0KJmd0OyByZXF1aXJlbWVudHMsIEkgZG9uJ3QgaGF2 ZSBhIHN0cm9uZyBsZWFkaW5nIG9uIHdoZXRoZXIgdGhpcyBuZWVkcyB0bzxicj4NCiZndDsgYmUg aW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBvbiBmb2xkZWQgaW50byB0aGUgZGF0YSBmb3JtYXQgZG9j dW1lbnQuIFNvPGJyPg0KJmd0OyBCcmlhbidzIHByb3Bvc2FsIHdvdWxkIHdvcmsgZm9yIG1lLjxi cj4NCiZndDs8YnI+DQomZ3Q7IFRodXMsIEknZCBsb3ZlIHRvIHNlZSB0aGlzIHNjb3BpbmcgdGV4 dCBkcmFmdGVkIGFuZCBmbG9hdGVkIHRvIHRoZTxicj4NCiZndDsgbGlzdCBhcyBhbiBlbWFpbCBv ciBpbiBhIHJldmlzaW9uIG9mIHRoZSBkYXRhIGZvcm1hdCBkb2N1bWVudC48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBDaGVlcnMsPGJyPg0KJmd0OyBBZHJpYW48YnI+DQpbQUNNXTxicj4NCjxicj4NCiYj NDM7MSBmb3IgYWRkaW5nIGEgU2NvcGUgc2VjdGlvbiB0bzxicj4NCjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhLTAyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyb2NrbmVy cy1pbmJhbmQtb2FtLWRhdGEtMDI8L2E+PGJyPg0KPGJyPg0KSSBmZWx0IHRoYXQgSSB1bmRlcnN0 b29kIHRoZSBzY29wZSBnb2luZyBpbnRvIHRoZSBkaXNjdXNzaW9uIE1vbmRheSBhbmQgdGhlIGFw cGxpY2FibGUgKHJlc3RyaWN0ZWQpIGRvbWFpbiAoSSBkaWQgdGhlIGhvbWV3b3JrLCB0aGUgc2lu Z2xlIGRyYWZ0IEZyYW5rIGludHJvZHVjZWQgb24gdGhlIG1haWxpbmcgbGlzdCB3YXMgWzBdICku PGJyPg0KPGJyPg0KU29tZSBhZGRpdGlvbmFsIHF1ZXN0aW9ucyBoYXZlIGJlZW4gcmFpc2VkIChl LmcuLCAmcXVvdDt3aGVyZSB3aWxsIE9BTSBiZSBpbnNlcnRlZCBhbmQgcmVtb3ZlZD8mcXVvdDsp IGFuZCBJJ2QgbGlrZSB0byBzZWUgdGhvc2UgaXRlbXMgc29ydGVkLW91dCBiZWZvcmUgd2UgZ28g dmVyeSBmYXIgKHRoZSBhZHZhbnRhZ2Ugb2Ygd2lkZXIgcmV2aWV3KS48YnI+DQo8YnI+DQpUaGUg cmVxdWlyZW1lbnRzIGRyYWZ0IG9ubHkgY2FtZS11cCB3aGVuIEkgYXNrZWQgc29tZSBxdWVzdGlv bnMgb24gdGhlIGxpc3QuIEZyYW5rIG1lbnRpb25lZCB0aGF0IHRoZSBvdXIgbGlzdCBkaXNjdXNz aW9uIG9uIGVxdWl2YWxlbnQgdHJlYXRtZW50IG9mIE9BTSAmYW1wOyBub24tT0FNIHBhY2tldHMg KCZxdW90O2NsYXNzIEMmcXVvdDspIHdhcyBhZGRlZCB0byB0aGUgcmVxdWlyZW1lbnRzIGRvY3Vt ZW50LCBhbmQgdGhhdCBzaG91bGQgbW92ZSB0byAtb2FtLWRhdGEtDQogdG9vLjxicj4NCjxicj4N Ckl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIHZlcnNpb24gb2YgdGhlIHNjb3BlIHRvIHJldmll dyBBU0FQLjxicj4NCjxicj4NCnRoYW5rcyBhbmQgcmVnYXJkcyw8YnI+DQpBbDxicj4NCjxicj4N ClswXSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJz LWluYmFuZC1vYW0tZGF0YS0wMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDI8L2E+PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGlwcG0gbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyI+aXBwbUBpZXRmLm9yZzwvYT48YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtPC9hPjxicj4NCiZndDsgM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX2lwcG0mYW1wO2Q9RHdJR2FRJmFtcDtjPUxGWVotPGJyPg0KJmd0OyBvOV9IVU1lTVRT UWljdmpJZyZhbXA7cj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3JmFtcDttPUdhcXVjenRLNTdmVGoz dnlZY01uSEc5WUs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IEwxIHRWa0FTUTVDM0toNjNvb0EmYW1wO3M9TWVzTTZCRlp5RWtWUHFzR3Ey SG80TEtTX0E0bnRmNVg1aEwwU3gwUnNkYyZhbXA7ZT08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQppcHBtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzppcHBtQGlldGYub3JnIj5pcHBtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7BD774C39BA24B7EA2973925AB719DA4ciscocom_-- From nobody Fri Apr 7 08:44:14 2017 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 4C046129465 for ; Fri, 7 Apr 2017 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 HpeX4A266Y-m for ; Fri, 7 Apr 2017 08:44:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8E512773A for ; Fri, 7 Apr 2017 08:44:06 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v37Fi07M012843; Fri, 7 Apr 2017 16:44:00 +0100 Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v37Fhvjn012826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Apr 2017 16:43:59 +0100 Reply-To: From: "Adrian Farrel" To: "'Frank Brockners \(fbrockne\)'" Cc: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <5e4cb5e81cb04f39856b1f055fa3e831@XCH-RCD-008.cisco.com> In-Reply-To: <5e4cb5e81cb04f39856b1f055fa3e831@XCH-RCD-008.cisco.com> Date: Fri, 7 Apr 2017 16:43:57 +0100 Message-ID: <0a2501d2afb5$c70412c0$550c3840$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3Ooq+i0V2uDTKsntzdbDryWnJDQIGbTuQAhzFMcMCAqiNpgJZUHRiAczg8HQCom8n2QGF54TAAb4MqMABFXUytwGaPkqGAb+m5bygS9+0wA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22990.007 X-TM-AS-Result: No--33.544-10.0-31-10 X-imss-scan-details: No--33.544-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wjNKWYiz0CE6F4q8hdmZvAiCTJUvpDBm3E+f wvzO1fU7VJrndaNUAER7SBt8Yqx4U1Sd1psTkBbtr51gSC67hpW+JGWINXafLHRNGrhtzGYfKLj w6uIZGu8rtGg346TA0CwtGSnCX+Q4TU8AcGDtvC+QTsyupo9izUCrr/LkAQ46+Cckfm+bb6CYrx rXC3Ld7vb1i6yXOj6d7QxY23YxJ7SH/lrNQBbGo8FWmsryu9ZfHznaOB9+eYgCj740gkc7rizyb VqWyY2N5yKkIwXpEoGRURDbcoHdK/tehid1W0/ArpWcnrFhC2nNUTeBBPKQKpUQzHWBKOFAidXg UqJvtIvUkcHUlP7WFYvNGppXuL17Ae7tDA1QuuFHFWsq1vzd1LHYBuPKKJGQ2oLGTNKlb9cRZBR dENkW6CQ55f2BnUKdCrad5YZTKeV8aZSb8TGgop1U1lojafr/g3XZcphu4ktt3Foef1kCwvRWeC swuZrg4BTMo1wvHAfHs1P4pGN3CrlepOYfePOthCecAVGCOf2agpdUd+Iwz5+D2WKPwBVcCLD0W gQfIp9TXO2T3nrkdaCKPNOwP97WLwqc1RzlixcI8o+oRtTdk2EF8bGZ0cKCXCmcAC8DBrPPWstw 2lGTKLlmNWKqCim8qSIZ8nm+T2BLdmeL82hotxi14cCd2FejX6IRwqkp2m7Vxx1cQgUoPqafHhz mAF+1LHIqCfd3IDqQgU+chixB/i95uXownWhRk3rl+MaNgxDp8lxWp2ellnBF/Z15SOgLuaesYH +TAYwGlvgMVl/cq6UkcZC5zAuwqBA65KM+yMieAiCmPx4NwFkMvWAuahr8ooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 07 Apr 2017 15:44:12 -0000 Hi Frank, Thanks for writing this text. It is a good clarification of the intended = scope and, I think, will help the ADs who seemed in Chicago to think the = intended scope was more limited. The sentence I have some concern over is: > The operator > of such a domain MUST put provisions in place to ensure that = in-situ > OAM data stays within the specific domain only (i.e., does not leak > beyond the edge) and consider potential impact of IOAM to ECMP > processing, path MTU and ICMP message handling. To tell an operator to put provisions in place to protect themselves = against a protocol is a bit delicate. Maybe you could make this less sensitive by explaining: - Which provisions are things like packet filters that MUST be = configured=20 and where they have to be configured. Are they packet drop filters? Can we assume that if iOAM tries to escape from a domain then there is a misbehaving/misconfigured node somewhere? - What "considering the potential impact" really means. I think that as worded it means "think about it and if you are worried, don't use = iOAM" which is probably not the effect you wanted to achieve :-) But = otherwise, what is the operator supposed to do? Worry? Configure something? Tune iOAM in some way? I am also not sure about the full extent of the functional scope here. Consider a packet going from A to Z. It enters the iOAM-aware domain at B and exits at Y. You have certainly defined that I can run iOAM from B to Y. I cannot quite tell whether you intend that iOAM is only used if B is a = point of encapsulation. In other words, is B...Y a tunnel, or can iOAM = be applied at B to the native packet that is flowing A...Z without = further encapsulation? Consider some transit nodes C and X within the iOAM-aware domain. I also = can't tell whether C can be the initiation point for iOAM and X the = termination point. If so, can this be done without requiring additional = encapsulation, or does C...X have to be a tunnel within the domain = (effectively creating a layer)? I am aware that there is an overlap between scope and solution in the = answers to my questions. I am not trying to dig into the solutions, but = I am concerned that without understanding the extent of the scope we = will either develop solutions that don't fit the intended scope, or we = will develop solutions that, when applied to the full scope, cause = alarming things to happen. Cheers, Adrian > -----Original Message----- > From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] > Sent: 06 April 2017 18:09 > To: Adrian Farrel (adrian@olddog.co.uk) (adrian@olddog.co.uk) > Subject: FW: [ippm] Vote at IPPM session >=20 > Hi Adrian, >=20 > thanks for your suggestions and continuous drive to include a scope = section into > draft-brockners-inband-oam-data. Does the new section 3 (see below) = meet > what you had in mind? >=20 > Thanks, Frank >=20 > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Frank Brockners > (fbrockne) > Sent: Freitag, 31. M=C3=A4rz 2017 07:28 > To: MORTON, ALFRED C (AL) ; adrian@olddog.co.uk; = 'Brian > Trammell (IETF)' > Cc: 'IPPM Chairs' ; ippm@ietf.org > Subject: Re: [ippm] Vote at IPPM session >=20 > Thanks for the suggestions and comments. We've posted a new revision = of draft- > brockners-inband-oam-data. > https://www.ietf.org/id/draft-brockners-inband-oam-data-04.txt = includes > section 3 on Scope, Applicability, and Assumptions, capturing the = discussion we > had in the WG meeting and on the list. We've also updated the = introduction to > refer to RFC7799 and classify in-situ OAM appropriately as hybrid, = type-1 OAM. >=20 > For everyone's benefit, here is a quote of the new section 3: >=20 > 3. Scope, Applicability, and Assumptions >=20 > In-situ OAM deployment assumes a set of contraints, requirements, = and > guiding principles which are described in this section. >=20 > Scope: This document defines the data fields and associated data > types for in-situ OAM. The in-situ OAM data field can be = transported > by a variety of transport protocols, including NSH, Segment = Routing, > VXLAN-GPE, Geneve, IPv6, or IPv4. Encapsulation details for these > different transport protocols are outside the scope of this = document. >=20 > Deployment domain (or scope) of in-situ OAM deployment: IOAM is a > network domain focused feature, with "network domain" being a set = of > network devices or entities within a single administration. For > example, a network domain can include an enterprise campus using > physical connections between devices or an overlay network using > virtual connections / tunnels for connectivity between said = devices. > A network domain is defined by its perimiter or edge. The operator > of such a domain MUST put provisions in place to ensure that = in-situ > OAM data stays within the specific domain only (i.e., does not leak > beyond the edge) and consider potential impact of IOAM to ECMP > processing, path MTU and ICMP message handling. >=20 > In-situ OAM control points: IOAM data fields are added to or = removed > from the live user traffic by the devices which form the edge of a > domain. Devices within an IOAM domain can update and/or add IOAM > data-fields. Domain edge devices can be hosts or network devices. >=20 > Traffic-sets that in-situ OAM is applied to: IOAM can be deployed = on > all or only on subsets of the live user traffic. It SHOULD be > possible to enable in-situ OAM on a selected set of traffic (e.g., > per interface, based on an access control list or flow = specification > defining a specific set of traffic, etc.) The selected set of > traffic can also be all traffic. >=20 > Encapsulation independence: Data formats for in-situ OAM SHOULD be > defined in a transport-independent manner. In-situ OAM applies to = a > variety of encapsulating protocols. A definition of how IOAM data > fields are carried by different transport protocols is outside the > scope of this document. >=20 > Layering: If several encapsulation protocols (e.g., in case of > tunneling) are stacked on top of each other, in-situ OAM = data-records > could be present at every layer. The behavior follows the = ships-in- > the-night model. >=20 > Combination with active OAM mechanisms: In-situ OAM SHOULD be = usable > for active network probing, enabling for example a customized = version > of traceroute. Decapsulating in-situ OAM nodes may have an ability > to send the in-situ OAM information retrieved from the packet back = to > the source address of the packet or to the encapsulating node. >=20 > Im-situ OAM implementation: The IOAM data-field definitions take = the > specifics of devices with hardware data-plane and software = data-plane > into account. >=20 > Thoughts/comments? With these changes, are we able to kick-off an = adoption > call? >=20 > Thanks, Frank >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Mittwoch, 29. M=C3=A4rz 2017 18:11 > To: adrian@olddog.co.uk; 'Brian Trammell (IETF)' ; = Frank > Brockners (fbrockne) > Cc: 'IPPM Chairs' ; ippm@ietf.org > Subject: RE: [ippm] Vote at IPPM session >=20 > > -----Original Message----- > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Wednesday, March 29, 2017 5:32 PM > > To: 'Brian Trammell (IETF)'; 'Frank Brockners (fbrockne)' > > Cc: 'IPPM Chairs'; ippm@ietf.org > > Subject: Re: [ippm] Vote at IPPM session > > > > > > There were several questions related to scope and applicability = in > > > > the WG > > > discussion =E2=80=93 and even more recently on the list. Those can = easily be > > > addressed by adding paragraph on applicability to > > > draft-brockners-inband-oam-data =E2=80=93 there isn=E2=80=99t a = need for a dedicated > requirements document. > > > > > > I tend to agree with this, although "a paragraph" seems a little > > > thin to me. I think there were some valid points made in that > > > discussion about the scope of the proposal that should be = addressed: > > > is IOAM meant for use tunnel-end- to-tunnel- end environment, > > > end-host-to-end-host, within a single network and/or across the > > > Internet. What I would suggest is adding a section to the data > > > model draft on applicability and assumptions about the environment > > > -- both about the devices adding IOAM signals to traffic as well = as > > > those consuming these signals from the wire and analyzing them > > > (possibly with the cooperation of devices not on the > > > wire) -- submitting a new revision, and we can run a more formal > > > adoption call on that. > > > > Although I was one of the people raising the "need" for the scope = and > > requirements, I don't have a strong leading on whether this needs to > > be in a separate document on folded into the data format document. = So > > Brian's proposal would work for me. > > > > Thus, I'd love to see this scoping text drafted and floated to the > > list as an email or in a revision of the data format document. > > > > Cheers, > > Adrian > [ACM] >=20 > +1 for adding a Scope section to > https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 >=20 > I felt that I understood the scope going into the discussion Monday = and the > applicable (restricted) domain (I did the homework, the single draft = Frank > introduced on the mailing list was [0] ). >=20 > Some additional questions have been raised (e.g., "where will OAM be = inserted > and removed?") and I'd like to see those items sorted-out before we go = very far > (the advantage of wider review). >=20 > The requirements draft only came-up when I asked some questions on the = list. > Frank mentioned that the our list discussion on equivalent treatment = of OAM & > non-OAM packets ("class C") was added to the requirements document, = and that > should move to -oam-data- too. >=20 > It would be good to have a version of the scope to review ASAP. >=20 > thanks and regards, > Al >=20 > [0] https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 >=20 >=20 >=20 > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIGaQ&c=3DLFYZ- > > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DGaqucztK57fTj3vyYcMnH > G9YK > > L1 > tVkASQ5C3Kh63ooA&s=3DMesM6BFZyEkVPqsGq2Ho4LKS_A4ntf5X5hL0Sx0Rsdc&e > =3D > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Fri Apr 7 10:57:50 2017 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 742BF1296D5 for ; Fri, 7 Apr 2017 10:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, 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 GIHQ_VWN1r-z for ; Fri, 7 Apr 2017 10:57:45 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802E21296CE for ; Fri, 7 Apr 2017 10:57:44 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id 81so73183151pgh.2 for ; Fri, 07 Apr 2017 10:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=eRyXYkETC1V/QKHk53FkgEzuEDn2RbJMhCXcfhAABhE=; b=urjGSxg7UypxWBavdfSWBFbUcfIzIcyOKQzfPsYJMDmRqXfTJjZSXsb6I6nQk1DZeJ sv9KhD5zG/0w6XVRGw7wLA9FyfAFCxQ0vsrLKtn+xejib6IGe4n3uqEiK9WBDcng9eOe xuJjhYgeEAPK8yO7VmGNegOclyA1Bd6vMYELLucuTDZI7lngzIIzS41tcMTmt6JgKQqE 2bgB2d+/nekeevNolgImofoIeScyRuETzfAsXIKgciJwVkXSD3EJhuknqWEJ0QzZy6GR S4KpgMGhhDj1FXrUfiZLLA8Glgo6S0aw9hhja8MULe2RackBFnDDkUE9fboOkdReR3ct IMIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=eRyXYkETC1V/QKHk53FkgEzuEDn2RbJMhCXcfhAABhE=; b=CzDYCJzo7IWF8q0T6fBRcwKy3TWDXzxRycDdvERtiPgHm1KUiQS6ywxMMse3bztOUZ sjG7e69JrvDB3VP0F3EA/HpuIC1dG5XSHPsRo10nrwri4tHWDzMb5FVz/rVeDl3a9rGI ZcH+i3g6Gc2lYxfdNM3A+4GYDA1OS0+OuRrjxW8StXUb265I+PWC5p+3skHl7AJ5LiID dX7zjzl2e3aE0eVgyW63Mk85gaq9weQJy1VQjdqDBX1hJfKo2X27xYvEPLbK7VdK/TJc y9EbCgnO8i3EXtkyW99LEiV/4oXHcNHRVd+29y2RFPk5vUcdfn4K19/pV5ZpYr7DeKhm hxsQ== X-Gm-Message-State: AFeK/H3MtdlwO84oDAmST90+/y/Wsnp7RrWXPcRcvbTzpurnICvSNAW9ky7WI0a6k7RxxQ== X-Received: by 10.84.192.129 with SMTP id c1mr51470436pld.181.1491587863968; Fri, 07 Apr 2017 10:57:43 -0700 (PDT) Received: from sjc-mahesh-nitro7.cisco.com ([128.107.241.175]) by smtp.gmail.com with ESMTPSA id 4sm10846038pff.17.2017.04.07.10.57.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Apr 2017 10:57:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1881ACB9-D783-48B0-984A-0D6FE7AA523C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F3BAF0@njmtexg5.research.att.com> Date: Fri, 7 Apr 2017 10:57:40 -0700 Cc: Ron Even , "ippm@ietf.org" Message-Id: References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAF0@njmtexg5.research.att.com> To: "ALFRED C MORTON (AL)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test 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, 07 Apr 2017 17:57:48 -0000 --Apple-Mail=_1881ACB9-D783-48B0-984A-0D6FE7AA523C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Besides, from a YANG modeling perspective, the model has to model both = the Control and Test part. Implementations that choose not to use = Control can choose not to do so.=20 > On Mar 27, 2017, at 4:07 PM, MORTON, ALFRED C (AL) = wrote: >=20 > I=E2=80=99m sorry Roni, but that=E2=80=99s exactly what this phrase, > =E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6=E2=80=9D = means, > suggesting a multi-step process to achieve a full TWAMP > implementation. > =20 > The sentence in the body sets the context for Appendix I. > It says the Appendix describes building TWAMP-Test *first*. > Clearly, TWAMP-Test is not the final step! > =20 > Al > =20 > From: Ron Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Monday, March 27, 2017 6:54 PM > To: MORTON, ALFRED C (AL) > Cc: Mahesh Jethanandani; ippm@ietf.org > Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship = with OWAMP-Test > =20 > Al, > The last part of your response " then implementing the rest of TWAMP = (TWAMP-Control)." is not there. This is why I said that it does not say = that you SHOULD implement the control protocol, you can stop after = implmenting the test protocol. > Roni > =20 > On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (AL) = > wrote: > Roni, in-line: > =20 > From: Ron Even [mailto:ron.even.tlv@gmail.com = ]=20 > Sent: Monday, March 27, 2017 5:54 PM > To: Mahesh Jethanandani > Cc: MORTON, ALFRED C (AL); ippm@ietf.org > Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship = with OWAMP-Test > =20 > Hi, > I read both RFC5357 and RFC 4656 and even though they say that TWAMP = consist of two protocol it never says that both MUST be used anywhere = in the document. The document does not have a lot of normative text. > =20 > Section 5 of RFC5357 is an example and not a requirement and even the = text that was mentioned in the IPPM session > =20 > "Appendix I = provides an example for = purely informational purposes. It > suggests an incremental path to adopting TWAMP, by implementing the > TWAMP-Test protocol first." > =20 > Does not say that using TWAMP-Test without the control protocol SHOULD = NOT be used. > [ACM]=20 > Of course it doesn=E2=80=99t! It says Appendix I describes a=20 > the first step of one process of standards-track TWAMP=20 > implementation, by starting with TWAMP-light, then=20 > implementing the rest of TWAMP (TWAMP-Control). > =20 > Al > =20 > =20 > =20 > =20 > Roni Even > =20 > =20 > =20 > =20 > =20 > On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani = > wrote: > Greg, > =20 > And the part that you forgot to quote that followed in Section 1.1 is: > =20 > TWAMP- > Control is used to initiate, start, and stop test sessions, whereas > TWAMP-Test is used to exchange test packets between two TWAMP > entities. > =20 > There is clearly a precedence for TWAMP-Control to be a entity by = itself and very much part of the TWAMP protocol. > =20 > If this is this rational for your comments on the YANG model, then I = fail to see RFC 5357 backing your claim that TWAMP-control is optional. > =20 > Cheers. > =20 > On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) > wrote: > =20 > Greg, > =20 > All ambiguity falls away in the context of > the complete TWAMP document, which says: > =20 > This example eliminates the need for the TWAMP-Control protocol, = and > assumes that the Session-Reflector is configured and communicates = its > configuration with the Server through non-standard means. > =20 > The example referred to above is not TWAMP; > it is the option you describe, but it is > called *TWAMP light*. > =20 > Al > =20 > From: ippm [mailto:ippm-bounces@ietf.org = ] On Behalf Of Greg Mirsky > Sent: Monday, March 27, 2017 3:16 PM > To: MORTON, ALFRED C (AL) > Cc: ippm@ietf.org > Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship = with OWAMP-Test > =20 > Hi Al, > then, in my opinion, there's certain ambiguity in the text of RFC 4656 = and in RFC 5357 as well because of the following statement in the very = first sentence of section 1.1 RFC 5357: > Similar to OWAMP [RFC4656 = ], TWAMP consists of two inter-related > protocols: TWAMP-Control and TWAMP-Test. The relationship of these > protocols is as defined in Section 1.1 = of OWAMP [RFC4656 = ].=20 > =20 > Regards, > Greg > =20 > On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) = > wrote: > Greg, > =20 > If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80= =9D (the term > you used today when presenting) we would have used the > RFC 2119 term in the text. > =20 > There are plenty of other examples where both Control > and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. > =20 > Al > =20 > =20 > From: ippm [mailto:ippm-bounces@ietf.org = ] On Behalf Of Greg Mirsky > Sent: Monday, March 27, 2017 12:29 PM > To: ippm@ietf.org > Subject: [ippm] RFC 4656 on use of OWAMP-Control and relationship with = OWAMP-Test > =20 > Dear All, > the second paragraph in section 1.1 of RFC 4656 states the following: > Although OWAMP-Test may be used in conjunction with a control > protocol other than OWAMP-Control, the authors have deliberately > chosen to include both protocols in the same RFC to encourage the > implementation and deployment of OWAMP-Control as a common > denominator control protocol for one-way active measurements. > =20 > I interpret "may be used" as MAY per RFC 2119. Please let me know if = this should not be the case. > =20 > Regards, > Greg > =20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm = > =20 > Mahesh Jethanandani > mjethanandani@gmail.com > =20 > =20 > =20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_1881ACB9-D783-48B0-984A-0D6FE7AA523C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Besides, from a YANG modeling perspective, the model has to = model both the Control and Test part. Implementations that choose not to = use Control can choose not to do so. 

On = Mar 27, 2017, at 4:07 PM, MORTON, ALFRED C (AL) <acmorton@att.com> = wrote:

I=E2=80=99= m sorry Roni, but that=E2=80=99s exactly what this phrase,
=E2=80=9C...an incremental = path to adopting TWAMP=E2=80=A6=E2=80=9D  means,
suggesting a multi-step process = to achieve a full TWAMP
implementation.
 
The sentence in the body sets the context for Appendix I.
It = says the Appendix describes building TWAMP-Test *first*.
Clearly, TWAMP-Test is not the = final step!
 
Al
 
From: Ron Even = [mailto:ron.even.tlv@gmail.com] 
Sent: Monday, March 27, 2017 6:54 = PM
To: MORTON, ALFRED C (AL)
Cc: Mahesh Jethanandani; ippm@ietf.org
Subject: Re: [ippm] RFC 4656 on use = of OWAMP-Control and relationship with OWAMP-Test
 
Al,
The last part of your = response  " then implementing the rest = of TWAMP (TWAMP-Control)." is not there. This is why I said that it does = not say that you SHOULD implement the control protocol, you can stop = after implmenting the test protocol.
Roni
 
On Mon, Mar 27, 2017 at 5:39 PM, MORTON, = ALFRED C (AL) <acmorton@att.com> wrote:
Roni, = in-line:
 
From: Ron Even [mailto:ron.even.tlv@gmail.com] 
Sent: Monday, March 27, 2017 5:54 = PM
To: Mahesh Jethanandani
Cc: MORTON, ALFRED C (AL); ippm@ietf.org
Subject: Re: [ippm] RFC 4656 on use = of OWAMP-Control and relationship with OWAMP-Test
 
Hi,
I read both RFC5357 = and RFC 4656 and even though they say that TWAMP consist of two protocol = it never says that  both MUST be used anywhere in the document. The = document does not have a lot of normative text.
 
Section 5 of RFC5357 is an example and = not a requirement and even the text that was mentioned in the IPPM = session
 
"Appendix = I provides an example for = purely informational purposes. It
   suggests an incremental path to adopting TWAMP, =
by implementing the
   =
TWAMP-Test protocol first."
 
Does not say that using TWAMP-Test without the control =
protocol SHOULD NOT be used.
[ACM] 
Of course it =
doesn=E2=80=99t! It says Appendix I describes a 
the first step of =
one process of standards-track TWAMP 
implementation, =
by starting with TWAMP-light, then 
implementing the =
rest of TWAMP (TWAMP-Control).
 
Al
 
 
 
 
Roni Even
 
 
 
 
 
On Mon, Mar 27, 2017 at 4:20 PM, Mahesh = Jethanandani <mjethanandani@gmail.com> wrote:
Greg,
 
And the part that you forgot to quote that followed in = Section 1.1 is:
 
TWAMP-
   =
Control is used to initiate, start, and stop test sessions, whereas
   =
TWAMP-Test is used to exchange test packets between two TWAMP
   =
entities.
 
There is clearly a = precedence for TWAMP-Control to be a entity by itself and very much part = of the TWAMP protocol.
 
If this is this rational for your comments on the YANG model, = then I fail to see RFC 5357 backing your claim that TWAMP-control is = optional.
 
Cheers.
 
On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) <acmorton@att.com> = wrote:
 
Greg,
 
All = ambiguity falls away in the context of
the complete TWAMP document, which says:
 
   This example eliminates the need for the = TWAMP-Control protocol, and
   assumes that the Session-Reflector is configured = and communicates its
   configuration with the Server through = non-standard means.
 
The = example referred to above is not TWAMP;
it is the option you describe, but it is
called *TWAMP light*.
 
Al
 
From: ippm [mailto:ippm-bounces@ietf.org]&n= bsp;On Behalf Of&n= bsp;Greg Mirsky
Sent:&n= bsp;Monday, March 27, 2017 3:16 PM
To:&n= bsp;MORTON, ALFRED C (AL)
Cc:&n= bsp;ippm@ietf.org
Subject:&n= bsp;Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship = with OWAMP-Test
 
Hi Al,
then, in my opinion, there's certain = ambiguity in the text of RFC 4656 and in RFC 5357 as well because of the = following statement in the very first sentence of section 1.1 RFC = 5357:
   Similar to OWAMP [RFC4656], =
TWAMP consists of two inter-related
   protocols: TWAMP-Control and =
TWAMP-Test.  The relationship of these
   =
protocols is as defined in Section =
1.1 of OWAMP [RFC4656]. =

 
Regards,
Greg
 
On Mon, Mar 27, 2017 at 12:24 PM, MORTON, = ALFRED C (AL) <acmorton@att.com> = wrote:
Greg,
 
If we = had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80=9D = (the term
you used today when presenting) = we would have used the
RFC = 2119 term in the text.
 
There = are plenty of other examples where both Control
and Test protocols are taken as =E2=80=9Cthe full = TWAMP=E2=80=9D.
 
Al
 
 
From: ippm [mailto:ippm-bounces@ietf.org]&n= bsp;On Behalf Of&n= bsp;Greg Mirsky
Sent:&n= bsp;Monday, March 27, 2017 12:29 PM
To:&n= bsp;ippm@ietf.org
Subject:&n= bsp;[ippm] RFC 4656 on use of OWAMP-Control and relationship with = OWAMP-Test
 
Dear All,
the second paragraph in section 1.1 of = RFC 4656 states the following:
   Although OWAMP-Test =
may be used in conjunction with a control
   protocol other than =
OWAMP-Control, the authors have deliberately
   =
chosen to include both protocols in the same RFC to encourage the
   =
implementation and deployment of OWAMP-Control as a common
   =
denominator control protocol for one-way active measurements.
 
I interpret =
"may be used" as MAY per RFC 2119. Please let me know if this should not =
be the case.
 
Regards,
Greg
 
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
 
Mahesh Jethanandani
 
 
 


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

<= /div>
Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_1881ACB9-D783-48B0-984A-0D6FE7AA523C-- From nobody Fri Apr 7 11:54:49 2017 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 5A5C812957D; Fri, 7 Apr 2017 11:54:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149159128636.11252.7449541927883223237.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 11:54:46 -0700 Archived-At: Subject: [ippm] Alia Atlas' No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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: Fri, 07 Apr 2017 18:54:46 -0000 Alia Atlas has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Sec 3.2.1, it specifies "Delta Time Last Received = (Send time packet 2 - Receive time packet 1)" & "Delta Time Last Sent = (Receive time packet 2 - Send time packet 1)". I think this would be clearer and not subject to misinterpretation if it were "n" and "n-1" - with words indicating wrapping cases. From nobody Fri Apr 7 12:57:53 2017 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 EB4F112948F for ; Fri, 7 Apr 2017 12:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 3gbLRoSA95DZ for ; Fri, 7 Apr 2017 12:57:38 -0700 (PDT) Received: from nm19-vm1.bullet.mail.gq1.yahoo.com (nm19-vm1.bullet.mail.gq1.yahoo.com [98.136.217.24]) (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 B326E128BB7 for ; Fri, 7 Apr 2017 12:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1491595054; bh=MqoAtJAbR2JDIS6EZn/NKP9tke2EqSDYtDqq3GHZWXY=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=NzXGNtqgiIIelzeLbK3HjzBHXmD3Qjc8ZD+1wcPaqwrLRwsT2VyZpEyEc03+Mlj1eqGfkBFoW0nuhWUsxOo+owGFkbarN+cqZFgGzjiX/x0s0eDV4tirp+t5/LmTQQaESzTyuNQcvFvRFS0sDUl4W1aOqMabaO2IIVnUm8bvw8EfqS1IFpDjpEN7VfBX+DYiRAxAt3Rlxb1SCvxXAFoq9BrrQeiCywO0ukfB8Em/p/Z0CWrWtHtZ5SYpxusdaITD/1txPi6vWrZBm/3QxAgbDKgABpE862VSIA489DG8w4veLQwFRUyh/tWG/KfIv9ZDN+EhqHbD7JI3XsPVxiw1aw== Received: from [98.137.12.57] by nm19.bullet.mail.gq1.yahoo.com with NNFMP; 07 Apr 2017 19:57:34 -0000 Received: from [98.137.12.203] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 07 Apr 2017 19:57:34 -0000 Received: from [127.0.0.1] by omp1011.mail.gq1.yahoo.com with NNFMP; 07 Apr 2017 19:57:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 563767.55255.bm@omp1011.mail.gq1.yahoo.com X-YMail-OSG: 8EbwKTMVM1ki3jC1VTMIaquyo816umn3G_ItAf9ZCwGRU5hxrWfJaAr6aCFnDST F.XkEr4WfHw0Gl9H0poqfzVuIrzpauZYt4oJjbp6OKTeM5MRtwek7luJ9e1dIu_GCUlj70U2JHBS 3I8aytFNs.Tk5W4Wg1SNlU.W4RduTd5yW6i23T1zXnGAzragtVfS2ZSuFWPUtvKkJEiHErG_jsL1 2e4K5dgRCOSZlxuHmdVjtex3C6at0c71VqQzxwj4Gifd278QLaybH_x9qmlt.qGNNq9wTfGPwB0i .volgKAjasj6pkZkNvMukYmySELv4GOvxVo7Ms5uCH5bWrMSNLw2ZqwNtWACIqB2nmBPc_TAOxmA 0ZfQDrwQf9hFxCkOwdm6GHaTaaoQ1uc6qihxpo1nbUYu2tMb5US3v4ijITOc6LPN84IGmq9BakKY p2shPTmz.7f1RuniDRkNQxAZ4rVYozXH3BpNsZH6vIA4PSEW3L9rlRarrsEeELGIs5vZ0ZDjOcBe 0UufV2oi9dFqOHv2POzlTpvy0cSPHXZt230RZMf_seN8B5fTDuMU- Received: from jws300007.mail.gq1.yahoo.com by sendmailws132.mail.gq1.yahoo.com; Fri, 07 Apr 2017 19:57:34 +0000; 1491595054.196 Date: Fri, 7 Apr 2017 19:57:33 +0000 (UTC) From: Reply-To: To: The IESG , Alia Atlas Cc: , Bill Cerveny , , , Message-ID: <362580254.4037586.1491595053683@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <362580254.4037586.1491595053683.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9272 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] Alia Atlas' No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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, 07 Apr 2017 19:57:40 -0000 Alia, Thanks for your comments. Good catch! We accept your comments. Please find new wording inline bel= ow. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Fri, 4/7/17, Alia Atlas wrote: Subject: [ippm] Alia Atlas' No Objection on draft-ietf-ippm-6man-pdm-optio= n-09: (with COMMENT) To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org Date: Friday, April 7, 2017, 11:54 AM =20 > Alia Atlas has entered the following ballot position for draft-ietf-ippm-= 6man-pdm-option-09: No Objection =20 =20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= for more information about IESG DISCUSS and COMMENT positions. =20 =20 > The document, along with other ballot positions, can be found here: https= ://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ =20 =20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- =20 > In Sec 3.2.1, it specifies "Delta Time Last Received =3D (Send time packe= t 2 - Receive time packet 1)" &=C2=A0 "Delta Time Last Sent =3D (Receive t= ime packet 2 - Send time packet 1)".=C2=A0=20 > I think this would be clearer and not subject to misinterpretation if it = were "n" and "n-1" - with words indicating wrapping cases. New wording ----------------- 3.2.1 PDM Layout ... Delta Time Last Received (DELTATLR) A 16-bit unsigned integer field. The value is set according to the scal= e in SCALEDTLR. Delta Time Last Received =3D (Send time packet n - Receive time packet n= -1) Delta Time Last Sent (DELTATLS) A 16-bit unsigned integer field. The value is set according to the sca= le in SCALEDTLS. Delta Time Last Sent =3D (Receive time packet n - Send time packet n-1) =20 =20 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm =20 From nobody Fri Apr 7 14:16:10 2017 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 A5A80127867 for ; Fri, 7 Apr 2017 14:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 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, HTTPS_HTTP_MISMATCH=1.989, 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 OYB7vOIqt9dW for ; Fri, 7 Apr 2017 14:15:53 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 50CDF120454 for ; Fri, 7 Apr 2017 14:15:45 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id b187so99841943oif.0 for ; Fri, 07 Apr 2017 14:15:45 -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=fQ0cea1XK7toZVuIHvEz+OBDzO/MbNZpDb1NIrym4sU=; b=I3tSC8CHcyV7AYhUJ15gCn2mmuYY/oGY3bAuNk+3Z66Z2YtWlx4Ove5jh57vKEQjd4 eu9q/OBDrNlgTyaYk1g1Fmr/yHssbUDNDcTvJ27jX+4084nkz5iSaBXdCW/K/+8am364 jMlFwgIEeWhAGGLxeinMa5NzV/KJnAHJXxcjEDlReiiRvXTzSCWxKDUD/TYHCXQRIXco fLFB9UotImYtZrjQ91qy9VlDoo8Lb5wWOp+carDhuUj7tl1/6RcDrAHwUU0H6v2P/PpG AgHGYighjUvgIYEtuX7gKPGhlM8egwPyL8Iw0V+9JBKKVeIxhfXoPhBOWm/jYQMhW/es yxvw== 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=fQ0cea1XK7toZVuIHvEz+OBDzO/MbNZpDb1NIrym4sU=; b=RzmCb7ZMzUfJnt6qZ0vadAlyEnwRbVXwqKMx94vQd9BxHfKYF/BitDNQNisdP3zPlK 8WeeYTnqaZdoryJFuA4XCXdHoX3HX2JxkECnZjuPaBuUNUgNAbkHR4EYoaDX+MxApYhM ofQ3AI26wn9J01mI6xYj5fM8nx0MMLWtaypvCawWtpj+3xMvlmIpyR6GMtUk5asTPDAi AfxY8/yrjj58qdI2wq85b2vCQamuZgJXXBWdr1ftuYb5Ykxg968+HcBscWOC+whLCtXL bZWvT6xO4cC18hfndOXz/sZekQbyEusQuQkW16UEtpDjfW5fhHn4g0w1bi3LmZYhVuGC rYog== X-Gm-Message-State: AFeK/H0P5b4LIQVW3ywNJHbxBYJMgxfpAVsippHREabmrPIo0RPydnFyVhOavz2pDF+/sWcbnEU/4drp8g6C8w== X-Received: by 10.157.49.11 with SMTP id e11mr24768401otc.206.1491599742285; Fri, 07 Apr 2017 14:15:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Fri, 7 Apr 2017 14:15:41 -0700 (PDT) In-Reply-To: References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAF0@njmtexg5.research.att.com> From: Greg Mirsky Date: Fri, 7 Apr 2017 14:15:41 -0700 Message-ID: To: Mahesh Jethanandani Cc: "ALFRED C MORTON (AL)" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a1146eedac95d02054c9a20e3 Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test 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, 07 Apr 2017 21:15:56 -0000 --001a1146eedac95d02054c9a20e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mahesh, I think that there could be two models - TWAMP-Control and TWAMP-Test. I don't see any good reason to have TWAMP-Test configuration model as part of TWAMP-Control. In fact, having it there makes control of a test session ambiguous as only one of them must be used to configure a test session. TWAMP-Control model only needs test session operational state model and it should use the one defined in TWAMP-Test model. Regards, Greg On Fri, Apr 7, 2017 at 10:57 AM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > Besides, from a YANG modeling perspective, the model has to model both th= e > Control and Test part. Implementations that choose not to use Control can > choose not to do so. > > On Mar 27, 2017, at 4:07 PM, MORTON, ALFRED C (AL) > wrote: > > I=E2=80=99m sorry Roni, but that=E2=80=99s exactly what this phrase, > =E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6=E2=80=9D mean= s, > suggesting a multi-step process to achieve a full TWAMP > implementation. > > The sentence in the body sets the context for Appendix I. > It says the Appendix describes building TWAMP-Test **first**. > Clearly, TWAMP-Test is not the final step! > > Al > > *From:* Ron Even [mailto:ron.even.tlv@gmail.com ] > *Sent:* Monday, March 27, 2017 6:54 PM > *To:* MORTON, ALFRED C (AL) > *Cc:* Mahesh Jethanandani; ippm@ietf.org > *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship > with OWAMP-Test > > Al, > The last part of your response "* then implementing the rest of TWAMP > (TWAMP-Control)." is not there. This is why I said that it does not say > that you SHOULD implement the control protocol, you can stop after > implmenting the test protocol.* > *Roni* > > On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (AL) > wrote: > Roni, in-line: > > *From:* Ron Even [mailto:ron.even.tlv@gmail.com] > *Sent:* Monday, March 27, 2017 5:54 PM > *To:* Mahesh Jethanandani > *Cc:* MORTON, ALFRED C (AL); ippm@ietf.org > *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship > with OWAMP-Test > > Hi, > I read both RFC5357 and RFC 4656 and even though they say that TWAMP > consist of two protocol it never says that both MUST be used anywhere in > the document. The document does not have a lot of normative text. > > Section 5 of RFC5357 is an example and not a requirement and even the tex= t > that was mentioned in the IPPM session > > "Appendix I > > provides an example for purely informational purposes. It > > suggests an incremental path to adopting TWAMP, by implementing the > > TWAMP-Test protocol first." > > > > Does not say that using TWAMP-Test without the control protocol SHOULD NO= T be used. > > *[ACM] * > > *Of course it doesn=E2=80=99t! It says Appendix I describes a * > > *the first step of one process of standards-track TWAMP * > > *implementation, by starting with TWAMP-light, then * > > *implementing the rest of TWAMP (TWAMP-Control).* > > > > *Al* > > > > > > > > > > Roni Even > > > > > > > > > > > On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > Greg, > > And the part that you forgot to quote that followed in Section 1.1 is: > > > TWAMP- > > Control is used to initiate, start, and stop test sessions, whereas > > TWAMP-Test is used to exchange test packets between two TWAMP > > entities. > > > There is clearly a precedence for TWAMP-Control to be a entity by itself > and very much part of the TWAMP protocol. > > If this is this rational for your comments on the YANG model, then I fail > to see RFC 5357 backing your claim that TWAMP-control is optional. > > Cheers. > > > On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) > wrote: > > Greg, > > All ambiguity falls away in the context of > the complete TWAMP document, which says: > > This example eliminates the need for the TWAMP-Control protocol, and > assumes that the Session-Reflector is configured and communicates its > configuration with the Server through non-standard means. > > The example referred to above is not TWAMP; > it is the option you describe, but it is > called **TWAMP light**. > > Al > > *From:* ippm [mailto:ippm-bounces@ietf.org ] *On > Behalf Of *Greg Mirsky > *Sent:* Monday, March 27, 2017 3:16 PM > *To:* MORTON, ALFRED C (AL) > *Cc:* ippm@ietf.org > *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship > with OWAMP-Test > > Hi Al, > then, in my opinion, there's certain ambiguity in the text of RFC 4656 an= d > in RFC 5357 as well because of the following statement in the very first > sentence of section 1.1 RFC 5357: > > Similar to OWAMP [RFC4656 ], TWAMP consists = of two inter-related > > protocols: TWAMP-Control and TWAMP-Test. The relationship of these > > protocols is as defined in Section 1.1 of OWAMP [RFC4656 ]. > > > > Regards, > > Greg > > > On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) > wrote: > Greg, > > If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80= =9D (the term > you used today when presenting) we would have used the > RFC 2119 term in the text. > > There are plenty of other examples where both Control > and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. > > Al > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Monday, March 27, 2017 12:29 PM > *To:* ippm@ietf.org > *Subject:* [ippm] RFC 4656 on use of OWAMP-Control and relationship with > OWAMP-Test > > Dear All, > the second paragraph in section 1.1 of RFC 4656 states the following: > > Although OWAMP-Test may be used in conjunction with a control > > protocol other than OWAMP-Control, the authors have deliberately > > chosen to include both protocols in the same RFC to encourage the > > implementation and deployment of OWAMP-Control as a common > > denominator control protocol for one-way active measurements. > > > > I interpret "may be used" as MAY per RFC 2119. Please let me know if this= should not be the case. > > > > Regards, > > Greg > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --001a1146eedac95d02054c9a20e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mahesh,
I think that there could be two models - TW= AMP-Control and TWAMP-Test. I don't see any good reason to have TWAMP-T= est configuration model as part of TWAMP-Control. In fact, having it there = makes control of a test session ambiguous as only one of them must be used = to configure a test session. TWAMP-Control model only needs test session op= erational state model and it should use the one defined in TWAMP-Test model= .

Regards,
Greg=C2=A0

On Fri, Apr 7, 2017 at 1= 0:57 AM, Mahesh Jethanandani <mjethanandani@gmail.com>= wrote:
Besides, from a YANG modeling perspective, the model has to model both t= he Control and Test part. Implementations that choose not to use Control ca= n choose not to do so.=C2=A0

On Mar 27, 2017, at 4:07 PM, MORTON, ALFRED C (AL) <= ;acmorton@att.com= > wrote:

I=E2=80= =99m sorry Roni, but that=E2=80=99s exactly what this phrase,=
=E2=80=9C...an incremental path to a= dopting TWAMP=E2=80=A6=E2=80=9D=C2=A0=C2=A0means,
suggesting a multi-step process to achieve a full TWAMP
implementation.
=C2=A0
The sentence in the body s= ets the context for Appendix I.
It s= ays the Appendix describes building TWAMP-Test *first*.
Clearly, TWAMP-Test is not the final step!
=C2=A0
Al
=C2=A0<= /div>
From:=C2=A0Ron Even [mailto:ron.even.tlv@gmail.com]=C2=A0
= Sent:=C2=A0= Monday, March 27, 2017 6:54 PM
To:=C2=A0MORTON, ALFRED C (AL)
<= b>Cc:=C2=A0= Mahesh Jethanandani; ippm@ietf.org
Subject:=C2=A0Re: [ippm] RFC 4656 on use of OWAMP-C= ontrol and relationship with OWAMP-Test
=C2=A0
Al,
The last part of yo= ur response =C2=A0"=C2=A0then implementing the rest of TWAMP (TWAMP-Control)." i= s not there. This is why I said that it does not say that you SHOULD implem= ent the control protocol, you can stop after implmenting the test protocol.=
Roni
=C2=A0<= /u>
On Mon, Mar 27, 2017 at 5:39 PM, MORTO= N, ALFRED C (AL) <acmorton@att.com> w= rote:
Roni, in-line:
=C2=A0
From:=C2=A0Ron Even [mailto:ron.even= .tlv@gmail.com]=C2=A0
Sent:=C2=A0Monday, March 27, 2017 5:54 PM
To= :=C2=A0Mahesh Jethanandani
Cc:=C2=A0MORTON, ALFRED C (AL);=C2=A0ippm@ietf.org
Subject:=C2=A0Re: [ippm] RFC 4656 on use of OWAMP-C= ontrol and relationship with OWAMP-Test
=C2=A0
Hi,
I read both RFC5357= and RFC 4656 and even though they say that TWAMP consist of two protocol i= t never says that =C2=A0both MUST be used anywhere in the document. The doc= ument does not have a lot of normative text.
=
=C2=A0
Section 5 of RFC5357 is an example and not a requirement and even t= he text that was mentioned in the IPPM session
=C2=A0
"Appendix I=C2=A0provides an example for purely informational purposes. It
=C2=A0=C2=A0 suggests an in=
cremental path to adopting TWAMP, by implementing the<=
/pre>
=C2=A0=C2=A0 TWAMP-Test protocol first."
=C2=A0
Does not say that using TWAMP-Test without the control pro=
tocol SHOULD NOT be used.
[ACM] 
Of course it doesn=E2=80=99t! It sa=
ys Appendix I describes a 
the first step of one process of standards-tra=
ck TWAMP 
implementation, by starting with TWAMP-light, then <=
u>
implement=
ing the rest of TWAMP (TWAMP-Control).
=C2=A0
Al
<=
i>=C2=A0
<= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie= r New'">=C2=A0
=C2=A0
=
=C2=A0
Roni Even=

=C2=A0
=C2=A0
=C2=A0<=
u>
=C2=A0
=C2=A0
On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani <= ;mjethanandani@gmail.com> wrote:<= u>
Greg,
=C2=A0
And the part that you forgot to quote that followed in Section 1.= 1 is:
=C2=A0= 
TWAMP-
=C2=A0=C2=A0 Control is used to initiate, start=
, and stop test sessions, whereas
=C2=A0=C2=
=A0 TWAMP-Test is used to exchange test packets between two TWAMP=

=C2=A0=C2=A0 entities.
=C2=A0
There is clearly a precedence for TWAMP-Control to be a entity by itself= and very much part of the TWAMP protocol.
=C2=A0
If this is this rational for your comments on the YANG model, then I = fail to see RFC 5357 backing your claim that TWAMP-control is optional.<= /u>
=C2=A0
Cheers.
=C2=A0
On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:
=C2=A0
Greg,
=C2= =A0
All ambiguity falls a= way in the context of
the= complete TWAMP document, which says:
=
=C2=A0
=C2= =A0=C2=A0 This example eliminates the need for the TWAMP-Control protocol, = and
=C2=A0=C2=A0 assumes = that the Session-Reflector is configured and communicates its=
=C2=A0=C2=A0 configuration with the Se= rver through non-standard means.
=C2=A0
= The exampl= e referred to above is not TWAMP;
it is the option you describe, but it is
called *TWAMP light*.<= /div>
=C2=A0
Al
<= span style=3D"font-size:11pt;font-family:'Courier New'">=C2=A0
= From:=C2=A0ippm [mailto:ippm-b= ounces@ietf.org]=C2=A0On Behalf= Of=C2=A0Greg Mirsky
Sent:=C2=A0Monday, March 27, 2017 3:16 PM
To:= =C2=A0MORTON, ALFRED C (AL)
Cc:=C2=A0ippm@ietf.= org
Subject:=C2=A0Re: [ippm] = RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test=
=C2=A0
Hi Al,
then, in my opinion, there's= certain ambiguity in the text of RFC 4656 and in RFC 5357 as well because = of the following statement in the very first sentence of section 1.1 RFC 53= 57:
=C2=A0=C2=A0 Similar t=
o OWAMP [RFC4656], TWAMP consists of two inter-related=

=C2=A0=C2=A0 protocols: TWAMP-Control and TWAMP-Test=
.=C2=A0 The relationship of these
=C2=A0=C2=
=A0 protocols is as defined in Section 1.1 of OWAMP [RFC4656]. 
=C2=A0=

Regards,
Greg=
=C2=A0<= /u>
On Mon, Mar 27, 2017= at 12:24 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:<= /div>
Greg,
=C2=A0
If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2= =80=9D (the term
you used= today when presenting) we would have used the
RFC 2119 term in the text.
=
=C2=A0
There are plenty of other examples where both Control
and Test protocols are taken as =E2=80= =9Cthe full TWAMP=E2=80=9D.
=C2=A0
Al
=C2=A0
=C2=A0
From:=C2=A0ippm [mailto:ippm-bounces@ietf.or= g]=C2=A0On Behalf Of=C2=A0Greg Mirsky
Sent:=C2=A0Monday, March 27, 2017 12:29 PM
To:=C2=A0ippm@ietf.org
Subject:=C2=A0[ippm] RFC 4656 on use of OWAMP-Control and relatio= nship with OWAMP-Test
=C2=A0
Dear All,
the second paragraph in section 1.1 of RFC 4656 states the fol= lowing:
=C2=A0=C2=A0 Altho=
ugh OWAMP-Test may be used in conjunction with a control
 =C2=A0=C2=A0protocol other than OWAMP-Control, the authors h=
ave deliberately
=C2=A0=C2=A0 chosen to inc=
lude both protocols in the same RFC to encourage the
=C2=A0=C2=A0 implementation and deployment of OWAMP-Control as a =
common
=C2=A0=C2=A0 denominator control pro=
tocol for one-way active measurements.
=C2=
=A0
I interpret "may be used" as =
MAY per RFC 2119. Please let me know if this should not be the case.=

=C2=A0
Regards,
Greg
=C2=A0
_____________________= __________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm<= /u>
=C2=A0
Mahesh Jethanandani<= /span>
=C2=A0
=
=C2=A0=
=C2=A0
=


______________________= _________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm


Mahesh Jethanandani




____________________________________= ___________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm


--001a1146eedac95d02054c9a20e3-- From nobody Fri Apr 7 14:41:32 2017 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 69D18127866; Fri, 7 Apr 2017 14:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lEP_8De9zlJ7; Fri, 7 Apr 2017 14:41:26 -0700 (PDT) Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637061250B8; Fri, 7 Apr 2017 14:41:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id 8765080384; Fri, 7 Apr 2017 17:41:25 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at aws.hosed.org Received: from aws.hosed.org ([127.0.0.1]) by localhost (aws.hosed.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBPqXUqiIcHn; Fri, 7 Apr 2017 17:41:25 -0400 (EDT) Received: from [10.0.0.102] (c-67-164-26-160.hsd1.ca.comcast.net [67.164.26.160]) by aws.hosed.org (Postfix) with ESMTPSA id 9A64F80383; Fri, 7 Apr 2017 17:41:24 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sarah B In-Reply-To: Date: Fri, 7 Apr 2017 14:41:23 -0700 Cc: ALFRED MORTON , "adrian@olddog.co.uk" , "Brian Trammell (IETF)" , IPPM Chairs , "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> To: "Frank Brockners (fbrockne)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 07 Apr 2017 21:41:30 -0000 Hi Frank, Thanks for the timely update. At first glance, reading through the below, I very much = appreciate the specific text outlining explicitly where the IOAM is = expected to be limited to; that there is a limit at all, and that it's = domain specific (picking up on the comment in the IPPM session to call = this out). Thanks. This seems to make sense. There is a section below = that gives me pause: "The operator of such a domain MUST put = provisions in place to ensure that in-situ OAM data stays within the = specific domain only (i.e., does not leak beyond the edge) and consider = potential impact of IOAM to ECMP processing, path MTU and ICMP message = handling." I'm sure every operator or implementation will have the best = laid plans in mind, but if there's a misconfigured or otherwise = malicious configuration wherein the IOAM does indeed leak outside of the = domain, what then? Instead of simply asking the user to not allow this, = provide proactive advice on options to alleviate or remediate this = possibility. Would you also consider either making the "and consider = potential impact" a separate explicit MUST or SHOULD (or otherwise) = requirement, with a little more clarity around what you mean for = potential impact? Thanks Sarah > On Mar 31, 2017, at 7:27 AM, Frank Brockners (fbrockne) = wrote: >=20 > Thanks for the suggestions and comments. We've posted a new revision = of draft-brockners-inband-oam-data. > https://www.ietf.org/id/draft-brockners-inband-oam-data-04.txt = includes section 3 on Scope, Applicability, and Assumptions, capturing = the discussion we had in the WG meeting and on the list. We've also = updated the introduction to refer to RFC7799 and classify in-situ OAM = appropriately as hybrid, type-1 OAM. >=20 > For everyone's benefit, here is a quote of the new section 3: >=20 > 3. Scope, Applicability, and Assumptions >=20 > In-situ OAM deployment assumes a set of contraints, requirements, = and > guiding principles which are described in this section. >=20 > Scope: This document defines the data fields and associated data > types for in-situ OAM. The in-situ OAM data field can be = transported > by a variety of transport protocols, including NSH, Segment Routing, > VXLAN-GPE, Geneve, IPv6, or IPv4. Encapsulation details for these > different transport protocols are outside the scope of this = document. >=20 > Deployment domain (or scope) of in-situ OAM deployment: IOAM is a > network domain focused feature, with "network domain" being a set of > network devices or entities within a single administration. For > example, a network domain can include an enterprise campus using > physical connections between devices or an overlay network using > virtual connections / tunnels for connectivity between said devices. > A network domain is defined by its perimiter or edge. The operator > of such a domain MUST put provisions in place to ensure that in-situ > OAM data stays within the specific domain only (i.e., does not leak > beyond the edge) and consider potential impact of IOAM to ECMP > processing, path MTU and ICMP message handling. >=20 > In-situ OAM control points: IOAM data fields are added to or removed > from the live user traffic by the devices which form the edge of a > domain. Devices within an IOAM domain can update and/or add IOAM > data-fields. Domain edge devices can be hosts or network devices. >=20 > Traffic-sets that in-situ OAM is applied to: IOAM can be deployed on > all or only on subsets of the live user traffic. It SHOULD be > possible to enable in-situ OAM on a selected set of traffic (e.g., > per interface, based on an access control list or flow specification > defining a specific set of traffic, etc.) The selected set of > traffic can also be all traffic. >=20 > Encapsulation independence: Data formats for in-situ OAM SHOULD be > defined in a transport-independent manner. In-situ OAM applies to a > variety of encapsulating protocols. A definition of how IOAM data > fields are carried by different transport protocols is outside the > scope of this document. >=20 > Layering: If several encapsulation protocols (e.g., in case of > tunneling) are stacked on top of each other, in-situ OAM = data-records > could be present at every layer. The behavior follows the ships-in- > the-night model. >=20 > Combination with active OAM mechanisms: In-situ OAM SHOULD be usable > for active network probing, enabling for example a customized = version > of traceroute. Decapsulating in-situ OAM nodes may have an ability > to send the in-situ OAM information retrieved from the packet back = to > the source address of the packet or to the encapsulating node. >=20 > Im-situ OAM implementation: The IOAM data-field definitions take the > specifics of devices with hardware data-plane and software = data-plane > into account. >=20 > Thoughts/comments? With these changes, are we able to kick-off an = adoption call? >=20 > Thanks, Frank >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 > Sent: Mittwoch, 29. M=C3=A4rz 2017 18:11 > To: adrian@olddog.co.uk; 'Brian Trammell (IETF)' ; = Frank Brockners (fbrockne) > Cc: 'IPPM Chairs' ; ippm@ietf.org > Subject: RE: [ippm] Vote at IPPM session >=20 >> -----Original Message----- >> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Adrian Farrel >> Sent: Wednesday, March 29, 2017 5:32 PM >> To: 'Brian Trammell (IETF)'; 'Frank Brockners (fbrockne)' >> Cc: 'IPPM Chairs'; ippm@ietf.org >> Subject: Re: [ippm] Vote at IPPM session >>=20 >>>> There were several questions related to scope and applicability in=20= >>>> the WG >>> discussion =E2=80=93 and even more recently on the list. Those can = easily be=20 >>> addressed by adding paragraph on applicability to=20 >>> draft-brockners-inband-oam-data =E2=80=93 there isn=E2=80=99t a need = for a dedicated requirements document. >>>=20 >>> I tend to agree with this, although "a paragraph" seems a little=20 >>> thin to me. I think there were some valid points made in that=20 >>> discussion about the scope of the proposal that should be addressed:=20= >>> is IOAM meant for use tunnel-end- to-tunnel- end environment, =20 >>> end-host-to-end-host, within a single network and/or across the=20 >>> Internet. What I would suggest is adding a section to the data=20 >>> model draft on applicability and assumptions about the environment=20= >>> -- both about the devices adding IOAM signals to traffic as well as=20= >>> those consuming these signals from the wire and analyzing them=20 >>> (possibly with the cooperation of devices not on the >>> wire) -- submitting a new revision, and we can run a more formal=20 >>> adoption call on that. >>=20 >> Although I was one of the people raising the "need" for the scope and=20= >> requirements, I don't have a strong leading on whether this needs to=20= >> be in a separate document on folded into the data format document. So=20= >> Brian's proposal would work for me. >>=20 >> Thus, I'd love to see this scoping text drafted and floated to the=20 >> list as an email or in a revision of the data format document. >>=20 >> Cheers, >> Adrian > [ACM]=20 >=20 > +1 for adding a Scope section to > https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 >=20 > I felt that I understood the scope going into the discussion Monday = and the applicable (restricted) domain (I did the homework, the single = draft Frank introduced on the mailing list was [0] ). >=20 > Some additional questions have been raised (e.g., "where will OAM be = inserted and removed?") and I'd like to see those items sorted-out = before we go very far (the advantage of wider review). >=20 > The requirements draft only came-up when I asked some questions on the = list. Frank mentioned that the our list discussion on equivalent = treatment of OAM & non-OAM packets ("class C") was added to the = requirements document, and that should move to -oam-data- too. >=20 > It would be good to have a version of the scope to review ASAP. >=20 > thanks and regards, > Al >=20 > [0] https://tools.ietf.org/html/draft-brockners-inband-oam-data-02 >=20 >=20 >=20 >>=20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIGaQ&c=3DLFYZ- >> = o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DGaqucztK57fTj3vyYcMnHG9YK= >> L1 tVkASQ5C3Kh63ooA&s=3DMesM6BFZyEkVPqsGq2Ho4LKS_A4ntf5X5hL0Sx0Rsdc&e=3D= > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Fri Apr 7 16:01:03 2017 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 5C1AB129480 for ; Fri, 7 Apr 2017 16:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, 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 tpIlj-NpDD6Q for ; Fri, 7 Apr 2017 16:00:36 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BAD128DE7 for ; Fri, 7 Apr 2017 15:59:52 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id x125so78699592pgb.0 for ; Fri, 07 Apr 2017 15:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=7WvrrqHirVRjpz6PHnD9CYVodWTS9imKOhsBBxqNFOc=; b=cqioNnyp9Qp4t7w3x2HHJO65EYgres/X4xTQowWAKblyOMuXQ0vKjnX/mGPnvf8ax7 llH4udvW7NkI+OJSc8l+XA2dI3GxoQGTcNj/3fMQzip2OC514Dh680isqXZoyd1QuJQ/ vm69c9S3lcT9A3LxY8g9DqegJCdKKVpirOLxlhavMAXfAiwtFNdaYYWblVK6Xdo6K/B8 Nt07aGnr5yWChvhoNtwkUdQNZ1QeTbq7ZsTdm47/3Kk6lZb6KjqFOr1ivsGKwIPCzDOH ucC5GWbieEmLcz/EyBdQsmQFAydIAXCSqsjrgBQRDLrenmPxnNCpk5X/EzLVus94VjKC nDAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7WvrrqHirVRjpz6PHnD9CYVodWTS9imKOhsBBxqNFOc=; b=nzG39D0d410U5kQPnk3r/lKCKPm/whcmq+a2N8LB9sWOFbZQ2x8BbJr+LEi82G0O/X 0Ox4f0OUe8J6c2gNZKogfs9986XYGojVRzUbmPbxdR5Jus6xabx2sSeQ/7aFOYcgd3sv wCVNh79fo/Q9vD7TLU92YuQv8OO//d3+NLhDP3a7QXqU+99FH9eU7/oM8uN0eIzSimHW vSE5g/46pCye+XXLIyKty2NTLHkPIinPKUoX2aXPl9GVnytbeMGuisqkyZWBXVlT7tud sOCWyYmqIYgCQX+bjnoyYaBKfaum/fj/iOPeWmpnMVNa2pQuNUHABSeYbqzra3X+HphL JCXg== X-Gm-Message-State: AFeK/H3T/GcVt+THRsZv90RePkCOZc+ZaIx8DKLGLWN+vw73A6PECRMDe33x8yQ/vhA+QA== X-Received: by 10.84.218.69 with SMTP id f5mr53110112plm.114.1491605991646; Fri, 07 Apr 2017 15:59:51 -0700 (PDT) Received: from ?IPv6:2602:306:cf77:df90:ca:aef:3579:8bfc? ([2602:306:cf77:df90:ca:aef:3579:8bfc]) by smtp.gmail.com with ESMTPSA id u129sm11405136pfu.48.2017.04.07.15.59.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Apr 2017 15:59:50 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_26CC6BAC-4003-4787-BFCC-640BB8509386" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Fri, 7 Apr 2017 15:59:49 -0700 Cc: "ALFRED C MORTON (AL)" , "ippm@ietf.org" Message-Id: References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAF0@njmtexg5.research.att.com> To: Greg Mirsky X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test 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, 07 Apr 2017 23:00:49 -0000 --Apple-Mail=_26CC6BAC-4003-4787-BFCC-640BB8509386 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greg, RFC 5357 defines both TWAMP-Control and TWAMP-Test and how they work = together. The YANG module, which is based on the RFC, therefore models = both. We see no reason to split the model. As said before, there is no = requirement that you have to implement/use the entire model.=20 Cheers. > On Apr 7, 2017, at 2:15 PM, Greg Mirsky wrote: >=20 > Hi Mahesh, > I think that there could be two models - TWAMP-Control and TWAMP-Test. = I don't see any good reason to have TWAMP-Test configuration model as = part of TWAMP-Control. In fact, having it there makes control of a test = session ambiguous as only one of them must be used to configure a test = session. TWAMP-Control model only needs test session operational state = model and it should use the one defined in TWAMP-Test model. >=20 > Regards, > Greg=20 >=20 > On Fri, Apr 7, 2017 at 10:57 AM, Mahesh Jethanandani = > wrote: > Besides, from a YANG modeling perspective, the model has to model both = the Control and Test part. Implementations that choose not to use = Control can choose not to do so.=20 >=20 >> On Mar 27, 2017, at 4:07 PM, MORTON, ALFRED C (AL) > wrote: >>=20 >> I=E2=80=99m sorry Roni, but that=E2=80=99s exactly what this phrase, >> =E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6=E2=80=9D = means, >> suggesting a multi-step process to achieve a full TWAMP >> implementation. >> =20 >> The sentence in the body sets the context for Appendix I. >> It says the Appendix describes building TWAMP-Test *first*. >> Clearly, TWAMP-Test is not the final step! >> =20 >> Al >> =20 >> From: Ron Even [mailto:ron.even.tlv@gmail.com = ]=20 >> Sent: Monday, March 27, 2017 6:54 PM >> To: MORTON, ALFRED C (AL) >> Cc: Mahesh Jethanandani; ippm@ietf.org >> Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship = with OWAMP-Test >> =20 >> Al, >> The last part of your response " then implementing the rest of TWAMP = (TWAMP-Control)." is not there. This is why I said that it does not say = that you SHOULD implement the control protocol, you can stop after = implmenting the test protocol. >> Roni >> =20 >> On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (AL) = > wrote: >> Roni, in-line: >> =20 >> From: Ron Even [mailto:ron.even.tlv@gmail.com = ]=20 >> Sent: Monday, March 27, 2017 5:54 PM >> To: Mahesh Jethanandani >> Cc: MORTON, ALFRED C (AL); ippm@ietf.org >> Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship = with OWAMP-Test >> =20 >> Hi, >> I read both RFC5357 and RFC 4656 and even though they say that TWAMP = consist of two protocol it never says that both MUST be used anywhere = in the document. The document does not have a lot of normative text. >> =20 >> Section 5 of RFC5357 is an example and not a requirement and even the = text that was mentioned in the IPPM session >> =20 >> "Appendix I = provides an example for = purely informational purposes. It >> suggests an incremental path to adopting TWAMP, by implementing = the >> TWAMP-Test protocol first." >> =20 >> Does not say that using TWAMP-Test without the control protocol = SHOULD NOT be used. >> [ACM]=20 >> Of course it doesn=E2=80=99t! It says Appendix I describes a=20 >> the first step of one process of standards-track TWAMP=20 >> implementation, by starting with TWAMP-light, then=20 >> implementing the rest of TWAMP (TWAMP-Control). >> =20 >> Al >> =20 >> =20 >> =20 >> =20 >> Roni Even >> =20 >> =20 >> =20 >> =20 >> =20 >> On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani = > wrote: >> Greg, >> =20 >> And the part that you forgot to quote that followed in Section 1.1 = is: >> =20 >> TWAMP- >> Control is used to initiate, start, and stop test sessions, = whereas >> TWAMP-Test is used to exchange test packets between two TWAMP >> entities. >> =20 >> There is clearly a precedence for TWAMP-Control to be a entity by = itself and very much part of the TWAMP protocol. >> =20 >> If this is this rational for your comments on the YANG model, then I = fail to see RFC 5357 backing your claim that TWAMP-control is optional. >> =20 >> Cheers. >> =20 >> On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) > wrote: >> =20 >> Greg, >> =20 >> All ambiguity falls away in the context of >> the complete TWAMP document, which says: >> =20 >> This example eliminates the need for the TWAMP-Control protocol, = and >> assumes that the Session-Reflector is configured and communicates = its >> configuration with the Server through non-standard means. >> =20 >> The example referred to above is not TWAMP; >> it is the option you describe, but it is >> called *TWAMP light*. >> =20 >> Al >> =20 >> From: ippm [mailto:ippm-bounces@ietf.org = ] On Behalf Of Greg Mirsky >> Sent: Monday, March 27, 2017 3:16 PM >> To: MORTON, ALFRED C (AL) >> Cc: ippm@ietf.org >> Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship = with OWAMP-Test >> =20 >> Hi Al, >> then, in my opinion, there's certain ambiguity in the text of RFC = 4656 and in RFC 5357 as well because of the following statement in the = very first sentence of section 1.1 RFC 5357: >> Similar to OWAMP [RFC4656 = ], TWAMP consists of two inter-related >> protocols: TWAMP-Control and TWAMP-Test. The relationship of = these >> protocols is as defined in Section 1.1 = of OWAMP [RFC4656 = ].=20 >> =20 >> Regards, >> Greg >> =20 >> On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) = > wrote: >> Greg, >> =20 >> If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80= =9D (the term >> you used today when presenting) we would have used the >> RFC 2119 term in the text. >> =20 >> There are plenty of other examples where both Control >> and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. >> =20 >> Al >> =20 >> =20 >> From: ippm [mailto:ippm-bounces@ietf.org = ] On Behalf Of Greg Mirsky >> Sent: Monday, March 27, 2017 12:29 PM >> To: ippm@ietf.org >> Subject: [ippm] RFC 4656 on use of OWAMP-Control and relationship = with OWAMP-Test >> =20 >> Dear All, >> the second paragraph in section 1.1 of RFC 4656 states the following: >> Although OWAMP-Test may be used in conjunction with a control >> protocol other than OWAMP-Control, the authors have deliberately >> chosen to include both protocols in the same RFC to encourage the >> implementation and deployment of OWAMP-Control as a common >> denominator control protocol for one-way active measurements. >> =20 >> I interpret "may be used" as MAY per RFC 2119. Please let me know if = this should not be the case. >> =20 >> Regards, >> Greg >> =20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm = >> =20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >> =20 >> =20 >> =20 >>=20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm = > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm = >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_26CC6BAC-4003-4787-BFCC-640BB8509386 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Greg,

RFC = 5357 defines both TWAMP-Control and TWAMP-Test and how they work = together. The YANG module, which is based on the RFC, therefore models = both. We see no reason to split the model. As said before, there is no = requirement that you have to implement/use the entire = model. 

Cheers.
=
Mahesh Jethanandani
mjethanandani@gmail.com




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



Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_26CC6BAC-4003-4787-BFCC-640BB8509386-- From nobody Fri Apr 7 17:59:36 2017 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 32CFC127978 for ; Fri, 7 Apr 2017 17:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, 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 SBey8T2LULLl for ; Fri, 7 Apr 2017 17:59:29 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 1CD2A1279EB for ; Fri, 7 Apr 2017 17:59:27 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id f193so103123993oib.2 for ; Fri, 07 Apr 2017 17:59:27 -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=Ul5USvF2gbS8UKhrf7mU+7x/Qw+k0N6ioF1L24PGDUc=; b=qsTbe0SCR5HokJMMX43v6ky+bnBOzOhfuu08VXw/gnMFbDVzvFrkgFlnfhheD6/4XM hRVR9wmrrUqNxjmT/9X/PNkDIyc0IFLwVCRMyQLkKXjLWRZBgWd7/szYiUbsJWpRX+6o ZDawGc88n++sQVHZxQOHr/m/GVhnF3CdiBCwQEbiVfJPQcMoMb34ysafaqhoiinii7MY kMdiVSSfda2BqPVn+52AfL2C9vF2usuYxkQtG1m45jFROi9Avo/0QnrTDJY9ENzBEmsx FZe3MtFF6ThjAMAO7riy0x5RxdqRTHpk7cx7sQRSa34RI+BKaidnkQB+uvRODWFciWdX Wx1A== 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=Ul5USvF2gbS8UKhrf7mU+7x/Qw+k0N6ioF1L24PGDUc=; b=mGumn0u4RGPBBXVXc74+ZO0iW+ZrDr9XPs8wNR+yjgia42sFRRVZAXgcQqeo8IQVCc rsQT3LvW5+y/POEovwfHE6z8bQgc5mKM2ADQovXF7qc+GYMaK7xcEj/WBCQpInB0gsJy TtpZFvlxFbg1M+rdi6TbZxtzpxQJSp95EsxV28Wa6LDhLuXXgp7mYz9UxCEd3ZP6rlNK oBGAcn4u7s1B58dgew2aPcxmmLN0LnWAIDe24FUXvJK2cpWXvn/JtFP75qTKfdgKoOIE dPsewC86nckwRKcsYG//6QIzqZxTd6vNtks5V75i14O/b0NX5TmXkFtpLDw4advBFod4 N8Kg== X-Gm-Message-State: AFeK/H3cCl95TRcP9SQOKg5My97Tk0hKkSOvCvfiHDiXdteW2psTKg82m9mIVHMsH5tUHbqMPVhl4UaqNZbgZQ== X-Received: by 10.202.186.138 with SMTP id k132mr23750020oif.157.1491613166423; Fri, 07 Apr 2017 17:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Fri, 7 Apr 2017 17:59:25 -0700 (PDT) In-Reply-To: References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAF0@njmtexg5.research.att.com> From: Greg Mirsky Date: Fri, 7 Apr 2017 17:59:25 -0700 Message-ID: To: Mahesh Jethanandani Cc: "ALFRED C MORTON (AL)" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113cd1f0ed5447054c9d4023 Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test 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, 08 Apr 2017 00:59:32 -0000 --001a113cd1f0ed5447054c9d4023 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mahesh, if one uses TWAMP-Control model defined in draft-ietf-ippm-twamp-yang, then, according to Figure 2, there's no need neither for container session-sender, nor for container session-reflector. In this case Session-Sender and Session-Reflector have only operational state data as all configuration from Control-Client and Server communicated to them over proprietary APIs. If one wants to instantiate TWAMP test session using YANG model from draft-ietf-ippm-twamp-yang, then there will be several issues with parameters referring to a Control-Client. Hence I propose to work together to use YANG model from draft-mirsky-ippm-twamp-light-yang as TWAMP-Test for the second scenario. Regards, Greg On Fri, Apr 7, 2017 at 3:59 PM, Mahesh Jethanandani wrote: > Greg, > > RFC 5357 defines both TWAMP-Control and TWAMP-Test and how they work > together. The YANG module, which is based on the RFC, therefore models > both. We see no reason to split the model. As said before, there is no > requirement that you have to implement/use the entire model. > > Cheers. > > On Apr 7, 2017, at 2:15 PM, Greg Mirsky wrote: > > Hi Mahesh, > I think that there could be two models - TWAMP-Control and TWAMP-Test. I > don't see any good reason to have TWAMP-Test configuration model as part = of > TWAMP-Control. In fact, having it there makes control of a test session > ambiguous as only one of them must be used to configure a test session. > TWAMP-Control model only needs test session operational state model and i= t > should use the one defined in TWAMP-Test model. > > Regards, > Greg > > On Fri, Apr 7, 2017 at 10:57 AM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > >> Besides, from a YANG modeling perspective, the model has to model both >> the Control and Test part. Implementations that choose not to use Contro= l >> can choose not to do so. >> >> On Mar 27, 2017, at 4:07 PM, MORTON, ALFRED C (AL) >> wrote: >> >> I=E2=80=99m sorry Roni, but that=E2=80=99s exactly what this phrase, >> =E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6=E2=80=9D mea= ns, >> suggesting a multi-step process to achieve a full TWAMP >> implementation. >> >> The sentence in the body sets the context for Appendix I. >> It says the Appendix describes building TWAMP-Test **first**. >> Clearly, TWAMP-Test is not the final step! >> >> Al >> >> *From:* Ron Even [mailto:ron.even.tlv@gmail.com = ] >> >> *Sent:* Monday, March 27, 2017 6:54 PM >> *To:* MORTON, ALFRED C (AL) >> *Cc:* Mahesh Jethanandani; ippm@ietf.org >> *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship >> with OWAMP-Test >> >> Al, >> The last part of your response "* then implementing the rest of TWAMP >> (TWAMP-Control)." is not there. This is why I said that it does not say >> that you SHOULD implement the control protocol, you can stop after >> implmenting the test protocol.* >> *Roni* >> >> On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (AL) >> wrote: >> Roni, in-line: >> >> *From:* Ron Even [mailto:ron.even.tlv@gmail.com] >> *Sent:* Monday, March 27, 2017 5:54 PM >> *To:* Mahesh Jethanandani >> *Cc:* MORTON, ALFRED C (AL); ippm@ietf.org >> *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship >> with OWAMP-Test >> >> Hi, >> I read both RFC5357 and RFC 4656 and even though they say that TWAMP >> consist of two protocol it never says that both MUST be used anywhere i= n >> the document. The document does not have a lot of normative text. >> >> Section 5 of RFC5357 is an example and not a requirement and even the >> text that was mentioned in the IPPM session >> >> "Appendix I >> >> provides an example for purely informational purposes. It >> >> suggests an incremental path to adopting TWAMP, by implementing the >> >> TWAMP-Test protocol first." >> >> >> >> Does not say that using TWAMP-Test without the control protocol SHOULD N= OT be used. >> >> *[ACM] * >> >> *Of course it doesn=E2=80=99t! It says Appendix I describes a * >> >> *the first step of one process of standards-track TWAMP * >> >> *implementation, by starting with TWAMP-light, then * >> >> *implementing the rest of TWAMP (TWAMP-Control).* >> >> >> >> *Al* >> >> >> >> >> >> >> >> >> >> Roni Even >> >> >> >> >> >> >> >> >> >> >> On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani < >> mjethanandani@gmail.com> wrote: >> Greg, >> >> And the part that you forgot to quote that followed in Section 1.1 is: >> >> >> TWAMP- >> >> Control is used to initiate, start, and stop test sessions, whereas >> >> TWAMP-Test is used to exchange test packets between two TWAMP >> >> entities. >> >> >> There is clearly a precedence for TWAMP-Control to be a entity by itself >> and very much part of the TWAMP protocol. >> >> If this is this rational for your comments on the YANG model, then I fai= l >> to see RFC 5357 backing your claim that TWAMP-control is optional. >> >> Cheers. >> >> >> On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) >> wrote: >> >> Greg, >> >> All ambiguity falls away in the context of >> the complete TWAMP document, which says: >> >> This example eliminates the need for the TWAMP-Control protocol, and >> assumes that the Session-Reflector is configured and communicates its >> configuration with the Server through non-standard means. >> >> The example referred to above is not TWAMP; >> it is the option you describe, but it is >> called **TWAMP light**. >> >> Al >> >> *From:* ippm [mailto:ippm-bounces@ietf.org ] *On >> Behalf Of *Greg Mirsky >> *Sent:* Monday, March 27, 2017 3:16 PM >> *To:* MORTON, ALFRED C (AL) >> *Cc:* ippm@ietf.org >> *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship >> with OWAMP-Test >> >> Hi Al, >> then, in my opinion, there's certain ambiguity in the text of RFC 4656 >> and in RFC 5357 as well because of the following statement in the very >> first sentence of section 1.1 RFC 5357: >> >> Similar to OWAMP [RFC4656 ], TWAMP consists = of two inter-related >> >> protocols: TWAMP-Control and TWAMP-Test. The relationship of these >> >> protocols is as defined in Section 1.1 of OWAMP [RFC4656 ]. >> >> >> >> Regards, >> >> Greg >> >> >> On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) >> wrote: >> Greg, >> >> If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2= =80=9D (the term >> you used today when presenting) we would have used the >> RFC 2119 term in the text. >> >> There are plenty of other examples where both Control >> and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. >> >> Al >> >> >> *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky >> *Sent:* Monday, March 27, 2017 12:29 PM >> *To:* ippm@ietf.org >> *Subject:* [ippm] RFC 4656 on use of OWAMP-Control and relationship with >> OWAMP-Test >> >> Dear All, >> the second paragraph in section 1.1 of RFC 4656 states the following: >> >> Although OWAMP-Test may be used in conjunction with a control >> >> protocol other than OWAMP-Control, the authors have deliberately >> >> chosen to include both protocols in the same RFC to encourage the >> >> implementation and deployment of OWAMP-Control as a common >> >> denominator control protocol for one-way active measurements. >> >> >> >> I interpret "may be used" as MAY per RFC 2119. Please let me know if thi= s should not be the case. >> >> >> >> Regards, >> >> Greg >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > --001a113cd1f0ed5447054c9d4023 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mahesh,
if one uses TWAMP-Control model defined in= =C2=A0draft-ietf-ippm-twamp-yang, then, according to Figure 2, there's = no need neither for container session-sender, nor for container session-ref= lector. In this case Session-Sender and Session-Reflector have only operati= onal state data as all configuration from Control-Client and Server communi= cated to them over proprietary APIs. If one wants to instantiate TWAMP test= session using YANG model from draft-ietf-ippm-twamp-yang, then there will = be several issues with parameters referring to a Control-Client. Hence I pr= opose to work together to use YANG model from=C2=A0draft-mirsky-ippm-twamp-= light-yang as TWAMP-Test for the second scenario.

= Regards,
Greg

On Fri, Apr 7, 2017 at 3:59 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Greg,

RFC 53= 57 defines both TWAMP-Control and TWAMP-Test and how they work together. Th= e YANG module, which is based on the RFC, therefore models both. We see no = reason to split the model. As said before, there is no requirement that you= have to implement/use the entire model.=C2=A0

Che= ers.

On Apr 7, 2017, at 2:15 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Mahesh,
I think that there could be two models - TWAMP-Control= and TWAMP-Test. I don't see any good reason to have TWAMP-Test configu= ration model as part of TWAMP-Control. In fact, having it there makes contr= ol of a test session ambiguous as only one of them must be used to configur= e a test session. TWAMP-Control model only needs test session operational s= tate model and it should use the one defined in TWAMP-Test model.

Regards,
Greg=C2=A0

On Fri, Apr 7, 2017 at 10:57 AM, Ma= hesh Jethanandani <mjethanandani@gmail.com> wrote:
=
Besides,= from a YANG modeling perspective, the model has to model both the Control = and Test part. Implementations that choose not to use Control can choose no= t to do so.=C2=A0

=
On Mar 27, 2017, at 4:07 PM, MORTON, ALFRED = C (AL) <acmorton@a= tt.com> wrote:

I=E2=80=99m sorry Roni, but tha= t=E2=80=99s exactly what this phrase,
=E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6= =E2=80=9D=C2=A0=C2=A0means,
suggesting a multi-step process to achieve a full TWAMP
implementation.
=C2=A0
The sentence in the body s= ets the context for Appendix I.
It s= ays the Appendix describes building TWAMP-Test *first*.
Clearly, TWAMP-Test is not the final step!
=C2=A0
Al
=C2=A0<= /div>
From:=C2=A0Ron Even [mailto:ron.even.tlv@gm= ail.com]=C2=A0
Sent:=C2=A0Mond= ay, March 27, 2017 6:54 PM
To:=C2=A0MORTON, ALFRED C= (AL)
Cc:=C2=A0Mahesh Jethanandani; ippm@ietf.org
Subject:=C2=A0Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship= with OWAMP-Test
=C2=A0
Al,<= /div>
The last part of your response =C2=A0"= ;= =C2=A0then implementing the rest of TWAMP (TWAMP-Control)." is = not there. This is why I said that it does not say that you SHOULD implemen= t the control protocol, you can stop after implmenting the test protocol.
Roni<= /u>
=C2=A0
On Mon, Mar 27, 2017 at 5:39 PM, MORTON,= ALFRED C (AL) <acmorton@att.com> wro= te:
Roni, in-line:<= u>
=C2=A0
From:=C2=A0Ron Even [mailto:ron.even.tlv@gmail.com]=C2=A0
Sent:= =C2=A0Monday, March 27, 2017 5:54 PM
To:= =C2=A0Mahesh Jethanandani
Cc:=C2=A0MORTON, AL= FRED C (AL);=C2=A0ippm@ietf.orgSubject:=C2=A0Re: [ippm] RFC 4656 on use of OWAMP-Con= trol and relationship with OWAMP-Test
=C2=A0
Hi,
I read both RFC5357 a= nd RFC 4656 and even though they say that TWAMP consist of two protocol it = never says that =C2=A0both MUST be used anywhere in the document. The docum= ent does not have a lot of normative text.
=C2=A0
Section 5 of RFC5357 is an example and not a requirement and even the= text that was mentioned in the IPPM session
=
=C2=A0
"Appendix I=C2=A0provides an example for purely information= al purposes. It
=C2=A0=
=C2=A0 suggests an incremental path to adopting TWAMP, by implementing the<=
/span>
=C2=A0=C2=A0 TWAMP-Test protoc=
ol first."
=C2=A0<=
u>
Does not say that using TWAMP-Test wi=
thout the control protocol SHOULD NOT be used.
[ACM] 
Of course it d=
oesn=E2=80=99t! It says Appendix I describes a 
the first step of one pro=
cess of standards-track TWAMP 
<=
b>implementation, by starting with TWAMP-lig=
ht, then 
implementing the rest of TWAMP (TWAMP-Control).
=C2=A0
Al
=C2=A0=

=C2=
=A0
=C2=A0
=C2=A0
=
Roni Even
=C2=A0=

=C2=A0
=C2=A0
=C2=A0<=
u>
=C2=A0
On Mon, Mar 27, 2017 at 4:20 PM, = Mahesh Jethanandani <mjethanandani@gm= ail.com> wrote:
Greg,=
=C2=A0
<= /div>
And the part that you forgot to quote that= followed in Section 1.1 is:
=C2=A0
TWAMP-
=C2=A0=C2=A0 Control is =
used to initiate, start, and stop test sessions, whereas
=C2=A0=C2=A0 TWAMP-Test is used to exchange test packets betw=
een two TWAMP
=C2=A0=C2=A0 entities.=

=C2=A0
There is clearly a precedence for TWAMP-Control t=
o be a entity by itself and very much part of the TWAMP protocol.=
=C2=A0
If this is this rational for your comments on = the YANG model, then I fail to see RFC 5357 backing your claim that TWAMP-c= ontrol is optional.
= =C2=A0
Cheers.<= u>
=C2=A0
On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL= ) <acmorton@att.com> wrote:=
=C2=A0
Greg,
=C2=A0
All ambiguity falls away in the context of
the complete TWAMP document, which says:=
=C2=A0
=C2=A0=C2=A0 This example eliminates the need for the TW= AMP-Control protocol, and
=C2=A0=C2=A0 assumes that the Session-Reflector is configured and commun= icates its
=C2=A0=C2=A0 c= onfiguration with the Server through non-standard means.
=C2=A0
The example referred to above is not TWAMP;<= /u>
it is the option you describe, but it is
called *TWAMP light= *.
=C2=A0<= u>
Al
=C2=A0
From:=C2=A0= ippm [<= a href=3D"mailto:ippm-bounces@ietf.org" style=3D"color:purple;text-decorati= on:underline" target=3D"_blank">mailto:ippm-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Greg Mirsky
= Sent:=C2=A0Monday,= March 27, 2017 3:16 PM
To:=C2=A0MORTON, ALFRED C (AL)
Cc:=C2=A0ippm@ietf.= org
Subject:=C2= =A0Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with= OWAMP-Test
=C2=A0
H= i Al,
then, in my= opinion, there's certain ambiguity in the text of RFC 4656 and in RFC = 5357 as well because of the following statement in the very first sentence = of section 1.1 RFC 5357:
=
=C2=A0=C2=A0 Similar to OWAMP [RFC4656], TWAMP consists of two in=
ter-related
=C2=A0=C2=A0 protocols: TWAMP-C=
ontrol and TWAMP-Test.=C2=A0 The relationship of these
<= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courie= r New'">=C2=A0=C2=A0 protocols is as defined in S= ection 1.1 of OWAMP [RFC4656]. =C2=A0
Regards,
Greg
=C2=A0
O= n Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wr= ote:
Greg,
=C2=A0
If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2= =80=9COPTIONAL=E2=80=9D (the term
you used today when presenting) we would have used the
RFC 2119 term in the text.=
=C2=A0
<= /div>
There are plenty of other examples where both Contro= l
and Test protocols ar= e taken as =E2=80=9Cthe full TWAMP=E2=80=9D.
=C2=A0
Al
=C2=A0
=C2=A0
From:=C2=A0ippm [mailto:ippm-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Greg Mirsky
Sent:=C2=A0Monday, March 27, 201= 7 12:29 PM
To:=C2= =A0ippm@ietf.o= rg
Subject:=C2=A0[ippm] RFC 4656 on use of OWAMP-Control and relationship wi= th OWAMP-Test
=C2=A0
Dear All,
the second paragraph in section 1.1 of RFC 4656 states the following:= 
=C2=A0=C2=A0 Although OWA=
MP-Test may be used in conjunction with a control
 =C2=A0=C2=A0protocol other than OWAMP-Control, the authors have del=
iberately
=C2=A0=C2=A0 chosen to include bo=
th protocols in the same RFC to encourage the
=C2=A0=C2=A0 implementation and deployment of OWAMP-Control as a common<=
u>
=C2=A0=C2=A0 denominator control protocol f=
or one-way active measurements.
=C2=A0
I interpret "may be used" as MAY per =
RFC 2119. Please let me know if this should not be the case.<=
/pre>
=C2=A0
Regards,=

Greg
=C2=A0
<= /div>
_____________________________= __________________
ippm mailing list
ip= pm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm=
=C2=A0
<= div>
Mahesh Je= thanandani
=C2=A0<= /div>
= =C2=A0
=C2=A0=


_________= ______________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm<= /p>

=

Mahesh Jethanandani




____________________________________= ___________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm



Mahesh Jethanandani




--001a113cd1f0ed5447054c9d4023-- From nobody Sat Apr 8 10:01:31 2017 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 EE3F5129450; Sat, 8 Apr 2017 10:01:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149167088296.3076.14946802136980332281.idtracker@ietfa.amsl.com> Date: Sat, 08 Apr 2017 10:01:22 -0700 Archived-At: Subject: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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: Sat, 08 Apr 2017 17:01:23 -0000 Warren Kumari has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The document says that packet sequence number are optional ("measurements based on optional sequence numbers and timing may be embedded in each packet"), but doesn't say what should be put in the PSNTP field if I'm not using them. It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets (the exmaple just has a dash). This means that I cannot create an interoperable implementation from this document alone. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions overhead from larger packets, but nothing about the additional processing time. In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it gets some number of "nonsensical" sequence numbers." -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic. Another example is section 4.4 Timing Attacks: "Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM. Consent is common in enterprises and with some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite. I don't understand Section 3.6 Dynamic Configuration Options. "If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed." I don't understand how an implementing OS could not have a default (unless this were random). If the default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled). Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off.", so I'm very confused what 3.6 is trying to say... From nobody Sat Apr 8 10:43:57 2017 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 AA4E0127863 for ; Sat, 8 Apr 2017 10:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=1.596, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 UNLivZ0q6DeL for ; Sat, 8 Apr 2017 10:43:46 -0700 (PDT) Received: from nm20-vm5.bullet.mail.gq1.yahoo.com (nm20-vm5.bullet.mail.gq1.yahoo.com [98.136.217.36]) (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 1FCC51293EE for ; Sat, 8 Apr 2017 10:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1491673423; bh=t5kFRrBSRqy7uQn/5ACphsAGTdmpaByb3ahXhKTsCZM=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=VL6kzPK3jzlvuiECAmyzWgczsa/bG0eWg+R92FsNH28VYOUAGCTMI5DGFrAZEcNcKOMtvNLqFUppZtvg8qNl/9FT4sJ7Fu3P2ildIkDP+CEtE36v5aPZT/7d16XQRcXu84B9oq4/Lxb9ZBG0nDLFtYqaz97QP+oeU61MSI6qDSRj7t64w7Au2uA7Z2gAk8ArV0CumIboDd2izv+nfdvnjI+KlGZKQBiS1gD3jK+RI2CDLHEIuJbHYil95BTWDJsippzLWOAWEZvlW4ittMgNOYQLEMO6Rein3aw5+tP2MNBq6PhQRKePE1oAhIUJjcVjsRtSZvQQeY1+AV+HqMqj0g== Received: from [216.39.60.184] by nm20.bullet.mail.gq1.yahoo.com with NNFMP; 08 Apr 2017 17:43:43 -0000 Received: from [98.137.12.244] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 08 Apr 2017 17:43:43 -0000 Received: from [127.0.0.1] by omp1052.mail.gq1.yahoo.com with NNFMP; 08 Apr 2017 17:43:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 448511.85344.bm@omp1052.mail.gq1.yahoo.com X-YMail-OSG: U3O9ipwVM1kusoTZZcfoZ7iFp3zY6MhB7PXTgNktrHNL6ZmeaN1S3NfFKimgL9x LXKgrfh5gsNAJ_A3Ma09pSmEXTKsDQclYdMQouuLvWsdS9VZ03x0Ek1f9V3ShzdWsKzaMz2nSWw1 vrAcRn78.RdsKpEWmtA0UU9GThK0E9JOC18_ZKhD4xQF4VDhxaw.63aHTXhEP8ZVu2svb_gbyTnN 50JAvbgTGHPhiRC7L1dXYWCkI6j5yhHZC4GU14vosMxyLvCF3om183WO79.d2QW5cm4MWvfM4._S e3ZNBpo3d.adnuWGXRxAxaAJ.Ogea4i_JfGCleBhMp4T393nkAu93r_PqmMQGncgkGJGqSYoLrqF 5NP9s.kxucMI8rAAidERrq.eSbde38brRGYtUCrbZt_Cq9181ogwzlRc52LRqquQiaYFkKGrkgPC Jz8.upyLhQCa_PLumtjkwiu01XzBzoFV6kFfSDt5uMokeO0W02GRfK_oiku5C4H4JocO66T.NMf1 I6Y2i8ORBT_TNaYA1wYK7a_kJvMbplbtzPIAhAFlJmUJd9w-- Received: from jws300001.mail.gq1.yahoo.com by sendmailws130.mail.gq1.yahoo.com; Sat, 08 Apr 2017 17:43:43 +0000; 1491673423.039 Date: Sat, 8 Apr 2017 17:43:42 +0000 (UTC) From: Reply-To: To: The IESG , Warren Kumari Cc: , , Bill Cerveny , , Message-ID: <471466896.449269.1491673422679@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <471466896.449269.1491673422679.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9365 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 08 Apr 2017 17:43:48 -0000 Warren, Thanks for your comments. I will respond to the comments section ASAP. But, this is for the DISCUSS > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- =20 > The document says that packet sequence number are optional ("measurements= based on optional sequence numbers and timing may be embedded in each pack= et"), but doesn't say what should > be put in the PSNTP field if I'm not using them. It also doesn't say wha= t I should put in the PSNLR field if I haven't received any PDM packets (th= e exmaple just has a dash). This means that I cannot create an > interoperable implementation from this document alone. What we meant to say is that the entire Destination Option is optional, not= that the packet sequence numbers are optional. Current wording --------------------- Abstract To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. Proposed wording ------------------------ Abstract To assess performance problems, measurements based on=20 sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. The use of the PDM Destination Option is optional. That is, an impleme= ntation may choose not to support it. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Sat, 4/8/17, Warren Kumari wrote: Subject: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (w= ith DISCUSS and COMMENT) To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att= .com, ippm@ietf.org Date: Saturday, April 8, 2017, 10:01 AM =20 Warren Kumari has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss =20 When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) =20 =20 Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ =20 =20 =20 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 The document says that packet sequence number are optional ("measurements based on optional sequence numbers and timing may be embedded in each packet"), but doesn't say what should be put in the PSNTP field if I'm not using them. It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets (the exmaple just has a dash). This means that I cannot create an interoperable implementation from this document alone. =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions overhead from larger packets, but nothing about the additional processing time. =20 In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it gets some number of "nonsensical" sequence numbers."=C2=A0 -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic. =20 Another example is section 4.4 Timing Attacks: "Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM.=C2=A0 Consent is common in enterprises and with some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite. =20 =20 I don't understand Section 3.6 Dynamic Configuration Options. "If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed." I don't understand how an implementing OS could not have a default (unless this were random). If the default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled). Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly=C2=A0 turned on by each stack on a host node by administrative action. The=C2=A0 default value of PDM is off.", so I'm very confused what 3.6 is trying to say... =20 =20 =20 From nobody Sat Apr 8 10:52:47 2017 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 1893C1293E1; Sat, 8 Apr 2017 10:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 6fPxwLxfUu8x; Sat, 8 Apr 2017 10:52:42 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 EFA81129420; Sat, 8 Apr 2017 10:52:41 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v38HjFki016460; Sat, 8 Apr 2017 13:52:39 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 29ptp4kvbh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 08 Apr 2017 13:52:38 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v38HqcVS030387; Sat, 8 Apr 2017 13:52:38 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v38HqQsv030299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Apr 2017 13:52:28 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sat, 8 Apr 2017 17:52:08 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v38Hq8sF013471; Sat, 8 Apr 2017 12:52:08 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v38Hq1bD013178; Sat, 8 Apr 2017 12:52:05 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-green.research.att.com (Postfix) with ESMTP id 70983E1079; Sat, 8 Apr 2017 13:51:43 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Sat, 8 Apr 2017 13:52:00 -0400 From: "MORTON, ALFRED C (AL)" To: "nalini.elkins@insidethestack.com" , "The IESG" , Warren Kumari CC: "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , "ippm@ietf.org" Thread-Topic: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) Thread-Index: AQHSsI+pAXS/Lfvno0S8gWKi1WvPz6G7vs2w Date: Sat, 8 Apr 2017 17:51:59 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F6C64C@njmtexg5.research.att.com> References: <471466896.449269.1491673422679.ref@mail.yahoo.com> <471466896.449269.1491673422679@mail.yahoo.com> In-Reply-To: <471466896.449269.1491673422679@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.250.188] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-08_16:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704080160 Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 08 Apr 2017 17:52:45 -0000 SGkgTmFsaW5pIGFuZCBXYXJyZW4sDQooZG9jIHNoZXBoZXJkIGNoaW1pbmctaW4pDQoNClBlcmhh cHM6DQpBYnN0cmFjdA0KDQogICBUbyBhc3Nlc3MgcGVyZm9ybWFuY2UgcHJvYmxlbXMsICB0aGlz IGRvY3VtZW50IGRlc2NyaWJlcyBvcHRpb25hbA0KICAgaGVhZGVycyBlbWJlZGRlZCBpbiBlYWNo IHBhY2tldCB0aGF0IHByb3ZpZGUgc2VxdWVuY2UgbnVtYmVycyBhbmQgdGltZXN0YW1wcyANCiAg IGFzIGEgYmFzaXMgZm9yIG1lYXN1cmVtZW50cy4NCiAgIC4uLg0KDQpBbA0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFj ay5jb20NCj4gW21haWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbV0NCj4gU2Vu dDogU2F0dXJkYXksIEFwcmlsIDA4LCAyMDE3IDE6NDQgUE0NCj4gVG86IFRoZSBJRVNHOyBXYXJy ZW4gS3VtYXJpDQo+IENjOiBkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uQGlldGYub3Jn OyBNT1JUT04sIEFMRlJFRCBDIChBTCk7DQo+IEJpbGwgQ2VydmVueTsgaXBwbS1jaGFpcnNAaWV0 Zi5vcmc7IGlwcG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFdhcnJlbiBLdW1hcmkncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRpb24tDQo+IDA5OiAod2l0aCBESVND VVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gV2FycmVuLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGNv bW1lbnRzLiAgSSB3aWxsIHJlc3BvbmQgdG8gdGhlIGNvbW1lbnRzIHNlY3Rpb24gQVNBUC4NCj4g DQo+ICBCdXQsIHRoaXMgaXMgZm9yIHRoZSBESVNDVVNTDQo+IA0KPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiBESVNDVVNTOg0KPiAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiANCj4gPiBUaGUgZG9jdW1l bnQgc2F5cyB0aGF0IHBhY2tldCBzZXF1ZW5jZSBudW1iZXIgYXJlIG9wdGlvbmFsDQo+ICgibWVh c3VyZW1lbnRzIGJhc2VkIG9uIG9wdGlvbmFsIHNlcXVlbmNlIG51bWJlcnMgYW5kIHRpbWluZyBt YXkgYmUNCj4gZW1iZWRkZWQgaW4gZWFjaCBwYWNrZXQiKSwgYnV0IGRvZXNuJ3Qgc2F5IHdoYXQg c2hvdWxkDQo+ID4gIGJlIHB1dCBpbiB0aGUgUFNOVFAgZmllbGQgaWYgSSdtIG5vdCB1c2luZyB0 aGVtLiBJdCBhbHNvIGRvZXNuJ3Qgc2F5DQo+IHdoYXQgSSBzaG91bGQgcHV0IGluIHRoZSBQU05M UiBmaWVsZCBpZiBJIGhhdmVuJ3QgcmVjZWl2ZWQgYW55IFBETQ0KPiBwYWNrZXRzICh0aGUgZXht YXBsZSBqdXN0IGhhcyBhIGRhc2gpLiBUaGlzIG1lYW5zIHRoYXQgSSBjYW5ub3QgY3JlYXRlDQo+ IGFuDQo+ID4gIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb24gZnJvbSB0aGlzIGRvY3VtZW50 IGFsb25lLg0KPiANCj4gV2hhdCB3ZSBtZWFudCB0byBzYXkgaXMgdGhhdCB0aGUgZW50aXJlIERl c3RpbmF0aW9uIE9wdGlvbiBpcyBvcHRpb25hbCwNCj4gbm90IHRoYXQgdGhlIHBhY2tldCBzZXF1 ZW5jZSBudW1iZXJzIGFyZSBvcHRpb25hbC4NCj4gDQo+IEN1cnJlbnQgd29yZGluZw0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gQWJzdHJhY3QNCj4gDQo+ICAgIFRvIGFzc2VzcyBwZXJmb3Jt YW5jZSBwcm9ibGVtcywgIG1lYXN1cmVtZW50cyBiYXNlZCBvbiBvcHRpb25hbA0KPiAgICBzZXF1 ZW5jZSBudW1iZXJzIGFuZCB0aW1pbmcgbWF5IGJlIGVtYmVkZGVkIGluIGVhY2ggcGFja2V0LiAg U3VjaA0KPiAgICBtZWFzdXJlbWVudHMgbWF5IGJlIGludGVycHJldGVkIGluIHJlYWwtdGltZSBv ciBhZnRlciB0aGUgZmFjdC4gQW4NCj4gICAgaW1wbGVtZW50YXRpb24gb2YgdGhlIGV4aXN0aW5n IElQdjYgRGVzdGluYXRpb24gT3B0aW9ucyBleHRlbnNpb24NCj4gICAgaGVhZGVyLCB0aGUgUGVy Zm9ybWFuY2UgYW5kIERpYWdub3N0aWMgTWV0cmljcyAoUERNKSBEZXN0aW5hdGlvbg0KPiAgICBP cHRpb25zIGV4dGVuc2lvbiBoZWFkZXIgYXMgd2VsbCBhcyB0aGUgZmllbGQgbGltaXRzLCBjYWxj dWxhdGlvbnMsDQo+ICAgIGFuZCB1c2FnZSBvZiB0aGUgUERNIGluIG1lYXN1cmVtZW50IGFyZSBp bmNsdWRlZCBpbiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gDQo+IFByb3Bvc2VkIHdvcmRpbmcNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBBYnN0cmFjdA0KPiANCj4gICAgVG8gYXNz ZXNzIHBlcmZvcm1hbmNlIHByb2JsZW1zLCAgbWVhc3VyZW1lbnRzIGJhc2VkIG9uDQo+ICAgIHNl cXVlbmNlIG51bWJlcnMgYW5kIHRpbWluZyBtYXkgYmUgZW1iZWRkZWQgaW4gZWFjaCBwYWNrZXQu ICBTdWNoDQo+ICAgIG1lYXN1cmVtZW50cyBtYXkgYmUgaW50ZXJwcmV0ZWQgaW4gcmVhbC10aW1l IG9yIGFmdGVyIHRoZSBmYWN0LiBBbg0KPiAgICBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZXhpc3Rp bmcgSVB2NiBEZXN0aW5hdGlvbiBPcHRpb25zIGV4dGVuc2lvbg0KPiAgICBoZWFkZXIsIHRoZSBQ ZXJmb3JtYW5jZSBhbmQgRGlhZ25vc3RpYyBNZXRyaWNzIChQRE0pIERlc3RpbmF0aW9uDQo+ICAg IE9wdGlvbnMgZXh0ZW5zaW9uIGhlYWRlciBhcyB3ZWxsIGFzIHRoZSBmaWVsZCBsaW1pdHMsIGNh bGN1bGF0aW9ucywNCj4gICAgYW5kIHVzYWdlIG9mIHRoZSBQRE0gaW4gbWVhc3VyZW1lbnQgYXJl IGluY2x1ZGVkIGluIHRoaXMgZG9jdW1lbnQuDQo+ICAgIFRoZSB1c2Ugb2YgdGhlIFBETSBEZXN0 aW5hdGlvbiBPcHRpb24gaXMgb3B0aW9uYWwuICAgVGhhdCBpcywgYW4NCj4gaW1wbGVtZW50YXRp b24NCj4gICAgbWF5IGNob29zZSBub3QgdG8gc3VwcG9ydCBpdC4NCj4gDQo+IFRoYW5rcywNCj4g DQo+IE5hbGluaSBFbGtpbnMNCj4gQ0VPIGFuZCBGb3VuZGVyDQo+IEluc2lkZSBQcm9kdWN0cywg SW5jLg0KPiB3d3cuaW5zaWRldGhlc3RhY2suY29tDQo+ICg4MzEpIDY1OS04MzYwDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBPbiBTYXQsIDQv OC8xNywgV2FycmVuIEt1bWFyaSA8d2FycmVuQGt1bWFyaS5uZXQ+IHdyb3RlOg0KPiANCj4gIFN1 YmplY3Q6IFdhcnJlbiBLdW1hcmkncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtaXBwbS02bWFuLXBk bS1vcHRpb24tMDk6DQo+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ICBUbzogIlRoZSBJ RVNHIiA8aWVzZ0BpZXRmLm9yZz4NCj4gIENjOiBkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0 aW9uQGlldGYub3JnLCAiQWwgTW9ydG9uIg0KPiA8YWNtb3J0b25AYXR0LmNvbT4sICJCaWxsIENl cnZlbnkiIDxpZXRmQHdqY2VydmVueS5jb20+LCBpcHBtLQ0KPiBjaGFpcnNAaWV0Zi5vcmcsIGFj bW9ydG9uQGF0dC5jb20sIGlwcG1AaWV0Zi5vcmcNCj4gIERhdGU6IFNhdHVyZGF5LCBBcHJpbCA4 LCAyMDE3LCAxMDowMSBBTQ0KPiANCj4gIFdhcnJlbiBLdW1hcmkgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZw0KPiAgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiAgZHJhZnQtaWV0Zi1pcHBtLTZtYW4t cGRtLW9wdGlvbi0wOToNCj4gIERpc2N1c3MNCj4gDQo+ICBXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZQ0KPiAgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ICBl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZA0KPiAgQ0MgbGluZXMuIChGZWVs IGZyZWUgdG8gY3V0IHRoaXMNCj4gIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K PiANCj4gDQo+ICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVtZW50X2Rp c2N1c3MtMkRjcml0ZXJpYS5odG1sJmQ9RHdJRmFRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3Zq SWcmcj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3Jm09RGVfNWhydERsakxKM1ZLNjZ0akxIaUFOVE45 DQo+IEs3WE1QZTVrWGQwRmpVY1Umcz1kOGF5dEp0RUNpTGo0UDFLT0IxcTVPUnEyakVhcFhGY2E4 X2M2WWF0QW53JmU9DQo+ICBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MN Cj4gIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiAgVGhlIGRvY3VtZW50LCBhbG9u ZyB3aXRoIG90aGVyIGJhbGxvdA0KPiAgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4g IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0Ff X2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRpcHBtLTJENm1hbi0yRHBk bS0NCj4gMkRvcHRpb25fJmQ9RHdJRmFRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1P ZnNTdThrVElsdFZ5RDFvTDcyY0J3Jm09RGVfNWhydERsakxKM1ZLNjZ0akxIaUFOVE45DQo+IEs3 WE1QZTVrWGQwRmpVY1Umcz00V3B5MUFtUkhleXVWa196RGJxRU5vZXJrSVlmMkF4UVRIcXAxZVRl amNJJmU9DQo+IA0KPiANCj4gDQo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICBESVNDVVNTOg0KPiAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCj4gIFRoZSBkb2N1bWVudCBzYXlzIHRoYXQgcGFja2V0IHNlcXVlbmNl DQo+ICBudW1iZXIgYXJlIG9wdGlvbmFsICgibWVhc3VyZW1lbnRzDQo+ICBiYXNlZCBvbiBvcHRp b25hbCBzZXF1ZW5jZSBudW1iZXJzIGFuZA0KPiAgdGltaW5nIG1heSBiZSBlbWJlZGRlZCBpbiBl YWNoDQo+ICBwYWNrZXQiKSwgYnV0IGRvZXNuJ3Qgc2F5IHdoYXQgc2hvdWxkDQo+ICBiZSBwdXQg aW4gdGhlIFBTTlRQIGZpZWxkIGlmIEknbQ0KPiAgbm90IHVzaW5nIHRoZW0uIEl0IGFsc28gZG9l c24ndCBzYXkNCj4gIHdoYXQgSSBzaG91bGQgcHV0IGluIHRoZSBQU05MUiBmaWVsZA0KPiAgaWYg SSBoYXZlbid0IHJlY2VpdmVkIGFueSBQRE0gcGFja2V0cw0KPiAgKHRoZSBleG1hcGxlIGp1c3Qg aGFzIGEgZGFzaCkuIFRoaXMNCj4gIG1lYW5zIHRoYXQgSSBjYW5ub3QgY3JlYXRlIGFuDQo+ICBp bnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uIGZyb20gdGhpcw0KPiAgZG9jdW1lbnQgYWxvbmUu DQo+IA0KPiANCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIENPTU1FTlQ6DQo+ICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IA0KPiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IElQdjYNCj4gIERlc3RpbmF0aW9u IE9wdGlvbi4gQWRkaW5nIHRoaXMgdG8gYQ0KPiAgcGFja2V0IHB1c2hlcyB0aGUgTDQgaW5mb3Jt YXRpb24NCj4gIGZ1cnRoZXIgb3V0LCBwb3RlbnRpYWxseSBtYWtpbmcgaXQNCj4gIHVuYXZhaWxh YmxlIHRvIHRoZSBmb3J3YXJkaW5nIGVuZ2luZSAvDQo+ICBBQ0xzLiBUaGlzIGlzIG5vdCBqdXN0 IGENCj4gIHRoZW9yZXRpY2FsIGlzc3VlIC0gc2VlIFJGQzc4NzIgZm9yDQo+ICByZWFsIHdvcmxk IGV4YW1wbGVzLiBUaGlzIG1lYW5zIHRoYXQNCj4gIGlmIEkgY29ubmVjdCB0byBhIHJlbW90ZSBt YWNoaW5lIGFuZA0KPiAgZW5hYmxlIHRoaXMsIEkgbWF5IGxvY2sgbXlzZWxmIG91dA0KPiAgb2Yg dGhlIG1hY2hpbmUgKHJldHVybiBwYWNrZXRzIG1heSBub3QNCj4gIG1ha2UgaXQgYmFjayB0byBt ZSk7IHRoaXMgc2hvdWxkDQo+ICBiZSBub3RlZCAocGVyaGFwcyBieSBleHBhbmRpbmcgb24NCj4g IHNlY3Rpb24gMS42KS4gSW4gYWRkaXRpb24sIGVuYWJsaW5nIFBETQ0KPiAgd2lsbCAoYWxtb3N0 IGRlZmluaXRlbHkpIGFkZCBzb21lDQo+ICBwcm9jZXNzaW5nIC8gdHJhbnNtaXQgdGltZSwgYW5k IHNvIHdpbGwNCj4gIHBlcnR1cmIgdGhlIHZlcnkgdGhpbmcgYmVpbmcgbWVhc3VyZWQgLQ0KPiAg SSBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50DQo+ICBzaG91bGQgbm90ZSB0aGlzLiBBcHBlbmRp eCBDIG1lbnRpb25zDQo+ICBvdmVyaGVhZCBmcm9tIGxhcmdlciBwYWNrZXRzLCBidXQNCj4gIG5v dGhpbmcgYWJvdXQgdGhlIGFkZGl0aW9uYWwgcHJvY2Vzc2luZw0KPiAgdGltZS4NCj4gDQo+ICBJ biBhZGRpdGlvbiwgbXVjaCBvZiB0aGUgc2VjdXJpdHkNCj4gIGFkdmljZSBmZWVscyBsaWtlIHNv cHMsIHNpbXBseSB0bw0KPiAgYXBwZWFzZSBzZWN1cml0eSBwZW9wbGUuIEZvciBleGFtcGxlLA0K PiAgaW4gIlBETSBhcyBhIENvdmVydCBDaGFubmVsIiB3ZQ0KPiAgZmluZDogIkhhdmluZyBzYWlk IHRoYXQsIGFuDQo+ICBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgc3RvcCB1c2luZyBQRE0gaWYgaXQN Cj4gIGdldHMgc29tZSBudW1iZXIgb2YgIm5vbnNlbnNpY2FsIg0KPiAgc2VxdWVuY2UgbnVtYmVy cy4iwqAgLS0gc2VlaW5nIGFzIGl0DQo+ICB3b3VsZCBiZSB0aGUgYXR0YWNrZXIgdXNpbmcgUERN IGFzIGENCj4gIGNvbnZlcnQgY2hhbm5lbCwgdGhpcyBpcyBsaWtlIHNheWluZw0KPiAgYXR0YWNr ZXJzIG11c3Qgc2V0IHRoZSBldmlsIGJpdCBvbiBhbGwNCj4gIGF0dGFjayB0cmFmZmljLg0KPiAN Cj4gIEFub3RoZXIgZXhhbXBsZSBpcyBzZWN0aW9uIDQuNCBUaW1pbmcNCj4gIEF0dGFja3M6DQo+ ICAiRXZlbiBzbywgaWYgdXNpbmcgUERNLCB3ZSBpbnRyb2R1Y2UNCj4gIHRoZSBjb25jZXB0IG9m IHVzZXIgIkNvbnNlbnQgdG8gYmUNCj4gIE1lYXN1cmVkIiBhcyBhIHByZS1yZXF1aXNpdGUgZm9y IHVzaW5nDQo+ICBQRE0uwqAgQ29uc2VudCBpcyBjb21tb24gaW4NCj4gIGVudGVycHJpc2VzIGFu ZCB3aXRoIHNvbWUgc3Vic2NyaXB0aW9uDQo+ICBzZXJ2aWNlcy4gU28sIGlmIHdpdGggUERNLCB3 ZQ0KPiAgcmVjb21tZW5kIHRoYXQgdGhlIHVzZXIgU0hPVUxEIGNvbnNlbnQNCj4gIHRvIGl0cyB1 c2UuIiAtIHRoaXMgaGFzIG5vdGhpbmcgdG8NCj4gIGRvIHdpdGggdGltaW5nIGF0dGFja3MuIElu IGFkZGl0aW9uIGENCj4gIGNvbmNlcHQgaXMgaW50cm9kdWNlZCwgYnV0IG5vdA0KPiAgcmVhbGx5 IGV4cGxhaW5lZCAtIGl0IGlzIHRoZW4gY2xhaW1lZA0KPiAgdGhhdCB0aGlzIGlzIGNvbW1vbiBp biBlbnRlcnByaXNlcw0KPiAgKHRydWUpLCBhbmQgdGhhdCB1c2VycyBTSE9VTEQgY29uc2VudA0K PiAgKG9yIHNob3VsZCBoYXZlIGFscmVhZHkgY29uc2VudGVkKQ0KPiAgdG8gYmVpbmcgbW9uaXRv cmVkLiBUaGlzIGZlZWxzIGxpa2UgaXQNCj4gIHdhcyBzcHJpbmtsZWQgb24gbGlrZSBzZWN1cml0 eQ0KPiAgZmFpcnkgZHVzdCB0byBtYWtlIHNlY3VyaXR5IHBlb3BsZQ0KPiAgaGFwcHksIGFuZCAo Zm9yIG1lKSBkb2VzIHRoZQ0KPiAgb3Bwb3NpdGUuDQo+IA0KPiANCj4gIEkgZG9uJ3QgdW5kZXJz dGFuZCBTZWN0aW9uIDMuNiBEeW5hbWljDQo+ICBDb25maWd1cmF0aW9uIE9wdGlvbnMuDQo+ICAi SWYgaW1wbGVtZW50ZWQsIGVhY2ggb3BlcmF0aW5nIHN5c3RlbQ0KPiAgTVVTVCBoYXZlIGEgZGVm YXVsdCBjb25maWd1cmF0aW9uDQo+ICBwYXJhbWV0ZXIsIGUuZy4NCj4gIGRpYWdfaGVhZGVyX3N5 c19kZWZhdWx0X3ZhbHVlPXllcy9uby4gVGhlIG9wZXJhdGluZw0KPiAgc3lzdGVtIE1BWSBhbHNv IGhhdmUgYSBkeW5hbWljDQo+ICBjb25maWd1cmF0aW9uIG9wdGlvbiB0byBjaGFuZ2UgdGhlDQo+ ICBjb25maWd1cmF0aW9uIHNldHRpbmcgYXMgbmVlZGVkLiINCj4gIEkgZG9uJ3QgdW5kZXJzdGFu ZCBob3cgYW4gaW1wbGVtZW50aW5nDQo+ICBPUyBjb3VsZCBub3QgaGF2ZSBhIGRlZmF1bHQNCj4g ICh1bmxlc3MgdGhpcyB3ZXJlIHJhbmRvbSkuIElmIHRoZQ0KPiAgZGVmYXVsdCB3ZXJlIG5vLCBw cmVzdW1hYmx5IGl0IHdvdWxkDQo+ICAqaGF2ZSogdG8gaGF2ZSBhIGR5bmFtaWMgb3B0aW9uIHRv DQo+ICBjaGFuZ2UgdGhlIGNvbmZpZyAob3IgaXQgY291bGQgbmV2ZXINCj4gIGJlIGVuYWJsZWQp Lg0KPiAgU2VjdGlvbiAzLjUuMSBzYXlzOiAiVGhlIFBETQ0KPiAgZGVzdGluYXRpb24gb3B0aW9u cyBleHRlbnNpb24gaGVhZGVyIE1VU1QgYmUNCj4gIGV4cGxpY2l0bHnCoCB0dXJuZWQgb24gYnkg ZWFjaA0KPiAgc3RhY2sgb24gYSBob3N0IG5vZGUgYnkgYWRtaW5pc3RyYXRpdmUNCj4gIGFjdGlv bi4gVGhlwqAgZGVmYXVsdCB2YWx1ZSBvZiBQRE0NCj4gIGlzIG9mZi4iLCBzbyBJJ20gdmVyeSBj b25mdXNlZCB3aGF0IDMuNg0KPiAgaXMgdHJ5aW5nIHRvIHNheS4uLg0KPiANCj4gDQo+IA0K From nobody Sun Apr 9 19:06:21 2017 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 D31C01293DB for ; Sun, 9 Apr 2017 19:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 KVz8AFIr0Ucq for ; Sun, 9 Apr 2017 19:06:16 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id EB9C81279EB for ; Sun, 9 Apr 2017 19:06:14 -0700 (PDT) X-scanvirus: By SEG_CYREN AntiVirus Engine X-scanresult: CLEAN X-MAILFROM: X-RCPTTO: X-FROMIP: 192.168.168.116 X-SEG-Scaned: 1 X-Received: unknown,192.168.168.116,20170410095748 Received: from unknown (HELO mx7.zte.com.cn) (192.168.168.116) by localhost with SMTP; 10 Apr 2017 01:57:48 -0000 X-scanvirus: By SEG_CYREN AntiVirus Engine X-scanresult: CLEAN X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.1.239 X-SEG-Scaned: 1 X-Received: unknown,10.30.1.239,20170410100159 Received: from unknown (HELO notes?smtp.zte.com.cn) (10.30.1.239) by localhost with SMTP; 10 Apr 2017 02:01:59 -0000 Received: from njxapp03.zte.com.cn ([10.41.132.202]) by notes_svr37.zte.com.cn (IBM Domino Release 9.0.1FP6) with SMTP id 2017041010061007-1657078 ; Mon, 10 Apr 2017 10:06:10 +0800 Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Mon, 10 Apr 2017 10:06:12 +0800 (CST) Date: Mon, 10 Apr 2017 10:06:12 +0800 (CST) X-Zmail-TransId: 2afd58eae894123-0bd48 X-Mailer: Zmail v1.0 Message-ID: <201704101006129797951@zte.com.cn> References: CA+RyBmXGz5=KozgmcTcKJM5ntTUEofNdgmq=ED_k-rpT46me_A@mail.gmail.com, CA+RyBmV1g3vEw_78umvMpPTz0VYzKoK6Mk7VOm6M=rdAXu-R3w@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , , X-MIMETrack: Itemize by SMTP Server on notes_svr37/zte_ltd(Release 9.0.1FP6|April 20, 2016) at 2017/04/10 10:06:10, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2017-04-10 10:06:01 Content-Type: multipart/mixed; boundary="=====_001_next=====" X-HQIP: 127.0.0.1 X-HQIP: 127.0.0.1 Archived-At: Subject: Re: [ippm] =?utf-8?q?RFC_4656_on_use_of_OWAMP-Control_and_relationsh?= =?utf-8?q?ip_withOWAMP-Test?= 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, 10 Apr 2017 02:06:20 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8" RnVsbHkgYWdyZWUuDQoNCkFmdGVyIHRoZSBzcGxpdCBvZiB0d28gc2NlbmFyaW9zIHRoZSBpbXBs ZW1lbnRlciBhbmQgdGhlIG9wZXJhdG9yIGNhbiBjaG9vc2UgWUFORyBtb2RlbCBhcyBuZWVkZWQg ZWFzaWx5IGFuZCBjbGVhcmx5Lg0KDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KWGlhbyBNaW4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQrljp/l p4vpgq7ku7YNCg0KDQoNCuWPkeS7tuS6uu+8miDvvJxncmVnaW1pcnNreUBnbWFpbC5jb23vvJ4N CuaUtuS7tuS6uu+8miDvvJxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbe+8ng0K5oqE6YCB5Lq677ya IO+8nGFjbW9ydG9uQGF0dC5jb23vvJ4g77ycaXBwbUBpZXRmLm9yZ++8ng0K5pelIOacnyDvvJoy MDE35bm0MDTmnIgwOOaXpSAwODo1NQ0K5Li7IOmimCDvvJpSZTogW2lwcG1dIFJGQyA0NjU2IG9u IHVzZSBvZiBPV0FNUC1Db250cm9sIGFuZCByZWxhdGlvbnNoaXAgd2l0aE9XQU1QLVRlc3QNCg0K DQoNCg0KDQoNCkhpIE1haGVzaCxpZiBvbmUgdXNlcyBUV0FNUC1Db250cm9sIG1vZGVsIGRlZmlu ZWQgaW4gZHJhZnQtaWV0Zi1pcHBtLXR3YW1wLXlhbmcsIHRoZW4sIGFjY29yZGluZyB0byBGaWd1 cmUgMiwgdGhlcmUncyBubyBuZWVkIG5laXRoZXIgZm9yIGNvbnRhaW5lciBzZXNzaW9uLXNlbmRl ciwgbm9yIGZvciBjb250YWluZXIgc2Vzc2lvbi1yZWZsZWN0b3IuIEluIHRoaXMgY2FzZSBTZXNz aW9uLVNlbmRlciBhbmQgU2Vzc2lvbi1SZWZsZWN0b3IgaGF2ZSBvbmx5IG9wZXJhdGlvbmFsIHN0 YXRlIGRhdGEgYXMgYWxsIGNvbmZpZ3VyYXRpb24gZnJvbSBDb250cm9sLUNsaWVudCBhbmQgU2Vy dmVyIGNvbW11bmljYXRlZCB0byB0aGVtIG92ZXIgcHJvcHJpZXRhcnkgQVBJcy4gSWYgb25lIHdh bnRzIHRvIGluc3RhbnRpYXRlIFRXQU1QIHRlc3Qgc2Vzc2lvbiB1c2luZyBZQU5HIG1vZGVsIGZy b20gZHJhZnQtaWV0Zi1pcHBtLXR3YW1wLXlhbmcsIHRoZW4gdGhlcmUgd2lsbCBiZSBzZXZlcmFs IGlzc3VlcyB3aXRoIHBhcmFtZXRlcnMgcmVmZXJyaW5nIHRvIGEgQ29udHJvbC1DbGllbnQuIEhl bmNlIEkgcHJvcG9zZSB0byB3b3JrIHRvZ2V0aGVyIHRvIHVzZSBZQU5HIG1vZGVsIGZyb20gZHJh ZnQtbWlyc2t5LWlwcG0tdHdhbXAtbGlnaHQteWFuZyBhcyBUV0FNUC1UZXN0IGZvciB0aGUgc2Vj b25kIHNjZW5hcmlvLg0KDQoNClJlZ2FyZHMsDQpHcmVnDQoNCg0KDQoNCk9uIEZyaSwgQXByIDcs IDIwMTcgYXQgMzo1OSBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSDvvJxtamV0aGFuYW5kYW5pQGdt YWlsLmNvbe+8niB3cm90ZToNCg0KR3JlZywNCg0KUkZDIDUzNTcgZGVmaW5lcyBib3RoIFRXQU1Q LUNvbnRyb2wgYW5kIFRXQU1QLVRlc3QgYW5kIGhvdyB0aGV5IHdvcmsgdG9nZXRoZXIuIFRoZSBZ QU5HIG1vZHVsZSwgd2hpY2ggaXMgYmFzZWQgb24gdGhlIFJGQywgdGhlcmVmb3JlIG1vZGVscyBi b3RoLiBXZSBzZWUgbm8gcmVhc29uIHRvIHNwbGl0IHRoZSBtb2RlbC4gQXMgc2FpZCBiZWZvcmUs IHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRoYXQgeW91IGhhdmUgdG8gaW1wbGVtZW50L3VzZSB0 aGUgZW50aXJlIG1vZGVsLiANCg0KDQpDaGVlcnMuDQoNCg0KT24gQXByIDcsIDIwMTcsIGF0IDI6 MTUgUE0sIEdyZWcgTWlyc2t5IO+8nGdyZWdpbWlyc2t5QGdtYWlsLmNvbe+8niB3cm90ZToNCg0K SGkgTWFoZXNoLEkgdGhpbmsgdGhhdCB0aGVyZSBjb3VsZCBiZSB0d28gbW9kZWxzIC0gVFdBTVAt Q29udHJvbCBhbmQgVFdBTVAtVGVzdC4gSSBkb24ndCBzZWUgYW55IGdvb2QgcmVhc29uIHRvIGhh dmUgVFdBTVAtVGVzdCBjb25maWd1cmF0aW9uIG1vZGVsIGFzIHBhcnQgb2YgVFdBTVAtQ29udHJv bC4gSW4gZmFjdCwgaGF2aW5nIGl0IHRoZXJlIG1ha2VzIGNvbnRyb2wgb2YgYSB0ZXN0IHNlc3Np b24gYW1iaWd1b3VzIGFzIG9ubHkgb25lIG9mIHRoZW0gbXVzdCBiZSB1c2VkIHRvIGNvbmZpZ3Vy ZSBhIHRlc3Qgc2Vzc2lvbi4gVFdBTVAtQ29udHJvbCBtb2RlbCBvbmx5IG5lZWRzIHRlc3Qgc2Vz c2lvbiBvcGVyYXRpb25hbCBzdGF0ZSBtb2RlbCBhbmQgaXQgc2hvdWxkIHVzZSB0aGUgb25lIGRl ZmluZWQgaW4gVFdBTVAtVGVzdCBtb2RlbC4NCg0KDQpSZWdhcmRzLA0KR3JlZyANCg0KDQoNCg0K T24gRnJpLCBBcHIgNywgMjAxNyBhdCAxMDo1NyBBTSwgTWFoZXNoIEpldGhhbmFuZGFuaSDvvJxt amV0aGFuYW5kYW5pQGdtYWlsLmNvbe+8niB3cm90ZToNCg0KQmVzaWRlcywgZnJvbSBhIFlBTkcg bW9kZWxpbmcgcGVyc3BlY3RpdmUsIHRoZSBtb2RlbCBoYXMgdG8gbW9kZWwgYm90aCB0aGUgQ29u dHJvbCBhbmQgVGVzdCBwYXJ0LiBJbXBsZW1lbnRhdGlvbnMgdGhhdCBjaG9vc2Ugbm90IHRvIHVz ZSBDb250cm9sIGNhbiBjaG9vc2Ugbm90IHRvIGRvIHNvLiANCg0KT24gTWFyIDI3LCAyMDE3LCBh dCA0OjA3IFBNLCBNT1JUT04sIEFMRlJFRCBDIChBTCkg77ycYWNtb3J0b25AYXR0LmNvbe+8niB3 cm90ZToNCg0KDQpJ4oCZbSBzb3JyeSBSb25pLCBidXQgdGhhdOKAmXMgZXhhY3RseSB3aGF0IHRo aXMgcGhyYXNlLA0KDQrigJwuLi5hbiBpbmNyZW1lbnRhbCBwYXRoIHRvIGFkb3B0aW5nIFRXQU1Q 4oCm4oCdICBtZWFucywNCg0Kc3VnZ2VzdGluZyBhIG11bHRpLXN0ZXAgcHJvY2VzcyB0byBhY2hp ZXZlIGEgZnVsbCBUV0FNUA0KDQppbXBsZW1lbnRhdGlvbi4NCg0KIA0KDQpUaGUgc2VudGVuY2Ug aW4gdGhlIGJvZHkgc2V0cyB0aGUgY29udGV4dCBmb3IgQXBwZW5kaXggSS4NCg0KSXQgc2F5cyB0 aGUgQXBwZW5kaXggZGVzY3JpYmVzIGJ1aWxkaW5nIFRXQU1QLVRlc3QgKmZpcnN0Ki4NCg0KQ2xl YXJseSwgVFdBTVAtVGVzdCBpcyBub3QgdGhlIGZpbmFsIHN0ZXAhDQoNCiANCg0KQWwNCg0KIA0K DQoNCg0KRnJvbTogUm9uIEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXSANClNl bnQ6IE1vbmRheSwgTWFyY2ggMjcsIDIwMTcgNjo1NCBQTQ0KVG86IE1PUlRPTiwgQUxGUkVEIEMg KEFMKQ0KQ2M6IE1haGVzaCBKZXRoYW5hbmRhbmkgaXBwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtpcHBtXSBSRkMgNDY1NiBvbiB1c2Ugb2YgT1dBTVAtQ29udHJvbCBhbmQgcmVsYXRpb25zaGlw IHdpdGggT1dBTVAtVGVzdA0KDQoNCg0KIA0KDQpBbCwNCg0KVGhlIGxhc3QgcGFydCBvZiB5b3Vy IHJlc3BvbnNlICAiIHRoZW4gaW1wbGVtZW50aW5nIHRoZSByZXN0IG9mIFRXQU1QIChUV0FNUC1D b250cm9sKS4iIGlzIG5vdCB0aGVyZS4gVGhpcyBpcyB3aHkgSSBzYWlkIHRoYXQgaXQgZG9lcyBu b3Qgc2F5IHRoYXQgeW91IFNIT1VMRCBpbXBsZW1lbnQgdGhlIGNvbnRyb2wgcHJvdG9jb2wsIHlv dSBjYW4gc3RvcCBhZnRlciBpbXBsbWVudGluZyB0aGUgdGVzdCBwcm90b2NvbC4NCg0KDQpSb25p DQoNCg0KDQogDQoNCk9uIE1vbiwgTWFyIDI3LCAyMDE3IGF0IDU6MzkgUE0sIE1PUlRPTiwgQUxG UkVEIEMgKEFMKSDvvJxhY21vcnRvbkBhdHQuY29t77yeIHdyb3RlOg0KDQpSb25pLCBpbi1saW5l Og0KDQogDQoNCg0KDQpGcm9tOiBSb24gRXZlbiBbbWFpbHRvOnJvbi5ldmVuLnRsdkBnbWFpbC5j b21dIA0KU2VudDogTW9uZGF5LCBNYXJjaCAyNywgMjAxNyA1OjU0IFBNDQpUbzogTWFoZXNoIEpl dGhhbmFuZGFuaQ0KQ2M6IE1PUlRPTiwgQUxGUkVEIEMgKEFMKSBpcHBtQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9sIGFuZCByZWxh dGlvbnNoaXAgd2l0aCBPV0FNUC1UZXN0DQoNCg0KDQogDQoNCkhpLA0KDQpJIHJlYWQgYm90aCBS RkM1MzU3IGFuZCBSRkMgNDY1NiBhbmQgZXZlbiB0aG91Z2ggdGhleSBzYXkgdGhhdCBUV0FNUCBj b25zaXN0IG9mIHR3byBwcm90b2NvbCBpdCBuZXZlciBzYXlzIHRoYXQgIGJvdGggTVVTVCBiZSB1 c2VkIGFueXdoZXJlIGluIHRoZSBkb2N1bWVudC4gVGhlIGRvY3VtZW50IGRvZXMgbm90IGhhdmUg YSBsb3Qgb2Ygbm9ybWF0aXZlIHRleHQuDQoNCg0KIA0KDQoNClNlY3Rpb24gNSBvZiBSRkM1MzU3 IGlzIGFuIGV4YW1wbGUgYW5kIG5vdCBhIHJlcXVpcmVtZW50IGFuZCBldmVuIHRoZSB0ZXh0IHRo YXQgd2FzIG1lbnRpb25lZCBpbiB0aGUgSVBQTSBzZXNzaW9uDQoNCg0KIA0KDQoNCiJBcHBlbmRp eCBJIHByb3ZpZGVzIGFuIGV4YW1wbGUgZm9yIHB1cmVseSBpbmZvcm1hdGlvbmFsIHB1cnBvc2Vz LiBJdA0KDQogICBzdWdnZXN0cyBhbiBpbmNyZW1lbnRhbCBwYXRoIHRvIGFkb3B0aW5nIFRXQU1Q LCBieSBpbXBsZW1lbnRpbmcgdGhlICAgVFdBTVAtVGVzdCBwcm90b2NvbCBmaXJzdC4iIA0KRG9l cyBub3Qgc2F5IHRoYXQgdXNpbmcgVFdBTVAtVGVzdCB3aXRob3V0IHRoZSBjb250cm9sIHByb3Rv Y29sIFNIT1VMRCBOT1QgYmUgdXNlZC5bQUNNXU9mIGNvdXJzZSBpdCBkb2VzbuKAmXQhIEl0IHNh eXMgQXBwZW5kaXggSSBkZXNjcmliZXMgYXRoZSBmaXJzdCBzdGVwIG9mIG9uZSBwcm9jZXNzIG9m IHN0YW5kYXJkcy10cmFjayBUV0FNUGltcGxlbWVudGF0aW9uLCBieSBzdGFydGluZyB3aXRoIFRX QU1QLWxpZ2h0LCB0aGVuaW1wbGVtZW50aW5nIHRoZSByZXN0IG9mIFRXQU1QIChUV0FNUC1Db250 cm9sKS4gDQpBbCANCiANCiANCiANClJvbmkgRXZlbiANCiANCiANCiANCg0KDQogDQoNCk9uIE1v biwgTWFyIDI3LCAyMDE3IGF0IDQ6MjAgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkg77ycbWpldGhh bmFuZGFuaUBnbWFpbC5jb23vvJ4gd3JvdGU6DQoNCkdyZWcsDQoNCiANCg0KDQpBbmQgdGhlIHBh cnQgdGhhdCB5b3UgZm9yZ290IHRvIHF1b3RlIHRoYXQgZm9sbG93ZWQgaW4gU2VjdGlvbiAxLjEg aXM6DQoNCg0KIA0KDQpUV0FNUC0gICBDb250cm9sIGlzIHVzZWQgdG8gaW5pdGlhdGUsIHN0YXJ0 LCBhbmQgc3RvcCB0ZXN0IHNlc3Npb25zLCB3aGVyZWFzICAgVFdBTVAtVGVzdCBpcyB1c2VkIHRv IGV4Y2hhbmdlIHRlc3QgcGFja2V0cyBiZXR3ZWVuIHR3byBUV0FNUCAgIGVudGl0aWVzLg0KIA0K DQoNClRoZXJlIGlzIGNsZWFybHkgYSBwcmVjZWRlbmNlIGZvciBUV0FNUC1Db250cm9sIHRvIGJl IGEgZW50aXR5IGJ5IGl0c2VsZiBhbmQgdmVyeSBtdWNoIHBhcnQgb2YgdGhlIFRXQU1QIHByb3Rv Y29sLg0KDQoNCiANCg0KDQpJZiB0aGlzIGlzIHRoaXMgcmF0aW9uYWwgZm9yIHlvdXIgY29tbWVu dHMgb24gdGhlIFlBTkcgbW9kZWwsIHRoZW4gSSBmYWlsIHRvIHNlZSBSRkMgNTM1NyBiYWNraW5n IHlvdXIgY2xhaW0gdGhhdCBUV0FNUC1jb250cm9sIGlzIG9wdGlvbmFsLg0KDQoNCiANCg0KDQpD aGVlcnMuDQoNCg0KIA0KDQoNCk9uIE1hciAyNywgMjAxNywgYXQgNDowOCBQTSwgTU9SVE9OLCBB TEZSRUQgQyAoQUwpIO+8nGFjbW9ydG9uQGF0dC5jb23vvJ4gd3JvdGU6DQoNCg0KIA0KDQoNCg0K R3JlZywNCg0KDQogDQoNCg0KQWxsIGFtYmlndWl0eSBmYWxscyBhd2F5IGluIHRoZSBjb250ZXh0 IG9mDQoNCg0KdGhlIGNvbXBsZXRlIFRXQU1QIGRvY3VtZW50LCB3aGljaCBzYXlzOg0KDQoNCiAN Cg0KDQogICBUaGlzIGV4YW1wbGUgZWxpbWluYXRlcyB0aGUgbmVlZCBmb3IgdGhlIFRXQU1QLUNv bnRyb2wgcHJvdG9jb2wsIGFuZA0KDQoNCiAgIGFzc3VtZXMgdGhhdCB0aGUgU2Vzc2lvbi1SZWZs ZWN0b3IgaXMgY29uZmlndXJlZCBhbmQgY29tbXVuaWNhdGVzIGl0cw0KDQoNCiAgIGNvbmZpZ3Vy YXRpb24gd2l0aCB0aGUgU2VydmVyIHRocm91Z2ggbm9uLXN0YW5kYXJkIG1lYW5zLg0KDQoNCiAN Cg0KDQpUaGUgZXhhbXBsZSByZWZlcnJlZCB0byBhYm92ZSBpcyBub3QgVFdBTVANCg0KDQppdCBp cyB0aGUgb3B0aW9uIHlvdSBkZXNjcmliZSwgYnV0IGl0IGlzDQoNCg0KY2FsbGVkICpUV0FNUCBs aWdodCouDQoNCg0KIA0KDQoNCkFsDQoNCg0KIA0KDQoNCg0KDQpGcm9tOiBpcHBtIFttYWlsdG86 aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IE1v bmRheSwgTWFyY2ggMjcsIDIwMTcgMzoxNiBQTQ0KVG86IE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0K Q2M6IGlwcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbaXBwbV0gUkZDIDQ2NTYgb24gdXNlIG9m IE9XQU1QLUNvbnRyb2wgYW5kIHJlbGF0aW9uc2hpcCB3aXRoIE9XQU1QLVRlc3QNCg0KDQoNCg0K IA0KDQoNCkhpIEFsLA0KDQoNCnRoZW4sIGluIG15IG9waW5pb24sIHRoZXJlJ3MgY2VydGFpbiBh bWJpZ3VpdHkgaW4gdGhlIHRleHQgb2YgUkZDIDQ2NTYgYW5kIGluIFJGQyA1MzU3IGFzIHdlbGwg YmVjYXVzZSBvZiB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiB0aGUgdmVyeSBmaXJzdCBzZW50 ZW5jZSBvZiBzZWN0aW9uIDEuMSBSRkMgNTM1NzoNCg0KDQogICBTaW1pbGFyIHRvIE9XQU1QIFtS RkM0NjU2XSwgVFdBTVAgY29uc2lzdHMgb2YgdHdvIGludGVyLXJlbGF0ZWQgICBwcm90b2NvbHM6 IFRXQU1QLUNvbnRyb2wgYW5kIFRXQU1QLVRlc3QuICBUaGUgcmVsYXRpb25zaGlwIG9mIHRoZXNl ICAgcHJvdG9jb2xzIGlzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAxLjEgb2YgT1dBTVAgW1JGQzQ2 NTZdLiANClJlZ2FyZHMsR3JlZw0KDQoNCiANCg0KDQpPbiBNb24sIE1hciAyNywgMjAxNyBhdCAx MjoyNCBQTSwgTU9SVE9OLCBBTEZSRUQgQyAoQUwpIO+8nGFjbW9ydG9uQGF0dC5jb23vvJ4gd3Jv dGU6DQoNCg0KR3JlZywNCg0KDQogDQoNCg0KSWYgd2UgaGFkIG1lYW50IFJGQyAyMTE5IOKAnE1B WeKAnSBvciDigJxPUFRJT05BTOKAnSAodGhlIHRlcm0NCg0KDQp5b3UgdXNlZCB0b2RheSB3aGVu IHByZXNlbnRpbmcpIHdlIHdvdWxkIGhhdmUgdXNlZCB0aGUNCg0KDQpSRkMgMjExOSB0ZXJtIGlu IHRoZSB0ZXh0Lg0KDQoNCiANCg0KDQpUaGVyZSBhcmUgcGxlbnR5IG9mIG90aGVyIGV4YW1wbGVz IHdoZXJlIGJvdGggQ29udHJvbA0KDQoNCmFuZCBUZXN0IHByb3RvY29scyBhcmUgdGFrZW4gYXMg 4oCcdGhlIGZ1bGwgVFdBTVDigJ0uDQoNCg0KIA0KDQoNCkFsDQoNCg0KIA0KDQoNCiANCg0KDQoN Cg0KRnJvbTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEdyZWcgTWlyc2t5DQpTZW50OiBNb25kYXksIE1hcmNoIDI3LCAyMDE3IDEyOjI5IFBNDQpUbzog aXBwbUBpZXRmLm9yZw0KU3ViamVjdDogW2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1D b250cm9sIGFuZCByZWxhdGlvbnNoaXAgd2l0aCBPV0FNUC1UZXN0DQoNCg0KDQoNCiANCg0KDQpE ZWFyIEFsbCwNCg0KDQp0aGUgc2Vjb25kIHBhcmFncmFwaCBpbiBzZWN0aW9uIDEuMSBvZiBSRkMg NDY1NiBzdGF0ZXMgdGhlIGZvbGxvd2luZzoNCg0KDQogICBBbHRob3VnaCBPV0FNUC1UZXN0IG1h eSBiZSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggYSBjb250cm9sICAgcHJvdG9jb2wgb3RoZXIg dGhhbiBPV0FNUC1Db250cm9sLCB0aGUgYXV0aG9ycyBoYXZlIGRlbGliZXJhdGVseSAgIGNob3Nl biB0byBpbmNsdWRlIGJvdGggcHJvdG9jb2xzIGluIHRoZSBzYW1lIFJGQyB0byBlbmNvdXJhZ2Ug dGhlICAgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgb2YgT1dBTVAtQ29udHJvbCBhcyBh IGNvbW1vbiAgIGRlbm9taW5hdG9yIGNvbnRyb2wgcHJvdG9jb2wgZm9yIG9uZS13YXkgYWN0aXZl IG1lYXN1cmVtZW50cy4gDQpJIGludGVycHJldCAibWF5IGJlIHVzZWQiIGFzIE1BWSBwZXIgUkZD IDIxMTkuIFBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGlzIHNob3VsZCBub3QgYmUgdGhlIGNhc2Uu IA0KUmVnYXJkcyxHcmVnDQoNCg0KDQoNCg0KDQoNCg0KIA0KDQoNCg0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxp c3QNCmlwcG1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBwbQ0KDQoNCg0KIA0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQoNCg0KbWpldGhhbmFuZGFuaUBn bWFpbC5jb20NCg0KDQogDQoNCg0KIA0KDQoNCiANCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBsaXN0DQppcHBtQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFu YW5kYW5pQGdtYWlsLmNvbQ0KDQoNCiAgDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogaXBwbSBtYWlsaW5nIGxpc3QNCiBpcHBtQGlldGYu b3JnDQogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQogDQoNCg0K DQoNCg0KDQoNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb20= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Fully agree.

After the split of two sc= enarios the implementer and the operator can choose YANG model as needed ea= sily and clearly.


Best Regards,

Xiao Min

<= /div>
=E5= =8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6
<= div class=3D"control-group zhistoryPanel">
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A =EF=BC=9Cgregimirsky@gmail.com=EF=BC=9E;
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF= =BC=9A =EF=BC=9Cmjethanandani@gmail.com=EF=BC=9E;
=E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9A =EF=BC=9Cacmo= rton@att.com=EF=BC=9E; =EF=BC=9Cippm@ietf.org=EF=BC=9E;
=E6=97=A5 =E6=9C=9F =EF=BC=9A2017=E5=B9=B404=E6=9C=8808=E6=97=A5 08:55
=E4=B8=BB =E9=A2=98 =EF=BC=9ARe: [ippm] RFC 4656 on use of OWAMP= -Control and relationship withOWAMP-Test


Hi Mahesh,
if one u= ses TWAMP-Control model defined in draft-ietf-ippm-twamp-yang, then, a= ccording to Figure 2, there's no need neither for container session-sender,= nor for container session-reflector. In this case Session-Sender and Sessi= on-Reflector have only operational state data as all configuration from Con= trol-Client and Server communicated to them over proprietary APIs. If one w= ants to instantiate TWAMP test session using YANG model from draft-ietf-ipp= m-twamp-yang, then there will be several issues with parameters referring t= o a Control-Client. Hence I propose to work together to use YANG model from=  draft-mirsky-ippm-twamp-light-yang as TWAMP-Test for the second scena= rio.

Regards,
Greg

On Fri, Apr 7, 2017 at = 3:59 PM, Mahesh Jethanandani =EF=BC=9Cmjethanandani@gmail.com=EF= =BC=9E wrote:
Greg,

RFC 5357 defines both TWAMP-Cont= rol and TWAMP-Test and how they work together. The YANG module, which is ba= sed on the RFC, therefore models both. We see no reason to split the model.= As said before, there is no requirement that you have to implement/use the= entire model. 

Cheers.

On Apr 7, 2017, at 2:15= PM, Greg Mirsky =EF=BC=9Cgregimirsky@gmail.com=EF=BC=9E wrote:

Hi M= ahesh,
I think that there could be two models - TWAMP-Control and TWAMP= -Test. I don't see any good reason to have TWAMP-Test configuration model a= s part of TWAMP-Control. In fact, having it there makes control of a test s= ession ambiguous as only one of them must be used to configure a test sessi= on. TWAMP-Control model only needs test session operational state model and= it should use the one defined in TWAMP-Test model.

Regards,
Greg 
On Fri, Apr 7, 2017 at 10:57 AM, Mahesh Jetha= nandani =EF=BC=9Cmjethanandani@gmail.com=EF=BC=9E wrote:
Besi= des, from a YANG modeling perspective, the model has to model both the Cont= rol and Test part. Implementations that choose not to use Control can choos= e not to do so. 
On Mar 27, 2017, at 4:07 PM, MORTON, A= LFRED C (AL) =EF=BC=9Cacmorton@att.com=EF=BC=9E wrote:

I=E2=80=99m sorry Ron= i, but that=E2=80=99s exactly what this phrase,
= =E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6=E2=80=9D  means,
suggesting a multi-step process to achieve a full TWAMP
i= mplementation.
 
The sentence in the body sets the c= ontext for Appendix I.
It says the Appendix describes building TWA= MP-Test *first*.
Clearly, TWAMP-Test is not the f= inal step!
 
Al
 
From: Ron Even [mailto:ron.even.tlv@gmail.co= m] 
Sent: = ;Monday, March 27, 2017 6:54 PM
To:&= nbsp;MORTON, ALFRED C (AL)
Cc: = Mahesh Jethanandani; ippm@ietf.org
Subject: = Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Tes= t
 
Al= ,
The last part of your response  " then implementing the rest of TWAMP (TWAMP-Control)." is not there. This= is why I said that it does not say that you SHOULD implement the control p= rotocol, you can stop after implmenting the test protocol.<= /div>
Roni
 
On Mon, Mar 27, 2017 at 5:39 PM, MORTO= N, ALFRED C (AL) =EF=BC=9Cacmorton@att.com=EF=BC=9E wrote:
From: Ron Even [mailto:ron.even.tlv@gmail.com] 
Sent: Monday, Marc= h 27, 2017 5:54 PM
To: Mahesh Jet= hanandani
Cc: MORTON, ALFRED C (A= L); ippm@ietf.org
<= strong>Subject: Re: [ippm] RFC 4656 on use o= f OWAMP-Control and relationship with OWAMP-Test
 
Hi,
I= read both RFC5357 and RFC 4656 and even though they say that TWAMP consist= of two protocol it never says that  both MUST be used anywhere in the= document. The document does not have a lot of normative text.
<= div>
 
Section 5 of RFC53= 57 is an example and not a requirement and even the text that was mentioned= in the IPPM session
 
=
"Appendix I<= span style=3D"font-size:10pt"> provides an example fo= r purely informational purposes. It
  &nbs=
p;suggests an incremental path to adopting TW=
AMP, by implementing the
   TWAMP-T=
est protocol first."
 
Does not=
 say that using TWAMP-Test without the c=
ontrol protocol SHOULD NOT be used.
[ACM=
]
Of course it doesn=E2=80=99t! It says&=
nbsp;Appendix I describes a
the first st=
ep of one process of standards-track TWAMP
implementation, by starting with TWAMP-light,&n=
bsp;then
implementing the rest of TWAMP =
(TWAMP-Control).
 
Al
 
 
 
 
Roni&=
nbsp;Even
 
 
 
 
 
On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani =EF= =BC=9Cmjethanandani@gmail.com=EF= =BC=9E wrote:
Greg,
 = ;
And the part that you forgot to quote that= followed in Section 1.1 is:
 
TWAMP-
  &nb=
sp;Control is used to initiate, start, and&nb=
sp;stop test sessions, whereas
   T=
WAMP-Test is used to exchange test packets&nb=
sp;between two TWAMP
   entities.
<= div>
 
There is clearly a= precedence for TWAMP-Control to be a entity by itself and very much part o= f the TWAMP protocol.
 
If this is this rational for your comments on the YANG mode= l, then I fail to see RFC 5357 backing your claim that TWAMP-control is opt= ional.
 
Cheers.
 
On= Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) =EF=BC=9Cacmorton@att.com=EF=BC=9E wrote:
Greg,
&= nbsp;
All ambiguity falls away in the context of=
the complete TWAMP document, which says:
=  
   This example eliminates the need fo= r the TWAMP-Control protocol, and
   assumes = that the Session-Reflector is configured and communicates its
<= /div>
   configuration with the Server through non-standard mean= s.
 
The example referred to a= bove is not TWAMP;
it is the option you describe, but i= t is
called *TWAMP light*.
 
Al
 
From: ippm [mai= lto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Monday, Ma= rch 27, 2017 3:16 PM
To: MORTON, ALFRED C (AL)
Cc: ippm@ietf.org
Subject: Re: [ippm] RFC 4656 on = use of OWAMP-Control and relationship with OWAMP-Test
 
Hi = Al,
then, in my opinion, there's certai= n ambiguity in the text of RFC 4656 and in RFC 5357 as well because of the = following statement in the very first sentence of section 1.1 RFC 5357:
   Similar to OWAMP [=
RFC4656], TWAMP consists of two inter-related
   protocols: TWAMP-Control and TWAMP-T=
est.  The relationship of these
 &n=
bsp; protocols is as defined in Section =
1.1 of OWAMP [RFC4656].
 
Regar=
ds,
Greg
 
On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFR= ED C (AL) =EF=BC=9Cacmorton@att.com=EF=BC=9E wrote:
Greg,=
 
If we had meant RFC 2119 = =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80=9D (the term
<= /div>
you used today when presenting) we would have used the
<= /div>
RFC 2119 term in the text.
 
There are plenty of other examples where both Control
and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D.
 
Al
 
 
From: ippm [mailt= o:ippm-boun= ces@ietf.org]<= wbr> On Behalf Of Greg Mirsky
Sent: Monday, March 27= , 2017 12:29 PM
To: ippm@ietf.org
Subject: [ippm] RFC 4656 on use of = OWAMP-Control and relationship with OWAMP-Test
 
= Dear All,
the second paragraph in secti= on 1.1 of RFC 4656 states the following:
 =
;  Although OWAMP-Test may be used in&nb=
sp;conjunction with a control
   pr=
otocol other than OWAMP-Control, the authors =
have deliberately
   chosen to incl=
ude both protocols in the same RFC to&nb=
sp;encourage the
   implementation and&n=
bsp;deployment of OWAMP-Control as a common
<= pre style=3D"margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courier Ne= w'">   denominator control protocol for = one-way active measurements.
 
I&nbs=
p;interpret "may be used" as MAY per RFC=
 2119. Please let me know if this s=
hould not be the case.
 
R=
egards,
Greg
 
 
Mahesh Jethanandani
 
 
 


=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ippm mailing li= st
ippm@ietf.org
https://www.ietf.or= g/mailman/listinfo/ippm


<= div>Mahesh Jethanandani


 


=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm


Mahesh Jet= hanandani


 




--=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Mon Apr 10 07:18:30 2017 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 7EB17129490; Mon, 10 Apr 2017 07:18:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-ippm-twamp-time-format@ietf.org, Bill Cerveny , ippm-chairs@ietf.org, ietf@wjcerveny.com, ippm@ietf.org, jrmitche@puck.nether.net X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149183390250.3076.7292862107229671405.idtracker@ietfa.amsl.com> Date: Mon, 10 Apr 2017 07:18:22 -0700 Archived-At: Subject: [ippm] Benoit Claise's No Objection on draft-ietf-ippm-twamp-time-format-05: (with COMMENT) 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, 10 Apr 2017 14:18:23 -0000 Benoit Claise has entered the following ballot position for draft-ietf-ippm-twamp-time-format-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Good feedback from Jon Mitchell, in his OPS-DIR review: Indeed, TWAMP Test, and the time stamp format to be used, may be controlled by means other than TWAMP Control, e.g., local configurable knob exposed via data model or CLI. I'll work on text updates for the next version. Regards, Greg On Fri, Mar 17, 2017 at 2:01 PM, Jon Mitchell wrote: Reviewer: Jon Mitchell Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Ready with Nits - this draft adds the ability to use PTP timestamps as an alternative to NTP timestamps for active performance measurement protocols OWAMP and TWAMP. Although this draft does a good job of discussing interoperability for both sides of the session having or not having support for this operational capability, in several places it states that if a send/receiver support this capability it must be set to 1 in the flags. However, only for TWAMP Light mode, this seems configurable. This may just be my interpretation, but it probably should state that local implementations MAY provide a configurable knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even if the capability is supported by the implementation. From nobody Mon Apr 10 09:29:55 2017 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 06ADF129A96; Mon, 10 Apr 2017 09:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 qTuLl8UImgpZ; Mon, 10 Apr 2017 09:29:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E35129AA2; Mon, 10 Apr 2017 09:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14370; q=dns/txt; s=iport; t=1491841774; x=1493051374; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3N0lx491XMGwu2lKafeBH6/df+/WVUwBsfNFdfduwyg=; b=DCQPPyiw/8x7IczxzdQAo9iX914dfdAeA8acXCspTWamgTiDmzDSZsdi DjX0yz97sPvTBmvxEslQ/jzxwHZiy2eY9MD5bqQEyizXpSwbRtVzrMgnb xyH5Ramj9/cMBzcqGDju9oKBDHprp142UJ3Xf2ENI1kEjAh5jRnQJ+H9Y g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAQBSsutY/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrYYELB4NfihORR5VXgg8hC4JCgzYCGoNJPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEhETMHCwUHBAIBCBEEAQEBAgIREgMCAgIlCxQBCAgCBA4FC?= =?us-ascii?q?Il/CA6pBIImin0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUWEcIMXgREKAQY?= =?us-ascii?q?BW4JHgl8FiSqTUQGGf4tQggiPQohjixwBHzh9CFsVQYRbHIFjdQGHIQEOF4EKg?= =?us-ascii?q?Q0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="229044948" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 16:29:33 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3AGTX42020764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 16:29:33 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 11:29:32 -0500 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.1210.000; Mon, 10 Apr 2017 11:29:32 -0500 From: "Frank Brockners (fbrockne)" To: Sarah B CC: ALFRED MORTON , "adrian@olddog.co.uk" , "Brian Trammell (IETF)" , "IPPM Chairs" , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ALTeVSHHK04UeHAEB7HUBtbKGqypeAgAAD3ACAAAfTAIAAIx6AgAA2hgCAAJuA4IAAxDyAgAAcNwCAABufgIAA1nmggA01g4CABATw0A== Date: Mon, 10 Apr 2017 16:29:32 +0000 Message-ID: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> In-Reply-To: <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> 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.190.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 10 Apr 2017 16:29:54 -0000 SGkgU2FyYWgsDQoNCnRoYW5rcyAtIGJvdGggeW91IGFuZCBBZHJpYW4gaGlnaGxpZ2h0ZWQgdGhl IG5lZWQgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIGZvciB3aGF0IHRoZSBp bXBhY3Qgb2YgSU9BTSBjb3VsZCBiZSB0byBFQ01QIHByb2Nlc3NpbmcsIHBhdGggTVRVIGFuZCBJ Q01QIG1lc3NhZ2UgaGFuZGxpbmcuIFdoaWxlIHRoZSBkZXRhaWxlZCBjb25zaWRlcmF0aW9ucyBm b3IgdGhlIGltcGFjdCBhcmUgdHJhbnNwb3J0IHByb3RvY29sIGRlcGVuZGVudCBhbmQgYXMgc3Vj aCBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0aGF0IGRpc2N1c3NlcyB0aGUgZGF0 YS1maWVsZHMgYW5kIGRhdGEtdHlwZXMgZm9yIElPQU0sIEkgYWdyZWUgdGhhdCBpdCBkb2VzIG1h a2Ugc2Vuc2UgdG8gcHJvdmlkZSBzb21lIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbiBhbmQgYXQgbGVh c3QgbWVudGlvbiBhIGNvdXBsZSBvZiBleGFtcGxlIGNhc2VzLiANCg0KSG93IGFib3V0OiAiVGhl IG9wZXJhdG9yIG9mIHN1Y2ggYSBkb21haW4gTVVTVCBwdXQgcHJvdmlzaW9ucyBpbiBwbGFjZSB0 byBlbnN1cmUgdGhhdCBpbi1zaXR1IE9BTSBkYXRhIHN0YXlzIHdpdGhpbiB0aGUgc3BlY2lmaWMg ZG9tYWluIG9ubHkgKGkuZS4sIGRvZXMgbm90IGxlYWsgYmV5b25kIHRoZSBlZGdlKSB1c2luZyBm b3IgZXhhbXBsZSBwYWNrZXQgZmlsdGVyaW5nIG1ldGhvZHMuIFRoZSBvcGVyYXRvciBTSE9VTEQg Y29uc2lkZXIgcG90ZW50aWFsIG9wZXJhdGlvbmFsIGltcGFjdCBvZiBJT0FNIHRvIG1lY2hhbmlz bXMgc3VjaCBhcyBFQ01QIHByb2Nlc3NpbmcgKGUuZy4gbG9hZC1iYWxhbmNpbmcgc2NoZW1lcyBi YXNlZCBvbiBwYWNrZXQgbGVuZ3RoIGNvdWxkIGJlIGltcGFjdGVkIGJ5IHRoZSBpbmNyZWFzZWQg cGFja2V0IHNpemUgZHVlIHRvIElPQU0pLCBwYXRoIE1UVSAoaS5lLiBlbnN1cmUgdGhhdCB0aGUg TVRVIG9mIGFsbCBsaW5rcyB3aXRoaW4gYSBkb21haW4gaXMgc3VmZmljaWVudGx5IGxhcmdlIHRv IHN1cHBvcnQgdGhlIGluY3JlYXNlZCBwYWNrZXQgc2l6ZSBkdWUgdG8gSU9BTSkgYW5kIElDTVAg bWVzc2FnZSBoYW5kbGluZyAoaS5lLiBpbiBjYXNlIG9mIGEgbmF0aXZlIElQdjYgdHJhbnNwb3J0 LCBJT0FNIHN1cHBvcnQgZm9yIElDTVB2NiBFY2hvIFJlcXVlc3QvUmVwbHkgY291bGQgZGVzaXJl ZCB3aGljaCB3b3VsZCB0cmFuc2xhdGUgaW50byBJQ01QdjYgZXh0ZW5zaW9ucyB0byBlbmFibGUg SU9BTSBkYXRhIGZpZWxkcyB0byBiZSBjb3BpZWQgZnJvbSBhbiBFY2hvIFJlcXVlc3QgbWVzc2Fn ZSB0byBhbiBFY2hvIFJlcGx5IG1lc3NhZ2UpLiINCg0KVGhvdWdodHM/DQoNClRoYW5rcywgRnJh bmsNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2FyYWggQiBbbWFpbHRv OnNiYW5rc0BlbmNyeXB0ZWQubmV0XSANClNlbnQ6IEZyZWl0YWcsIDcuIEFwcmlsIDIwMTcgMjM6 NDENClRvOiBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVAY2lzY28uY29tPg0K Q2M6IEFMRlJFRCBNT1JUT04gPGFjbW9ydG9uQGF0dC5jb20+OyBhZHJpYW5Ab2xkZG9nLmNvLnVr OyBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+OyBJUFBNIENoYWlycyA8 aXBwbS1jaGFpcnNAaWV0Zi5vcmc+OyBpcHBtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2lwcG1d IFZvdGUgYXQgSVBQTSBzZXNzaW9uDQoNCkhpIEZyYW5rLA0KCVRoYW5rcyBmb3IgdGhlIHRpbWVs eSB1cGRhdGUuDQoJQXQgZmlyc3QgZ2xhbmNlLCByZWFkaW5nIHRocm91Z2ggdGhlIGJlbG93LCBJ IHZlcnkgbXVjaCBhcHByZWNpYXRlIHRoZSBzcGVjaWZpYyB0ZXh0IG91dGxpbmluZyBleHBsaWNp dGx5IHdoZXJlIHRoZSBJT0FNIGlzIGV4cGVjdGVkIHRvIGJlIGxpbWl0ZWQgdG87IHRoYXQgdGhl cmUgaXMgYSBsaW1pdCBhdCBhbGwsIGFuZCB0aGF0IGl0J3MgZG9tYWluIHNwZWNpZmljIChwaWNr aW5nIHVwIG9uIHRoZSBjb21tZW50IGluIHRoZSBJUFBNIHNlc3Npb24gdG8gY2FsbCB0aGlzIG91 dCkuIFRoYW5rcy4gVGhpcyBzZWVtcyB0byBtYWtlIHNlbnNlLiBUaGVyZSBpcyBhIHNlY3Rpb24g YmVsb3cgdGhhdCBnaXZlcyBtZSBwYXVzZTogIjxzbmlwPlRoZSBvcGVyYXRvciBvZiBzdWNoIGEg ZG9tYWluIE1VU1QgcHV0IHByb3Zpc2lvbnMgaW4gcGxhY2UgdG8gZW5zdXJlIHRoYXQgaW4tc2l0 dSBPQU0gZGF0YSBzdGF5cyB3aXRoaW4gdGhlIHNwZWNpZmljIGRvbWFpbiBvbmx5IChpLmUuLCBk b2VzIG5vdCBsZWFrIGJleW9uZCB0aGUgZWRnZSkgYW5kIGNvbnNpZGVyIHBvdGVudGlhbCBpbXBh Y3Qgb2YgSU9BTSB0byBFQ01QIHByb2Nlc3NpbmcsIHBhdGggTVRVIGFuZCBJQ01QIG1lc3NhZ2Ug aGFuZGxpbmcuIiBJJ20gc3VyZSBldmVyeSBvcGVyYXRvciBvciBpbXBsZW1lbnRhdGlvbiB3aWxs IGhhdmUgdGhlIGJlc3QgbGFpZCBwbGFucyBpbiBtaW5kLCBidXQgaWYgdGhlcmUncyBhIG1pc2Nv bmZpZ3VyZWQgb3Igb3RoZXJ3aXNlIG1hbGljaW91cyBjb25maWd1cmF0aW9uIHdoZXJlaW4gdGhl IElPQU0gZG9lcyBpbmRlZWQgbGVhayBvdXRzaWRlIG9mIHRoZSBkb21haW4sIHdoYXQgdGhlbj8g SW5zdGVhZCBvZiBzaW1wbHkgYXNraW5nIHRoZSB1c2VyIHRvIG5vdCBhbGxvdyB0aGlzLCBwcm92 aWRlIHByb2FjdGl2ZSBhZHZpY2Ugb24gb3B0aW9ucyB0byBhbGxldmlhdGUgb3IgcmVtZWRpYXRl IHRoaXMgcG9zc2liaWxpdHkuIFdvdWxkIHlvdSBhbHNvIGNvbnNpZGVyIGVpdGhlciBtYWtpbmcg dGhlICJhbmQgY29uc2lkZXIgcG90ZW50aWFsIGltcGFjdCIgYSBzZXBhcmF0ZSBleHBsaWNpdCBN VVNUIG9yIFNIT1VMRCAob3Igb3RoZXJ3aXNlKSByZXF1aXJlbWVudCwgd2l0aCBhIGxpdHRsZSBt b3JlIGNsYXJpdHkgYXJvdW5kIHdoYXQgeW91IG1lYW4gZm9yIHBvdGVudGlhbCBpbXBhY3Q/DQoN ClRoYW5rcw0KU2FyYWgNCg0KDQoNCj4gT24gTWFyIDMxLCAyMDE3LCBhdCA3OjI3IEFNLCBGcmFu ayBCcm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+ IFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb25zIGFuZCBjb21tZW50cy4gV2UndmUgcG9zdGVkIGEg bmV3IHJldmlzaW9uIG9mIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEuDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDQudHh0 IGluY2x1ZGVzIHNlY3Rpb24gMyBvbiBTY29wZSwgQXBwbGljYWJpbGl0eSwgYW5kIEFzc3VtcHRp b25zLCBjYXB0dXJpbmcgdGhlIGRpc2N1c3Npb24gd2UgaGFkIGluIHRoZSBXRyBtZWV0aW5nIGFu ZCBvbiB0aGUgbGlzdC4gV2UndmUgYWxzbyB1cGRhdGVkIHRoZSBpbnRyb2R1Y3Rpb24gdG8gcmVm ZXIgdG8gUkZDNzc5OSBhbmQgY2xhc3NpZnkgaW4tc2l0dSBPQU0gYXBwcm9wcmlhdGVseSBhcyBo eWJyaWQsIHR5cGUtMSBPQU0uDQo+IA0KPiBGb3IgZXZlcnlvbmUncyBiZW5lZml0LCBoZXJlIGlz IGEgcXVvdGUgb2YgdGhlIG5ldyBzZWN0aW9uIDM6DQo+IA0KPiAzLiAgU2NvcGUsIEFwcGxpY2Fi aWxpdHksIGFuZCBBc3N1bXB0aW9ucw0KPiANCj4gICBJbi1zaXR1IE9BTSBkZXBsb3ltZW50IGFz c3VtZXMgYSBzZXQgb2YgY29udHJhaW50cywgcmVxdWlyZW1lbnRzLCBhbmQNCj4gICBndWlkaW5n IHByaW5jaXBsZXMgd2hpY2ggYXJlIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24uDQo+IA0KPiAg IFNjb3BlOiBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGRhdGEgZmllbGRzIGFuZCBhc3NvY2lh dGVkIGRhdGENCj4gICB0eXBlcyBmb3IgaW4tc2l0dSBPQU0uICBUaGUgaW4tc2l0dSBPQU0gZGF0 YSBmaWVsZCBjYW4gYmUgdHJhbnNwb3J0ZWQNCj4gICBieSBhIHZhcmlldHkgb2YgdHJhbnNwb3J0 IHByb3RvY29scywgaW5jbHVkaW5nIE5TSCwgU2VnbWVudCBSb3V0aW5nLA0KPiAgIFZYTEFOLUdQ RSwgR2VuZXZlLCBJUHY2LCBvciBJUHY0LiAgRW5jYXBzdWxhdGlvbiBkZXRhaWxzIGZvciB0aGVz ZQ0KPiAgIGRpZmZlcmVudCB0cmFuc3BvcnQgcHJvdG9jb2xzIGFyZSBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gICBEZXBsb3ltZW50IGRvbWFpbiAob3Igc2NvcGUp IG9mIGluLXNpdHUgT0FNIGRlcGxveW1lbnQ6IElPQU0gaXMgYQ0KPiAgIG5ldHdvcmsgZG9tYWlu IGZvY3VzZWQgZmVhdHVyZSwgd2l0aCAibmV0d29yayBkb21haW4iIGJlaW5nIGEgc2V0IG9mDQo+ ICAgbmV0d29yayBkZXZpY2VzIG9yIGVudGl0aWVzIHdpdGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJh dGlvbi4gIEZvcg0KPiAgIGV4YW1wbGUsIGEgbmV0d29yayBkb21haW4gY2FuIGluY2x1ZGUgYW4g ZW50ZXJwcmlzZSBjYW1wdXMgdXNpbmcNCj4gICBwaHlzaWNhbCBjb25uZWN0aW9ucyBiZXR3ZWVu IGRldmljZXMgb3IgYW4gb3ZlcmxheSBuZXR3b3JrIHVzaW5nDQo+ICAgdmlydHVhbCBjb25uZWN0 aW9ucyAvIHR1bm5lbHMgZm9yIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIHNhaWQgZGV2aWNlcy4NCj4g ICBBIG5ldHdvcmsgZG9tYWluIGlzIGRlZmluZWQgYnkgaXRzIHBlcmltaXRlciBvciBlZGdlLiAg VGhlIG9wZXJhdG9yDQo+ICAgb2Ygc3VjaCBhIGRvbWFpbiBNVVNUIHB1dCBwcm92aXNpb25zIGlu IHBsYWNlIHRvIGVuc3VyZSB0aGF0IGluLXNpdHUNCj4gICBPQU0gZGF0YSBzdGF5cyB3aXRoaW4g dGhlIHNwZWNpZmljIGRvbWFpbiBvbmx5IChpLmUuLCBkb2VzIG5vdCBsZWFrDQo+ICAgYmV5b25k IHRoZSBlZGdlKSBhbmQgY29uc2lkZXIgcG90ZW50aWFsIGltcGFjdCBvZiBJT0FNIHRvIEVDTVAN Cj4gICBwcm9jZXNzaW5nLCBwYXRoIE1UVSBhbmQgSUNNUCBtZXNzYWdlIGhhbmRsaW5nLg0KPiAN Cj4gICBJbi1zaXR1IE9BTSBjb250cm9sIHBvaW50czogSU9BTSBkYXRhIGZpZWxkcyBhcmUgYWRk ZWQgdG8gb3IgcmVtb3ZlZA0KPiAgIGZyb20gdGhlIGxpdmUgdXNlciB0cmFmZmljIGJ5IHRoZSBk ZXZpY2VzIHdoaWNoIGZvcm0gdGhlIGVkZ2Ugb2YgYQ0KPiAgIGRvbWFpbi4gIERldmljZXMgd2l0 aGluIGFuIElPQU0gZG9tYWluIGNhbiB1cGRhdGUgYW5kL29yIGFkZCBJT0FNDQo+ICAgZGF0YS1m aWVsZHMuICBEb21haW4gZWRnZSBkZXZpY2VzIGNhbiBiZSBob3N0cyBvciBuZXR3b3JrIGRldmlj ZXMuDQo+IA0KPiAgIFRyYWZmaWMtc2V0cyB0aGF0IGluLXNpdHUgT0FNIGlzIGFwcGxpZWQgdG86 IElPQU0gY2FuIGJlIGRlcGxveWVkIG9uDQo+ICAgYWxsIG9yIG9ubHkgb24gc3Vic2V0cyBvZiB0 aGUgbGl2ZSB1c2VyIHRyYWZmaWMuICBJdCBTSE9VTEQgYmUNCj4gICBwb3NzaWJsZSB0byBlbmFi bGUgaW4tc2l0dSBPQU0gb24gYSBzZWxlY3RlZCBzZXQgb2YgdHJhZmZpYyAoZS5nLiwNCj4gICBw ZXIgaW50ZXJmYWNlLCBiYXNlZCBvbiBhbiBhY2Nlc3MgY29udHJvbCBsaXN0IG9yIGZsb3cgc3Bl Y2lmaWNhdGlvbg0KPiAgIGRlZmluaW5nIGEgc3BlY2lmaWMgc2V0IG9mIHRyYWZmaWMsIGV0Yy4p ICBUaGUgc2VsZWN0ZWQgc2V0IG9mDQo+ICAgdHJhZmZpYyBjYW4gYWxzbyBiZSBhbGwgdHJhZmZp Yy4NCj4gDQo+ICAgRW5jYXBzdWxhdGlvbiBpbmRlcGVuZGVuY2U6IERhdGEgZm9ybWF0cyBmb3Ig aW4tc2l0dSBPQU0gU0hPVUxEIGJlDQo+ICAgZGVmaW5lZCBpbiBhIHRyYW5zcG9ydC1pbmRlcGVu ZGVudCBtYW5uZXIuICBJbi1zaXR1IE9BTSBhcHBsaWVzIHRvIGENCj4gICB2YXJpZXR5IG9mIGVu Y2Fwc3VsYXRpbmcgcHJvdG9jb2xzLiAgQSBkZWZpbml0aW9uIG9mIGhvdyBJT0FNIGRhdGENCj4g ICBmaWVsZHMgYXJlIGNhcnJpZWQgYnkgZGlmZmVyZW50IHRyYW5zcG9ydCBwcm90b2NvbHMgaXMg b3V0c2lkZSB0aGUNCj4gICBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gICBMYXllcmlu ZzogSWYgc2V2ZXJhbCBlbmNhcHN1bGF0aW9uIHByb3RvY29scyAoZS5nLiwgaW4gY2FzZSBvZg0K PiAgIHR1bm5lbGluZykgYXJlIHN0YWNrZWQgb24gdG9wIG9mIGVhY2ggb3RoZXIsIGluLXNpdHUg T0FNIGRhdGEtcmVjb3Jkcw0KPiAgIGNvdWxkIGJlIHByZXNlbnQgYXQgZXZlcnkgbGF5ZXIuICBU aGUgYmVoYXZpb3IgZm9sbG93cyB0aGUgc2hpcHMtaW4tDQo+ICAgdGhlLW5pZ2h0IG1vZGVsLg0K PiANCj4gICBDb21iaW5hdGlvbiB3aXRoIGFjdGl2ZSBPQU0gbWVjaGFuaXNtczogSW4tc2l0dSBP QU0gU0hPVUxEIGJlIHVzYWJsZQ0KPiAgIGZvciBhY3RpdmUgbmV0d29yayBwcm9iaW5nLCBlbmFi bGluZyBmb3IgZXhhbXBsZSBhIGN1c3RvbWl6ZWQgdmVyc2lvbg0KPiAgIG9mIHRyYWNlcm91dGUu ICBEZWNhcHN1bGF0aW5nIGluLXNpdHUgT0FNIG5vZGVzIG1heSBoYXZlIGFuIGFiaWxpdHkNCj4g ICB0byBzZW5kIHRoZSBpbi1zaXR1IE9BTSBpbmZvcm1hdGlvbiByZXRyaWV2ZWQgZnJvbSB0aGUg cGFja2V0IGJhY2sgdG8NCj4gICB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBvciB0 byB0aGUgZW5jYXBzdWxhdGluZyBub2RlLg0KPiANCj4gICBJbS1zaXR1IE9BTSBpbXBsZW1lbnRh dGlvbjogVGhlIElPQU0gZGF0YS1maWVsZCBkZWZpbml0aW9ucyB0YWtlIHRoZQ0KPiAgIHNwZWNp ZmljcyBvZiBkZXZpY2VzIHdpdGggaGFyZHdhcmUgZGF0YS1wbGFuZSBhbmQgc29mdHdhcmUgZGF0 YS1wbGFuZQ0KPiAgIGludG8gYWNjb3VudC4NCj4gDQo+IFRob3VnaHRzL2NvbW1lbnRzPyBXaXRo IHRoZXNlIGNoYW5nZXMsIGFyZSB3ZSBhYmxlIHRvIGtpY2stb2ZmIGFuIGFkb3B0aW9uIGNhbGw/ DQo+IA0KPiBUaGFua3MsIEZyYW5rDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBNT1JUT04sIEFMRlJFRCBDIChBTCkgW21haWx0bzphY21vcnRvbkBhdHQuY29tXQ0K PiBTZW50OiBNaXR0d29jaCwgMjkuIE3DpHJ6IDIwMTcgMTg6MTENCj4gVG86IGFkcmlhbkBvbGRk b2cuY28udWs7ICdCcmlhbiBUcmFtbWVsbCAoSUVURiknIDxpZXRmQHRyYW1tZWxsLmNoPjsgDQo+ IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb20+DQo+IENjOiAn SVBQTSBDaGFpcnMnIDxpcHBtLWNoYWlyc0BpZXRmLm9yZz47IGlwcG1AaWV0Zi5vcmcNCj4gU3Vi amVjdDogUkU6IFtpcHBtXSBWb3RlIGF0IElQUE0gc2Vzc2lvbg0KPiANCj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KPj4gU2VudDogV2VkbmVzZGF5LCBNYXJj aCAyOSwgMjAxNyA1OjMyIFBNDQo+PiBUbzogJ0JyaWFuIFRyYW1tZWxsIChJRVRGKSc7ICdGcmFu ayBCcm9ja25lcnMgKGZicm9ja25lKScNCj4+IENjOiAnSVBQTSBDaGFpcnMnOyBpcHBtQGlldGYu b3JnDQo+PiBTdWJqZWN0OiBSZTogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uDQo+PiANCj4+ Pj4gVGhlcmUgd2VyZSBzZXZlcmFsIHF1ZXN0aW9ucyByZWxhdGVkIHRvIHNjb3BlIGFuZCBhcHBs aWNhYmlsaXR5IGluIA0KPj4+PiB0aGUgV0cNCj4+PiBkaXNjdXNzaW9uIOKAkyBhbmQgZXZlbiBt b3JlIHJlY2VudGx5IG9uIHRoZSBsaXN0LiBUaG9zZSBjYW4gZWFzaWx5IGJlIA0KPj4+IGFkZHJl c3NlZCBieSBhZGRpbmcgcGFyYWdyYXBoIG9uIGFwcGxpY2FiaWxpdHkgdG8gDQo+Pj4gZHJhZnQt YnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSDigJMgdGhlcmUgaXNu4oCZdCBhIG5lZWQgZm9yIGEg ZGVkaWNhdGVkIHJlcXVpcmVtZW50cyBkb2N1bWVudC4NCj4+PiANCj4+PiBJIHRlbmQgdG8gYWdy ZWUgd2l0aCB0aGlzLCBhbHRob3VnaCAiYSBwYXJhZ3JhcGgiIHNlZW1zIGEgbGl0dGxlIA0KPj4+ IHRoaW4gdG8gbWUuIEkgdGhpbmsgdGhlcmUgd2VyZSBzb21lIHZhbGlkIHBvaW50cyBtYWRlIGlu IHRoYXQgDQo+Pj4gZGlzY3Vzc2lvbiBhYm91dCB0aGUgc2NvcGUgb2YgdGhlIHByb3Bvc2FsIHRo YXQgc2hvdWxkIGJlIGFkZHJlc3NlZDoNCj4+PiBpcyBJT0FNIG1lYW50IGZvciB1c2UgdHVubmVs LWVuZC0gdG8tdHVubmVsLSBlbmQgZW52aXJvbm1lbnQsIA0KPj4+IGVuZC1ob3N0LXRvLWVuZC1o b3N0LCB3aXRoaW4gYSBzaW5nbGUgbmV0d29yayBhbmQvb3IgYWNyb3NzIHRoZSANCj4+PiBJbnRl cm5ldC4gIFdoYXQgSSB3b3VsZCBzdWdnZXN0IGlzIGFkZGluZyBhIHNlY3Rpb24gdG8gdGhlIGRh dGEgDQo+Pj4gbW9kZWwgZHJhZnQgb24gYXBwbGljYWJpbGl0eSBhbmQgYXNzdW1wdGlvbnMgYWJv dXQgdGhlIGVudmlyb25tZW50DQo+Pj4gLS0gYm90aCBhYm91dCB0aGUgZGV2aWNlcyBhZGRpbmcg SU9BTSBzaWduYWxzIHRvIHRyYWZmaWMgYXMgd2VsbCBhcyANCj4+PiB0aG9zZSBjb25zdW1pbmcg dGhlc2Ugc2lnbmFscyBmcm9tIHRoZSB3aXJlIGFuZCBhbmFseXppbmcgdGhlbSANCj4+PiAocG9z c2libHkgd2l0aCB0aGUgY29vcGVyYXRpb24gb2YgZGV2aWNlcyBub3Qgb24gdGhlDQo+Pj4gd2ly ZSkgLS0gc3VibWl0dGluZyBhIG5ldyByZXZpc2lvbiwgYW5kIHdlIGNhbiBydW4gYSBtb3JlIGZv cm1hbCANCj4+PiBhZG9wdGlvbiBjYWxsIG9uIHRoYXQuDQo+PiANCj4+IEFsdGhvdWdoIEkgd2Fz IG9uZSBvZiB0aGUgcGVvcGxlIHJhaXNpbmcgdGhlICJuZWVkIiBmb3IgdGhlIHNjb3BlIGFuZCAN Cj4+IHJlcXVpcmVtZW50cywgSSBkb24ndCBoYXZlIGEgc3Ryb25nIGxlYWRpbmcgb24gd2hldGhl ciB0aGlzIG5lZWRzIHRvIA0KPj4gYmUgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBvbiBmb2xkZWQg aW50byB0aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQuIFNvIA0KPj4gQnJpYW4ncyBwcm9wb3NhbCB3 b3VsZCB3b3JrIGZvciBtZS4NCj4+IA0KPj4gVGh1cywgSSdkIGxvdmUgdG8gc2VlIHRoaXMgc2Nv cGluZyB0ZXh0IGRyYWZ0ZWQgYW5kIGZsb2F0ZWQgdG8gdGhlIA0KPj4gbGlzdCBhcyBhbiBlbWFp bCBvciBpbiBhIHJldmlzaW9uIG9mIHRoZSBkYXRhIGZvcm1hdCBkb2N1bWVudC4NCj4+IA0KPj4g Q2hlZXJzLA0KPj4gQWRyaWFuDQo+IFtBQ01dDQo+IA0KPiArMSBmb3IgYWRkaW5nIGEgU2NvcGUg c2VjdGlvbiB0bw0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJz LWluYmFuZC1vYW0tZGF0YS0wMg0KPiANCj4gSSBmZWx0IHRoYXQgSSB1bmRlcnN0b29kIHRoZSBz Y29wZSBnb2luZyBpbnRvIHRoZSBkaXNjdXNzaW9uIE1vbmRheSBhbmQgdGhlIGFwcGxpY2FibGUg KHJlc3RyaWN0ZWQpIGRvbWFpbiAoSSBkaWQgdGhlIGhvbWV3b3JrLCB0aGUgc2luZ2xlIGRyYWZ0 IEZyYW5rIGludHJvZHVjZWQgb24gdGhlIG1haWxpbmcgbGlzdCB3YXMgWzBdICkuDQo+IA0KPiBT b21lIGFkZGl0aW9uYWwgcXVlc3Rpb25zIGhhdmUgYmVlbiByYWlzZWQgKGUuZy4sICJ3aGVyZSB3 aWxsIE9BTSBiZSBpbnNlcnRlZCBhbmQgcmVtb3ZlZD8iKSBhbmQgSSdkIGxpa2UgdG8gc2VlIHRo b3NlIGl0ZW1zIHNvcnRlZC1vdXQgYmVmb3JlIHdlIGdvIHZlcnkgZmFyICh0aGUgYWR2YW50YWdl IG9mIHdpZGVyIHJldmlldykuDQo+IA0KPiBUaGUgcmVxdWlyZW1lbnRzIGRyYWZ0IG9ubHkgY2Ft ZS11cCB3aGVuIEkgYXNrZWQgc29tZSBxdWVzdGlvbnMgb24gdGhlIGxpc3QuIEZyYW5rIG1lbnRp b25lZCB0aGF0IHRoZSBvdXIgbGlzdCBkaXNjdXNzaW9uIG9uIGVxdWl2YWxlbnQgdHJlYXRtZW50 IG9mIE9BTSAmIG5vbi1PQU0gcGFja2V0cyAoImNsYXNzIEMiKSB3YXMgYWRkZWQgdG8gdGhlIHJl cXVpcmVtZW50cyBkb2N1bWVudCwgYW5kIHRoYXQgc2hvdWxkIG1vdmUgdG8gLW9hbS1kYXRhLSB0 b28uDQo+IA0KPiBJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYSB2ZXJzaW9uIG9mIHRoZSBzY29w ZSB0byByZXZpZXcgQVNBUC4NCj4gDQo+IHRoYW5rcyBhbmQgcmVnYXJkcywNCj4gQWwNCj4gDQo+ IFswXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1v YW0tZGF0YS0wMg0KPiANCj4gDQo+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gaXBwbSBtYWlsaW5nIGxpc3QNCj4+IGlwcG1AaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0NCj4+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pcHBtJmQ9RHdJR2FRJmM9 TEZZWi0NCj4+IG85X0hVTWVNVFNRaWN2aklnJnI9T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZtPUdh cXVjenRLNTdmVGozdnlZY01uSEc5WQ0KPj4gSw0KPj4gTDEgdFZrQVNRNUMzS2g2M29vQSZzPU1l c002QkZaeUVrVlBxc0dxMkhvNExLU19BNG50ZjVYNWhMMFN4MFJzZGMmZT0NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaXBwbSBtYWlsaW5nIGxp c3QNCj4gaXBwbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwcG0NCg0K From nobody Mon Apr 10 09:31:20 2017 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 09034129562; Mon, 10 Apr 2017 09:31:19 -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 cCvon_4EYswA; Mon, 10 Apr 2017 09:31:17 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B777129566; Mon, 10 Apr 2017 09:31:08 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id r203so154162158oib.3; Mon, 10 Apr 2017 09:31:08 -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=2JVZHc7hX/az4HfFf4s/+OtOczCIPY/kINpgO+x1xLY=; b=aYHzaOqE6IdE7AZP0LWcfGKEJzk9y8hpXDBTm3BQIxnJsEg/dnuYReBqZgOqz6Gfg3 nSNSgPnuXSuOG+ECIyiHs3oD6ia3FhY0jXFw3C9ZsUHBLatAxuBF4WtdxotkuAm/5oCn n3pbQRkgof8OGAijQnv0c+Z2KO0dgKB7AoxRljC670z1LGI6lq/3LWyWXfR0IHFg0lbf VvIKT6NW+b8xL0qCVe5jlEu5fE7h7Vt/hemgWkLs1VkmSjvFEZcHh+E/zOwYjh+yGuUd 1d1tZ11zMiTSNrBHbaOL25iL6OExb3ALDAgqwFGOWhFVvoLiw5EaF5ZaFoG/FvZo9Sez htlA== 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=2JVZHc7hX/az4HfFf4s/+OtOczCIPY/kINpgO+x1xLY=; b=sWk/qx9m+BhKbiyrAjrQbBwMethVyz3twUqeldFMiZ+7HrqisQOk1053VUUPMZczkC DdDBiPu55usNMYW3tR4M5T8E0XA8xHZTZtRbaE/IevBprTabNv1AvA80fiYuHhpTt45X 6Iprgv7dp6NolJSYt+LBKTCJlK2bdbkDuRII1aoeCk9fTM1OTH8vTG+u/yP1wBN5Hk/6 +CIqX/h1mmS9pKnhTSKgq/PZxRrYu3YAClq/ukEIvp0D7UCzUwvcD4P+QaLX+x+z0JwX tSHkRwW8bKGs06EZRmaE+vwd7W+X71REfJuxCcFdoY+oVeb86AcAdV1dKHm+o0InVR0n Ta+Q== X-Gm-Message-State: AN3rC/6gT0KGlwt/WiJy82/b56hNaEnWoO3+cgXaTTeFvO2O7PboiLgS25BfALbrH6Yudb6wP7IjCmlTr4PD1A== X-Received: by 10.157.42.82 with SMTP id t76mr5477307ota.40.1491841867253; Mon, 10 Apr 2017 09:31:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.165 with HTTP; Mon, 10 Apr 2017 09:31:06 -0700 (PDT) In-Reply-To: References: <148977726052.13049.17633302885192133866@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 10 Apr 2017 09:31:06 -0700 Message-ID: To: Jon Mitchell Cc: ops-dir@ietf.org, draft-ietf-ippm-twamp-time-format.all@ietf.org, "ietf@ietf.org" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113d09de8f0dbb054cd28017 Archived-At: Subject: Re: [ippm] Review of draft-ietf-ippm-twamp-time-format-05 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, 10 Apr 2017 16:31:19 -0000 --001a113d09de8f0dbb054cd28017 Content-Type: text/plain; charset=UTF-8 Hi Jon, apologies for the extended delay to address your comment. I'd like to add the following just before the Section 2.1: Implementations of OWAMP and/or TWAMP MAY provide a configuration knob to bypass the timestamp format negotiation process and to use the locally configured values instead. Hope it captures the idea of and addresses your comment. Regards, Greg On Mon, Mar 20, 2017 at 10:34 AM, Greg Mirsky wrote: > Hi Jon, > thank you for kind consideration of the draft and thoughtful comment. > Indeed, TWAMP Test, and the time stamp format to be used, may be controlled > by means other than TWAMP Control, e.g., local configurable knob exposed > via data model or CLI. I'll work on text updates for the next version. > > Regards, > Greg > > On Fri, Mar 17, 2017 at 2:01 PM, Jon Mitchell > wrote: > >> Reviewer: Jon Mitchell >> Review result: Has Nits >> >> I have reviewed this document as part of the Operational directorate's >> >> ongoing effort to review all IETF documents being processed by the >> IESG. These >> comments were written with the intent of improving the operational >> aspects of the >> IETF drafts. Comments that are not addressed in last call may be >> included in AD reviews >> during the IESG review. Document editors and WG chairs should treat >> these comments >> just like any other last call comments. >> >> Ready with Nits - this draft adds the ability to use PTP timestamps as >> an alternative to NTP timestamps for active performance measurement >> protocols OWAMP and TWAMP. Although this draft does a good job of >> discussing interoperability for both sides of the session having or >> not having support for this operational capability, in several places >> it states that if a send/receiver support this capability it must be >> set to 1 in the flags. However, only for TWAMP Light mode, this seems >> configurable. This may just be my interpretation, but it probably >> should state that local implementations MAY provide a configurable >> knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even if >> the capability is supported by the implementation. >> >> >> > --001a113d09de8f0dbb054cd28017 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Avis = de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.


_____= __________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm





--


3D"Accedian.com"

Henrik Nydell

Sr Manage= r Global Strategy & Solutions


<= /colgroup>

Cell

Email

Skype

+46 709845992

hnydell@accedian.com

hnydell



=C2=A0 =C2=A0 =C2=A0 =C2=A0


=



Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

--001a113dd7ae1b7d66054d6fa106-- From nobody Tue Apr 18 07:08:10 2017 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 2AEB21317EF; Tue, 18 Apr 2017 07:07:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ippm-chairs@ietf.org, ippm@ietf.org, ietf@wjcerveny.com, Bill Cerveny , draft-ietf-ippm-twamp-time-format@ietf.org, spencerdawkins.ietf@gmail.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <149252447716.16178.14433318809514561189.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 07:07:57 -0700 Archived-At: Subject: [ippm] Protocol Action: 'Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)' to Proposed Standard (draft-ietf-ippm-twamp-time-format-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: Tue, 18 Apr 2017 14:07:57 -0000 The IESG has approved the following document: - 'Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)' (draft-ietf-ippm-twamp-time-format-06.txt) as Proposed Standard This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/ Technical Summary This document describes an OPTIONAL feature for active performance measurement protocols allowing use of time stamp format defined in IEEE-1588v2-2008. Working Group Summary As indicated, this document describes an OPTIONAL feature allowing the use of the time stamp format defined in IEEE-1588v2-2008 for active measurement protocols and is uncontroversial. Document Quality During the document's life as an individual submission, the document received a small number of suggested changes, which were implemented. For adoption, there were four e-mails of support and no dissents. Post-adoption, the working group document was only revised once, to reflect an author change. ZTE already supports the PTP time stamp format in TWAMP Test packets. Broadcom DNX devices (88670, 88370, 88680, 88470) will support the standard data-plane requirements. Personnel The document shepherd is Bill Cerveny. The responsible area director is Spencer Dawkins. From nobody Tue Apr 18 09:53:42 2017 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 819A5126C25; Tue, 18 Apr 2017 09:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 4Pjff7BHfKRC; Tue, 18 Apr 2017 09:53:39 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F3E12F258; Tue, 18 Apr 2017 09:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2211; q=dns/txt; s=iport; t=1492534418; x=1493744018; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=03cR9WToKznyIsPonSqjkT7qkzVR/cQGn6qd5I8VcnA=; b=GtlahrRlWycGlzKGLpiPAVkX2yCuSLqiZPwRAjO60bucP8bFj+4gzDwR J/AoJ3Sy68JeBfyDgnMg1xE552tyqoDFiwkSudC7kb/E8pYHqzQRahqA6 bd5GV1ZzNEIPriSXf85eiWLRRiD0bxyLm4N06Gtvc0/dyuQEuhwtESPbk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAByQ/ZY/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1OBbAeNdJFjlWGCD4YkAoN0PxgBAgEBAQEBAQFrHQuFFQEBAQE?= =?us-ascii?q?CATo/BQcEAgEIEQQBAR8JBzIUCQgCBA4FCIoJCK1CiyMBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdhlKBXYMYijwFljSGbgGSYIIJhTGKF5QNAR84gQVjFYcpdYd+gQ0?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208";a="234404795" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2017 16:53:37 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3IGrbxv030229 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Apr 2017 16:53:37 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.1210.3; Tue, 18 Apr 2017 11:53:37 -0500 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.1210.000; Tue, 18 Apr 2017 11:53:37 -0500 From: "Frank Brockners (fbrockne)" To: "adrian@olddog.co.uk" CC: "'ALFRED MORTON'" , "'Brian Trammell (IETF)'" , "'IPPM Chairs'" , "ippm@ietf.org" , "'Sarah B'" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ALTeVSHHK04UeHAEB7HUBtbKGqypeAgAAD3ACAAAfTAIAAIx6AgAA2hgCAAJuA4IAAxDyAgAAcNwCAABufgIAA1nmggA01g4CABATw0IADbGAAgARQ/ICABOIu0A== Date: Tue, 18 Apr 2017 16:53:36 +0000 Message-ID: <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> In-Reply-To: <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> 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.190.230] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 18 Apr 2017 16:53:40 -0000 Hi Adrian, thanks - please see inline below... -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Samstag, 15. April 2017 11:16 To: Frank Brockners (fbrockne) Cc: 'ALFRED MORTON' ; 'Brian Trammell (IETF)' ; 'IPPM Chairs' ; ippm@ietf.org; 'Sarah B' Subject: RE: [ippm] Vote at IPPM session Hi Frank, all, Thanks for proposing some text. > How about: "The operator of such a domain MUST put provisions in place=20 > to ensure that in-situ OAM data stays within the specific domain only=20 > (i.e., does not > leak beyond the edge) using for example packet filtering methods. The=20 > operator SHOULD consider potential operational impact of IOAM to=20 > mechanisms such as ECMP processing (e.g. load-balancing schemes based=20 > on packet length could be impacted by the increased packet size due to=20 > IOAM), path MTU (i.e. ensure that the MTU of all links within a domain=20 > is sufficiently large to support the increased > packet size due to IOAM) and ICMP message handling (i.e. in case of a=20 > native IPv6 > transport, IOAM support for ICMPv6 Echo Request/Reply could desired=20 > which would translate into ICMPv6 extensions to enable IOAM data=20 > fields to be copied from an Echo Request message to an Echo Reply message= )." Like Sarah, I think this is a start. I remain disappointed that it is the operators' responsibility to ensure va= rious things, and not a feature of the protocol or implementation. But perhaps this text serves as a warning to the operators about using impl= ementations of iOAM and so will suffice. ...FB: The current document is just the starting point. Let's hope that the= WG can improve the current approach further and/or suggest improved text. I think the use of 2119 capitalisation is meaningless in this paragraph, an= d that the "SHOULD" in the second sentence should in any case be a "must". ...FB: Thanks. Will change/correct in the next revision (along with a set o= f typos that I introduced when crafting the section) Thanks, Frank Thanks, Adrian From nobody Tue Apr 18 12:25:51 2017 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 B30DB12EAED; Tue, 18 Apr 2017 12:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ocGRzgtV9rbZ; Tue, 18 Apr 2017 12:25:48 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1F9129C31; Tue, 18 Apr 2017 12:25:48 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6A8D6340EC9; Tue, 18 Apr 2017 21:25:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.12607); Tue, 18 Apr 2017 21:25:44 +0200 (CEST) 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, 18 Apr 2017 21:25:44 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 14881619; Tue, 18 Apr 2017 21:25:44 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_53E45982-B885-4C48-B0F7-030E4EF31B67"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> Date: Tue, 18 Apr 2017 21:25:43 +0200 Cc: "adrian@olddog.co.uk" , Al Morton , IPPM Chairs , "ippm@ietf.org" , Sarah B Message-Id: <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> To: "Frank Brockners (fbrockne)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 18 Apr 2017 19:25:51 -0000 --Apple-Mail=_53E45982-B885-4C48-B0F7-030E4EF31B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Frank, all, Speaking as an individual. First, thanks for the scope section... this is all much more concrete = now. So, as I understand it, iOAM is designed first and foremost to be a = single-network (in the sense of "coherent administrative domain") = protocol data model with a binding to a variety of "carrier" protocols = (the draft speaks of "transports" in the RTG-area meaning of the term, = not the TSV-area one, so let's overload "carrier" here instead), some of = which are also explicitly single-network, some of which less so... I tend to share the concerns of those who've expressed discomfort with = the "warning label approach" to ensuring that iOAM data stays = single-network, but I'm not sure it's a problem *for the data model*. I = don't necessarily read this "MUST NOT leave the network" as an = additional responsibility of operators, but rather on the designers of = carrier protocols for iOAM data. Now, some of the carrier protocols = (e.g. IPv6 extension headers) provide no such protection or support for = providing that protection, so in that case it falls to the implementor = of the iOAM solution to provide it... but this is rather a matter to be = handled on a per carrier protocol basis, isn't it? Cheers, Brian > On 18 Apr 2017, at 18:53, Frank Brockners (fbrockne) = wrote: >=20 > Hi Adrian, >=20 > thanks - please see inline below... >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Samstag, 15. April 2017 11:16 > To: Frank Brockners (fbrockne) > Cc: 'ALFRED MORTON' ; 'Brian Trammell (IETF)' = ; 'IPPM Chairs' ; ippm@ietf.org; = 'Sarah B' > Subject: RE: [ippm] Vote at IPPM session >=20 > Hi Frank, all, >=20 > Thanks for proposing some text. >=20 >> How about: "The operator of such a domain MUST put provisions in = place >> to ensure that in-situ OAM data stays within the specific domain only >> (i.e., does > not >> leak beyond the edge) using for example packet filtering methods. The >> operator SHOULD consider potential operational impact of IOAM to >> mechanisms such as ECMP processing (e.g. load-balancing schemes based >> on packet length could be impacted by the increased packet size due = to >> IOAM), path MTU (i.e. ensure that the MTU of all links within a = domain >> is sufficiently large to support the > increased >> packet size due to IOAM) and ICMP message handling (i.e. in case of a >> native > IPv6 >> transport, IOAM support for ICMPv6 Echo Request/Reply could desired >> which would translate into ICMPv6 extensions to enable IOAM data >> fields to be copied from an Echo Request message to an Echo Reply = message)." >=20 > Like Sarah, I think this is a start. >=20 > I remain disappointed that it is the operators' responsibility to = ensure various things, and not a feature of the protocol or = implementation. >=20 > But perhaps this text serves as a warning to the operators about using = implementations of iOAM and so will suffice. >=20 > ...FB: The current document is just the starting point. Let's hope = that the WG can improve the current approach further and/or suggest = improved text. >=20 > I think the use of 2119 capitalisation is meaningless in this = paragraph, and that the "SHOULD" in the second sentence should in any = case be a "must". >=20 > ...FB: Thanks. Will change/correct in the next revision (along with a = set of typos that I introduced when crafting the section) >=20 > Thanks, Frank >=20 > Thanks, > Adrian --Apple-Mail=_53E45982-B885-4C48-B0F7-030E4EF31B67 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9mg3AAoJEIoSt78L6kajpBYP/2oCM/yTU3Lbw5c2J4liJekZ 9Mps1IkUVp9eqg1Y78MDYj8matClipwGpM5JNOfir6rxXdwx2HHu2gs7Pmei6rtE 5j3u+ifVmVxbkvTDcL3/nX4pwzZg2nFkxqD9Ddjk8Xsua2oqRMe+NXXgBG+jKS2A 1/sMy3URYvkJxsEtXsZKDRnzW627tDugdgEgztS5rO/PujK/znd0cXjBMaDAztTS /WwR4bF9ZXJgkFGtr+WkLHV5lLcLd4CovYF2EYpKNyhLoerBiwcvwZqprDiFVmU/ Ae/VK07h5zkn8aH6oG7hYmj9q+2CT4/kVwpqqCmWHC+1gszrFPj0UMp2TCHwem5t 12xQ4BiWKl8Wh2QxM55lpJOA5zpGPDsZrO25oUUIlDIq/cv/7PPgOub4cJhxcVvx PZFiN50qEjairUeH4rygjvWhli8X3CIzOG8WAZ1W/qTHfuGeWjl+llZ7zH9Pz49w 2YA8i6tSF7EJTFukmP217Pt3mMa4fA91ry8CWG451w+LbmRuscmxqPYyFjkVM3uE +Ac8EZ1fUxDybdA3JH8W42YNVd5iftydY4poXfvmkQtkN0gJRDtqzHtum78dTD7B TwjzCCJh0BPrAVAkh1vlWoSIXjxCx5a9EF0h9zHTjtKn/P19hfSHhW/1zN/QhAAI rr1fPjujMNz6rzH/W7uF =3rlR -----END PGP SIGNATURE----- --Apple-Mail=_53E45982-B885-4C48-B0F7-030E4EF31B67-- From nobody Tue Apr 18 13:05:08 2017 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 1F4861293D9; Tue, 18 Apr 2017 13:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 8IVEPOt2Yg30; Tue, 18 Apr 2017 13:05:05 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 8559412EABC; Tue, 18 Apr 2017 13:05:05 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3IJtgmp006311; Tue, 18 Apr 2017 16:05:00 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 29wrfusv66-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Apr 2017 16:04:59 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3IK4wml020897; Tue, 18 Apr 2017 16:04:59 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3IK4npQ020505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 16:04:50 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 18 Apr 2017 20:04:31 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v3IK4Ulv023981; Tue, 18 Apr 2017 15:04:31 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v3IK4NiP023669; Tue, 18 Apr 2017 15:04:23 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-green.research.att.com (Postfix) with ESMTP id 0431BE1078; Tue, 18 Apr 2017 16:04:03 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 16:04:22 -0400 From: "MORTON, ALFRED C (AL)" To: "Brian Trammell (IETF)" , "Frank Brockners (fbrockne)" CC: "adrian@olddog.co.uk" , IPPM Chairs , "ippm@ietf.org" , Sarah B Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ANywb7w7Y7CUWYR5PjBqbNA6GqudOAgAAD3QCAAAfSAIAAIx6AgAA2hgCAAPdoAIAAaFWAgAAcNwD//8lsgIAC5LeAgAt5d4CABF/eAIADEXMAgARQ+4CABTbyAIAAKoCA///CZvA= Date: Tue, 18 Apr 2017 20:04:22 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> In-Reply-To: <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.178.187.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-18_17:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704180157 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 18 Apr 2017 20:05:07 -0000 All, one alternative to consider, below. Al > -----Original Message----- > From: Brian Trammell (IETF) [mailto:ietf@trammell.ch] > Sent: Tuesday, April 18, 2017 3:26 PM > To: Frank Brockners (fbrockne) > Cc: adrian@olddog.co.uk; MORTON, ALFRED C (AL); IPPM Chairs; > ippm@ietf.org; Sarah B > Subject: Re: [ippm] Vote at IPPM session >=20 > hi Frank, all, >=20 > Speaking as an individual. >=20 > First, thanks for the scope section... this is all much more concrete > now. >=20 > So, as I understand it, iOAM is designed first and foremost to be a > single-network (in the sense of "coherent administrative domain") > protocol data model with a binding to a variety of "carrier" protocols > (the draft speaks of "transports" in the RTG-area meaning of the term, > not the TSV-area one, so let's overload "carrier" here instead), some of > which are also explicitly single-network, some of which less so... >=20 > I tend to share the concerns of those who've expressed discomfort with > the "warning label approach" to ensuring that iOAM data stays single- > network, but I'm not sure it's a problem *for the data model*. I don't > necessarily read this "MUST NOT leave the network" as an additional > responsibility of operators, but rather on the designers of carrier > protocols for iOAM data. Now, some of the carrier protocols (e.g. IPv6 > extension headers) provide no such protection or support for providing > that protection, so in that case it falls to the implementor of the iOAM > solution to provide it... but this is rather a matter to be handled on a > per carrier protocol basis, isn't it? >=20 > Cheers, > Brian [ACM]=20 IOM, there is a general message to convey for all future protocol=20 development. Something like "sufficient provisions should be made to restrict the iOAM traffic to the intended domain." We could provide guidance to interconnecting network operators, as well, effectively allowing them to discard traffic containing=20 unexpected iOAM data. This would be applicable to=20 non-iOAM network operators, but might be more important for interconnecting operators who have established their own iOAM domain. This is similar to the approach we used for BMWG test traffic: there are v4 and v6 address spaces dedicated for isolated test=20 environments, and any packet with testing addresses observed on=20 the Internet may be discarded. regards, Al >=20 >=20 >=20 > > On 18 Apr 2017, at 18:53, Frank Brockners (fbrockne) > wrote: > > > > Hi Adrian, > > > > thanks - please see inline below... > > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Samstag, 15. April 2017 11:16 > > To: Frank Brockners (fbrockne) > > Cc: 'ALFRED MORTON' ; 'Brian Trammell (IETF)' > ; 'IPPM Chairs' ; ippm@ietf.org; > 'Sarah B' > > Subject: RE: [ippm] Vote at IPPM session > > > > Hi Frank, all, > > > > Thanks for proposing some text. > > > >> How about: "The operator of such a domain MUST put provisions in > place > >> to ensure that in-situ OAM data stays within the specific domain only > >> (i.e., does > > not > >> leak beyond the edge) using for example packet filtering methods. The > >> operator SHOULD consider potential operational impact of IOAM to > >> mechanisms such as ECMP processing (e.g. load-balancing schemes based > >> on packet length could be impacted by the increased packet size due > to > >> IOAM), path MTU (i.e. ensure that the MTU of all links within a > domain > >> is sufficiently large to support the > > increased > >> packet size due to IOAM) and ICMP message handling (i.e. in case of a > >> native > > IPv6 > >> transport, IOAM support for ICMPv6 Echo Request/Reply could desired > >> which would translate into ICMPv6 extensions to enable IOAM data > >> fields to be copied from an Echo Request message to an Echo Reply > message)." > > > > Like Sarah, I think this is a start. > > > > I remain disappointed that it is the operators' responsibility to > ensure various things, and not a feature of the protocol or > implementation. > > > > But perhaps this text serves as a warning to the operators about using > implementations of iOAM and so will suffice. > > > > ...FB: The current document is just the starting point. Let's hope > that the WG can improve the current approach further and/or suggest > improved text. > > > > I think the use of 2119 capitalisation is meaningless in this > paragraph, and that the "SHOULD" in the second sentence should in any > case be a "must". > > > > ...FB: Thanks. Will change/correct in the next revision (along with a > set of typos that I introduced when crafting the section) > > > > Thanks, Frank > > > > Thanks, > > Adrian From nobody Tue Apr 18 18:25:12 2017 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 6F681128768 for ; Tue, 18 Apr 2017 18:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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, TRACKER_ID=1.306, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 vDyV67xzZVWQ for ; Tue, 18 Apr 2017 18:25:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 71AA1129462 for ; Tue, 18 Apr 2017 18:25:05 -0700 (PDT) X-AuditID: c1b4fb25-c27a798000006af2-cb-58f6bc6f9caa Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 30.49.27378.F6CB6F85; Wed, 19 Apr 2017 03:25:03 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 19 Apr 2017 03:25:01 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+/3R7DUzM1IKAPtj8kLqtd61QeY7VV6h4eoliWQ2BJk=; b=ZMKzhv79i2mjhle939wneYbE8MqycKw1FQs3fI+AIygvK7PWwJaRooQMkfVbjFP5qtMeW4u0OWQtYIt03Z/dWHxyVvKfEYNg9TUY2d97VzTP2S4UViizjB4+5szfRsjMNlQj7yNyg+IytgMckopqQoqUUonWj+pJV+J59bJdbrU= Received: from HE1PR0701MB2890.eurprd07.prod.outlook.com (10.168.92.139) by HE1PR0701MB2889.eurprd07.prod.outlook.com (10.168.92.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 01:24:59 +0000 Received: from HE1PR0701MB2890.eurprd07.prod.outlook.com ([10.168.92.139]) by HE1PR0701MB2890.eurprd07.prod.outlook.com ([10.168.92.139]) with mapi id 15.01.1047.011; Wed, 19 Apr 2017 01:24:59 +0000 From: Wei Luo S To: Henrik Nydell , Greg Mirsky CC: "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" , "ippm@ietf.org" Thread-Topic: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 Thread-Index: AdKfjbtnL0qaxZ/BTSW5iz4J/5svIACD9wOAACJTwJAABbJJgASONwaAAPEk+wAAG5+yMA== Date: Wed, 19 Apr 2017 01:24:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: accedian.com; dkim=none (message not signed) header.d=none;accedian.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [106.38.5.8] x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2889; 7:jRD9vIk8Sd+3I9eYk5HW6J40tQhnsejG292oxHxvmJ2hEWgx1seNm3HO8wU6K6TFWC9g4un2ihmhzK7L5euZZ5OSczKYXHd2NcFQdOEvBLjPa4M/Qep9FZTGPWdkWwxe3xSn6kBbJcVRRWGiE3S4606JkwPH0GFh7uM2i+xVEvmsgOcgnGrJSJX8poPnU7GSeloafb1ABo/U+sRCsuYpv/QPnrgZ3PvBrxXjdcfmqRqf2f+1ade4cLE8a3e8WTlY+BdWijbFj6l7FkCe/ICzXRdWrlf66BxKwFBr6mv3aYlz9Ds99pWoIwcL4F3adVKQRdiSLK4enZU+rzVSrWTy6Q== x-ms-office365-filtering-correlation-id: 874a00bf-470e-47b4-5b57-08d486c2e52c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR0701MB2889; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(254769517575571)(266236234300168)(72170088055959)(31418570063057)(128460861657000)(179696456005106)(254730959083279)(86561027422486)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:HE1PR0701MB2889; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2889; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(39860400002)(377454003)(51444003)(24454002)(66654002)(606005)(6436002)(7736002)(74316002)(7906003)(6506006)(99286003)(54906002)(733005)(77096006)(229853002)(53376002)(38730400002)(2906002)(39060400002)(33656002)(2900100001)(236005)(53946003)(189998001)(6246003)(25786009)(19609705001)(54896002)(9686003)(6306002)(53936002)(86362001)(5890100001)(55016002)(19618635001)(53546009)(16200700003)(54356999)(122556002)(66066001)(230783001)(8936002)(50986999)(93886004)(4326008)(81166006)(3280700002)(7696004)(7066003)(5660300001)(2950100002)(6116002)(19273905006)(3846002)(8676002)(102836003)(790700001)(76176999)(3660700001)(579004)(559001)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2889; H:HE1PR0701MB2890.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2890E73A9A9D5E896235E651D7180HE1PR0701MB2890_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 01:24:58.9496 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2889 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGOfu+bZ/D6XHeXjcRHFgzSK0JjSxRkJqRUf/EqEhnfqiom27e +6MhWqRlXlJ0qRksywvOLLJEo4artLw1FTJFzUtmEoJ5zTK3z8D/fuc8D+d534dDEYJOtpCK V6XSGpUyUczhkZWKNu+D6o5VRcCHQR9ZzfYCKVstn2XLjDk5pOzW5E8ihJTXmULkL/XjXLnB sMGS/7Isc86SF3jHYujE+HRa4x8cxYvTrdeSyV313Myhe0VcHWoq5uYjOwpwINQuN3LyEY8S YCOClsdbBHN4j2B8ZJBjdZH4NgE1HTwrC7CeBS19aYypB8G7qipkFThYAnnPzSwru+AImPyT a2MCFyGYK8nMRxTljOVQMBtlRRccDtOjUsZ9HsbaWxAT5QPrFQ224fg4CswrA4iJshBQOGSy CXb4HAxYjLbZEHaDtZ6m3Sh3GJ25z2I2w2Do6CcYdoXv03/Z1ocQLkXwtv3+7vpeMN9cumsq JGC6T8ZwBHycGrY1AbgYwaeSEcQIavh2fYFkuB/Bdm8YYxpmwdrQ7K7gCXd6K9iMkMeFG7pN W5wzFsL40E3EsCfMj3Wyi5BEv2d0htUw12Vk620dOEF35Qyp36mMwL5gbPdnLN5wt2CKy/BO 8VXV3L33tYjbgFy1tDY6Kfaw1I/WxF/RatUqPxWd2op2PtWbZ799XiDLYqgJYQqJ7fmTolWF gK1M12YlmRBQhNiF37y0ohDwY5RZ2bRGHalJS6S1JiSiSLE7P/TVgEKAY5WpdAJNJ9Oa/yqL shPqkEu3Kmg02r3VTf6w89GEn8kxbCv0FD+d80RSfrT8sv0RaXBk/NXXlcK2wOxqSdgDi0Hs UC9qzDgdFLDP11yzsbn/UtnXz+oJj8yyaF+RNCG7Ok1yomrRlcj1MoSTP0QX6xTpT1MSnDJm WOaTwQGpS8evpXSNSTVjZzx8HbuKHb6ISW2c8tABQqNV/gM9nlOMUAMAAA== Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 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, 19 Apr 2017 01:25:10 -0000 --_000_HE1PR0701MB2890E73A9A9D5E896235E651D7180HE1PR0701MB2890_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuDQoNClRoYW5rcywNCldlaSBMdW8NCg0KRnJv bTogSGVucmlrIE55ZGVsbCBbbWFpbHRvOmhueWRlbGxAYWNjZWRpYW4uY29tXQ0KU2VudDogVHVl c2RheSwgQXByaWwgMTgsIDIwMTcgNzo1OSBQTQ0KVG86IEdyZWcgTWlyc2t5IDxncmVnaW1pcnNr eUBnbWFpbC5jb20+DQpDYzogV2VpIEx1byBTIDx3ZWkucy5sdW9AZXJpY3Nzb24uY29tPjsgZHJh ZnQtbWlyc2t5LWlwcG0tdHdhbXAtbGlnaHQteWFuZ0B0b29scy5pZXRmLm9yZzsgaXBwbUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtpcHBtXSBTb21lIHRob3VnaCBvbiBkcmFmdC1taXJza3ktaXBw bS10d2FtcC1saWdodC15YW5nLTA3DQoNCkkgd291bGQgYXNrIHlvdSB0byBjb25zaWRlciBhZGRp bmcgc29tZSBtb3JlIHZhbHVhYmxlIG1ldHJpY3MNCjEpIExvc3MgYnVyc3Qgc2l6ZSBtYXgNCg0K DQogICAgICAgIGxlYWYgbG9zcy1idXJzdC1tYXggew0KDQogICAgICAgICAgICAgICAgdHlwZSBp bnQzMjsNCg0KICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQoNCiAgICAgICAgICAgICAgICAi SGlnaGVzdCBudW1iZXIgb2YgbG9zdCBwYWNrZXRzIGJhY2stdG8tYmFjayBkdXJpbmcgaW50ZXJ2 YWwuIjsNCg0KICAgICAgICB9DQpbV0VJXSBBZ3JlZSwgaXTigJlzIHZhbHVhYmxlLCBJIHRoaW5r IHdlIHNob3VsZCBhZGQgaXQuIEJlc2lkZXMsIEkgc3VnZ2VzdCB0byBhZGQgb25lIG1vcmUgbWV0 cmljczogbG9zcy1idXJzdC1taW4sIHdoaWNoIGlzIHRoZSBtaW5pbXVtICBudW1iZXIgb2YgbG9z dCBwYWNrZXRzIGJhY2stdG8tYmFjayBkdXJpbmcgaW50ZXJ2YWwuDQoNCjIpIExvc3MgYnVyc3Qg Y291bnQgKHRlbGxzIGhvdyBtYW55IGluc3RhbmNlcyB0aGVyZSB3YXMgb2YgcGFja2V0IGxvc3Mg ZHVyaW5nIGFuIGludGVydmFsLCBvbmUgImluc3RhbmNlIiBtZWFucyBvbmUgb3IgbW9yZSBjb25z ZWN1dGl2ZSBwYWNrZXRzIGxvc3QuDQoNCg0KICAgICAgICBsZWFmIGxvc3MtYnVyc3QtY291bnQg ew0KDQogICAgICAgICAgICAgICAgdHlwZSBpbnQzMjsNCg0KICAgICAgICAgICAgICAgIGRlc2Ny aXB0aW9uDQoNCiAgICAgICAgICAgICAgICAiTnVtYmVyIG9mIG9jY2FzaW9ucyB3aXRoIHBhY2tl dCBsb3NzIGR1cmluZyBpbnRlcnZhbC4iOw0KDQogICAgICAgIH0NCg0KVG8gZnVydGhlciBleHBs YWluIHRoZSBhYm92ZSBtZXRyaWNzLCBjb25zaWRlciA2MC1zZWNvbmQgaW50ZXJ2YWwgYmVsb3cg d2l0aCAxIHBhY2tldCBwZXIgc2Vjb25kIG1vbml0b3JpbmcsIHdoZXJlIHggbWVhbnMgbG9zdCBw YWNrZXQgYW5kIG8gbWVhbnMgcmVjaWV2ZWQuDQoNCjAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYwcw0Kb29vWG9vWG9vb29YWFhYb29v b29vb29vb1hYb29vb29Yb29vWG9vb29vb29vWFhYWFhYWFhYWFhYb29vDQoNClRoaXMgNjBzLWlu dGVydmFsIGhhcyAyMiBsb3N0IHBhY2tldHMgKCAyMi82MCA9MzYuNjclIGxvc3MpDQpMb3NzIGJ1 cnN0IG1heCBpcyAxMiBwYWNrZXRzLCBudW1iZXIgb2YgbG9zcyBpbnN0YW5jZXMgYXJlIDcNCg0K W1dFSV0gQWdyZWUuIEl0IHNob3VsZCBiZSBhZGRlZC4gRm9yIHN0YXRlZnVsIHJlZmxlY3Rvciwg dHdvIG1vcmUgbWV0cmljcyBjYW4gYmUgYWRkZWQ6IGxvc3MtYnVyc3QtY291bnQtZmFyLWVuZCwg bG9zcy1idXJzdC1jb3VudC1uZWFyLWVuZC4NCg0KMykgUGVyY2VudGlsZXMgYXJlIHZlcnkgdXNl ZnVsIGFuZCBpbXBvcnRhbnQuIElmIHRoZXkgY2Fubm90IGJlICJjb25maWd1cmFibGUiIGluIHRo ZSBZYW5nIG1vZGVsIEkgd291bGQgc3VnZ2VzdCB5b3UgdG8gY29uc2lkZXIgYWRkaW5nIGF0IGxl YXN0IHRoZSA5NXRoLCA5OXRoIGFuZCA5OS45dGggcGVyY2VudGlsZXMgZm9yIGFsbCBkZWxheSB0 eXBlIG1ldHJpY3MuDQpbV0VJXSBDb3VsZCB5b3UgZXhwbGFpbiB0aGUgbWVhbmluZyBvZiDigJxw ZXJjZW50aWxl4oCdIGhlcmU/DQoNCg0KT24gVGh1LCBBcHIgMTMsIDIwMTcgYXQgNjo1MyBQTSwg R3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21h aWwuY29tPj4gd3JvdGU6DQpEZWFyIEFsbCwNCnRoZSBuZXcgdXBkYXRlIG9mIHRoZSBUV0FNUC1M aWdodCBZQU5HIG1vZGVsPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1taXJza3kt aXBwbS10d2FtcC1saWdodC15YW5nLTA4PiBoYXMgYmVlbiBwdWJsaXNoZWQuIEl0IGluY2x1ZGVz IHRoZSBmb2xsb3dpbmc6DQoNCiAgKiAgIHBhY2tldCBsb3NzIHJhdGlvIGFzIGRlY2ltYWw2NCB0 eXBlIHdpdGggZnJhY3Rpb24tc2l6ZSA1Ow0KICAqICAgc2Vzc2lvbi1yZWZsZWN0b3Igc3RhdGUg cGFyYW1ldGVyIGluIHNlc3Npb24tc2VuZGVyIGNvbnRhaW5lcjsNCiAgKiAgIGRlZmluZWQgY29u dGludW91cyBhbmQgcGVyaW9kaWMgbW9kZXMgdG8gZXhlY3V0ZSBhIHRlc3Qgc2Vzc2lvbiBhbmQg aG93IHBlcmZvcm1hbmNlIG1ldHJpY3MgYXJlIGNhbGN1bGF0ZWQgaW4gZWFjaCBvZiB0aGUgbW9k ZXM7DQogICogICByZXBvcnRpbmcgb2Ygb25lLXdheSBwYWNrZXQgbG9zcyBtZXRyaWNzLCBib3Ro IG5lYXItZW5kIGFuZCBmYXItZW5kLCBoYXMgZGVwZW5kZW5jeSBvZiByZWZsZWN0b3IncyBtb2Rl Lg0KU29tZSBxdWVzdGlvbnMgc3RpbGwgYmVpbmcgZGlzY3Vzc2VkIGFuZCB3ZSBncmVhdGx5IGFw cHJlY2lhdGUgc3VnZ2VzdGlvbnMsIGNvbW1lbnRzOg0KDQogICogICBpbmNsdWRlIHBlcmNlbnRp bGUgaW4gZGVsYXkgYW5kIGRlbGF5LXZhcmlhdGlvbiBjb250YWluZXJzPw0KICAqICAgZGVmYXVs dCB2YWx1ZSBmb3Igc2Vzc2lvbi10aW1lb3V0IGluIHNlc3Npb24tc2VuZGVyIGNvbnRhaW5lciBp cyA5MDAgc2Vjb25kcy4gU2VlbXMgdG9vIGJpZy4gV2hhdCBtYXkgYmUgcHJhY3RpY2FsPyBDaGFu Z2UgdW5pdHMgZnJvbSBzZWNvbmRzIHRvIGNlbnRpc2Vjb25kcyBvciBtaWxsaXNlY29uZHM/DQpS ZWdhcmRzLA0KR3JlZw0KDQpPbiBUdWUsIE1hciAyMSwgMjAxNyBhdCA1OjIxIEFNLCBIZW5yaWsg TnlkZWxsIDxobnlkZWxsQGFjY2VkaWFuLmNvbTxtYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb20+ PiB3cm90ZToNClNvbWUgY29tbWVudHMgZnJvbSB0aGUgImZpZWxkIiBhcyBBY2NlZGlhbiBoYXMg c2V2ZXJhbCBodW5kcmVkIHRob3VzYW5kIFRXQU1QIHNlc3Npb25zIHJ1bm5pbmcgKGNvbnRpbm91 c2x5KSBhdCBudW1lcm91cyBUaWVyIG9uZSBtb2JpbGUvZml4ZWQgb3BlcmF0b3JzIGdsb2JhbGx5 Lg0KDQpPbiBUdWUsIE1hciAyMSwgMjAxNyBhdCAxMTo1MiBBTSwgV2VpIEx1byBTIDx3ZWkucy5s dW9AZXJpY3Nzb24uY29tPG1haWx0bzp3ZWkucy5sdW9AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpI aSBHcmVnLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgcmVzcG9uc2UuIFBsZWFzZSBzZWUgbXkg cmVwbHkgaW5saW5lIHRhZ2dlZCBbV0VJPj5dLg0KDQpSZWdhcmRzLA0KV2VpIEx1bw0KDQpGcm9t OiBHcmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2lt aXJza3lAZ21haWwuY29tPl0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIxLCAyMDE3IDE6MTYgQU0N ClRvOiBXZWkgTHVvIFMgPHdlaS5zLmx1b0Blcmljc3Nvbi5jb208bWFpbHRvOndlaS5zLmx1b0Bl cmljc3Nvbi5jb20+Pg0KQ2M6IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+OyBk cmFmdC1taXJza3ktaXBwbS10d2FtcC1saWdodC15YW5nQHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC1taXJza3ktaXBwbS10d2FtcC1saWdodC15YW5nQHRvb2xzLmlldGYub3JnPg0KU3ViamVj dDogUmU6IFNvbWUgdGhvdWdoIG9uIGRyYWZ0LW1pcnNreS1pcHBtLXR3YW1wLWxpZ2h0LXlhbmct MDcNCg0KSGkgV2VpIEx1bywNCm1hbnkgdGhhbmtzIGZvciB5b3VyIHRob3JvdWdoIHJldmlldyBh bmQgdGhlIG1vc3QgaGVscGZ1bCBjb21tZW50cyB0byB0aGUgVFdBTVAgTGlnaHQoVGVzdCkgbW9k ZWwuIFBsZWFzZSBmaW5kIG15IGFuc3dlcnMsIG5vdGVzIGluLWxpbmUgdGFnZ2VkIEdJTT4+Lg0K DQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBTYXQsIE1hciAxOCwgMjAxNyBhdCA0OjI3IEFNLCBXZWkg THVvIFMgPHdlaS5zLmx1b0Blcmljc3Nvbi5jb208bWFpbHRvOndlaS5zLmx1b0Blcmljc3Nvbi5j b20+PiB3cm90ZToNCkhpIEdyZWcgJiBBZHJpYW4sDQoNClRoaXMgaXMgV2VpIEx1byBmcm9tIEVy aWNzc29uLiBJIHdvcmsgb24gVFdBTVAgbGlnaHQgYXJlYSBpbiBFcmljc3Nvbi4gVGhlIGN1cnJl bnQgVFdBTVAgTGlnaHQgWUFORyBtb2RlbCBpcyB3ZWxsIGRlZmluZWQuIFRoYW5rcyBmb3IgeW91 ciBncmVhdCBqb2IuDQpCdXQgYnkgd29ya2luZyBjbG9zZWx5IHdpdGggb3VyIGN1c3RvbWVycywg d2UgZ290IHNvbWUgbmV3IHVzZXIgY2FzZXMgb24gVFdBTVAgbGlnaHQuIEkgYmVsaWV2ZSB0aGVz ZSB1c2VyIGNhc2VzIGFyZSB2YWx1YWJsZSBhbmQgcG9wdWxhciBlbm91Z2ggdG8gYmUgbW9kZWxl ZCBpbiBUV0FNUCBMaWdodCBZQU5HLiBJIGhvcGUgSSBjYW4gYmUgYSBjb250cmlidXRvciAgYW5k IGNvLXdvcmsgd2l0aCB5b3UgbW92ZSB0aGlzIGRyYWZ0IGZvcndhcmQuDQpJICBkcmFmdGVkIGEg bmV3IHZlcnNpb24gb2YgdGhlIFRXQU1QIGxpZ2h0IFlBTkcgbW9kZWwgYmFzZWQgb24gdmVyc2lv biBpZXRmLXR3YW1wLWxpZ2h0QDIwMTctMDItMTMueWFuZzxtYWlsdG86aWV0Zi10d2FtcC1saWdo dEAyMDE3LTAyLTEzLnlhbmc+LiBDb3VsZCB5b3UgcGxlYXNlIGNvbW1lbnRzIG9uIGl0PyBBbnkg ZGlzY3Vzc2lvbiBpcyB3ZWxjb21lLg0KVGhlIGRyYWZ0IHlhbmcgbW9kZWwgYW5kIHRyZWUgaXMg YXR0YWNoZWQuIFRvIG1ha2UgeW91IGZpbmQgdGhlIHVwZGF0ZXMgcXVpY2tseSwgSSBoaWdobGln aHRlZCBhbGwgdGhlIHVwZGF0ZXMgaW4gZmlsZSBpZXRmLXR3YW1wLWxpZ2h0LXdlaWx1by5wZGYu DQoNClRoZSBmb2xsb3dpbmcgYXJlIHRoZSBsaXN0IG9mIG1haW4gdXBkYXRlczoNCjEuIEFkZCBh IG5ldyB0eXBlZGVmOiBwZXJjZW50LiBUaGlzIGlzIGEgbmV3IHR5cGUgZGVmaW5lZCBmb3IgcGFj a2V0IGxvc3MgcmF0aW8uDQpDb25zaWRlcmF0aW9uOg0KMSkuIEZyb20gdGhlIGN1c3RvbWVyIHBl cnNwZWN0aXZlLCBwYWNrZXQgbG9zcyByYXRpbyBpcyBhIG1vcmUgbWVhbmluZ2Z1bCBkYXRhLiBJ biBtb3N0IG9mIHRoZSB0aW1lLCB0aGUgYWJzb2x1dGUgbnVtYmVyIGlzIG1lYW5pbmdsZXNzIHRv IHVzZXIsIGVzcGVjaWFsbHkgdGhleSBkbyB0aGUgVFdBTVAgdGVzdCBjb250aW51b3VzbHkuIFRo ZXkgYXJlIG1vcmUgY2FyZSBhYm91dCB0aGUgcmF0aW8gdGhhbiB0aGUgYWJzb2x1dGUgbnVtYmVy LiBTbyBhZGRpbmcgaXQgbWFrZXMgdGhpcyBtb2RlbCBtb3JlIGZyaWVuZGx5IHRvIGN1c3RvbWVy Ow0KMikuIEZyb20gdGhlIHNlcnZpY2UgbGF5ZXIgYXNzdXJhbmNlKFNMQSkgcGVyc3BlY3RpdmUs IHRoZSBwYWNrZXQgbG9zcyByYXRpbyBpcyBhIG1ham9yIG1lYXN1cmVzLiBTbyB3aXRoIGFkZGlu ZyBwYWNrZXQgbG9zcyByYXRpbyBpbiBtb2RlbCwgdGhlIFRXQU1QIGNhbiB3b3JrIGluIFNMQSBm cmFtZXdvcmsgbW9yZSBzbW9vdGhseS4NCjMpLiBJdCBzZWVtcyBzb21lIHNpbWlsYXIgcHJvdG9j b2zigJlzIFlBTkcgbW9kZWwgaGFzIHRoZSBzYW1lIGRlZmluaXRpb24sIGUuZy4g4oCYU2Vydmlj ZSBPQU0gUGVyZm9ybWFuY2UgTW9uaXRvcmluZyBZQU5HIE1vZHVsZeKAmSwgaHR0cHM6Ly93d3cu bWVmLm5ldC9Bc3NldHMvVGVjaG5pY2FsX1NwZWNpZmljYXRpb25zL1BERi9NRUZfMzkucGRmLg0K QWdyZWVkIHBhY2tldCBsb3NzIGlzIGltcG9ydGFudCwgaG93ZXZlciBhbm90aGVyIGltcG9ydGFu dCBsb3NzIG1ldHJpYyBpcyBsb3NzIGJ1cnN0IHNpemUgKG1heC9taW4pIGFuZCBudW1iZXIgb2Yg bG9zcyBidXJzdHMuIEEgbG9zcyBidXJzdCBvZiAxMCBjb25zZWN1dGl2ZSBUV0FNUC10ZXN0IHBh Y2tldHMgY2FuIGJlIGRlZW1lZCBtb3JlIHNlcmlvdXMgdGhhbiAxMCBsb3N0IHBhY2tldHMgc3By ZWFkIGV2ZW5seSBvdmVyIHRoZSByZXBvcnQgaW50ZXJ2YWwuDQpHSU0+PiBJbmRlZWQsIHBhY2tl dCBsb3NzIG1vcmUgb2Z0ZW4gZXhwcmVzc2VkIGFzIHBhY2tldCBsb3NzIHJhdGlvIHJhdGhlciB0 aGFuIGFzIHRoZSBhYnNvbHV0ZSBudW1iZXIuIEl0IHdvdWxkIGJlIG1vc3QgaGVscGZ1bCB0byBo ZWFyIGZyb20gbmV0d29yayBvcGVyYXRvcnMgaWYgdGhleSBzZWUgaW50cm9kdWN0aW9uIG9mIFBh Y2tldCBMb3NzIFJhdGlvIGludG8gdGhlIFRXQU1QIG1vZGVsIGhlbHBmdWwuDQoyLiBBZGQgYSBu ZXcgdHlwZWRlZjogc3RhdGUtbW9kZS4gSXQgZGVmaW5lcyBhIGNvbW1vbiB0eXBlIGZvciBzdGF0 ZWZ1bC9zdGF0ZWxlc3MgcmVmbGVjdG9yLiBUaGlzIHR5cGUgd2lsbCBiZSB1c2VkIGluIGJvdGgg c2VuZGVyIHNlc3Npb24gYW5kIHJlZmxlY3RvciBzZXNzaW9uLg0KQ29uc2lkZXJhdGlvbjoNCklm IHRoZSByZWZsZWN0b3IgaXMgc3RhdGVmdWwsIHRoZSBUV0FNUCBsaWdodCBjYW4gbWVhc3VyZSBt b3JlIGl0ZW1zLCBlLmcuIG9uZSB3YXkgcGFja2V0IGxvc3MuIFNvIGZvciBzZW5kZXIsIHRoZSBz dGF0cyBjYWxjdWxhdGlvbiBhbmQgc2hvdyBpcyBkaWZmZXJlbnQuIFdoZW4gdGhlIHJlZmxlY3Rv ciBpcyBzdGF0ZWxlc3MsIGl0IGRvZXNu4oCZdCBuZWVkIHRvIGNhbGN1bGF0ZSB0aGUgb25lIHdh eSBwYWNrZXQgbG9zcy4gVGhlIG9uZSB3YXkgcGFja2V0IGxvc3MgaXMgaW52YWxpZCBhbmQgc2hv dWxkbuKAmXQgYmUgcHJlc2VudGVkIHRvIGN1c3RvbWVyLiBXaGVuIHRoZSByZWZsZWN0b3IgaXMg c3RhdGVsZXNzLCB0aGUgc2VuZGVyIG5lZWRzIHRvIGNhbGN1bGF0ZSB0aGUgb25lIHdheSBwYWNr ZXQgbG9zcy4gQW5kIHRoZSBkYXRhIHNob3VsZCBiZSBwcmVzZW50IHRvIGN1c3RvbWVyLiBTbyB0 aGlzIGlzIHVzZWQgYXMgYSDigJh3aGVu4oCZIGNvbmRpdGlvbiBpbiB0aGUgbW9kZWzigJlzIFJP IHRyZWUuDQpHSU0+PiBZZXMsIGlmIFNlc3Npb24tU2VuZGVyIGlzIGF3YXJlIG9mIHRoZSBtb2Rl IGNvcnJlc3BvbmRpbmcgU2Vzc2lvbi1SZWZsZWN0b3Igb3BlcmF0ZXMsIHRoZSBzZW5kZXIgbWF5 IGF2b2lkIGNhbGN1bGF0aW9uIG9mIHNvbWUgcGVyZm9ybWFuY2UgbWV0cmljcywgZS5nLiwgb25l LXdheSBwYWNrZXQgbG9zcy4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSBvcmNoZXN0cmF0b3IgaXMg YXdhcmUgb2YgdGhlIHN0YXRlLW1vZGUgYW5kIHNob3VsZCBiZSBjYXBhYmxlIHRvIHByb3Blcmx5 IHVzZSBtZXRyaWNzIHJlcG9ydGVkIGJ5IHRoZSBTZXNzaW9uLVNlbmRlci4NCltXRUk+Pl0gWWVz LCB0aGUgb3JjaGVzdHJhdG9yIGNvdWxkIGtub3cgdGhhdC4gQnV0IGZyb20gdGhlIG1vZGVsIHNp ZGUsIHRoaXMgaXMgbm90IGNvcnJlY3QuICBUaGUgbW9kZWwgc2hvdWxkIHJlcHJlc2VudCB0aGUg cmlnaHQgYmVoYXZpb3IgYW5kIHNob3VsZG7igJl0IGRvIGFzc3VtcHRpb24gb24gb3JjaGVzdHJh dG9yLg0KSSBhZ3JlZSB0aGUgbW9kZWwgc2hvdWxkIGRlc2NyaWJlIGJvdGggb25lLXdheSBsb3Nz IG1ldHJpY3MgYW5kIHJvdW5kdHJpcCBsb3NzIG1ldHJpY3MsIGFuZCB0aGUgc2VuZGVyIHNob3Vs ZCBiZSBhYmxlIHRvIHVzZSBlaXRoZXIgbW9kZSB3aGVuIGNhbGN1bGF0aW5nLCBwb3RlbnRpYWxs eSBhbHNvIHBvcHVsYXRpbmcgdGhlIHJvdW5kdHJpcCBkZWxheSB2YWx1ZXMgd2l0aCBwcm9wZXIg dDEtdDAgKyB0My10MiB2YWx1ZXMsIGFzIHdlbGwgYXMgcmVwb3J0aW5nIHRoZSB0Mi10MSB2YWx1 ZXMgdGhhdCB3b3VsZCBpbmRpY2F0ZSBidWZmZXIgbG9hZC9DUFUgbG9hZCBpbiB0aGUgVFdBTVAg cmVzcG9uZGVycyBwcm9jZXNzaW5nIHRpbWUuDQozLiBBZGQgYSBuZXcgdHlwZWRlZjogc2VuZC1t b2RlLiBUaGlzIGlzIGEgbmV3IHR5cGUgZm9yIHNlbmRlciBzZXNzaW9uLiBJdCBtYWtlcyB0aGUg c2VuZGVyIHNlc3Npb24gY2FuIHNlbmQgcGFja2V0IGNvbnRpbnVvdXNseSBhbmQgbW9uaXRvciB0 aGUgbmV0d29yayBhbGwgdGhlIHRpbWUuDQpDb25zaWRlcmF0aW9uOg0KVGhlIHVzZXIgY2FzZSBp cyB0aGF0OiB0aGUgdXNlciBydW5zIFRXQU1QIGxpZ2h0IHNlc3Npb25zIHRvIHdhdGNoIGxpbmtz IHF1YWxpdHkgY29udGludW91c2x5LiBUaGUgc2Vzc2lvbiBudW1iZXIgY291bGQgYmUgdmVyeSBi aWcuIFRoZXNlIFRXQU1QIHNlc3Npb25zIGFyZSBtYW5hZ2VkIGJ5IFNMQSBmcmFtZXdvcmsgb3Ig c2ltaWxhci4gU0xBIHJldHJpZXZlcyB0aGUgc3RhdHMgZnJvbSBUV0FNUCBwZXJpb2RpY2FsbHks IGUuZy4gMTVtaW5zLiBJbiBvdGhlciB3b3JkcywgYWxsIHRoZSBwZXJmb3JtYW5jZSBtZXRyaWNz IGFyZSBjYWxjdWxhdGVkIGJhc2VkIG9uIHRoZSBwYWNrZXRzIHNlbnQvcmVjZWl2ZWQgd2l0aGlu IDE1bWlucy4gVGhpcyBtYWtlcyB0aGUgY2FsY3VsYXRpb24gYmVjb21lIHBvc3NpYmxlLiBXaXRo IHRoZSBwZXJpb2RpY2FsIHN0YXRzIGRhdGEsIHRoZSBOZXR3b3JrIE1hbmFnZW1lbnQgc29mdHdh cmUgY2FuIGRvIGZ1cnRoZXIgYWN0aW9ucyBpZiBzb21lIGFibm9ybWFsIHN0YXRzIG9ic2VydmVk LiAgVGhpcyBpcyBhIG1vcmUgZ2VuZXJhbCB1c2VyIGNhc2UgaW4gY3VzdG9tZXIgc2l0ZS4gV2hp bGUgdGhlIG5vbi1jb250aW51b3VzIFRXQU1QIHNlbmRlciBzZXNzaW9uIGlzIGdlbmVyYWxseSB1 c2VkIGZvciBkZWJ1Z2dpbmcgcHVycG9zZSBvbiBhIGxpbmsuDQpHSU0+PiBJIHRoaW5rIHRoYXQg c3VwcG9ydCBvZiBjb250aW51b3VzIG1lYXN1cmVtZW50IGlzIGluIExNQVAgZG9tYWluLCBub3Qg Zm9yIFRXQU1QIFRlc3QgZGF0YSBtb2RlbC4gVG8gY29uZHVjdCBjb250aW51b3VzIG1lYXN1cmVt ZW50IGhlIExNQVAgQ29udHJvbGxlciwgaW4gbXkgb3BpbmlvbiwgcHJvZ3JhbXMgdGhlIE1lYXN1 cmVtZW50IEFnZW50IHRvIHBlcmZvcm0gVFdBTVAgVGVzdCBzZXNzaW9uIHdpdGggY2VydGFpbiBz ZXQgb2YgcGFyYW1ldGVycyBhbmQgcmVwZWF0IGl0IHdpdGhvdXQgYW55IGludGVydmFsIChpbnRl cnZhbCA9IDApLg0KDQpNYW55IG9wZXJhdG9ycyB1c2UgVFdBTVAgaW4gY29udGlub3VzIG1vZGUs IG5vdCBvbmx5IHdpdGggQWNjZWRpYW4gdGVzdCBwb2ludHMgYW5kIHJlcG9ydCBhdCBmaXhlZCBp bnRlcnZhbHMsIHR5cGljYWxseSByYW5naW5nIGZyb20gNXMgdG8gNSBvciAxNSBtaW51dGVzLCB3 aXRoIDEtbWludXRlIGJlaW5nIHRoZSBtb3N0IHBvcHVsYXIgZ3JhbnVsYXJpdHkgY3VycmVudGx5 LiBUaGUgYWR2YW50YWdlIGlzIHRoYXQgdGhlIHJlc3VsdCBjYWxjdWxhdGlvbiBjYW4gYmUgaGFu ZGxlZCBzZXBhcmF0ZWx5IGZyb20gdGhlIFRXQU1QLXRlc3Qgc2VuZGluZy9yZWNpZXZpbmcsIHNv IHRoYXQgdGhlcmUgaXMgbm8gcGFyYWxsZWxpc20gcmVxdWlyZWQgdG8gbW9uaXRvciAyNC83LiBJ ZiBhIHN0YXJ0LXN0b3AtYmFzZWQgbWV0aG9kb2xvZ3kgaXMgdXNlZCwgdGhlIHNlbmRlciBuZWVk cyB0byBzdGFydCB1cCB0aGUgbmV3IHRlc3Qgc2Vzc2lvbiBldmVuIGJlZm9yZSB0aGUgcHJldmlv dXMgb25lIGhhcyBlbmRlZCwgc2luY2UgdGhlIHByZXZpb3VzIHNlc3Npb24gbmVlZHMgdG8gd2Fp dCBYIHNlY29uZHMgKG9yIGF0IGxlYXN0IFkgMTAwcyBvZiBtaWxsaXNlY29uZHMpIGJlZm9yZSBp dCBzdG9wcyB3YWl0aW5nIGZvciBwYWNrZXRzIHRvIGNvbWUgYmFjay4gQW5kIHRoaXMgbmV3IHNl c3Npb24gbmVlZHMgdG8gaGF2ZSBhIGRpZmZlcmVudCBzaWduYXR1cmUgaW4gb3JkZXIgZm9yIHRo ZSBzZW5kZXIgdG8gZGlzY2VybiB3aGljaCBwYWNrZXRzIGJlbG9uZyB0byB0aGUgcHJldmlvdXMg aW50ZXJ2YWwgYW5kIHdoaWNoIGJlbG9uZyB0byB0aGUgY3VycmVudC4NCg0KSW4gYSBjb250aW5v dXMgdGVzdC1tb2RlbCwgdGhlIHNlbmRlciBjYW4ganVzdCBzaW1wbHkgcmVjb3JkIHRoZSBzZXF1 ZW5jZSBudW1iZXIgb2YgdGhlIGxhc3QgcGFja2V0IHRyYW5zbWl0dGVkIGluIHRoZSBpbnRlcnZh bCB0byBiZSByZXBvcnRlZCwgd2FpdCBmb3IgaXQgdG8gY29tZSBiYWNrLCBvciBhIE1BWFRJTUUs IHRoZW4gcmVwb3J0IHRoYXQgcmVzdWx0LCB3aGlsZSBjb250aW51aW5nIHRvIHRyYW5zbWl0IGZv ciB0aGUgbmV4dCBpbnRlcnZhbC4NCg0KSWYgdGhlICJpbnRlcnZhbD09MCIgcGFyYW1ldGVyIGlz IGludGVuZGVkIHRvIGJlIHVzZWQgZm9yIGNvbnRpbm91cyB0eXBlIHRlc3RzLCB0aGVuIHdoYXQg cGFyYW1ldGVyIHNob3VsZCBpbmRpY2F0ZSB0byB0aGUgc2VuZGVyIGF0IHdoYXQgaW50ZXJ2YWxz IHRvIHByb2R1Y2UgcmVzdWx0cz8NCjQuIEFkZCBhIG5ldyBncm91cDogcGFja2V0LWxvc3Mtc3Rh dGlzdGljcy4gSXQgZ3JvdXBpbmcgdHdvIHBhY2tldCBsb3NzIHN0YXRpc3RpY3M6IGxvc3MtY291 bnQgYW5kIGxvc3MtcmF0aW8uIFRoaXMgZ3JvdXAgd2lsbCBiZSB1c2VkIGluIFJPIHN0YXRzIHRy ZWUuDQpHSU0+PiBJJ2QgbGlrZSB0byBjb250aW51ZSBkaXNjdXNzaW9uLg0KW1dFST4+XSBPSy4N CjUuIE1vdmUgbGVhZiBkc2NwIG91dCBmcm9tIGdyb3VwaW5nIHNlc3Npb24tbGlnaHQtcGFyYW1l dGVycy4gVGhlIGxlYWYgZHNjcCBpcyBvbmx5IHZhbGlkIHdoZW4gdGhlIGRzY3AtaGFuZGxpbmct bW9kZSBpcyB1c2UtY29uZmlndXJlZC12YWx1ZS4gQSB3aGVuIGNvbmRpdGlvbiBzaGFsbCBiZSBh ZGRlZCB0byBpdC4gU28gaXQgY2Fu4oCZdCBiZSBpbiB0aGlzIGdyb3VwLg0KR0lNPj4gSSdtIGNv bmNlcm5lZCB0aGF0IHRoZW4gdGhlIG1vZGVsIHdpbGwgbm90IGJlIGFibGUgdG8gc3VwcG9ydCBj b25jdXJyZW50IFRXQU1QIFRlc3Qgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIFRl c3QgUG9pbnRzIChJUCBhZGRyZXNzK3BvcnQgbnVtYmVyKSBhdCBkaWZmZXJlbnQgQ29TIG1hcmtp bmdzLg0KW1dFST4+XSBBY3R1YWxseSwgSSBoYXZlIGNvbmNlcm4gb24gdXNpbmcgZml2ZSB0dXBs ZShJUCBhZGRyZXNzK3BvcnQgbnVtYmVyK2RzY3ApIHRvIGlkZW50aWZ5IGEgVFdBTVAgdGVzdCBz ZXNzaW9uLiBUaGUgRFNDUCBpcyBub3QgYSBjb25zdGFudCB2YWx1ZSBpbiBwYWNrZXQuIEl0IGNv dWxkIGJlIG1vZGlmaWVkIGJ5IHRoZSByb3V0ZXJzIGluIHRoZSBwYXRoLiBGb3IgZXhhbXBsZSwg dGhlIHNlbmRlciBoYXMgdHdvIHNlc3Npb25zOiBzZXNzaW9uIEHigJlzIGZpdmUgdHVwbGUgaXM6 IFNpcD0xLjEuMS4xLCBEaXA9Mi4yLjIuMiwgU3BvcnQ9NTAwMDAsIERwb3J0PTUwMDAxLCBEU0NQ PWNzMi4gU2Vzc2lvbiBC4oCZcyBmaXZlIHR1cGxlIGlzOiBTaXA9MS4xLjEuMSwgRGlwPTIuMi4y LjIsIFNwb3J0PTUwMDAwLCBEcG9ydD01MDAwMSwgRFNDUD1jczMuIFRoZSBvbmx5IGRpZmZlcmVu Y2UgYmV0d2VlbiBzZXNzaW9uIEEgYW5kIHNlc3Npb24gQiBpcyBEU0NQLiBJZiB0aGUgdGVzdCBw YWNrZXTigJlzIERTQ1Agb2Ygc2Vzc2lvbiBCIGlzIG1vZGlmaWVkIHRvIGNzMiBieSBhIHJvdXRl ciBpbiB0aGUgcGF0aC4gVGhlIGZpdmUgdHVwbGVzIGFyZSBleGFjdGx5IHRoZSBzYW1lIGZvciBy ZWZsZWN0b3IuIEl0IGNhbuKAmXQgZGlmZmVyZW50aWF0ZSB3aGljaCBwYWNrZXQgaXMgZnJvbSBz ZXNzaW9uIEEsIHdoaWNoIHBhY2tldCBpcyBmcm9tIHNlc3Npb24gQi4gSXQgY291bGQgbWVzcyB0 aGUgcmVmbGVjdG9y4oCZcyBzZXNzaW9uIHNlcXVlbmNlIG51bWJlci4gQW5kIGFsc28sIHRoZSBz ZW5kZXIgd2lsbCBiZSBtZXNzZWQgYmVjYXVzZSB0aGUgcmVjZWl2ZWQgcmVwbHkgcGFja2V04oCZ cyBmaXZlIHR1cGxlIGFyZSBleGFjdGx5IHRoZSBzYW1lLg0KU28gSSB0aGluayBpdOKAmXMgbW9y ZSByZWFzb25hYmxlIHRvIHVzZSBmb3VyIHR1cGxlIHRvIGlkZW50aWZ5IGEgc2Vzc2lvbi4NCg0K WWVzLCB0aGlzIHdvdWxkIGJlIGFwcHJlY2lhdGVkIGJ5IHVzZXJzLiBDaGFuZ2VzIGluIERTQ1Ag aXMgYSByZWFzb25hYmx5IGNvbW1vbiBuZXR3b3JrIGVycm9yIHRoYXQgdXNlcnMgY2FuIGRldGVj dCB3aXRoIGNvbnRpbm91cyBUV0FNUCBtb25pdG9yaW5nLCB0aHVzIGl0IGlzIGdvb2QgdG8gbm90 IGluY2x1ZGUgdGhlIERTQ1AgdmFsdWUgYXMgcGFydCBvZiB0aGUgInNlc3Npb24gaWRlbnRpZmlp ZXIiIGJ1dCBpbnN0ZWFkIHVzZSA0LXR1cGxlIHdpdGggVURQIHNvdXJjZSBwb3J0IHRvIGlkZW50 aWZ5IHNldmVyYWwgcGFyYWxsZWwgZmxvd3MgYmV0d2VlbiB0aGUgc2FtZSBzZW5kZXIgYW5kIHJl c3BvbmRlci4NCjYuIEFkZCBsZWFmICdzZXNzaW9uLXBhY2tldC1zZW5kLW1vZGUnIHRvIC90d2Ft cC1saWdodC90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci90ZXN0LXNlc3Npb24qLiBUaGlzIGxl YWYgc3BlY2lmaWVzIHRoZSBzZW5kZXIgc2Vzc2lvbidzIHBhY2tldCBzZW5kIG1vZGU6IGNvbnRp bnVvdXMgb3Igbm9uLWNvbnRpbnVvdXMuDQpHSU0+PiBBcyBkaXNjdXNzZWQgaW4gIzMsIEkgdGhp bmsgdGhhdCBpdCBpcyBhbHJlYWR5IHBhcnQgb2YgTE1BUCBZQU5HIG1vZGVsLg0KNy4gQWRkIGxl YWYgJ3JlZmxlY3Rvci1saWdodC1tb2RlLXN0YXRlJyB0byAvdHdhbXAtbGlnaHQvdHdhbXAtbGln aHQtc2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNzaW9uKi4gVGhpcyBsZWFmIGluZGljYXRlcyB0aGUg dGhlIHJlZmxlY3RvcidzIG1vZGU6IHN0YXRlZnVsIG9yIHN0YXRlbGVzcy4gSWYgdGhlIHJlZmxl Y3RvcidzIG1vZGUgaXMgc3RhdGVmdWwuIFR3byBvbmUgd2F5IHBhY2tldCBsb3NzIHN0YXRpc3Rp Y3MgY2FuIGJlIGdvdDogb25lLXdheS1wYWNrZXQtbG9zcy1mYXItZW5kLCBvbmUtd2F5LXBhY2tl dC1sb3NzLW5lYXItZW5kLg0KQ29uc2lkZXJhdGlvbjoNCk9ubHkgdmFsaWQgZGF0YSBzaG91bGQg YmUgcHJlc2VudGVkIHRvIHVzZXIuIE90aGVyd2lzZSBpdCBjb3VsZCBtaXNsZWFkaW5nIHVzZXIg aW4gc29tZSBjYXNlcy4NCkdJTT4+IEEgaW4gcmVzcG9uc2UgdG8gIzIuDQo4LiBNb2RpZnkgbGVh ZiAvdHdhbXAtbGlnaHQvdHdhbXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNzaW9uKi9u dW1iZXItb2YtcGFja2V0cy4gQWRkIGEgJ3doZW4nIGNvbmRpdGlvbiB0byB0aGlzIGxlYWYuIFdo ZW4gc2VuZC1tb2RlIGlzICdjb250aW51b3VzJywgdGhlIGxlYWYgbnVtYmVyLW9mLXBhY2tldHMg aXMgbWVhbmluZ2xlc3MuIFNvIGFkZCBhICd3aGVuJyBjb25kaXRpb24gdG8gbGltaXQgaXQuICBC ZXNpZGVzLCBhZGRlZCBhIGRlZmF1bHQgdmFsdWUg4oCYMTDigJkgdG8gaXQuIFdoZW4gdGhlIHNl bmQtbW9kZSBpcyAnbm9uLWNvbnRpbnVvdXMnLCB0aGUgc2Vzc2lvbiBjYW4ndCB3b3JrIHdpdGgg YW4gZW1wdHkgbnVtYmVyLW9mLXBhY2tldHMuDQpHSU0+PiBBcyBJJ3ZlIG5vdGVkIGluICMzLiBX aWxsIGFkZCBkZWZhdWx0Lg0KOS4gQWRkIGxlYWYgdGltZSBvdXQgdG8gL3R3YW1wLWxpZ2h0L3R3 YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVyL3Rlc3Qtc2Vzc2lvbiouIEEgdGltZW91dCBtZWNoYW5p c20gaXMgbmVlZGVkIHdoZW4gdGhlIHNlbmRlciBzZXNzaW9uIGNhbid0IGdldCBhbGwgdGhlIHJl cGx5IHBhY2tldHMgZm9yIGEgbG9uZyB0aW1lLg0KR0lNPj4gVGhhbmsgeW91LCB3aWxsIGFkZCBp biB0aGUgbmV4dCB1cGRhdGUuDQoxMC4gTW9kaWZ5IGxlYWYgL3R3YW1wLWxpZ2h0L3R3YW1wLWxp Z2h0LXNlc3Npb24tc2VuZGVyL3Rlc3Qtc2Vzc2lvbiovaW50ZXJ2YWwuIENoYW5nZSB0aGUgdW5p dHMgZnJvbSDigJhtaWNyb3NlY29uZHPigJkgdG8g4oCYbWlsbGlzZWNvbmRz4oCZLiBBZGQgYSBk ZWZhdWx0IHZhbHVlIDEwMDAuDQpDb25zaWRlcmF0aW9uOg0KICAgIDEpLiBUaGUgYWltIG9mIFRX QU1QIGlzIHRvIG1lYXN1cmUgbmV0d29yayBxdWFsaXR5LCBidXQgbm90IGZhc3QgZmFpbHVyZSBk ZXRlY3Rpb24uIFNvIGEgbWlsbGlzZWNvbmQgcGFja2V0IGludGVydmFsIGlzIGVub3VnaC4NCiAg ICAyKS4gSW50ZXJ2YWwgaXMgYSBuZWNlc3NhcnkgcGFyYW1ldGVyIGZvciBhIHNlc3Npb24uIEEg c2VuZGVyIHNlc3Npb24gY2FuJ3Qgd29yayB3aXRoIGFuIGVtcHR5IHBhY2tldCBzZW5kIGludGVy dmFsLiBTbyBhZGRlZCBhIGRlZmF1bHQgdmFsdWUgdG8gaXQuDQpHSU0+PiBUaGFuayB5b3UuIFdl J3ZlIG1hZGUgdW5pdHMgb2YgaW50ZXJ2YWwgbWljcm9zZWNvbmRzIGluIHRoZSBsYXN0IHVwZGF0 ZSBhbHJlYWR5LiBJIHRoaW5rIHRoYXQgY2hhbmdpbmcgdG8gbWlsbGlzZWNvbmRzIG1heSBiZSB0 b28gcmVzdHJpY3RpdmUsIGxpbWl0IHVzZSBjYXNlcyBmb3IgVFdBTVAgVGVzdC4gV2lsbCBhZGQg ZGVmYXVsdCB2YWx1ZSB3aXRoIHRoZSBuZXh0IHVwZGF0ZS4NCltXRUk+Pl0gU29ycnksIEkgZG8g bm90IHNlZSB0aGUgcmVhc29uLiBBcmUgdGhlcmUgYW55IHVzZXIgY2FzZXMgdG8gdXNlIG1pY3Jv c2Vjb25kcz8NCjExLiBBZGQgbGVhZiAnZHNjcCcgdG8gL3R3YW1wLWxpZ2h0L3R3YW1wLWxpZ2h0 LXNlc3Npb24tc2VuZGVyL3Rlc3Qtc2Vzc2lvbiouIFRoaXMgaXMgdGhlIGxlYWYgbW92ZWQgb3V0 IGZyb20gZ3JvdXBpbmcgc2Vzc2lvbi1saWdodC1wYXJhbWV0ZXJzLg0KR0lNPj4gQXMgbm90ZWQg aW4gcmVzcG9uc2UgIzUsIHRoZSBjaGFuZ2UgbWF5IGxpbWl0IGFiaWxpdHkgdG8gcnVuIGNvbmN1 cnJlbnQgVFdBTVAgVGVzdCBzZXNzaW9ucyBwZXIgQ29TLiBJIGNvbnNpZGVyIHRoYXQgdG8gYmUg dmFsdWFibGUgbW9kZSBidXQgd291bGQgbGlrZSB0byBoZWFyIGZyb20gbmV0d29yayBvcGVyYXRv cnMgaWYgdGhhdCBpcyBpbmRlZWQgdXNlZnVsIGluZm9ybWF0aW9uLg0KDQpTZWUgbXkgY29tbWVu dCBhYm92ZS4gSSBhcmd1ZSB0aGF0IGl0IGlzIHVzZWZ1bCB0byBrZWVwIHRyYWNrIG9mIGNoYW5n aW5nIERTQ1AgdmFsdWVzLCBhbmQgdHJlYXRpbmcgRFNDUCBhcyBhIG1ldHJpYyBvZiB0aGUgVFdB TVAgU2Vzc2lvbiBqdXN0IGxpa2UgbG9zcyBhbmQgZGVsYXkNCjEyLiBNb3ZlIGxlYXZlcyAncmVm LXdhaXQnLCAncmVmbGVjdG9yLWxpZ2h0LW1vZGUtc3RhdGUnIGFuZCAnZHNjcC1oYW5kbGluZy1t b2RlJyBmcm9tIC90d2FtcC1saWdodC90d2FtcC1saWdodC1zZXNzaW9uLXJlZmxlY3RvciB0byAv dHdhbXAtbGlnaHQvdHdhbXAtbGlnaHQtc2Vzc2lvbi1yZWZsZWN0b3IvdGVzdC1zZXNzaW9uKi4g VGhlc2UgdGhyZWUgYXR0cmlidXRlcyBzaG91bGQgYmUgc2Vzc2lvbiBzcGVjaWZpYy4gRGlmZmVy ZW50IHNlc3Npb24gY291bGQgaGF2ZSBkaWZmZXJlbnQgdmFsdWVzLiBUaGV5IGFyZSBub3QgY29t bW9uIGF0dHJpYnV0ZXMuDQpHSU0+PiBBZ3JlZSwgd2lsbCBtYWtlIGl0IGluIHRoZSBuZXh0IHVw ZGF0ZS4NCjEzLiBBZGQgbGVhZiAnZHNjcCcgdG8gL3R3YW1wLWxpZ2h0L3R3YW1wLWxpZ2h0LXNl c3Npb24tcmVmbGVjdG9yL3Rlc3Qtc2Vzc2lvbiouIFRoaXMgaXMgdGhlIGxlYWYgbW92ZWQgb3V0 IGZyb20gZ3JvdXBpbmcgc2Vzc2lvbi1saWdodC1wYXJhbWV0ZXJzLiBCZXNpZGVzIHRoZSBtb3Zl bWVudCwgYWRkZWQgYSAnd2hlbicgY29uZGl0aW9uIHRvIHRoZSBsZWFmICdkc2NwJy4gVGhpcyBs ZWFmIGlzIG9ubHkgdmFsaWQgd2hlbiB0aGUgZHNjcC1oYW5kbGluZy1tb2RlIGlzICd1c2UtY29u ZmlndXJlZC12YWx1ZScuDQpHSU0+PiBBcyByZXNwb25zZSB0byAjNS4NCjE0LiBNb2RpZnkgbGVh ZiAvdHdhbXAtbGlnaHQtc3RhdGUvdHdhbXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXItc3RhdGUvdGVz dC1zZXNzaW9uLXN0YXRlKi9jdXJyZW50LXN0YXRzL251bWJlci1vZi1wYWNrZXRzLiBBZGQgYSAn d2hlbicgY29uZGl0aW9uIHRvIHRoaXMgbGVhZi4gV2hlbiBzZW5kLW1vZGUgaXMgJ2NvbnRpbnVv dXMnLCB0aGUgbGVhZiBudW1iZXItb2YtcGFja2V0cyBpcyBtZWFuaW5nbGVzcy4NCkdJTT4+IFNp bWlsYXIgdG8gIzMuDQoxNS4gTW9kaWZ5IGxlYWYgL3R3YW1wLWxpZ2h0LXN0YXRlL3R3YW1wLWxp Z2h0LXNlc3Npb24tc2VuZGVyLXN0YXRlL3Rlc3Qtc2Vzc2lvbi1zdGF0ZSovY3VycmVudC1zdGF0 cy9pbnRlcnZhbC4gQ2hhbmdlIHRoZSB1bml0cyBmcm9tIG1pY3Jvc2Vjb25kcyB0byBtaWxsaXNl Y29uZHMuDQpHSU0+PiBJIHRoaW5rIHRoYXQgbWljcm9zZWNvbmRzIGlzIHJlYXNvbmFibGUuDQox Ni4gQWRkIGxlYXZlcyAndHdvLXdheS1wYWNrZXQtbG9zcycsICdvbmUtd2F5LXBhY2tldC1sb3Nz LWZhci1lbmQnIGFuZCAnb25lLXdheS1wYWNrZXQtbG9zcy1uZWFyLWVuZCcgdG8gL3R3YW1wLWxp Z2h0LXN0YXRlL3R3YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVyLXN0YXRlL3Rlc3Qtc2Vzc2lvbi1z dGF0ZSovY3VycmVudC1zdGF0cy8uIFRoZXNlIGFyZSB0aGUgbmV3IHN0YXRpc3RpY3MgZm9yIHN0 YXRlZnVsIHJlZmxlY3Rvci4NCkdJTT4+IFRoYW5rIHlvdSwgd2lsbCBiZSBjb21pbmcgaW4gdGhl IG5leHQgdXBkYXRlLg0KMTcuIFJlbW92ZSBsZWFmIGxvc3MtcGFja2V0IGluIC90d2FtcC1saWdo dC1zdGF0ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1zdGF0ZS90ZXN0LXNlc3Npb24tc3Rh dGUqL2N1cnJlbnQtc3RhdHMuIFRoZSBsb3NzIHBhY2tldGVkIGlzIHJlcGxhY2VkIHdpdGggJ3R3 by13YXktcGFja2V0LWxvc3MnIHN0YXRlZCBhYm92ZS4NCkdJTT4+IEFncmVlLg0KMTguIE1vZGlm eSBsZWFmIHRvIC90d2FtcC1saWdodC1zdGF0ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1z dGF0ZS90ZXN0LXNlc3Npb24tc3RhdGUqL2hpc3Rvcnktc3RhdHMqL2ludGVydmFsLiBDaGFuZ2Ug dGhlIHVuaXRzIGZyb20gbWljcm9zZWNvbmRzIHRvIG1pbGxpc2Vjb25kcy4NCkdJTT4+IEkgdGhp bmsgdGhhdCB3aWxsIGxpbWl0IGFwcGxpY2FiaWxpdHkgb2YgVFdBTVAgVGVzdC4NCjE5LiBBZGQg bGVhdmVzICd0d28td2F5LXBhY2tldC1sb3NzJywgJ29uZS13YXktcGFja2V0LWxvc3MtZmFyLWVu ZCcgYW5kICdvbmUtd2F5LXBhY2tldC1sb3NzLW5lYXItZW5kJyB0byAvdHdhbXAtbGlnaHQtc3Rh dGUvdHdhbXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXItc3RhdGUvdGVzdC1zZXNzaW9uLXN0YXRlKi9o aXN0b3J5LXN0YXRzKi8uIFRoZXNlIGFyZSB0aGUgbmV3IHN0YXRpc3RpY3MgZm9yIHN0YXRlZnVs IHJlZmxlY3Rvci4NCkdJTT4+IEFncmVlLg0KDQpUaGFua3MsDQpXZWkgTHVvDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBs aXN0DQppcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg0KDQotLQ0KDQoNCltBY2NlZGlhbi5jb21d DQoNCg0KSGVucmlrIE55ZGVsbA0KDQpTciBNYW5hZ2VyIEdsb2JhbCBTdHJhdGVneSAmIFNvbHV0 aW9ucw0KDQoNCg0KQ2VsbA0KDQpFbWFpbA0KDQpTa3lwZQ0KDQoNCis0NiA3MDk4NDU5OTI8dGVs Ois0NiUyMDcwJTIwOTg0JTIwNTklMjA5Mj4NCg0KaG55ZGVsbEBhY2NlZGlhbi5jb208bWFpbHRv Om1rb3dhbGtlQGFjY2VkaWFuLmNvbT4NCg0KaDxodHRwOi8vbGlua2VkaW4uY29tL2luL21hZWtv d2Fsaz5ueWRlbGwNCg0KDQoNCltodHRwczovL2xoNC5nb29nbGV1c2VyY29udGVudC5jb20vcllN WDlCcTVNU3dwb3lFQ095V2VjbzJ6TlNnbXQzM0wyZUxIR1BXelVVbnZWMmxjUXRsM3dzVXBTSHRJ VW94ckJWaHpDSy1lTmtvX0VGdkxGRHVKX1NYTndIOHVtamVzeTVqMDh5UFl5cDFLUFRtRGV2eUZL RTdndnNiUl8xbl9DV0g1N2dMbV08aHR0cDovL2FjY2VkaWFuLmNvbS8+W2h0dHBzOi8vbGg2Lmdv b2dsZXVzZXJjb250ZW50LmNvbS9SckNuQmpITW5oV2lWa0RlQUNwbDBjLTU2NXFMMHlHekg2LUZ4 VWxXWTJld3NhSXh1Y1VmdjhYRElmWk1zY1RNakx6NXJ1UzFuOG5ZQ3JZbzV2ajBXNXN4UGtfMU1v dkJiVWRueGtpNUtWOE82M25mNk5RNUtvV3dNVlpFWW80S2FKTXh6bHFnXTxodHRwOi8vYmxvZy5h Y2NlZGlhbi5jb20vPiBbaHR0cHM6Ly9saDQuZ29vZ2xldXNlcmNvbnRlbnQuY29tL0E5Y1B5MFRF QklJX0ZxOUt6Q3FRbGFBTjM2T01oOHBpLXNEYmtWZWFMVXRZYmxJVjBybEFOVnh6Y0d4Qng4RDBv QWpxdmJCWWJsN0QzVWhGbmxrOE9sQ2x2MC1kaWhJMndRaS1mc3hQQlBMN3JiZGpudnV5dUROd2p6 VmtFenE3a0ZrUGVTWlNdIDxodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS9hY2NlZGlh bi1uZXR3b3Jrcz4gICBbaHR0cHM6Ly9saDQuZ29vZ2xldXNlcmNvbnRlbnQuY29tL01EMWxhbDdJ bzMwYTdsSzhXVWxZRzJ5NmZzbmRDbWtrc2lKMXZXYjRRU0dmdFREeFRzdUxESUdSSWtua0k3Zmdw RnM2RzBQYVB2eDlvbDZrQkNoZ0ZTZ3hRQk9nWGx3RkRwM2NxeG9jM0VYTzd2VkJxZVpDbDYwRFV6 Nm8tX0g0amVBam1ONW5dIDxodHRwczovL3R3aXR0ZXIuY29tL0FjY2VkaWFuPiAgIFtodHRwczov L2xoNi5nb29nbGV1c2VyY29udGVudC5jb20vajlKNkZ4R29lLVVRbUVVLTJUWUh0VjJiSHduNWJX QlFWSjRFOVh4eDhlLXgzQW8teGtuWkpiWFIxZFBmZVZBdDdXSXpidGwyN3lYbjNiWGxhdUYtY0pH Y09UME9Mb3RVLVgwbU1wNzlwVnY4Q1pabV9EdXlLelJ2RVd2YWhpZTJMYmQ5bjBZSl0gPGh0dHBz Oi8vd3d3LmZhY2Vib29rLmNvbS9hY2NlZGlhbj4gICBbaHR0cHM6Ly9saDUuZ29vZ2xldXNlcmNv bnRlbnQuY29tL0lKbUdXWG1tc0MwemtRWk4xdFM3QVVOUTBRdWRoZHdmNjB0NndMZ19xdkNsNGQ1 bVNqelNBb3VUY0NFbDdsUmpORVNpZUc2WmlHaGdRbkZYSHBkdnpUWU5OVFVPcWZVV0QtNktiR3dH eG0yak0wS3FRb01LTzZ2a2NRNWlLUTJjcEo3OXk4NEddIDxodHRwOi8vd3d3LnlvdXR1YmUuY29t L3VzZXIvYWNjZWRpYW4+DQoNCg0KW2h0dHBzOi8vbGg0Lmdvb2dsZXVzZXJjb250ZW50LmNvbS9T RjZwdGNUdWpNMjRnLTdUTDNjTDVDTUZIcXdnRmkya1NGblpsNk9TNkhhX2VXNmY4elAyN2l5Q1RM N281YjV2bGI1cDQzM3dHckRrWmtiQkZhWEFGanhsTWduY09sYTlFVDd2LTc3MUV2djRzNThCOUQ2 UEdqQVVETzlkWlo4bGFLSTA4MVVyXQ0KDQoNCg0KQXZpcyBkZSBjb25maWRlbnRpYWxpdMOpDQoN CkxlcyBpbmZvcm1hdGlvbnMgY29udGVudWVzIGRhbnMgbGUgcHLDqXNlbnQgbWVzc2FnZSBldCBk YW5zIHRvdXRlIHBpw6hjZSBxdWkgbHVpIGVzdCBqb2ludGUgc29udCBjb25maWRlbnRpZWxsZXMg ZXQgcGV1dmVudCDDqnRyZSBwcm90w6lnw6llcyBwYXIgbGUgc2VjcmV0IHByb2Zlc3Npb25uZWwu IENlcyBpbmZvcm1hdGlvbnMgc29udCDDoCBs4oCZdXNhZ2UgZXhjbHVzaWYgZGUgc29uIG91IGRl IHNlcyBkZXN0aW5hdGFpcmVzLiBTaSB2b3VzIHJlY2V2ZXogY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBz4oCZaWwgdm91cyBwbGFpdCBjb21tdW5pcXVlciBpbW3DqWRpYXRlbWVudCBh dmVjIGzigJlleHDDqWRpdGV1ciBldCBlbiBkw6l0cnVpcmUgdG91dCBleGVtcGxhaXJlLiBEZSBw bHVzLCBpbCB2b3VzIGVzdCBzdHJpY3RlbWVudCBpbnRlcmRpdCBkZSBsZSBkaXZ1bGd1ZXIsIGRl IGxlIGRpc3RyaWJ1ZXIgb3UgZGUgbGUgcmVwcm9kdWlyZSBzYW5zIGzigJlhdXRvcmlzYXRpb24g ZGUgbOKAmWV4cMOpZGl0ZXVyLiBNZXJjaS4NCg0KQ29uZmlkZW50aWFsaXR5IG5vdGljZQ0KDQpU aGlzIGUtbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudCBoZXJldG8gY29udGFpbiBjb25m aWRlbnRpYWwgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgYW5kIHdoaWNoIGlz IGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiBpdHMgYWRkcmVzc2VlKHMpLiBJZiB5 b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBkZXN0cm95IGFueSBjb3B5IHRoZXJlb2YuIEZ1cnRoZXJtb3JlLCBhbnkg ZGlzY2xvc3VyZSwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdlIGFuZC9v ciBhbnkgYXR0YWNobWVudCBoZXJldG8gd2l0aG91dCB0aGUgY29uc2VudCBvZiB0aGUgc2VuZGVy IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIFRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBsaXN0DQppcHBtQGll dGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHBtDQoNCg0KDQoNCi0tDQoNCg0KW0FjY2VkaWFuLmNvbV0NCg0KDQpIZW5y aWsgTnlkZWxsDQoNClNyIE1hbmFnZXIgR2xvYmFsIFN0cmF0ZWd5ICYgU29sdXRpb25zDQoNCg0K DQpDZWxsDQoNCkVtYWlsDQoNClNreXBlDQoNCg0KKzQ2IDcwOTg0NTk5Mg0KDQpobnlkZWxsQGFj Y2VkaWFuLmNvbTxtYWlsdG86bWtvd2Fsa2VAYWNjZWRpYW4uY29tPg0KDQpoPGh0dHA6Ly9saW5r ZWRpbi5jb20vaW4vbWFla293YWxrPm55ZGVsbA0KDQoNCg0KW2h0dHBzOi8vbGg0Lmdvb2dsZXVz ZXJjb250ZW50LmNvbS9yWU1YOUJxNU1Td3BveUVDT3lXZWNvMnpOU2dtdDMzTDJlTEhHUFd6VVVu dlYybGNRdGwzd3NVcFNIdElVb3hyQlZoekNLLWVOa29fRUZ2TEZEdUpfU1hOd0g4dW1qZXN5NWow OHlQWXlwMUtQVG1EZXZ5RktFN2d2c2JSXzFuX0NXSDU3Z0xtXTxodHRwOi8vYWNjZWRpYW4uY29t Lz5baHR0cHM6Ly9saDYuZ29vZ2xldXNlcmNvbnRlbnQuY29tL1JyQ25CakhNbmhXaVZrRGVBQ3Bs MGMtNTY1cUwweUd6SDYtRnhVbFdZMmV3c2FJeHVjVWZ2OFhESWZaTXNjVE1qTHo1cnVTMW44bllD cllvNXZqMFc1c3hQa18xTW92QmJVZG54a2k1S1Y4TzYzbmY2TlE1S29Xd01WWkVZbzRLYUpNeHps cWddPGh0dHA6Ly9ibG9nLmFjY2VkaWFuLmNvbS8+IFtodHRwczovL2xoNC5nb29nbGV1c2VyY29u dGVudC5jb20vQTljUHkwVEVCSUlfRnE5S3pDcVFsYUFOMzZPTWg4cGktc0Ria1ZlYUxVdFlibElW MHJsQU5WeHpjR3hCeDhEMG9BanF2YkJZYmw3RDNVaEZubGs4T2xDbHYwLWRpaEkyd1FpLWZzeFBC UEw3cmJkam52dXl1RE53anpWa0V6cTdrRmtQZVNaU10gPGh0dHBzOi8vd3d3LmxpbmtlZGluLmNv bS9jb21wYW55L2FjY2VkaWFuLW5ldHdvcmtzPiAgIFtodHRwczovL2xoNC5nb29nbGV1c2VyY29u dGVudC5jb20vTUQxbGFsN0lvMzBhN2xLOFdVbFlHMnk2ZnNuZENta2tzaUoxdldiNFFTR2Z0VER4 VHN1TERJR1JJa25rSTdmZ3BGczZHMFBhUHZ4OW9sNmtCQ2hnRlNneFFCT2dYbHdGRHAzY3F4b2Mz RVhPN3ZWQnFlWkNsNjBEVXo2by1fSDRqZUFqbU41bl0gPGh0dHBzOi8vdHdpdHRlci5jb20vQWNj ZWRpYW4+ICAgW2h0dHBzOi8vbGg2Lmdvb2dsZXVzZXJjb250ZW50LmNvbS9qOUo2RnhHb2UtVVFt RVUtMlRZSHRWMmJId241YldCUVZKNEU5WHh4OGUteDNBby14a25aSmJYUjFkUGZlVkF0N1dJemJ0 bDI3eVhuM2JYbGF1Ri1jSkdjT1QwT0xvdFUtWDBtTXA3OXBWdjhDWlptX0R1eUt6UnZFV3ZhaGll MkxiZDluMFlKXSA8aHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL2FjY2VkaWFuPiAgIFtodHRwczov L2xoNS5nb29nbGV1c2VyY29udGVudC5jb20vSUptR1dYbW1zQzB6a1FaTjF0UzdBVU5RMFF1ZGhk d2Y2MHQ2d0xnX3F2Q2w0ZDVtU2p6U0FvdVRjQ0VsN2xSak5FU2llRzZaaUdoZ1FuRlhIcGR2elRZ Tk5UVU9xZlVXRC02S2JHd0d4bTJqTTBLcVFvTUtPNnZrY1E1aUtRMmNwSjc5eTg0R10gPGh0dHA6 Ly93d3cueW91dHViZS5jb20vdXNlci9hY2NlZGlhbj4NCg0KDQpbaHR0cHM6Ly9saDQuZ29vZ2xl dXNlcmNvbnRlbnQuY29tL1NGNnB0Y1R1ak0yNGctN1RMM2NMNUNNRkhxd2dGaTJrU0ZuWmw2T1M2 SGFfZVc2Zjh6UDI3aXlDVEw3bzViNXZsYjVwNDMzd0dyRGtaa2JCRmFYQUZqeGxNZ25jT2xhOUVU N3YtNzcxRXZ2NHM1OEI5RDZQR2pBVURPOWRaWjhsYUtJMDgxVXJdDQoNCg0KDQpBdmlzIGRlIGNv bmZpZGVudGlhbGl0w6kNCg0KTGVzIGluZm9ybWF0aW9ucyBjb250ZW51ZXMgZGFucyBsZSBwcsOp c2VudCBtZXNzYWdlIGV0IGRhbnMgdG91dGUgcGnDqGNlIHF1aSBsdWkgZXN0IGpvaW50ZSBzb250 IGNvbmZpZGVudGllbGxlcyBldCBwZXV2ZW50IMOqdHJlIHByb3TDqWfDqWVzIHBhciBsZSBzZWNy ZXQgcHJvZmVzc2lvbm5lbC4gQ2VzIGluZm9ybWF0aW9ucyBzb250IMOgIGzigJl1c2FnZSBleGNs dXNpZiBkZSBzb24gb3UgZGUgc2VzIGRlc3RpbmF0YWlyZXMuIFNpIHZvdXMgcmVjZXZleiBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IHPigJlpbCB2b3VzIHBsYWl0IGNvbW11bmlxdWVy IGltbcOpZGlhdGVtZW50IGF2ZWMgbOKAmWV4cMOpZGl0ZXVyIGV0IGVuIGTDqXRydWlyZSB0b3V0 IGV4ZW1wbGFpcmUuIERlIHBsdXMsIGlsIHZvdXMgZXN0IHN0cmljdGVtZW50IGludGVyZGl0IGRl IGxlIGRpdnVsZ3VlciwgZGUgbGUgZGlzdHJpYnVlciBvdSBkZSBsZSByZXByb2R1aXJlIHNhbnMg bOKAmWF1dG9yaXNhdGlvbiBkZSBs4oCZZXhww6lkaXRldXIuIE1lcmNpLg0KDQpDb25maWRlbnRp YWxpdHkgbm90aWNlDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50IGhl cmV0byBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmls ZWdlZCBhbmQgd2hpY2ggaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIGl0cyBh ZGRyZXNzZWUocykuIElmIHlvdSByZWNlaXZlIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNl IGluZm9ybSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRlc3Ryb3kgYW55IGNvcHkgdGhlcmVvZi4g RnVydGhlcm1vcmUsIGFueSBkaXNjbG9zdXJlLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0 aGlzIG1lc3NhZ2UgYW5kL29yIGFueSBhdHRhY2htZW50IGhlcmV0byB3aXRob3V0IHRoZSBjb25z ZW50IG9mIHRoZSBzZW5kZXIgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gVGhhbmsgeW91Lg0K --_000_HE1PR0701MB2890E73A9A9D5E896235E651D7180HE1PR0701MB2890_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFu Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MTQ4NTM5MDc5MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTczNzkxNjAw MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTc1NDQzMDY5 MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6Mzg1NTQ3NTgwO30NCkBsaXN0IGwxOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDox LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5QbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+V2VpIEx1bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gSGVucmlrIE55ZGVsbCBbbWFpbHRvOmhueWRlbGxAYWNjZWRpYW4uY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDE4LCAyMDE3IDc6NTkgUE08YnI+ DQo8Yj5Ubzo8L2I+IEdyZWcgTWlyc2t5ICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBXZWkgTHVvIFMgJmx0O3dlaS5zLmx1b0Blcmljc3Nvbi5jb20mZ3Q7OyBk cmFmdC1taXJza3ktaXBwbS10d2FtcC1saWdodC15YW5nQHRvb2xzLmlldGYub3JnOyBpcHBtQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaXBwbV0gU29tZSB0aG91Z2ggb24gZHJh ZnQtbWlyc2t5LWlwcG0tdHdhbXAtbGlnaHQteWFuZy0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgd291bGQgYXNrIHlvdSB0byBjb25zaWRlciBhZGRpbmcgc29tZSBt b3JlIHZhbHVhYmxlIG1ldHJpY3M8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4xKSBMb3NzIGJ1cnN0IHNpemUgbWF4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBsb3NzLWJ1cnN0LW1heCB7PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW50MzI7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O0hpZ2hlc3QgbnVtYmVyIG9mIGxvc3QgcGFja2V0cyBiYWNrLXRvLWJhY2sgZHVyaW5nIGlu dGVydmFsLiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+W1dFSV0gQWdyZWUsIGl04oCZcyB2YWx1YWJsZSwgSSB0aGluayB3ZSBzaG91bGQgYWRk IGl0LiBCZXNpZGVzLCBJIHN1Z2dlc3QgdG8gYWRkIG9uZSBtb3JlIG1ldHJpY3M6IGxvc3MtYnVy c3QtbWluLCB3aGljaCBpcyB0aGUgbWluaW11bSAmbmJzcDtudW1iZXIgb2YgbG9zdCBwYWNrZXRz IGJhY2stdG8tYmFjayBkdXJpbmcgaW50ZXJ2YWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpIExvc3MgYnVyc3QgY291bnQg KHRlbGxzIGhvdyBtYW55IGluc3RhbmNlcyB0aGVyZSB3YXMgb2YgcGFja2V0IGxvc3MgZHVyaW5n IGFuIGludGVydmFsLCBvbmUgJnF1b3Q7aW5zdGFuY2UmcXVvdDsgbWVhbnMgb25lIG9yIG1vcmUg Y29uc2VjdXRpdmUgcGFja2V0cyBsb3N0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgbG9zcy1idXJzdC1jb3VudCB7PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW50MzI7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90 O051bWJlciBvZiBvY2Nhc2lvbnMgd2l0aCBwYWNrZXQgbG9zcyBkdXJpbmcgaW50ZXJ2YWwuJnF1 b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UbyBmdXJ0aGVyIGV4cGxhaW4gdGhlIGFib3ZlIG1ldHJpY3MsIGNvbnNpZGVyIDYwLXNl Y29uZCBpbnRlcnZhbCBiZWxvdyB3aXRoIDEgcGFja2V0IHBlciBzZWNvbmQgbW9uaXRvcmluZywg d2hlcmUgeCBtZWFucyBsb3N0IHBhY2tldCBhbmQgbyBtZWFucyByZWNpZXZlZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4wICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgNjBzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5vb29Yb29Yb29vb1hYWFhvb29vb29vb29vWFhvb29vb1hvb29Yb29vb29v b29YWFhYWFhYWFhYWFhvb288L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgNjBzLWludGVydmFsIGhhcyAyMiBsb3N0IHBhY2tl dHMgKCAyMi82MCA9MzYuNjclIGxvc3MpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb3NzIGJ1cnN0IG1heCBpcyAxMiBwYWNrZXRzLCBudW1iZXIg b2YgbG9zcyBpbnN0YW5jZXMgYXJlIDc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bV0VJXSBBZ3JlZS4gSXQgc2hvdWxkIGJlIGFk ZGVkLiBGb3Igc3RhdGVmdWwgcmVmbGVjdG9yLCB0d28gbW9yZSBtZXRyaWNzIGNhbiBiZSBhZGRl ZDogbG9zcy1idXJzdC1jb3VudC1mYXItZW5kLCBsb3NzLWJ1cnN0LWNvdW50LW5lYXItZW5kLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4zKSBQZXJjZW50aWxlcyBhcmUgdmVyeSB1c2VmdWwgYW5kIGltcG9ydGFudC4gSWYgdGhl eSBjYW5ub3QgYmUgJnF1b3Q7Y29uZmlndXJhYmxlJnF1b3Q7IGluIHRoZSBZYW5nIG1vZGVsIEkg d291bGQgc3VnZ2VzdCB5b3UgdG8gY29uc2lkZXIgYWRkaW5nIGF0IGxlYXN0IHRoZSA5NXRoLCA5 OXRoIGFuZCA5OS45dGggcGVyY2VudGlsZXMgZm9yIGFsbCBkZWxheSB0eXBlIG1ldHJpY3MuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b V0VJXSBDb3VsZCB5b3UgZXhwbGFpbiB0aGUgbWVhbmluZyBvZiDigJxwZXJjZW50aWxl4oCdIGhl cmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVGh1LCBBcHIgMTMsIDIwMTcgYXQgNjo1MyBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhy ZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ncmVnaW1p cnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBBbGwsPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LW1pcnNreS1pcHBtLXR3YW1wLWxpZ2h0LXlhbmctMDgiIHRhcmdldD0iX2Js YW5rIj50aGUgbmV3IHVwZGF0ZSBvZiB0aGUgVFdBTVAtTGlnaHQgWUFORyBtb2RlbDwvYT4mbmJz cDtoYXMgYmVlbiBwdWJsaXNoZWQuIEl0IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmc6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCnBhY2tldCBsb3NzIHJhdGlvIGFzIGRl Y2ltYWw2NCB0eXBlIHdpdGggZnJhY3Rpb24tc2l6ZSA1OzxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCnNlc3Npb24tcmVmbGVj dG9yIHN0YXRlIHBhcmFtZXRlciBpbiBzZXNzaW9uLXNlbmRlciBjb250YWluZXI7PG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K ZGVmaW5lZCBjb250aW51b3VzIGFuZCBwZXJpb2RpYyBtb2RlcyB0byBleGVjdXRlIGEgdGVzdCBz ZXNzaW9uIGFuZCBob3cgcGVyZm9ybWFuY2UgbWV0cmljcyBhcmUgY2FsY3VsYXRlZCBpbiBlYWNo IG9mIHRoZSBtb2Rlczs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpyZXBvcnRpbmcgb2Ygb25lLXdheSBwYWNrZXQgbG9zcyBt ZXRyaWNzLCBib3RoIG5lYXItZW5kIGFuZCBmYXItZW5kLCBoYXMgZGVwZW5kZW5jeSBvZiByZWZs ZWN0b3IncyBtb2RlLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNvbWUgcXVlc3Rpb25zIHN0aWxsIGJlaW5nIGRpc2N1c3NlZCBhbmQgd2UgZ3JlYXRs eSBhcHByZWNpYXRlIHN1Z2dlc3Rpb25zLCBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQppbmNsdWRlIHBlcmNlbnRpbGUgaW4gZGVsYXkg YW5kIGRlbGF5LXZhcmlhdGlvbiBjb250YWluZXJzPzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCmRlZmF1bHQgdmFsdWUgZm9y IHNlc3Npb24tdGltZW91dCBpbiBzZXNzaW9uLXNlbmRlciBjb250YWluZXIgaXMgOTAwIHNlY29u ZHMuIFNlZW1zIHRvbyBiaWcuIFdoYXQgbWF5IGJlIHByYWN0aWNhbD8gQ2hhbmdlIHVuaXRzIGZy b20gc2Vjb25kcyB0byBjZW50aXNlY29uZHMgb3IgbWlsbGlzZWNvbmRzPzxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWc8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUdWUsIE1hciAyMSwgMjAxNyBhdCA1OjIxIEFNLCBIZW5yaWsgTnlkZWxsICZs dDs8YSBocmVmPSJtYWlsdG86aG55ZGVsbEBhY2NlZGlhbi5jb20iIHRhcmdldD0iX2JsYW5rIj5o bnlkZWxsQGFjY2VkaWFuLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Tb21lIGNvbW1lbnRzIGZyb20gdGhlICZxdW90O2ZpZWxkJnF1b3Q7IGFzIEFjY2Vk aWFuIGhhcyBzZXZlcmFsIGh1bmRyZWQgdGhvdXNhbmQgVFdBTVAgc2Vzc2lvbnMgcnVubmluZyAo Y29udGlub3VzbHkpIGF0IG51bWVyb3VzIFRpZXIgb25lIG1vYmlsZS9maXhlZCBvcGVyYXRvcnMg Z2xvYmFsbHkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIE1hciAyMSwgMjAxNyBhdCAxMTo1MiBBTSwgV2VpIEx1byBTICZsdDs8YSBo cmVmPSJtYWlsdG86d2VpLnMubHVvQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndlaS5z Lmx1b0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5IaSBHcmVnLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGEgbG90IGZvciB5b3VyIHJlc3Bv bnNlLiBQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZSB0YWdnZWQgW1dFSSZndDsmZ3Q7XS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldlaSBMdW88L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBHcmVnIE1pcnNreSBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5n cmVnaW1pcnNreUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1h cmNoIDIxLCAyMDE3IDE6MTYgQU08YnI+DQo8Yj5Ubzo8L2I+IFdlaSBMdW8gUyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOndlaS5zLmx1b0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj53ZWkucy5s dW9AZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpp cHBtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzpkcmFmdC1taXJza3ktaXBwbS10d2FtcC1saWdodC15YW5nQHRvb2xzLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1taXJza3ktaXBwbS10d2FtcC1saWdodC15YW5nQHRv b2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU29tZSB0aG91Z2ggb24g ZHJhZnQtbWlyc2t5LWlwcG0tdHdhbXAtbGlnaHQteWFuZy0wNzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBXZWkgTHVvLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+bWFueSB0aGFua3MgZm9yIHlvdXIgdGhvcm91Z2ggcmV2 aWV3IGFuZCB0aGUgbW9zdCBoZWxwZnVsIGNvbW1lbnRzIHRvIHRoZSBUV0FNUCBMaWdodChUZXN0 KSBtb2RlbC4gUGxlYXNlIGZpbmQgbXkgYW5zd2Vycywgbm90ZXMgaW4tbGluZSB0YWdnZWQgR0lN Jmd0OyZndDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5HcmVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T24gU2F0LCBNYXIgMTgsIDIwMTcgYXQgNDoyNyBBTSwgV2VpIEx1byBT ICZsdDs8YSBocmVmPSJtYWlsdG86d2VpLnMubHVvQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPndlaS5zLmx1b0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEdyZWcgJmFtcDsgQWRyaWFuLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBpcyBXZWkgTHVvIGZyb20gRXJpY3Nzb24uIEkg d29yayBvbiBUV0FNUCBsaWdodCBhcmVhIGluIEVyaWNzc29uLiBUaGUgY3VycmVudCBUV0FNUCBM aWdodCBZQU5HIG1vZGVsIGlzIHdlbGwgZGVmaW5lZC4gVGhhbmtzIGZvciB5b3VyIGdyZWF0IGpv Yi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CdXQgYnkgd29ya2lu ZyBjbG9zZWx5IHdpdGggb3VyIGN1c3RvbWVycywgd2UgZ290IHNvbWUgbmV3IHVzZXIgY2FzZXMg b24gVFdBTVAgbGlnaHQuIEkgYmVsaWV2ZSB0aGVzZSB1c2VyIGNhc2VzIGFyZSB2YWx1YWJsZSBh bmQgcG9wdWxhciBlbm91Z2ggdG8gYmUgbW9kZWxlZCBpbiBUV0FNUCBMaWdodCBZQU5HLg0KIEkg aG9wZSBJIGNhbiBiZSBhIGNvbnRyaWJ1dG9yICZuYnNwO2FuZCBjby13b3JrIHdpdGggeW91IG1v dmUgdGhpcyBkcmFmdCBmb3J3YXJkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JICZuYnNwO2RyYWZ0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgVFdBTVAgbGln aHQgWUFORyBtb2RlbCBiYXNlZCBvbiB2ZXJzaW9uDQo8YSBocmVmPSJtYWlsdG86aWV0Zi10d2Ft cC1saWdodEAyMDE3LTAyLTEzLnlhbmciIHRhcmdldD0iX2JsYW5rIj5pZXRmLXR3YW1wLWxpZ2h0 QDIwMTctMDItMTMueWFuZzwvYT4uIENvdWxkIHlvdSBwbGVhc2UgY29tbWVudHMgb24gaXQ/IEFu eSBkaXNjdXNzaW9uIGlzIHdlbGNvbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoZSBkcmFmdCB5YW5nIG1vZGVsIGFuZCB0cmVlIGlzIGF0dGFjaGVkLiBUbyBtYWtl IHlvdSBmaW5kIHRoZSB1cGRhdGVzIHF1aWNrbHksIEkNCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k OnllbGxvdyI+aGlnaGxpZ2h0ZWQ8L3NwYW4+IGFsbCB0aGUgdXBkYXRlcyBpbiBmaWxlIGlldGYt dHdhbXAtbGlnaHQtd2VpbHVvLnBkZi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBm b2xsb3dpbmcgYXJlIHRoZSBsaXN0IG9mIG1haW4gdXBkYXRlczo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MS4gQWRkIGEgbmV3IHR5cGVkZWY6IHBlcmNlbnQuIFRo aXMgaXMgYSBuZXcgdHlwZSBkZWZpbmVkIGZvciBwYWNrZXQgbG9zcyByYXRpby48L2I+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbnNpZGVyYXRpb246DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDo5Ljc1cHQiPg0KMSku IEZyb20gdGhlIGN1c3RvbWVyIHBlcnNwZWN0aXZlLCBwYWNrZXQgbG9zcyByYXRpbyBpcyBhIG1v cmUgbWVhbmluZ2Z1bCBkYXRhLiBJbiBtb3N0IG9mIHRoZSB0aW1lLCB0aGUgYWJzb2x1dGUgbnVt YmVyIGlzIG1lYW5pbmdsZXNzIHRvIHVzZXIsIGVzcGVjaWFsbHkgdGhleSBkbyB0aGUgVFdBTVAg dGVzdCBjb250aW51b3VzbHkuIFRoZXkgYXJlIG1vcmUgY2FyZSBhYm91dCB0aGUgcmF0aW8gdGhh biB0aGUgYWJzb2x1dGUgbnVtYmVyLiBTbw0KIGFkZGluZyBpdCBtYWtlcyB0aGlzIG1vZGVsIG1v cmUgZnJpZW5kbHkgdG8gY3VzdG9tZXI7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO3RleHQtaW5kZW50OjkuNzVwdCI+DQoyKS4gRnJvbSB0aGUgc2VydmljZSBsYXllciBh c3N1cmFuY2UoU0xBKSBwZXJzcGVjdGl2ZSwgdGhlIHBhY2tldCBsb3NzIHJhdGlvIGlzIGEgbWFq b3IgbWVhc3VyZXMuIFNvIHdpdGggYWRkaW5nIHBhY2tldCBsb3NzIHJhdGlvIGluIG1vZGVsLCB0 aGUgVFdBTVAgY2FuIHdvcmsgaW4gU0xBIGZyYW1ld29yayBtb3JlIHNtb290aGx5Lg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6OS43NXB0Ij4NCjMp LiBJdCBzZWVtcyBzb21lIHNpbWlsYXIgcHJvdG9jb2zigJlzIFlBTkcgbW9kZWwgaGFzIHRoZSBz YW1lIGRlZmluaXRpb24sIGUuZy4g4oCYU2VydmljZSBPQU0gUGVyZm9ybWFuY2UgTW9uaXRvcmlu ZyBZQU5HIE1vZHVsZeKAmSwNCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lm1lZi5uZXQvQXNzZXRzL1Rl Y2huaWNhbF9TcGVjaWZpY2F0aW9ucy9QREYvTUVGXzM5LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPmh0dHBzOi8vd3d3Lm1lZi5uZXQvQXNzZXRz L1RlY2huaWNhbF9TcGVjaWZpY2F0aW9ucy9QREYvTUVGXzM5LnBkZjwvc3Bhbj48L2E+LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlZCBwYWNrZXQgbG9zcyBpcyBpbXBvcnRh bnQsIGhvd2V2ZXIgYW5vdGhlciBpbXBvcnRhbnQgbG9zcyBtZXRyaWMgaXMgbG9zcyBidXJzdCBz aXplIChtYXgvbWluKSBhbmQgbnVtYmVyIG9mIGxvc3MgYnVyc3RzLiBBIGxvc3MgYnVyc3Qgb2Yg MTAgY29uc2VjdXRpdmUgVFdBTVAtdGVzdCBwYWNrZXRzIGNhbiBiZSBkZWVtZWQgbW9yZSBzZXJp b3VzIHRoYW4gMTAgbG9zdCBwYWNrZXRzIHNwcmVhZCBldmVubHkNCiBvdmVyIHRoZSByZXBvcnQg aW50ZXJ2YWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkdJ TSZndDsmZ3Q7IEluZGVlZCwgcGFja2V0IGxvc3MgbW9yZSBvZnRlbiBleHByZXNzZWQgYXMgcGFj a2V0IGxvc3MgcmF0aW8gcmF0aGVyIHRoYW4gYXMgdGhlIGFic29sdXRlIG51bWJlci4gSXQgd291 bGQgYmUgbW9zdCBoZWxwZnVsIHRvIGhlYXIgZnJvbSBuZXR3b3JrIG9wZXJhdG9ycyBpZiB0aGV5 IHNlZSBpbnRyb2R1Y3Rpb24NCiBvZiBQYWNrZXQgTG9zcyBSYXRpbyBpbnRvIHRoZSBUV0FNUCBt b2RlbCBoZWxwZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj4yLiBBZGQgYSBuZXcgdHlwZWRlZjogc3RhdGUtbW9kZS4gSXQgZGVmaW5l cyBhIGNvbW1vbiB0eXBlIGZvciBzdGF0ZWZ1bC9zdGF0ZWxlc3MgcmVmbGVjdG9yLiBUaGlzIHR5 cGUgd2lsbCBiZSB1c2VkIGluIGJvdGggc2VuZGVyIHNlc3Npb24gYW5kIHJlZmxlY3RvciBzZXNz aW9uLjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29uc2lkZXJh dGlvbjoNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB0aGUgcmVm bGVjdG9yIGlzIHN0YXRlZnVsLCB0aGUgVFdBTVAgbGlnaHQgY2FuIG1lYXN1cmUgbW9yZSBpdGVt cywgZS5nLiBvbmUgd2F5IHBhY2tldCBsb3NzLiBTbyBmb3Igc2VuZGVyLCB0aGUgc3RhdHMgY2Fs Y3VsYXRpb24gYW5kIHNob3cgaXMgZGlmZmVyZW50LiBXaGVuIHRoZSByZWZsZWN0b3IgaXMNCiBz dGF0ZWxlc3MsIGl0IGRvZXNu4oCZdCBuZWVkIHRvIGNhbGN1bGF0ZSB0aGUgb25lIHdheSBwYWNr ZXQgbG9zcy4gVGhlIG9uZSB3YXkgcGFja2V0IGxvc3MgaXMgaW52YWxpZCBhbmQgc2hvdWxkbuKA mXQgYmUgcHJlc2VudGVkIHRvIGN1c3RvbWVyLiBXaGVuIHRoZSByZWZsZWN0b3IgaXMgc3RhdGVs ZXNzLCB0aGUgc2VuZGVyIG5lZWRzIHRvIGNhbGN1bGF0ZSB0aGUgb25lIHdheSBwYWNrZXQgbG9z cy4gQW5kIHRoZSBkYXRhIHNob3VsZCBiZSBwcmVzZW50DQogdG8gY3VzdG9tZXIuIFNvIHRoaXMg aXMgdXNlZCBhcyBhIOKAmHdoZW7igJkgY29uZGl0aW9uIGluIHRoZSBtb2RlbOKAmXMgUk8gdHJl ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5HSU0mZ3Q7Jmd0OyBZZXMsIGlmIFNlc3Npb24tU2VuZGVy IGlzIGF3YXJlIG9mIHRoZSBtb2RlIGNvcnJlc3BvbmRpbmcgU2Vzc2lvbi1SZWZsZWN0b3Igb3Bl cmF0ZXMsIHRoZSBzZW5kZXIgbWF5IGF2b2lkIGNhbGN1bGF0aW9uIG9mIHNvbWUgcGVyZm9ybWFu Y2UgbWV0cmljcywgZS5nLiwgb25lLXdheSBwYWNrZXQgbG9zcy4NCiBPbiB0aGUgb3RoZXIgaGFu ZCwgdGhlIG9yY2hlc3RyYXRvciBpcyBhd2FyZSBvZiB0aGUgc3RhdGUtbW9kZSBhbmQgc2hvdWxk IGJlIGNhcGFibGUgdG8gcHJvcGVybHkgdXNlIG1ldHJpY3MgcmVwb3J0ZWQgYnkgdGhlIFNlc3Np b24tU2VuZGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bV0VJJmd0 OyZndDtdIFllcywgdGhlIG9yY2hlc3RyYXRvciBjb3VsZCBrbm93IHRoYXQuIEJ1dCBmcm9tIHRo ZSBtb2RlbCBzaWRlLCB0aGlzIGlzIG5vdCBjb3JyZWN0LiZuYnNwOyBUaGUgbW9kZWwgc2hvdWxk IHJlcHJlc2VudCB0aGUgcmlnaHQNCiBiZWhhdmlvciBhbmQgc2hvdWxkbuKAmXQgZG8gYXNzdW1w dGlvbiBvbiBvcmNoZXN0cmF0b3IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhlIG1vZGVsIHNob3VsZCBkZXNjcmliZSBi b3RoIG9uZS13YXkgbG9zcyBtZXRyaWNzIGFuZCByb3VuZHRyaXAgbG9zcyBtZXRyaWNzLCBhbmQg dGhlIHNlbmRlciBzaG91bGQgYmUgYWJsZSB0byB1c2UgZWl0aGVyIG1vZGUgd2hlbiBjYWxjdWxh dGluZywgcG90ZW50aWFsbHkgYWxzbyBwb3B1bGF0aW5nIHRoZSByb3VuZHRyaXAgZGVsYXkgdmFs dWVzIHdpdGggcHJvcGVyIHQxLXQwICYjNDM7IHQzLXQyDQogdmFsdWVzLCBhcyB3ZWxsIGFzIHJl cG9ydGluZyB0aGUgdDItdDEgdmFsdWVzIHRoYXQgd291bGQgaW5kaWNhdGUgYnVmZmVyIGxvYWQv Q1BVIGxvYWQgaW4gdGhlIFRXQU1QIHJlc3BvbmRlcnMgcHJvY2Vzc2luZyB0aW1lLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj4zLiBBZGQgYSBuZXcgdHlw ZWRlZjogc2VuZC1tb2RlLiBUaGlzIGlzIGEgbmV3IHR5cGUgZm9yIHNlbmRlciBzZXNzaW9uLiBJ dCBtYWtlcyB0aGUgc2VuZGVyIHNlc3Npb24gY2FuIHNlbmQgcGFja2V0IGNvbnRpbnVvdXNseSBh bmQgbW9uaXRvciB0aGUgbmV0d29yayBhbGwgdGhlIHRpbWUuPC9iPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db25zaWRlcmF0aW9uOg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSB1c2VyIGNhc2UgaXMgdGhhdDogdGhlIHVzZXIgcnVu cyBUV0FNUCBsaWdodCBzZXNzaW9ucyB0byB3YXRjaCBsaW5rcyBxdWFsaXR5IGNvbnRpbnVvdXNs eS4gVGhlIHNlc3Npb24gbnVtYmVyIGNvdWxkIGJlIHZlcnkgYmlnLiBUaGVzZSBUV0FNUCBzZXNz aW9ucyBhcmUgbWFuYWdlZCBieSBTTEEgZnJhbWV3b3JrDQogb3Igc2ltaWxhci4gU0xBIHJldHJp ZXZlcyB0aGUgc3RhdHMgZnJvbSBUV0FNUCBwZXJpb2RpY2FsbHksIGUuZy4gMTVtaW5zLiBJbiBv dGhlciB3b3JkcywgYWxsIHRoZSBwZXJmb3JtYW5jZSBtZXRyaWNzIGFyZSBjYWxjdWxhdGVkIGJh c2VkIG9uIHRoZSBwYWNrZXRzIHNlbnQvcmVjZWl2ZWQgd2l0aGluIDE1bWlucy4gVGhpcyBtYWtl cyB0aGUgY2FsY3VsYXRpb24gYmVjb21lIHBvc3NpYmxlLiBXaXRoIHRoZSBwZXJpb2RpY2FsIHN0 YXRzIGRhdGEsDQogdGhlIE5ldHdvcmsgTWFuYWdlbWVudCBzb2Z0d2FyZSBjYW4gZG8gZnVydGhl ciBhY3Rpb25zIGlmIHNvbWUgYWJub3JtYWwgc3RhdHMgb2JzZXJ2ZWQuJm5ic3A7IFRoaXMgaXMg YSBtb3JlIGdlbmVyYWwgdXNlciBjYXNlIGluIGN1c3RvbWVyIHNpdGUuIFdoaWxlIHRoZSBub24t Y29udGludW91cyBUV0FNUCBzZW5kZXIgc2Vzc2lvbiBpcyBnZW5lcmFsbHkgdXNlZCBmb3IgZGVi dWdnaW5nIHB1cnBvc2Ugb24gYSBsaW5rLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5HSU0m Z3Q7Jmd0OyBJIHRoaW5rIHRoYXQgc3VwcG9ydCBvZiBjb250aW51b3VzIG1lYXN1cmVtZW50IGlz IGluIExNQVAgZG9tYWluLCBub3QgZm9yIFRXQU1QIFRlc3QgZGF0YSBtb2RlbC4gVG8gY29uZHVj dCBjb250aW51b3VzIG1lYXN1cmVtZW50IGhlIExNQVAgQ29udHJvbGxlciwgaW4gbXkgb3Bpbmlv biwgcHJvZ3JhbXMNCiB0aGUgTWVhc3VyZW1lbnQgQWdlbnQgdG8gcGVyZm9ybSBUV0FNUCBUZXN0 IHNlc3Npb24gd2l0aCBjZXJ0YWluIHNldCBvZiBwYXJhbWV0ZXJzIGFuZCByZXBlYXQgaXQgd2l0 aG91dCBhbnkgaW50ZXJ2YWwgKGludGVydmFsID0gMCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYW55IG9wZXJhdG9ycyB1c2UgVFdBTVAgaW4g Y29udGlub3VzIG1vZGUsIG5vdCBvbmx5IHdpdGggQWNjZWRpYW4gdGVzdCBwb2ludHMgYW5kIHJl cG9ydCBhdCBmaXhlZCBpbnRlcnZhbHMsIHR5cGljYWxseSByYW5naW5nIGZyb20gNXMgdG8gNSBv ciAxNSBtaW51dGVzLCB3aXRoIDEtbWludXRlIGJlaW5nIHRoZSBtb3N0IHBvcHVsYXIgZ3JhbnVs YXJpdHkgY3VycmVudGx5LiBUaGUgYWR2YW50YWdlIGlzIHRoYXQNCiB0aGUgcmVzdWx0IGNhbGN1 bGF0aW9uIGNhbiBiZSBoYW5kbGVkIHNlcGFyYXRlbHkgZnJvbSB0aGUgVFdBTVAtdGVzdCBzZW5k aW5nL3JlY2lldmluZywgc28gdGhhdCB0aGVyZSBpcyBubyBwYXJhbGxlbGlzbSByZXF1aXJlZCB0 byBtb25pdG9yIDI0LzcuIElmIGEgc3RhcnQtc3RvcC1iYXNlZCBtZXRob2RvbG9neSBpcyB1c2Vk LCB0aGUgc2VuZGVyIG5lZWRzIHRvIHN0YXJ0IHVwIHRoZSBuZXcgdGVzdCBzZXNzaW9uIGV2ZW4g YmVmb3JlIHRoZSBwcmV2aW91cw0KIG9uZSBoYXMgZW5kZWQsIHNpbmNlIHRoZSBwcmV2aW91cyBz ZXNzaW9uIG5lZWRzIHRvIHdhaXQgWCBzZWNvbmRzIChvciBhdCBsZWFzdCBZIDEwMHMgb2YgbWls bGlzZWNvbmRzKSBiZWZvcmUgaXQgc3RvcHMgd2FpdGluZyBmb3IgcGFja2V0cyB0byBjb21lIGJh Y2suIEFuZCB0aGlzIG5ldyBzZXNzaW9uIG5lZWRzIHRvIGhhdmUgYSBkaWZmZXJlbnQgc2lnbmF0 dXJlIGluIG9yZGVyIGZvciB0aGUgc2VuZGVyIHRvIGRpc2Nlcm4gd2hpY2ggcGFja2V0cw0KIGJl bG9uZyB0byB0aGUgcHJldmlvdXMgaW50ZXJ2YWwgYW5kIHdoaWNoIGJlbG9uZyB0byB0aGUgY3Vy cmVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gYSBjb250aW5vdXMgdGVzdC1tb2RlbCwgdGhlIHNlbmRlciBjYW4ganVzdCBzaW1wbHkg cmVjb3JkIHRoZSBzZXF1ZW5jZSBudW1iZXIgb2YgdGhlIGxhc3QgcGFja2V0IHRyYW5zbWl0dGVk IGluIHRoZSBpbnRlcnZhbCB0byBiZSByZXBvcnRlZCwgd2FpdCBmb3IgaXQgdG8gY29tZSBiYWNr LCBvciBhIE1BWFRJTUUsIHRoZW4gcmVwb3J0IHRoYXQgcmVzdWx0LCB3aGlsZSBjb250aW51aW5n IHRvIHRyYW5zbWl0DQogZm9yIHRoZSBuZXh0IGludGVydmFsLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgJnF1b3Q7aW50ZXJ2YWw9 PTAmcXVvdDsgcGFyYW1ldGVyIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgZm9yIGNvbnRpbm91cyB0 eXBlIHRlc3RzLCB0aGVuIHdoYXQgcGFyYW1ldGVyIHNob3VsZCBpbmRpY2F0ZSB0byB0aGUgc2Vu ZGVyIGF0IHdoYXQgaW50ZXJ2YWxzIHRvIHByb2R1Y2UgcmVzdWx0cz8gJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjQuIEFkZCBhIG5ldyBncm91 cDogcGFja2V0LWxvc3Mtc3RhdGlzdGljcy4gSXQgZ3JvdXBpbmcgdHdvIHBhY2tldCBsb3NzIHN0 YXRpc3RpY3M6IGxvc3MtY291bnQgYW5kIGxvc3MtcmF0aW8uIFRoaXMgZ3JvdXAgd2lsbCBiZSB1 c2VkIGluIFJPIHN0YXRzIHRyZWUuPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkdJTSZndDsmZ3Q7 IEknZCBsaWtlIHRvIGNvbnRpbnVlIGRpc2N1c3Npb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1dFSSZndDsmZ3Q7XSBPSy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjUuIE1vdmUgbGVhZiBkc2NwIG91dCBmcm9tIGdyb3VwaW5nIHNlc3Npb24tbGlnaHQt cGFyYW1ldGVycy4gVGhlIGxlYWYgZHNjcCBpcyBvbmx5IHZhbGlkIHdoZW4gdGhlIGRzY3AtaGFu ZGxpbmctbW9kZSBpcyB1c2UtY29uZmlndXJlZC12YWx1ZS4gQSB3aGVuIGNvbmRpdGlvbiBzaGFs bCBiZSBhZGRlZA0KIHRvIGl0LiBTbyBpdCBjYW7igJl0IGJlIGluIHRoaXMgZ3JvdXAuPC9iPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkdJTSZndDsmZ3Q7IEknbSBjb25jZXJuZWQgdGhhdCB0aGVuIHRo ZSBtb2RlbCB3aWxsIG5vdCBiZSBhYmxlIHRvIHN1cHBvcnQgY29uY3VycmVudCBUV0FNUCBUZXN0 IHNlc3Npb25zIGJldHdlZW4gdGhlIHNhbWUgcGFpciBvZiBUZXN0IFBvaW50cyAoSVAgYWRkcmVz cyYjNDM7cG9ydCBudW1iZXIpIGF0IGRpZmZlcmVudCBDb1MNCiBtYXJraW5ncy4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1dFSSZndDsmZ3Q7XSBBY3R1YWxs eSwgSSBoYXZlIGNvbmNlcm4gb24gdXNpbmcgZml2ZSB0dXBsZShJUCBhZGRyZXNzJiM0Mztwb3J0 IG51bWJlciYjNDM7ZHNjcCkgdG8gaWRlbnRpZnkgYSBUV0FNUCB0ZXN0IHNlc3Npb24uIFRoZSBE U0NQIGlzIG5vdA0KIGEgY29uc3RhbnQgdmFsdWUgaW4gcGFja2V0LiBJdCBjb3VsZCBiZSBtb2Rp ZmllZCBieSB0aGUgcm91dGVycyBpbiB0aGUgcGF0aC4gRm9yIGV4YW1wbGUsIHRoZSBzZW5kZXIg aGFzIHR3byBzZXNzaW9uczogc2Vzc2lvbiBB4oCZcyBmaXZlIHR1cGxlIGlzOiBTaXA9MS4xLjEu MSwgRGlwPTIuMi4yLjIsIFNwb3J0PTUwMDAwLCBEcG9ydD01MDAwMSwgRFNDUD1jczIuIFNlc3Np b24gQuKAmXMgZml2ZSB0dXBsZSBpczogU2lwPTEuMS4xLjEsIERpcD0yLjIuMi4yLA0KIFNwb3J0 PTUwMDAwLCBEcG9ydD01MDAwMSwgRFNDUD1jczMuIFRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2Vl biBzZXNzaW9uIEEgYW5kIHNlc3Npb24gQiBpcyBEU0NQLiBJZiB0aGUgdGVzdCBwYWNrZXTigJlz IERTQ1Agb2Ygc2Vzc2lvbiBCIGlzIG1vZGlmaWVkIHRvIGNzMiBieSBhIHJvdXRlciBpbiB0aGUg cGF0aC4gVGhlIGZpdmUgdHVwbGVzIGFyZSBleGFjdGx5IHRoZSBzYW1lIGZvciByZWZsZWN0b3Iu IEl0IGNhbuKAmXQgZGlmZmVyZW50aWF0ZSB3aGljaA0KIHBhY2tldCBpcyBmcm9tIHNlc3Npb24g QSwgd2hpY2ggcGFja2V0IGlzIGZyb20gc2Vzc2lvbiBCLiBJdCBjb3VsZCBtZXNzIHRoZSByZWZs ZWN0b3LigJlzIHNlc3Npb24gc2VxdWVuY2UgbnVtYmVyLiBBbmQgYWxzbywgdGhlIHNlbmRlciB3 aWxsIGJlIG1lc3NlZCBiZWNhdXNlIHRoZSByZWNlaXZlZCByZXBseSBwYWNrZXTigJlzIGZpdmUg dHVwbGUgYXJlIGV4YWN0bHkgdGhlIHNhbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5TbyBJIHRoaW5rIGl04oCZcyBtb3JlIHJlYXNvbmFibGUgdG8gdXNl IGZvdXIgdHVwbGUgdG8gaWRlbnRpZnkgYSBzZXNzaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhpcyB3b3VsZCBiZSBh cHByZWNpYXRlZCBieSB1c2Vycy4gQ2hhbmdlcyBpbiBEU0NQIGlzIGEgcmVhc29uYWJseSBjb21t b24gbmV0d29yayBlcnJvciB0aGF0IHVzZXJzIGNhbiBkZXRlY3Qgd2l0aCBjb250aW5vdXMgVFdB TVAgbW9uaXRvcmluZywgdGh1cyBpdCBpcyBnb29kIHRvIG5vdCBpbmNsdWRlIHRoZSBEU0NQIHZh bHVlIGFzIHBhcnQgb2YgdGhlICZxdW90O3Nlc3Npb24gaWRlbnRpZmlpZXImcXVvdDsgYnV0DQog aW5zdGVhZCB1c2UgNC10dXBsZSB3aXRoIFVEUCBzb3VyY2UgcG9ydCB0byBpZGVudGlmeSBzZXZl cmFsIHBhcmFsbGVsIGZsb3dzIGJldHdlZW4gdGhlIHNhbWUgc2VuZGVyIGFuZCByZXNwb25kZXIu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjYu IEFkZCBsZWFmICdzZXNzaW9uLXBhY2tldC1zZW5kLW1vZGUnIHRvIC90d2FtcC1saWdodC90d2Ft cC1saWdodC1zZXNzaW9uLXNlbmRlci90ZXN0LXNlc3Npb24qLiBUaGlzIGxlYWYgc3BlY2lmaWVz IHRoZSBzZW5kZXIgc2Vzc2lvbidzIHBhY2tldCBzZW5kIG1vZGU6IGNvbnRpbnVvdXMgb3Igbm9u LWNvbnRpbnVvdXMuPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkdJTSZndDsmZ3Q7IEFzIGRpc2N1 c3NlZCBpbiAjMywgSSB0aGluayB0aGF0IGl0IGlzIGFscmVhZHkgcGFydCBvZiBMTUFQIFlBTkcg bW9kZWwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjcuIEFkZCBsZWFmICdyZWZsZWN0b3ItbGlnaHQtbW9kZS1zdGF0ZScgdG8g L3R3YW1wLWxpZ2h0L3R3YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVyL3Rlc3Qtc2Vzc2lvbiouIFRo aXMgbGVhZiBpbmRpY2F0ZXMgdGhlIHRoZSByZWZsZWN0b3IncyBtb2RlOiBzdGF0ZWZ1bCBvciBz dGF0ZWxlc3MuIElmIHRoZQ0KIHJlZmxlY3RvcidzIG1vZGUgaXMgc3RhdGVmdWwuIFR3byBvbmUg d2F5IHBhY2tldCBsb3NzIHN0YXRpc3RpY3MgY2FuIGJlIGdvdDogb25lLXdheS1wYWNrZXQtbG9z cy1mYXItZW5kLCBvbmUtd2F5LXBhY2tldC1sb3NzLW5lYXItZW5kLjwvYj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29uc2lkZXJhdGlvbjoNCjxzcGFuIHN0eWxlPSJj b2xvcjojNDQ3MkM0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9ubHkgdmFsaWQgZGF0YSBzaG91bGQgYmUgcHJlc2VudGVkIHRvIHVzZXIuIE90 aGVyd2lzZSBpdCBjb3VsZCBtaXNsZWFkaW5nIHVzZXIgaW4gc29tZSBjYXNlcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5HSU0mZ3Q7Jmd0OyBBIGluIHJlc3BvbnNlIHRvICMyLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj44LiBNb2Rp ZnkgbGVhZiAvdHdhbXAtbGlnaHQvdHdhbXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNz aW9uKi9udW1iZXItb2YtcGFja2V0cy4gQWRkIGEgJ3doZW4nIGNvbmRpdGlvbiB0byB0aGlzIGxl YWYuIFdoZW4gc2VuZC1tb2RlIGlzICdjb250aW51b3VzJywgdGhlIGxlYWYgbnVtYmVyLW9mLXBh Y2tldHMNCiBpcyBtZWFuaW5nbGVzcy4gU28gYWRkIGEgJ3doZW4nIGNvbmRpdGlvbiB0byBsaW1p dCBpdC4mbmJzcDsgQmVzaWRlcywgYWRkZWQgYSBkZWZhdWx0IHZhbHVlIOKAmDEw4oCZIHRvIGl0 LiBXaGVuIHRoZSBzZW5kLW1vZGUgaXMgJ25vbi1jb250aW51b3VzJywgdGhlIHNlc3Npb24gY2Fu J3Qgd29yayB3aXRoIGFuIGVtcHR5IG51bWJlci1vZi1wYWNrZXRzLjwvYj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5HSU0mZ3Q7Jmd0OyBBcyBJJ3ZlIG5vdGVkIGluICMzLiBXaWxsIGFkZCBkZWZhdWx0 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj45LiBBZGQgbGVhZiB0aW1lIG91dCB0byAvdHdhbXAtbGlnaHQvdHdhbXAtbGlnaHQt c2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNzaW9uKi4gQSB0aW1lb3V0IG1lY2hhbmlzbSBpcyBuZWVk ZWQgd2hlbiB0aGUgc2VuZGVyIHNlc3Npb24gY2FuJ3QgZ2V0IGFsbCB0aGUgcmVwbHkgcGFja2V0 cyBmb3IgYSBsb25nDQogdGltZS48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R0lNJmd0OyZndDsg VGhhbmsgeW91LCB3aWxsIGFkZCBpbiB0aGUgbmV4dCB1cGRhdGUuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjEwLiBNb2RpZnkg bGVhZiAvdHdhbXAtbGlnaHQvdHdhbXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNzaW9u Ki9pbnRlcnZhbC4gQ2hhbmdlIHRoZSB1bml0cyBmcm9tIOKAmG1pY3Jvc2Vjb25kc+KAmSB0byDi gJhtaWxsaXNlY29uZHPigJkuIEFkZCBhIGRlZmF1bHQgdmFsdWUgMTAwMC4NCjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29uc2lkZXJhdGlvbjo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEpLiBUaGUg YWltIG9mIFRXQU1QIGlzIHRvIG1lYXN1cmUgbmV0d29yayBxdWFsaXR5LCBidXQgbm90IGZhc3Qg ZmFpbHVyZSBkZXRlY3Rpb24uIFNvIGEgbWlsbGlzZWNvbmQgcGFja2V0IGludGVydmFsIGlzIGVu b3VnaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDIpLiBJbnRlcnZhbCBpcyBhIG5lY2Vzc2FyeSBwYXJhbWV0ZXIgZm9yIGEgc2Vzc2lv bi4gQSBzZW5kZXIgc2Vzc2lvbiBjYW4ndCB3b3JrIHdpdGggYW4gZW1wdHkgcGFja2V0IHNlbmQg aW50ZXJ2YWwuIFNvIGFkZGVkIGEgZGVmYXVsdCB2YWx1ZSB0byBpdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5HSU0mZ3Q7Jmd0OyBUaGFuayB5b3UuIFdlJ3ZlIG1hZGUgdW5pdHMgb2YgaW50ZXJ2YWwg bWljcm9zZWNvbmRzIGluIHRoZSBsYXN0IHVwZGF0ZSBhbHJlYWR5LiBJIHRoaW5rIHRoYXQgY2hh bmdpbmcgdG8gbWlsbGlzZWNvbmRzIG1heSBiZSB0b28gcmVzdHJpY3RpdmUsIGxpbWl0IHVzZSBj YXNlcyBmb3IgVFdBTVAgVGVzdC4NCiBXaWxsIGFkZCBkZWZhdWx0IHZhbHVlIHdpdGggdGhlIG5l eHQgdXBkYXRlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bV0VJJmd0 OyZndDtdIFNvcnJ5LCBJIGRvIG5vdCBzZWUgdGhlIHJlYXNvbi4gQXJlIHRoZXJlIGFueSB1c2Vy IGNhc2VzIHRvIHVzZSBtaWNyb3NlY29uZHM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj4xMS4gQWRkIGxlYWYgJ2RzY3AnIHRv IC90d2FtcC1saWdodC90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci90ZXN0LXNlc3Npb24qLiBU aGlzIGlzIHRoZSBsZWFmIG1vdmVkIG91dCBmcm9tIGdyb3VwaW5nIHNlc3Npb24tbGlnaHQtcGFy YW1ldGVycy48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R0lNJmd0OyZndDsgQXMgbm90ZWQgaW4g cmVzcG9uc2UgIzUsIHRoZSBjaGFuZ2UgbWF5IGxpbWl0IGFiaWxpdHkgdG8gcnVuIGNvbmN1cnJl bnQgVFdBTVAgVGVzdCBzZXNzaW9ucyBwZXIgQ29TLiBJIGNvbnNpZGVyIHRoYXQgdG8gYmUgdmFs dWFibGUgbW9kZSBidXQgd291bGQgbGlrZSB0byBoZWFyIGZyb20gbmV0d29yaw0KIG9wZXJhdG9y cyBpZiB0aGF0IGlzIGluZGVlZCB1c2VmdWwgaW5mb3JtYXRpb24uJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWUgbXkgY29tbWVudCBh Ym92ZS4gSSBhcmd1ZSB0aGF0IGl0IGlzIHVzZWZ1bCB0byBrZWVwIHRyYWNrIG9mIGNoYW5naW5n IERTQ1AgdmFsdWVzLCBhbmQgdHJlYXRpbmcgRFNDUCBhcyBhIG1ldHJpYyBvZiB0aGUgVFdBTVAg U2Vzc2lvbiBqdXN0IGxpa2UgbG9zcyBhbmQgZGVsYXkmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MTIuIE1vdmUgbGVhdmVzICdyZWYtd2FpdCcs ICdyZWZsZWN0b3ItbGlnaHQtbW9kZS1zdGF0ZScgYW5kICdkc2NwLWhhbmRsaW5nLW1vZGUnIGZy b20gL3R3YW1wLWxpZ2h0L3R3YW1wLWxpZ2h0LXNlc3Npb24tcmVmbGVjdG9yIHRvIC90d2FtcC1s aWdodC90d2FtcC1saWdodC1zZXNzaW9uLXJlZmxlY3Rvci90ZXN0LXNlc3Npb24qLg0KIFRoZXNl IHRocmVlIGF0dHJpYnV0ZXMgc2hvdWxkIGJlIHNlc3Npb24gc3BlY2lmaWMuIERpZmZlcmVudCBz ZXNzaW9uIGNvdWxkIGhhdmUgZGlmZmVyZW50IHZhbHVlcy4gVGhleSBhcmUgbm90IGNvbW1vbiBh dHRyaWJ1dGVzLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5HSU0mZ3Q7Jmd0OyBBZ3JlZSwgd2ls bCBtYWtlIGl0IGluIHRoZSBuZXh0IHVwZGF0ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MTMuIEFkZCBsZWFmICdkc2NwJyB0 byAvdHdhbXAtbGlnaHQvdHdhbXAtbGlnaHQtc2Vzc2lvbi1yZWZsZWN0b3IvdGVzdC1zZXNzaW9u Ki4gVGhpcyBpcyB0aGUgbGVhZiBtb3ZlZCBvdXQgZnJvbSBncm91cGluZyBzZXNzaW9uLWxpZ2h0 LXBhcmFtZXRlcnMuIEJlc2lkZXMgdGhlIG1vdmVtZW50LCBhZGRlZA0KIGEgJ3doZW4nIGNvbmRp dGlvbiB0byB0aGUgbGVhZiAnZHNjcCcuIFRoaXMgbGVhZiBpcyBvbmx5IHZhbGlkIHdoZW4gdGhl IGRzY3AtaGFuZGxpbmctbW9kZSBpcyAndXNlLWNvbmZpZ3VyZWQtdmFsdWUnLjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5HSU0mZ3Q7Jmd0OyBBcyByZXNwb25zZSB0byAjNS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MTQuIE1v ZGlmeSBsZWFmIC90d2FtcC1saWdodC1zdGF0ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1z dGF0ZS90ZXN0LXNlc3Npb24tc3RhdGUqL2N1cnJlbnQtc3RhdHMvbnVtYmVyLW9mLXBhY2tldHMu IEFkZCBhICd3aGVuJyBjb25kaXRpb24gdG8gdGhpcyBsZWFmLiBXaGVuIHNlbmQtbW9kZSBpcw0K ICdjb250aW51b3VzJywgdGhlIGxlYWYgbnVtYmVyLW9mLXBhY2tldHMgaXMgbWVhbmluZ2xlc3Mu PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkdJTSZndDsmZ3Q7IFNpbWlsYXIgdG8gIzMuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjE1LiBNb2RpZnkgbGVhZiAvdHdhbXAtbGlnaHQtc3RhdGUvdHdhbXAtbGlnaHQtc2Vzc2lvbi1z ZW5kZXItc3RhdGUvdGVzdC1zZXNzaW9uLXN0YXRlKi9jdXJyZW50LXN0YXRzL2ludGVydmFsLiBD aGFuZ2UgdGhlIHVuaXRzIGZyb20gbWljcm9zZWNvbmRzIHRvIG1pbGxpc2Vjb25kcy48L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+R0lNJmd0OyZndDsgSSB0aGluayB0aGF0IG1pY3Jvc2Vjb25kcyBp cyByZWFzb25hYmxlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj4xNi4gQWRkIGxlYXZlcyAndHdvLXdheS1wYWNrZXQtbG9zcycs ICdvbmUtd2F5LXBhY2tldC1sb3NzLWZhci1lbmQnIGFuZCAnb25lLXdheS1wYWNrZXQtbG9zcy1u ZWFyLWVuZCcgdG8gL3R3YW1wLWxpZ2h0LXN0YXRlL3R3YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVy LXN0YXRlL3Rlc3Qtc2Vzc2lvbi1zdGF0ZSovY3VycmVudC1zdGF0cy8uDQogVGhlc2UgYXJlIHRo ZSBuZXcgc3RhdGlzdGljcyBmb3Igc3RhdGVmdWwgcmVmbGVjdG9yLjwvYj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5HSU0mZ3Q7Jmd0OyBUaGFuayB5b3UsIHdpbGwgYmUgY29taW5nIGluIHRoZSBuZXh0 IHVwZGF0ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+MTcuIFJlbW92ZSBsZWFmIGxvc3MtcGFja2V0IGluIC90d2FtcC1saWdo dC1zdGF0ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1zdGF0ZS90ZXN0LXNlc3Npb24tc3Rh dGUqL2N1cnJlbnQtc3RhdHMuIFRoZSBsb3NzIHBhY2tldGVkIGlzIHJlcGxhY2VkIHdpdGggJ3R3 by13YXktcGFja2V0LWxvc3MnDQogc3RhdGVkIGFib3ZlLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5HSU0mZ3Q7Jmd0OyBBZ3JlZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MTguIE1vZGlmeSBsZWFmIHRvIC90d2FtcC1saWdo dC1zdGF0ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1zdGF0ZS90ZXN0LXNlc3Npb24tc3Rh dGUqL2hpc3Rvcnktc3RhdHMqL2ludGVydmFsLiBDaGFuZ2UgdGhlIHVuaXRzIGZyb20gbWljcm9z ZWNvbmRzIHRvIG1pbGxpc2Vjb25kcy48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R0lNJmd0OyZn dDsgSSB0aGluayB0aGF0IHdpbGwgbGltaXQgYXBwbGljYWJpbGl0eSBvZiBUV0FNUCBUZXN0LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj4xOS4gQWRkIGxlYXZlcyAndHdvLXdheS1wYWNrZXQtbG9zcycsICdvbmUtd2F5LXBhY2tl dC1sb3NzLWZhci1lbmQnIGFuZCAnb25lLXdheS1wYWNrZXQtbG9zcy1uZWFyLWVuZCcgdG8gL3R3 YW1wLWxpZ2h0LXN0YXRlL3R3YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVyLXN0YXRlL3Rlc3Qtc2Vz c2lvbi1zdGF0ZSovaGlzdG9yeS1zdGF0cyovLg0KIFRoZXNlIGFyZSB0aGUgbmV3IHN0YXRpc3Rp Y3MgZm9yIHN0YXRlZnVsIHJlZmxlY3Rvci48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R0lNJmd0 OyZndDsgQWdyZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPldlaSBMdW88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQppcHBtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzppcHBtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw cG08L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9y ZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIg c3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMTgzIiBoZWlnaHQ9IjQ1IiBz dHlsZT0id2lkdGg6MS45MDYyaW47aGVpZ2h0Oi40Njg3aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNy Yz0iaHR0cHM6Ly9saDUuZ29vZ2xldXNlcmNvbnRlbnQuY29tLzhDRmF6REQ3d2U1VmZmSF9iMWdW U1pXVnRqLWRTMnVIZGFabzhyalBwaFpHbDNuTjZ4NmwyanRRcWJ6bzFiRU9kM3dhYllCdGdQXzdm eldZdlJaNHByYlNxb1o3dmcxVmx5OEEwbG5LQ2Uzc3VESFRQV19tSHlfcEoweU5DRWdfRnIzVzJX Y1kiIGFsdD0iQWNjZWRpYW4uY29tIj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5n OjBpbiAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzE5MzU2MCI+SGVucmlrIE55ZGVsbDwvc3Bhbj48L2I+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzlDOTk5OSI+U3IgTWFuYWdlciBHbG9iYWwgU3RyYXRlZ3kgJmFtcDsgU29sdXRpb25zPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0i Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjUw LjBwdCI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjUwLjBwdCI+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOUM5 OTk5Ij5DZWxsPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5Qzk5OTki PkVtYWlsPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5Qzk5OTkiPlNr eXBlPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0 eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjBp biAwaW4gMGluIDBpbjtoZWlnaHQ6NTAuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5Qzk5OTkiPjxhIGhy ZWY9InRlbDomIzQzOzQ2JTIwNzAlMjA5ODQlMjA1OSUyMDkyIiB0YXJnZXQ9Il9ibGFuayI+JiM0 Mzs0NiA3MDk4NDU5OTI8L2E+PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxMTU1Q0MiPmhueWRlbGw8YSBocmVmPSJtYWlsdG86bWtvd2Fsa2VAYWNjZWRpYW4uY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj5AYWNjZWRp YW4uY29tPC9zcGFuPjwvYT48L3NwYW4+PC91PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48dT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzExNTVDQyI+PGEgaHJlZj0iaHR0cDovL2xpbmtlZGluLmNvbS9pbi9tYWVrb3dhbGsiIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPmg8L3NwYW4+PC9h Pm55ZGVsbDwvc3Bhbj48L3U+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGEgaHJlZj0iaHR0cDovL2FjY2VkaWFu LmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMTE1NUNDO3RleHQtZGVjb3JhdGlvbjpub25lIj48 aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjMxIiBoZWlnaHQ9IjMxIiBzdHlsZT0id2lkdGg6LjMyMjlp bjtoZWlnaHQ6LjMyMjlpbiIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJodHRwczovL2xoNC5nb29n bGV1c2VyY29udGVudC5jb20vcllNWDlCcTVNU3dwb3lFQ095V2VjbzJ6TlNnbXQzM0wyZUxIR1BX elVVbnZWMmxjUXRsM3dzVXBTSHRJVW94ckJWaHpDSy1lTmtvX0VGdkxGRHVKX1NYTndIOHVtamVz eTVqMDh5UFl5cDFLUFRtRGV2eUZLRTdndnNiUl8xbl9DV0g1N2dMbSI+PC9zcGFuPjwvYT48YSBo cmVmPSJodHRwOi8vYmxvZy5hY2NlZGlhbi5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxMTU1Q0M7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIw IiB3aWR0aD0iMzEiIGhlaWdodD0iMzEiIHN0eWxlPSJ3aWR0aDouMzIyOWluO2hlaWdodDouMzIy OWluIiBpZD0iX3gwMDAwX2kxMDI3IiBzcmM9Imh0dHBzOi8vbGg2Lmdvb2dsZXVzZXJjb250ZW50 LmNvbS9SckNuQmpITW5oV2lWa0RlQUNwbDBjLTU2NXFMMHlHekg2LUZ4VWxXWTJld3NhSXh1Y1Vm djhYRElmWk1zY1RNakx6NXJ1UzFuOG5ZQ3JZbzV2ajBXNXN4UGtfMU1vdkJiVWRueGtpNUtWOE82 M25mNk5RNUtvV3dNVlpFWW80S2FKTXh6bHFnIj48L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0Ij48YSBocmVmPSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS9hY2NlZGlhbi1u ZXR3b3JrcyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMTE1NUNDO3Rl eHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjMxIiBoZWlnaHQ9IjMx IiBzdHlsZT0id2lkdGg6LjMyMjlpbjtoZWlnaHQ6LjMyMjlpbiIgaWQ9Il94MDAwMF9pMTAyOCIg c3JjPSJodHRwczovL2xoNC5nb29nbGV1c2VyY29udGVudC5jb20vQTljUHkwVEVCSUlfRnE5S3pD cVFsYUFOMzZPTWg4cGktc0Ria1ZlYUxVdFlibElWMHJsQU5WeHpjR3hCeDhEMG9BanF2YkJZYmw3 RDNVaEZubGs4T2xDbHYwLWRpaEkyd1FpLWZzeFBCUEw3cmJkam52dXl1RE53anpWa0V6cTdrRmtQ ZVNaUyI+PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCiAm bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGEgaHJlZj0iaHR0cHM6 Ly90d2l0dGVyLmNvbS9BY2NlZGlhbiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMTE1NUNDO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9 IjMxIiBoZWlnaHQ9IjMxIiBzdHlsZT0id2lkdGg6LjMyMjlpbjtoZWlnaHQ6LjMyMjlpbiIgaWQ9 Il94MDAwMF9pMTAyOSIgc3JjPSJodHRwczovL2xoNC5nb29nbGV1c2VyY29udGVudC5jb20vTUQx bGFsN0lvMzBhN2xLOFdVbFlHMnk2ZnNuZENta2tzaUoxdldiNFFTR2Z0VER4VHN1TERJR1JJa25r STdmZ3BGczZHMFBhUHZ4OW9sNmtCQ2hnRlNneFFCT2dYbHdGRHAzY3F4b2MzRVhPN3ZWQnFlWkNs NjBEVXo2by1fSDRqZUFqbU41biI+PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4NCiAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL2FjY2VkaWFuIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxMTU1Q0M7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxp bWcgYm9yZGVyPSIwIiB3aWR0aD0iMzEiIGhlaWdodD0iMzEiIHN0eWxlPSJ3aWR0aDouMzIyOWlu O2hlaWdodDouMzIyOWluIiBpZD0iX3gwMDAwX2kxMDMwIiBzcmM9Imh0dHBzOi8vbGg2Lmdvb2ds ZXVzZXJjb250ZW50LmNvbS9qOUo2RnhHb2UtVVFtRVUtMlRZSHRWMmJId241YldCUVZKNEU5WHh4 OGUteDNBby14a25aSmJYUjFkUGZlVkF0N1dJemJ0bDI3eVhuM2JYbGF1Ri1jSkdjT1QwT0xvdFUt WDBtTXA3OXBWdjhDWlptX0R1eUt6UnZFV3ZhaGllMkxiZDluMFlKIj48L3NwYW4+PC9hPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KICZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0Ij48YSBocmVmPSJodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIv YWNjZWRpYW4iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzExNTVDQzt0 ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIzMSIgaGVpZ2h0PSIz MSIgc3R5bGU9IndpZHRoOi4zMjI5aW47aGVpZ2h0Oi4zMjI5aW4iIGlkPSJfeDAwMDBfaTEwMzEi IHNyYz0iaHR0cHM6Ly9saDUuZ29vZ2xldXNlcmNvbnRlbnQuY29tL0lKbUdXWG1tc0MwemtRWk4x dFM3QVVOUTBRdWRoZHdmNjB0NndMZ19xdkNsNGQ1bVNqelNBb3VUY0NFbDdsUmpORVNpZUc2WmlH aGdRbkZYSHBkdnpUWU5OVFVPcWZVV0QtNktiR3dHeG0yak0wS3FRb01LTzZ2a2NRNWlLUTJjcEo3 OXk4NEciPjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjQ3IiBoZWlnaHQ9 IjIwOCIgc3R5bGU9IndpZHRoOjIuNTcyOWluO2hlaWdodDoyLjE2NjZpbiIgaWQ9Il94MDAwMF9p MTAzMiIgc3JjPSJodHRwczovL2xoNC5nb29nbGV1c2VyY29udGVudC5jb20vU0Y2cHRjVHVqTTI0 Zy03VEwzY0w1Q01GSHF3Z0ZpMmtTRm5abDZPUzZIYV9lVzZmOHpQMjdpeUNUTDdvNWI1dmxiNXA0 MzN3R3JEa1prYkJGYVhBRmp4bE1nbmNPbGE5RVQ3di03NzFFdnY0czU4QjlENlBHakFVRE85ZFpa OGxhS0kwODFVciI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdCI+QXZpcyBkZSBjb25maWRlbnRpYWxpdMOpPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJmb250LXNpemU6Ny41cHQiPkxlcyBp bmZvcm1hdGlvbnMgY29udGVudWVzIGRhbnMgbGUgcHLDqXNlbnQgbWVzc2FnZSBldCBkYW5zIHRv dXRlIHBpw6hjZSBxdWkgbHVpIGVzdCBqb2ludGUgc29udCBjb25maWRlbnRpZWxsZXMgZXQgcGV1 dmVudCDDqnRyZSBwcm90w6lnw6llcyBwYXIgbGUgc2VjcmV0IHByb2Zlc3Npb25uZWwuIENlcyBp bmZvcm1hdGlvbnMgc29udCDDoCBs4oCZdXNhZ2UgZXhjbHVzaWYgZGUgc29uDQogb3UgZGUgc2Vz IGRlc3RpbmF0YWlyZXMuIFNpIHZvdXMgcmVjZXZleiBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IHPigJlpbCB2b3VzIHBsYWl0IGNvbW11bmlxdWVyIGltbcOpZGlhdGVtZW50IGF2ZWMg bOKAmWV4cMOpZGl0ZXVyIGV0IGVuIGTDqXRydWlyZSB0b3V0IGV4ZW1wbGFpcmUuIERlIHBsdXMs IGlsIHZvdXMgZXN0IHN0cmljdGVtZW50IGludGVyZGl0IGRlIGxlIGRpdnVsZ3VlciwgZGUgbGUg ZGlzdHJpYnVlciBvdSBkZSBsZSByZXByb2R1aXJlDQogc2FucyBs4oCZYXV0b3Jpc2F0aW9uIGRl IGzigJlleHDDqWRpdGV1ci4gTWVyY2kuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRlItQ0EiIHN0eWxlPSJmb250LXNpemU6Ny41cHQiPkNvbmZpZGVudGlhbGl0eSBub3Rp Y2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 Ij5UaGlzIGUtbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudCBoZXJldG8gY29udGFpbiBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgYW5kIHdoaWNo IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiBpdHMgYWRkcmVzc2VlKHMpLiBJ ZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gc2VuZGVy DQogaW1tZWRpYXRlbHkgYW5kIGRlc3Ryb3kgYW55IGNvcHkgdGhlcmVvZi4gRnVydGhlcm1vcmUs IGFueSBkaXNjbG9zdXJlLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIG1lc3NhZ2Ug YW5kL29yIGFueSBhdHRhY2htZW50IGhlcmV0byB3aXRob3V0IHRoZSBjb25zZW50IG9mIHRoZSBz ZW5kZXIgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gVGhhbmsgeW91Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQppcHBtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv cmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNv bGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9 ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMTgzIiBoZWlnaHQ9IjQ1IiBzdHlsZT0i d2lkdGg6MS45MDYyaW47aGVpZ2h0Oi40Njg3aW4iIGlkPSJfeDAwMDBfaTEwMzMiIHNyYz0iaHR0 cHM6Ly9saDUuZ29vZ2xldXNlcmNvbnRlbnQuY29tLzhDRmF6REQ3d2U1VmZmSF9iMWdWU1pXVnRq LWRTMnVIZGFabzhyalBwaFpHbDNuTjZ4NmwyanRRcWJ6bzFiRU9kM3dhYllCdGdQXzdmeldZdlJa NHByYlNxb1o3dmcxVmx5OEEwbG5LQ2Uzc3VESFRQV19tSHlfcEoweU5DRWdfRnIzVzJXY1kiIGFs dD0iQWNjZWRpYW4uY29tIj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxl PSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjBpbiAw aW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzE5MzU2MCI+SGVucmlrIE55ZGVsbDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzlDOTk5 OSI+U3IgTWFuYWdlciBHbG9iYWwgU3RyYXRlZ3kgJmFtcDsgU29sdXRpb25zPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVy LWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjUwLjBwdCI+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiAwaW47aGVpZ2h0OjUwLjBwdCI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOUM5OTk5Ij5D ZWxsPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5Qzk5OTkiPkVtYWls PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5Qzk5OTkiPlNreXBlPC9z cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJi b3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjBpbiAwaW4g MGluIDBpbjtoZWlnaHQ6NTAuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5Qzk5OTkiPiYjNDM7NDYgNzA5 ODQ1OTkyPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxMTU1Q0MiPmhu eWRlbGw8YSBocmVmPSJtYWlsdG86bWtvd2Fsa2VAYWNjZWRpYW4uY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj5AYWNjZWRpYW4uY29tPC9zcGFu PjwvYT48L3NwYW4+PC91PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzExNTVDQyI+PGEg aHJlZj0iaHR0cDovL2xpbmtlZGluLmNvbS9pbi9tYWVrb3dhbGsiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPmg8L3NwYW4+PC9hPm55ZGVsbDwvc3Bh bj48L3U+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGEgaHJlZj0iaHR0cDovL2FjY2VkaWFuLmNvbS8iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMTE1NUNDO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0i MCIgd2lkdGg9IjMxIiBoZWlnaHQ9IjMxIiBzdHlsZT0id2lkdGg6LjMyMjlpbjtoZWlnaHQ6LjMy MjlpbiIgaWQ9Il94MDAwMF9pMTAzNCIgc3JjPSJodHRwczovL2xoNC5nb29nbGV1c2VyY29udGVu dC5jb20vcllNWDlCcTVNU3dwb3lFQ095V2VjbzJ6TlNnbXQzM0wyZUxIR1BXelVVbnZWMmxjUXRs M3dzVXBTSHRJVW94ckJWaHpDSy1lTmtvX0VGdkxGRHVKX1NYTndIOHVtamVzeTVqMDh5UFl5cDFL UFRtRGV2eUZLRTdndnNiUl8xbl9DV0g1N2dMbSI+PC9zcGFuPjwvYT48YSBocmVmPSJodHRwOi8v YmxvZy5hY2NlZGlhbi5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxMTU1Q0M7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMzEi IGhlaWdodD0iMzEiIHN0eWxlPSJ3aWR0aDouMzIyOWluO2hlaWdodDouMzIyOWluIiBpZD0iX3gw MDAwX2kxMDM1IiBzcmM9Imh0dHBzOi8vbGg2Lmdvb2dsZXVzZXJjb250ZW50LmNvbS9SckNuQmpI TW5oV2lWa0RlQUNwbDBjLTU2NXFMMHlHekg2LUZ4VWxXWTJld3NhSXh1Y1VmdjhYRElmWk1zY1RN akx6NXJ1UzFuOG5ZQ3JZbzV2ajBXNXN4UGtfMU1vdkJiVWRueGtpNUtWOE82M25mNk5RNUtvV3dN VlpFWW80S2FKTXh6bHFnIj48L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48YSBocmVm PSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS9hY2NlZGlhbi1uZXR3b3JrcyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMTE1NUNDO3RleHQtZGVjb3JhdGlv bjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjMxIiBoZWlnaHQ9IjMxIiBzdHlsZT0id2lk dGg6LjMyMjlpbjtoZWlnaHQ6LjMyMjlpbiIgaWQ9Il94MDAwMF9pMTAzNiIgc3JjPSJodHRwczov L2xoNC5nb29nbGV1c2VyY29udGVudC5jb20vQTljUHkwVEVCSUlfRnE5S3pDcVFsYUFOMzZPTWg4 cGktc0Ria1ZlYUxVdFlibElWMHJsQU5WeHpjR3hCeDhEMG9BanF2YkJZYmw3RDNVaEZubGs4T2xD bHYwLWRpaEkyd1FpLWZzeFBCUEw3cmJkam52dXl1RE53anpWa0V6cTdrRmtQZVNaUyI+PC9zcGFu PjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCiAmbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNv bS9BY2NlZGlhbiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMTE1NUND O3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjMxIiBoZWlnaHQ9 IjMxIiBzdHlsZT0id2lkdGg6LjMyMjlpbjtoZWlnaHQ6LjMyMjlpbiIgaWQ9Il94MDAwMF9pMTAz NyIgc3JjPSJodHRwczovL2xoNC5nb29nbGV1c2VyY29udGVudC5jb20vTUQxbGFsN0lvMzBhN2xL OFdVbFlHMnk2ZnNuZENta2tzaUoxdldiNFFTR2Z0VER4VHN1TERJR1JJa25rSTdmZ3BGczZHMFBh UHZ4OW9sNmtCQ2hnRlNneFFCT2dYbHdGRHAzY3F4b2MzRVhPN3ZWQnFlWkNsNjBEVXo2by1fSDRq ZUFqbU41biI+PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4N CiAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuZmFjZWJvb2suY29tL2FjY2VkaWFuIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxMTU1Q0M7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIw IiB3aWR0aD0iMzEiIGhlaWdodD0iMzEiIHN0eWxlPSJ3aWR0aDouMzIyOWluO2hlaWdodDouMzIy OWluIiBpZD0iX3gwMDAwX2kxMDM4IiBzcmM9Imh0dHBzOi8vbGg2Lmdvb2dsZXVzZXJjb250ZW50 LmNvbS9qOUo2RnhHb2UtVVFtRVUtMlRZSHRWMmJId241YldCUVZKNEU5WHh4OGUteDNBby14a25a SmJYUjFkUGZlVkF0N1dJemJ0bDI3eVhuM2JYbGF1Ri1jSkdjT1QwT0xvdFUtWDBtTXA3OXBWdjhD WlptX0R1eUt6UnZFV3ZhaGllMkxiZDluMFlKIj48L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPg0KICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuNXB0Ij48YSBocmVmPSJodHRwOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIvYWNjZWRpYW4iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzExNTVDQzt0ZXh0LWRlY29yYXRp b246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIzMSIgaGVpZ2h0PSIzMSIgc3R5bGU9Indp ZHRoOi4zMjI5aW47aGVpZ2h0Oi4zMjI5aW4iIGlkPSJfeDAwMDBfaTEwMzkiIHNyYz0iaHR0cHM6 Ly9saDUuZ29vZ2xldXNlcmNvbnRlbnQuY29tL0lKbUdXWG1tc0MwemtRWk4xdFM3QVVOUTBRdWRo ZHdmNjB0NndMZ19xdkNsNGQ1bVNqelNBb3VUY0NFbDdsUmpORVNpZUc2WmlHaGdRbkZYSHBkdnpU WU5OVFVPcWZVV0QtNktiR3dHeG0yak0wS3FRb01LTzZ2a2NRNWlLUTJjcEo3OXk4NEciPjwvc3Bh bj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjQ3IiBoZWlnaHQ9IjIwOCIgc3R5bGU9 IndpZHRoOjIuNTcyOWluO2hlaWdodDoyLjE2NjZpbiIgaWQ9Il94MDAwMF9pMTA0MCIgc3JjPSJo dHRwczovL2xoNC5nb29nbGV1c2VyY29udGVudC5jb20vU0Y2cHRjVHVqTTI0Zy03VEwzY0w1Q01G SHF3Z0ZpMmtTRm5abDZPUzZIYV9lVzZmOHpQMjdpeUNUTDdvNWI1dmxiNXA0MzN3R3JEa1prYkJG YVhBRmp4bE1nbmNPbGE5RVQ3di03NzFFdnY0czU4QjlENlBHakFVRE85ZFpaOGxhS0kwODFVciI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJGUi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdCI+QXZpcyBkZSBjb25maWRlbnRpYWxp dMOpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJm b250LXNpemU6Ny41cHQiPkxlcyBpbmZvcm1hdGlvbnMgY29udGVudWVzIGRhbnMgbGUgcHLDqXNl bnQgbWVzc2FnZSBldCBkYW5zIHRvdXRlIHBpw6hjZSBxdWkgbHVpIGVzdCBqb2ludGUgc29udCBj b25maWRlbnRpZWxsZXMgZXQgcGV1dmVudCDDqnRyZSBwcm90w6lnw6llcyBwYXIgbGUgc2VjcmV0 IHByb2Zlc3Npb25uZWwuIENlcyBpbmZvcm1hdGlvbnMgc29udCDDoCBs4oCZdXNhZ2UgZXhjbHVz aWYgZGUgc29uDQogb3UgZGUgc2VzIGRlc3RpbmF0YWlyZXMuIFNpIHZvdXMgcmVjZXZleiBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IHPigJlpbCB2b3VzIHBsYWl0IGNvbW11bmlxdWVy IGltbcOpZGlhdGVtZW50IGF2ZWMgbOKAmWV4cMOpZGl0ZXVyIGV0IGVuIGTDqXRydWlyZSB0b3V0 IGV4ZW1wbGFpcmUuIERlIHBsdXMsIGlsIHZvdXMgZXN0IHN0cmljdGVtZW50IGludGVyZGl0IGRl IGxlIGRpdnVsZ3VlciwgZGUgbGUgZGlzdHJpYnVlciBvdSBkZSBsZSByZXByb2R1aXJlDQogc2Fu cyBs4oCZYXV0b3Jpc2F0aW9uIGRlIGzigJlleHDDqWRpdGV1ci4gTWVyY2kuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlItQ0EiIHN0eWxlPSJmb250LXNpemU6Ny41cHQi PkNvbmZpZGVudGlhbGl0eSBub3RpY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0Ij5UaGlzIGUtbWFpbCBtZXNzYWdlIGFuZCBhbnkgYXR0YWNo bWVudCBoZXJldG8gY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJl IHByaXZpbGVnZWQgYW5kIHdoaWNoIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBv ZiBpdHMgYWRkcmVzc2VlKHMpLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Is IHBsZWFzZSBpbmZvcm0gc2VuZGVyDQogaW1tZWRpYXRlbHkgYW5kIGRlc3Ryb3kgYW55IGNvcHkg dGhlcmVvZi4gRnVydGhlcm1vcmUsIGFueSBkaXNjbG9zdXJlLCBkaXN0cmlidXRpb24gb3IgY29w eWluZyBvZiB0aGlzIG1lc3NhZ2UgYW5kL29yIGFueSBhdHRhY2htZW50IGhlcmV0byB3aXRob3V0 IHRoZSBjb25zZW50IG9mIHRoZSBzZW5kZXIgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gVGhhbmsg eW91Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR0701MB2890E73A9A9D5E896235E651D7180HE1PR0701MB2890_-- From nobody Tue Apr 18 19:11:19 2017 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 ED38F126C2F; Tue, 18 Apr 2017 19:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 q74XVNzW8J8V; Tue, 18 Apr 2017 19:11:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66411200DF; Tue, 18 Apr 2017 19:11:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLH54993; Wed, 19 Apr 2017 02:11:12 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 19 Apr 2017 03:11:12 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 19 Apr 2017 10:11:00 +0800 From: Tianran Zhou To: "MORTON, ALFRED C (AL)" , "Brian Trammell (IETF)" , "Frank Brockners (fbrockne)" CC: IPPM Chairs , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+AQqwOfU4bhxE6OT40sqe9xy6Gp8KmAgAAD3ACAAAfTAIAAIx6AgAA2hgCAAPdoAIAAaFWAgAAcNgCAABufgIACkoWAgAt5d4CABF/dAIADEXMAgARQ/ICABTbxAIAAKoCAgAAKzQCAAOa8MA== Date: Wed, 19 Apr 2017 02:10:59 +0000 Message-ID: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.58F6C741.004C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 98a08d21ef769b941ef7cde85a91f180 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 19 Apr 2017 02:11:19 -0000 Hi Al, I am not clear about some of your suggestions. Please see inline. Thanks, Tianran > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, ALFRED C > (AL) > Sent: Wednesday, April 19, 2017 4:04 AM > To: Brian Trammell (IETF); Frank Brockners (fbrockne) > Cc: IPPM Chairs; ippm@ietf.org > Subject: Re: [ippm] Vote at IPPM session >=20 > All, > one alternative to consider, below. > Al >=20 > > -----Original Message----- > > From: Brian Trammell (IETF) [mailto:ietf@trammell.ch] > > Sent: Tuesday, April 18, 2017 3:26 PM > > To: Frank Brockners (fbrockne) > > Cc: adrian@olddog.co.uk; MORTON, ALFRED C (AL); IPPM Chairs; > > ippm@ietf.org; Sarah B > > Subject: Re: [ippm] Vote at IPPM session > > > > hi Frank, all, > > > > Speaking as an individual. > > > > First, thanks for the scope section... this is all much more concrete > > now. > > > > So, as I understand it, iOAM is designed first and foremost to be a > > single-network (in the sense of "coherent administrative domain") > > protocol data model with a binding to a variety of "carrier" protocols > > (the draft speaks of "transports" in the RTG-area meaning of the term, > > not the TSV-area one, so let's overload "carrier" here instead), some > > of which are also explicitly single-network, some of which less so... > > > > I tend to share the concerns of those who've expressed discomfort with > > the "warning label approach" to ensuring that iOAM data stays single- > > network, but I'm not sure it's a problem *for the data model*. I don't > > necessarily read this "MUST NOT leave the network" as an additional > > responsibility of operators, but rather on the designers of carrier > > protocols for iOAM data. Now, some of the carrier protocols (e.g. IPv6 > > extension headers) provide no such protection or support for providing > > that protection, so in that case it falls to the implementor of the > > iOAM solution to provide it... but this is rather a matter to be > > handled on a per carrier protocol basis, isn't it? > > > > Cheers, > > Brian > [ACM] >=20 > IOM, there is a general message to convey for all future protocol develop= ment. > Something like "sufficient provisions should be made to restrict the iOAM > traffic to the intended domain." >=20 > We could provide guidance to interconnecting network operators, as well, > effectively allowing them to discard traffic containing unexpected iOAM > data.=20 "Discard" the traffic? This might be available for active measurement with = additional testing packets. But this iOAM is in-situ within the data packet= . The discard will harm the user traffic. Or bypassing the iOAM instruction= /header be better? >This would be applicable to non-iOAM network operators, but might > be more important for interconnecting operators who have established thei= r > own iOAM domain. >=20 > This is similar to the approach we used for BMWG test traffic: > there are v4 and v6 address spaces dedicated for isolated test environmen= ts, > and any packet with testing addresses observed on the Internet may be > discarded. >=20 > regards, > Al >=20 > > > > > > > > > On 18 Apr 2017, at 18:53, Frank Brockners (fbrockne) > > wrote: > > > > > > Hi Adrian, > > > > > > thanks - please see inline below... > > > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: Samstag, 15. April 2017 11:16 > > > To: Frank Brockners (fbrockne) > > > Cc: 'ALFRED MORTON' ; 'Brian Trammell (IETF)' > > ; 'IPPM Chairs' ; > > ippm@ietf.org; 'Sarah B' > > > Subject: RE: [ippm] Vote at IPPM session > > > > > > Hi Frank, all, > > > > > > Thanks for proposing some text. > > > > > >> How about: "The operator of such a domain MUST put provisions in > > place > > >> to ensure that in-situ OAM data stays within the specific domain > > >> only (i.e., does > > > not > > >> leak beyond the edge) using for example packet filtering methods. > > >> The operator SHOULD consider potential operational impact of IOAM > > >> to mechanisms such as ECMP processing (e.g. load-balancing schemes > > >> based on packet length could be impacted by the increased packet > > >> size due > > to > > >> IOAM), path MTU (i.e. ensure that the MTU of all links within a > > domain > > >> is sufficiently large to support the > > > increased > > >> packet size due to IOAM) and ICMP message handling (i.e. in case of > > >> a native > > > IPv6 > > >> transport, IOAM support for ICMPv6 Echo Request/Reply could desired > > >> which would translate into ICMPv6 extensions to enable IOAM data > > >> fields to be copied from an Echo Request message to an Echo Reply > > message)." > > > > > > Like Sarah, I think this is a start. > > > > > > I remain disappointed that it is the operators' responsibility to > > ensure various things, and not a feature of the protocol or > > implementation. > > > > > > But perhaps this text serves as a warning to the operators about > > > using > > implementations of iOAM and so will suffice. > > > > > > ...FB: The current document is just the starting point. Let's hope > > that the WG can improve the current approach further and/or suggest > > improved text. > > > > > > I think the use of 2119 capitalisation is meaningless in this > > paragraph, and that the "SHOULD" in the second sentence should in any > > case be a "must". > > > > > > ...FB: Thanks. Will change/correct in the next revision (along with > > > a > > set of typos that I introduced when crafting the section) > > > > > > Thanks, Frank > > > > > > Thanks, > > > Adrian >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Tue Apr 18 19:17:27 2017 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 6884A126C2F; Tue, 18 Apr 2017 19:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, 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 PJTgqnRqRb30; Tue, 18 Apr 2017 19:17:24 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 429661200DF; Tue, 18 Apr 2017 19:17:24 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3J2Eo1j017294; Tue, 18 Apr 2017 22:17:17 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 29ww4bhrr6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Apr 2017 22:17:17 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3J2HGeZ002243; Tue, 18 Apr 2017 22:17:17 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3J2HAvc002201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 22:17:11 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 19 Apr 2017 02:17:05 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v3J2H5ep017729; Tue, 18 Apr 2017 21:17:05 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v3J2GtlB017083; Tue, 18 Apr 2017 21:16:56 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id BD4B5E08B5; Tue, 18 Apr 2017 22:16:54 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 22:16:54 -0400 From: "MORTON, ALFRED C (AL)" To: Tianran Zhou , "Brian Trammell (IETF)" , "Frank Brockners (fbrockne)" CC: IPPM Chairs , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ANywb7w7Y7CUWYR5PjBqbNA6GqudOAgAAD3QCAAAfSAIAAIx6AgAA2hgCAAPdoAIAAaFWAgAAcNwD//8lsgIAC5LeAgAt5d4CABF/eAIADEXMAgARQ+4CABTbyAIAAKoCA///CZvCAAK7VgP//vUHQ Date: Wed, 19 Apr 2017 02:16:53 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F71D09@njmtexg5.research.att.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.240.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-19_01:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704190019 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 19 Apr 2017 02:17:26 -0000 Quick reply in-line, > -----Original Message----- > From: Tianran Zhou [mailto:zhoutianran@huawei.com] > Sent: Tuesday, April 18, 2017 10:11 PM > To: MORTON, ALFRED C (AL); Brian Trammell (IETF); Frank Brockners > (fbrockne) > Cc: IPPM Chairs; ippm@ietf.org > Subject: RE: [ippm] Vote at IPPM session >=20 > Hi Al, >=20 > I am not clear about some of your suggestions. > Please see inline. >=20 > Thanks, > Tianran >=20 > > -----Original Message----- > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, ALFRED > C > > (AL) > > Sent: Wednesday, April 19, 2017 4:04 AM > > To: Brian Trammell (IETF); Frank Brockners (fbrockne) > > Cc: IPPM Chairs; ippm@ietf.org > > Subject: Re: [ippm] Vote at IPPM session > > > > All, > > one alternative to consider, below. > > Al > > > > > -----Original Message----- > > > From: Brian Trammell (IETF) [mailto:ietf@trammell.ch] > > > Sent: Tuesday, April 18, 2017 3:26 PM > > > To: Frank Brockners (fbrockne) > > > Cc: adrian@olddog.co.uk; MORTON, ALFRED C (AL); IPPM Chairs; > > > ippm@ietf.org; Sarah B > > > Subject: Re: [ippm] Vote at IPPM session > > > > > > hi Frank, all, > > > > > > Speaking as an individual. > > > > > > First, thanks for the scope section... this is all much more > concrete > > > now. > > > > > > So, as I understand it, iOAM is designed first and foremost to be a > > > single-network (in the sense of "coherent administrative domain") > > > protocol data model with a binding to a variety of "carrier" > protocols > > > (the draft speaks of "transports" in the RTG-area meaning of the > term, > > > not the TSV-area one, so let's overload "carrier" here instead), > some > > > of which are also explicitly single-network, some of which less > so... > > > > > > I tend to share the concerns of those who've expressed discomfort > with > > > the "warning label approach" to ensuring that iOAM data stays > single- > > > network, but I'm not sure it's a problem *for the data model*. I > don't > > > necessarily read this "MUST NOT leave the network" as an additional > > > responsibility of operators, but rather on the designers of carrier > > > protocols for iOAM data. Now, some of the carrier protocols (e.g. > IPv6 > > > extension headers) provide no such protection or support for > providing > > > that protection, so in that case it falls to the implementor of the > > > iOAM solution to provide it... but this is rather a matter to be > > > handled on a per carrier protocol basis, isn't it? > > > > > > Cheers, > > > Brian > > [ACM] > > > > IOM, there is a general message to convey for all future protocol > development. > > Something like "sufficient provisions should be made to restrict the > iOAM > > traffic to the intended domain." > > > > We could provide guidance to interconnecting network operators, as > well, > > effectively allowing them to discard traffic containing unexpected > iOAM > > data. >=20 > "Discard" the traffic? This might be available for active measurement > with additional testing packets. But this iOAM is in-situ within the > data packet. The discard will harm the user traffic. Or bypassing the > iOAM instruction/header be better? [ACM]=20 Yes, discard. The traffic was not properly processed at the domain boundary=20 (the iOAM data should have been processed and removed). Traffic that unintentionally escapes a network may have=20 undesirable effects (harm) on downstream networks, especially if others are planning to add iOAM data. Al >=20 > >This would be applicable to non-iOAM network operators, but might > > be more important for interconnecting operators who have established > their > > own iOAM domain. > > > > This is similar to the approach we used for BMWG test traffic: > > there are v4 and v6 address spaces dedicated for isolated test > environments, > > and any packet with testing addresses observed on the Internet may be > > discarded. > > > > regards, > > Al > > > > > > > > > > > > > > > On 18 Apr 2017, at 18:53, Frank Brockners (fbrockne) > > > wrote: > > > > > > > > Hi Adrian, > > > > > > > > thanks - please see inline below... > > > > > > > > -----Original Message----- > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > Sent: Samstag, 15. April 2017 11:16 > > > > To: Frank Brockners (fbrockne) > > > > Cc: 'ALFRED MORTON' ; 'Brian Trammell (IETF)' > > > ; 'IPPM Chairs' ; > > > ippm@ietf.org; 'Sarah B' > > > > Subject: RE: [ippm] Vote at IPPM session > > > > > > > > Hi Frank, all, > > > > > > > > Thanks for proposing some text. > > > > > > > >> How about: "The operator of such a domain MUST put provisions in > > > place > > > >> to ensure that in-situ OAM data stays within the specific domain > > > >> only (i.e., does > > > > not > > > >> leak beyond the edge) using for example packet filtering methods. > > > >> The operator SHOULD consider potential operational impact of IOAM > > > >> to mechanisms such as ECMP processing (e.g. load-balancing > schemes > > > >> based on packet length could be impacted by the increased packet > > > >> size due > > > to > > > >> IOAM), path MTU (i.e. ensure that the MTU of all links within a > > > domain > > > >> is sufficiently large to support the > > > > increased > > > >> packet size due to IOAM) and ICMP message handling (i.e. in case > of > > > >> a native > > > > IPv6 > > > >> transport, IOAM support for ICMPv6 Echo Request/Reply could > desired > > > >> which would translate into ICMPv6 extensions to enable IOAM data > > > >> fields to be copied from an Echo Request message to an Echo Reply > > > message)." > > > > > > > > Like Sarah, I think this is a start. > > > > > > > > I remain disappointed that it is the operators' responsibility to > > > ensure various things, and not a feature of the protocol or > > > implementation. > > > > > > > > But perhaps this text serves as a warning to the operators about > > > > using > > > implementations of iOAM and so will suffice. > > > > > > > > ...FB: The current document is just the starting point. Let's hope > > > that the WG can improve the current approach further and/or suggest > > > improved text. > > > > > > > > I think the use of 2119 capitalisation is meaningless in this > > > paragraph, and that the "SHOULD" in the second sentence should in > any > > > case be a "must". > > > > > > > > ...FB: Thanks. Will change/correct in the next revision (along > with > > > > a > > > set of typos that I introduced when crafting the section) > > > > > > > > Thanks, Frank > > > > > > > > Thanks, > > > > Adrian > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIFAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3D8cY2uEv8ohR5Vo7ht_h5e44A= t- > tNd7YjYG-2Zqv08rg&s=3DazHzymcSqyhfRrLm7_QX2YbyttdWrjvr2-Y268j9wWI&e=3D From nobody Tue Apr 18 20:09:34 2017 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 02DA31314D2; Tue, 18 Apr 2017 20:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 zotTeUg_2hUQ; Tue, 18 Apr 2017 20:09:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF84B1277BB; Tue, 18 Apr 2017 20:09:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFC46197; Wed, 19 Apr 2017 03:09:22 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 19 Apr 2017 04:09:21 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 19 Apr 2017 11:09:18 +0800 From: Tianran Zhou To: "MORTON, ALFRED C (AL)" , "Brian Trammell (IETF)" , "Frank Brockners (fbrockne)" CC: IPPM Chairs , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+AQqwOfU4bhxE6OT40sqe9xy6Gp8KmAgAAD3ACAAAfTAIAAIx6AgAA2hgCAAPdoAIAAaFWAgAAcNgCAABufgIACkoWAgAt5d4CABF/dAIADEXMAgARQ/ICABTbxAIAAKoCAgAAKzQCAAOa8MP//gViAgACTMqA= Date: Wed, 19 Apr 2017 03:09:17 +0000 Message-ID: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F71D09@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F71D09@njmtexg5.research.att.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58F6D4E3.0063, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7232588c78cf7fd948d611e4c23027e6 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 19 Apr 2017 03:09:29 -0000 Thanks Al. Got you. Then I think the inter-domain/operator should be complex while discard is o= ne of many negotiable policies. For example, one operator(access) may want to transit another network(core)= . > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Wednesday, April 19, 2017 10:17 AM > To: Tianran Zhou; Brian Trammell (IETF); Frank Brockners (fbrockne) > Cc: IPPM Chairs; ippm@ietf.org > Subject: RE: [ippm] Vote at IPPM session >=20 > Quick reply in-line, >=20 > > -----Original Message----- > > From: Tianran Zhou [mailto:zhoutianran@huawei.com] > > Sent: Tuesday, April 18, 2017 10:11 PM > > To: MORTON, ALFRED C (AL); Brian Trammell (IETF); Frank Brockners > > (fbrockne) > > Cc: IPPM Chairs; ippm@ietf.org > > Subject: RE: [ippm] Vote at IPPM session > > > > Hi Al, > > > > I am not clear about some of your suggestions. > > Please see inline. > > > > Thanks, > > Tianran > > > > > -----Original Message----- > > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, > > > ALFRED > > C > > > (AL) > > > Sent: Wednesday, April 19, 2017 4:04 AM > > > To: Brian Trammell (IETF); Frank Brockners (fbrockne) > > > Cc: IPPM Chairs; ippm@ietf.org > > > Subject: Re: [ippm] Vote at IPPM session > > > > > > All, > > > one alternative to consider, below. > > > Al > > > > > > > -----Original Message----- > > > > From: Brian Trammell (IETF) [mailto:ietf@trammell.ch] > > > > Sent: Tuesday, April 18, 2017 3:26 PM > > > > To: Frank Brockners (fbrockne) > > > > Cc: adrian@olddog.co.uk; MORTON, ALFRED C (AL); IPPM Chairs; > > > > ippm@ietf.org; Sarah B > > > > Subject: Re: [ippm] Vote at IPPM session > > > > > > > > hi Frank, all, > > > > > > > > Speaking as an individual. > > > > > > > > First, thanks for the scope section... this is all much more > > concrete > > > > now. > > > > > > > > So, as I understand it, iOAM is designed first and foremost to be > > > > a single-network (in the sense of "coherent administrative > > > > domain") protocol data model with a binding to a variety of "carrie= r" > > protocols > > > > (the draft speaks of "transports" in the RTG-area meaning of the > > term, > > > > not the TSV-area one, so let's overload "carrier" here instead), > > some > > > > of which are also explicitly single-network, some of which less > > so... > > > > > > > > I tend to share the concerns of those who've expressed discomfort > > with > > > > the "warning label approach" to ensuring that iOAM data stays > > single- > > > > network, but I'm not sure it's a problem *for the data model*. I > > don't > > > > necessarily read this "MUST NOT leave the network" as an > > > > additional responsibility of operators, but rather on the > > > > designers of carrier protocols for iOAM data. Now, some of the carr= ier > protocols (e.g. > > IPv6 > > > > extension headers) provide no such protection or support for > > providing > > > > that protection, so in that case it falls to the implementor of > > > > the iOAM solution to provide it... but this is rather a matter to > > > > be handled on a per carrier protocol basis, isn't it? > > > > > > > > Cheers, > > > > Brian > > > [ACM] > > > > > > IOM, there is a general message to convey for all future protocol > > development. > > > Something like "sufficient provisions should be made to restrict the > > iOAM > > > traffic to the intended domain." > > > > > > We could provide guidance to interconnecting network operators, as > > well, > > > effectively allowing them to discard traffic containing unexpected > > iOAM > > > data. > > > > "Discard" the traffic? This might be available for active measurement > > with additional testing packets. But this iOAM is in-situ within the > > data packet. The discard will harm the user traffic. Or bypassing the > > iOAM instruction/header be better? > [ACM] > Yes, discard. >=20 > The traffic was not properly processed at the domain boundary (the iOAM > data should have been processed and removed). > Traffic that unintentionally escapes a network may have undesirable effec= ts > (harm) on downstream networks, especially if others are planning to add > iOAM data. >=20 > Al >=20 > > > > >This would be applicable to non-iOAM network operators, but might be > > >more important for interconnecting operators who have established > > their > > > own iOAM domain. > > > > > > This is similar to the approach we used for BMWG test traffic: > > > there are v4 and v6 address spaces dedicated for isolated test > > environments, > > > and any packet with testing addresses observed on the Internet may > > > be discarded. > > > > > > regards, > > > Al > > > > > > > > > > > > > > > > > > > > On 18 Apr 2017, at 18:53, Frank Brockners (fbrockne) > > > > wrote: > > > > > > > > > > Hi Adrian, > > > > > > > > > > thanks - please see inline below... > > > > > > > > > > -----Original Message----- > > > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > > > Sent: Samstag, 15. April 2017 11:16 > > > > > To: Frank Brockners (fbrockne) > > > > > Cc: 'ALFRED MORTON' ; 'Brian Trammell (IETF)' > > > > ; 'IPPM Chairs' ; > > > > ippm@ietf.org; 'Sarah B' > > > > > Subject: RE: [ippm] Vote at IPPM session > > > > > > > > > > Hi Frank, all, > > > > > > > > > > Thanks for proposing some text. > > > > > > > > > >> How about: "The operator of such a domain MUST put provisions > > > > >> in > > > > place > > > > >> to ensure that in-situ OAM data stays within the specific > > > > >> domain only (i.e., does > > > > > not > > > > >> leak beyond the edge) using for example packet filtering methods= . > > > > >> The operator SHOULD consider potential operational impact of > > > > >> IOAM to mechanisms such as ECMP processing (e.g. load-balancing > > schemes > > > > >> based on packet length could be impacted by the increased > > > > >> packet size due > > > > to > > > > >> IOAM), path MTU (i.e. ensure that the MTU of all links within a > > > > domain > > > > >> is sufficiently large to support the > > > > > increased > > > > >> packet size due to IOAM) and ICMP message handling (i.e. in > > > > >> case > > of > > > > >> a native > > > > > IPv6 > > > > >> transport, IOAM support for ICMPv6 Echo Request/Reply could > > desired > > > > >> which would translate into ICMPv6 extensions to enable IOAM > > > > >> data fields to be copied from an Echo Request message to an > > > > >> Echo Reply > > > > message)." > > > > > > > > > > Like Sarah, I think this is a start. > > > > > > > > > > I remain disappointed that it is the operators' responsibility > > > > > to > > > > ensure various things, and not a feature of the protocol or > > > > implementation. > > > > > > > > > > But perhaps this text serves as a warning to the operators about > > > > > using > > > > implementations of iOAM and so will suffice. > > > > > > > > > > ...FB: The current document is just the starting point. Let's > > > > > hope > > > > that the WG can improve the current approach further and/or > > > > suggest improved text. > > > > > > > > > > I think the use of 2119 capitalisation is meaningless in this > > > > paragraph, and that the "SHOULD" in the second sentence should in > > any > > > > case be a "must". > > > > > > > > > > ...FB: Thanks. Will change/correct in the next revision (along > > with > > > > > a > > > > set of typos that I introduced when crafting the section) > > > > > > > > > > Thanks, Frank > > > > > > > > > > Thanks, > > > > > Adrian > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIFAg&c=3DLFYZ- > > > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3D8cY2uEv8ohR5Vo7ht_h5e44A= t > > - tNd7YjYG-2Zqv08rg&s=3DazHzymcSqyhfRrLm7_QX2YbyttdWrjvr2-Y268j9wWI&e= =3D From nobody Wed Apr 19 00:14:53 2017 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 9F80C131530; Wed, 19 Apr 2017 00:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 03DzgwF1O36s; Wed, 19 Apr 2017 00:14:50 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC32131529; Wed, 19 Apr 2017 00:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1492586089; x=1524122089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KWSSkTvqIlbmY0pn+121XQSCSls5CYXk5tapYreczEg=; b=AVOUUe0Gxkz4CY//kl/YqcHvV9dKoKVlxr+h5vLG/KEEdR04TtuxdfqA ohjyp0vI/UxEux0uRhwl3rybXGOSKoZJ4LQIDAC7Mqc4M9ky4TTaQwieQ 47WHVGAs43YFG9YvJZ77pQSnngxEhJ+d+yn94In0BuU3XGhTRSxbQQ/6A RFIdVnykr0ZWjFC2c+lMyVLEGYVhUcwOqSdcSNsN50EjVZxi4L0h7aT45 Zf1lUKRelHtyPERYqBoeob9+bqj+J+o3YqpDT3ra5bVEZRglCaJ7txnA0 GxW+viiZJPVVXli8e4XTw02dyaCJi54GEFZRfG4rjGOTRJhYShqVCJiPS w==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/RC4-SHA; 19 Apr 2017 09:14:46 +0200 X-IronPort-AV: E=Sophos;i="5.37,220,1488841200"; d="scan'208";a="6880638" Received: from he101659.emea1.cds.t-internal.com ([10.134.226.19]) by QDE8PP.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 09:14:46 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101659.emea1.cds.t-internal.com (10.134.226.19) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Apr 2017 09:14:46 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Wed, 19 Apr 2017 09:14:46 +0200 From: To: CC: , , , Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSuH8ZPZAWv+5YD0yHKUp0Ir+32KHMRDMw Date: Wed, 19 Apr 2017 07:14:45 +0000 Message-ID: <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.170.86] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 19 Apr 2017 07:14:51 -0000 Hi Al, is a non-iOAM network operator able to detect standard ipv6 packets with iO= AM extensions, if the receiving operators equipment is configured to suppor= t standard ipv6 protocol only? The pre-condition here is "non-iOAM domain" = at the receiving side. My point is, if a domain isn't interested in support= ing the iOAM extensions, is it obliged to operate iOAM aware equipment to d= etect undesired traffic at network boundaries? I'm not sure, whether this is an IPPM discussion. Is there any other IPPM p= rotocol or packet content requiring a discard of traffic at a domain bounda= ry? Regards, Ruediger [ACM]=20 IOM, there is a general message to convey for all future protocol developme= nt. Something like "sufficient provisions should be made to restrict the iO= AM traffic to the intended domain." We could provide guidance to interconnecting network operators, as well, ef= fectively allowing them to discard traffic containing unexpected iOAM data.= This would be applicable to non-iOAM network operators, but might be more = important for interconnecting operators who have established their own iOAM= domain. This is similar to the approach we used for BMWG test traffic: there are v4 and v6 address spaces dedicated for isolated test environments= , and any packet with testing addresses observed on the Internet may be dis= carded. From nobody Wed Apr 19 00:43:16 2017 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 ED8FA13153A for ; Wed, 19 Apr 2017 00:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TRACKER_ID=1.306, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian-com.20150623.gappssmtp.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 wUjeZQ6XBE_5 for ; Wed, 19 Apr 2017 00:43:10 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E44B131537 for ; Wed, 19 Apr 2017 00:43:10 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id x184so18475329oia.1 for ; Wed, 19 Apr 2017 00:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UixDYlSYvFXz9/X6EqpOOLB525NfIIcrzK0bmi2wc2k=; b=eAIZmugENxS0einbUwwhU8qUUaJnr2FkcmSsArKeHpumDHt1TT8pml3USEl0NQujVM 2Bh/Jqk4u3YE6R177wqTHHyoy85RgmjeBE43kmnKby60uwOr1lP78u7YyCU/zAm7M1Rp Vxur264abZSuMFQ8lVOz5sBu7OAu4Oc8d2G4FjDJ4PV9G9EuqyF2JbBq5LKD81zL2JOv XGakNlshGg4dvTtpdr77pObYHeq26Zt4aVfeNvudDHv7YTIvArjw0nEcki+sJOgCo960 8WrgffXORv+DaBFd313AOAczNxAO93hgbdRQHc/+9aWcq75duwOOHRUMshJGhUOIshdP 6H3Q== 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=UixDYlSYvFXz9/X6EqpOOLB525NfIIcrzK0bmi2wc2k=; b=EGh41k8OEGZETRtwqRcJbqeyhGdQPiPtw6NfM6Zgz4rN7tTUtB+Qahq46wvb8VlzA7 ngYtgVAK2AWN+ITRUCMR8vk/oGRyPxGCOquFsvYRtoL0ua9ZNBhB9sKnmfvU2EynGQ/U HhCFw1nVyyYOdlpY2fLsyJtAx7na1Jy7dNVcLP4c3r0Ujdt0wv+XH1Ym/YrUnWY67h3q BpVxOaoCakck9W5XHUUNWID/LwxEkCSu7lhBQBSqa7bL2b2TWa2MnAIk2129D3kiCPQb CQU+7RAPdWdnsqNa3WKKq5N3boxhzzK6aXoybylqYJVGAS6c9q5AVojOLw63asSc3AIr IeUA== X-Gm-Message-State: AN3rC/6+f1B5jyVnNJuUjIVxFjY39A3GWkrXgbdo+7PXvD6nLjDizVS3 tYw4LL1H5RRJp/vI2+jY9EfMDTh1cOAU/4yMRFLuvkcPPW06kUSfBLqm0BPd9B9Q3tkh6HQ5QV8 a X-Received: by 10.157.53.55 with SMTP id o52mr616520otc.97.1492587789677; Wed, 19 Apr 2017 00:43:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.9.151 with HTTP; Wed, 19 Apr 2017 00:43:08 -0700 (PDT) In-Reply-To: References: From: Henrik Nydell Date: Wed, 19 Apr 2017 09:43:08 +0200 Message-ID: To: Wei Luo S Cc: Greg Mirsky , "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a11c019720009ec054d802d45 Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 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, 19 Apr 2017 07:43:15 -0000 --001a11c019720009ec054d802d45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please see my clarifications inline Thanks Henrik On Wed, Apr 19, 2017 at 3:24 AM, Wei Luo S wrote: > Please see my comments inline. > > > > Thanks, > > Wei Luo > > > > *From:* Henrik Nydell [mailto:hnydell@accedian.com] > *Sent:* Tuesday, April 18, 2017 7:59 PM > *To:* Greg Mirsky > *Cc:* Wei Luo S ; draft-mirsky-ippm-twamp-light- > yang@tools.ietf.org; ippm@ietf.org > *Subject:* Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-0= 7 > > > > I would ask you to consider adding some more valuable metrics > > 1) Loss burst size max > > > > leaf loss-burst-max { > > type int32; > > description > > "Highest number of lost packets back-to-back during inter= val."; > > } > > [WEI] Agree, it=E2=80=99s valuable, I think we should add it. Besides, I = suggest > to add one more metrics: loss-burst-min, which is the minimum number of > lost packets back-to-back during interval. > [HN] I Agree loss-burst-min is also an important metric for gap analysis > > 2) Loss burst count (tells how many instances there was of packet loss > during an interval, one "instance" means one or more consecutive packets > lost. > > > > leaf loss-burst-count { > > type int32; > > description > > "Number of occasions with packet loss during interval."; > > } > > > > To further explain the above metrics, consider 60-second interval below > with 1 packet per second monitoring, where x means lost packet and o mean= s > recieved. > > > > 0 60s > > oooXooXooooXXXXooooooooooXXoooooXoooXooooooooXXXXXXXXXXXXooo > > > > This 60s-interval has 22 lost packets ( 22/60 =3D36.67% loss) > > Loss burst max is 12 packets, number of loss instances are 7 > > > > [WEI] Agree. It should be added. For stateful reflector, two more metrics > can be added: loss-burst-count-far-end, loss-burst-count-near-end. > > > > 3) Percentiles are very useful and important. If they cannot be > "configurable" in the Yang model I would suggest you to consider adding a= t > least the 95th, 99th and 99.9th percentiles for all delay type metrics. > > [WEI] Could you explain the meaning of =E2=80=9Cpercentile=E2=80=9D here? > [HN] Instead of just reporting the min/max/avg values; +--ro one-way-delay-far-end | | | +--ro delay | | | | +--ro min? yang:gauge32 | | | | +--ro max? yang:gauge32 | | | | +--ro avg? yang:gauge32 | | | +--ro delay-variation | | | +--ro min? uint32 | | | +--ro max? uint32 | | | +--ro avg? uint32 A percentile gives more granularity. Percentile 95 for delay means that out of all samples in the interval, if you remove the 5% highest, then the next largest delay value is p95. So a delay value of 23.412ms at p95 means that 95% of the delay samples during the interval were lower than or equal to 23.412ms. Using percentiles allows for filtering out spikes, instead reporting on "bulk" delay during an interval. Especcially useful for SLA/SLO-based monitoring where you do not necessarily want to raise an alarm on a max spike that was caused by a single packet being delayed, but instead look at percentile 95 or 99 or 99.5 depending on what resolution you want. Many protocols and functions use a percentile so define in which range the protocol or function operates well. One example is from the mobile world, where Ericsson and others define the RAN requirements in terms of delay and delay variation with percentiles. I.e it is OK that a few packets break the delay limit, as long as 99% don't (p99). Many operators use continous TWAMP monitoring with quite high packet rates, like 50 packets per second. With 60 second interval reporting, this means 3,000 samples per interval, giving plenty of room to calculate 99.9 percentile (removing 3 highest samples out of the 3,000) For a standardized Yang model the best would of course be if these percentiles were not statically defined, but could be configurable depending on what the user wants to see. For sake of simpicity I think three definable percentiles would be sufficient. percentile-a [0.1 .. 99.9] percentile-b [0.1 .. 99.9] percentile-c [0.1 .. 99.9] And these three then reported (if implemented by the TWAMP sender) for both roundtrip, far-end and near-end. and for both delay and delay-variation metrics. > > > > > On Thu, Apr 13, 2017 at 6:53 PM, Greg Mirsky > wrote: > > Dear All, > > the new update of the TWAMP-Light YANG model > has > been published. It includes the following: > > - packet loss ratio as decimal64 type with fraction-size 5; > - session-reflector state parameter in session-sender container; > - defined continuous and periodic modes to execute a test session and > how performance metrics are calculated in each of the modes; > - reporting of one-way packet loss metrics, both near-end and far-end, > has dependency of reflector's mode. > > Some questions still being discussed and we greatly appreciate > suggestions, comments: > > - include percentile in delay and delay-variation containers? > - default value for session-timeout in session-sender container is 900 > seconds. Seems too big. What may be practical? Change units from secon= ds to > centiseconds or milliseconds? > > Regards, > > Greg > > > > On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell > wrote: > > Some comments from the "field" as Accedian has several hundred thousand > TWAMP sessions running (continously) at numerous Tier one mobile/fixed > operators globally. > > > > On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S > wrote: > > Hi Greg, > > > > Thanks a lot for your response. Please see my reply inline tagged [WEI>>]= . > > > > Regards, > > Wei Luo > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Tuesday, March 21, 2017 1:16 AM > *To:* Wei Luo S > *Cc:* ippm@ietf.org; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org > *Subject:* Re: Some though on draft-mirsky-ippm-twamp-light-yang-07 > > > > Hi Wei Luo, > > many thanks for your thorough review and the most helpful comments to the > TWAMP Light(Test) model. Please find my answers, notes in-line tagged GIM= >>. > > > > Regards, > > Greg > > > > On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S wrote= : > > Hi Greg & Adrian, > > > > This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. Th= e > current TWAMP Light YANG model is well defined. Thanks for your great job= . > > But by working closely with our customers, we got some new user cases on > TWAMP light. I believe these user cases are valuable and popular enough t= o > be modeled in TWAMP Light YANG. I hope I can be a contributor and co-wor= k > with you move this draft forward. > > I drafted a new version of the TWAMP light YANG model based on version > ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any > discussion is welcome. > > The draft yang model and tree is attached. To make you find the updates > quickly, I highlighted all the updates in file > ietf-twamp-light-weiluo.pdf. > > > > The following are the list of main updates: > > *1. Add a new typedef: percent. This is a new type defined for packet los= s > ratio.* > > Consideration: > > 1). From the customer perspective, packet loss ratio is a more meaningful > data. In most of the time, the absolute number is meaningless to user, > especially they do the TWAMP test continuously. They are more care about > the ratio than the absolute number. So adding it makes this model more > friendly to customer; > > 2). From the service layer assurance(SLA) perspective, the packet loss > ratio is a major measures. So with adding packet loss ratio in model, the > TWAMP can work in SLA framework more smoothly. > > 3). It seems some similar protocol=E2=80=99s YANG model has the same defi= nition, > e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99, > https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf. > > Agreed packet loss is important, however another important loss metric is > loss burst size (max/min) and number of loss bursts. A loss burst of 10 > consecutive TWAMP-test packets can be deemed more serious than 10 lost > packets spread evenly over the report interval. > > GIM>> Indeed, packet loss more often expressed as packet loss ratio rathe= r > than as the absolute number. It would be most helpful to hear from networ= k > operators if they see introduction of Packet Loss Ratio into the TWAMP > model helpful. > > *2. Add a new typedef: state-mode. It defines a common type for > stateful/stateless reflector. This type will be used in both sender sessi= on > and reflector session.* > > Consideration: > > If the reflector is stateful, the TWAMP light can measure more items, e.g= . > one way packet loss. So for sender, the stats calculation and show is > different. When the reflector is stateless, it doesn=E2=80=99t need to ca= lculate > the one way packet loss. The one way packet loss is invalid and shouldn= =E2=80=99t > be presented to customer. When the reflector is stateless, the sender nee= ds > to calculate the one way packet loss. And the data should be present to > customer. So this is used as a =E2=80=98when=E2=80=99 condition in the mo= del=E2=80=99s RO tree. > > GIM>> Yes, if Session-Sender is aware of the mode corresponding > Session-Reflector operates, the sender may avoid calculation of some > performance metrics, e.g., one-way packet loss. On the other hand, the > orchestrator is aware of the state-mode and should be capable to properly > use metrics reported by the Session-Sender. > > [WEI>>] Yes, the orchestrator could know that. But from the model side, > this is not correct. The model should represent the right behavior and > shouldn=E2=80=99t do assumption on orchestrator. > > I agree the model should describe both one-way loss metrics and roundtrip > loss metrics, and the sender should be able to use either mode when > calculating, potentially also populating the roundtrip delay values with > proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that > would indicate buffer load/CPU load in the TWAMP responders processing ti= me. > > *3. Add a new typedef: send-mode. This is a new type for sender session. > It makes the sender session can send packet continuously and monitor the > network all the time.* > > Consideration: > > The user case is that: the user runs TWAMP light sessions to watch links > quality continuously. The session number could be very big. These TWAMP > sessions are managed by SLA framework or similar. SLA retrieves the stats > from TWAMP periodically, e.g. 15mins. In other words, all the performance > metrics are calculated based on the packets sent/received within 15mins. > This makes the calculation become possible. With the periodical stats dat= a, > the Network Management software can do further actions if some abnormal > stats observed. This is a more general user case in customer site. While > the non-continuous TWAMP sender session is generally used for debugging > purpose on a link. > > GIM>> I think that support of continuous measurement is in LMAP domain, > not for TWAMP Test data model. To conduct continuous measurement he LMAP > Controller, in my opinion, programs the Measurement Agent to perform TWAM= P > Test session with certain set of parameters and repeat it without any > interval (interval =3D 0). > > > > Many operators use TWAMP in continous mode, not only with Accedian test > points and report at fixed intervals, typically ranging from 5s to 5 or 1= 5 > minutes, with 1-minute being the most popular granularity currently. The > advantage is that the result calculation can be handled separately from t= he > TWAMP-test sending/recieving, so that there is no parallelism required to > monitor 24/7. If a start-stop-based methodology is used, the sender needs > to start up the new test session even before the previous one has ended, > since the previous session needs to wait X seconds (or at least Y 100s of > milliseconds) before it stops waiting for packets to come back. And this > new session needs to have a different signature in order for the sender t= o > discern which packets belong to the previous interval and which belong to > the current. > > > > In a continous test-model, the sender can just simply record the sequence > number of the last packet transmitted in the interval to be reported, wai= t > for it to come back, or a MAXTIME, then report that result, while > continuing to transmit for the next interval. > > > > If the "interval=3D=3D0" parameter is intended to be used for continous t= ype > tests, then what parameter should indicate to the sender at what interval= s > to produce results? > > *4. Add a new group: packet-loss-statistics. It grouping two packet loss > statistics: loss-count and loss-ratio. This group will be used in RO stat= s > tree.* > > GIM>> I'd like to continue discussion. > > [WEI>>] OK. > > *5. Move leaf dscp out from grouping session-light-parameters. The leaf > dscp is only valid when the dscp-handling-mode is use-configured-value. A > when condition shall be added to it. So it can=E2=80=99t be in this group= .* > > GIM>> I'm concerned that then the model will not be able to support > concurrent TWAMP Test sessions between the same pair of Test Points (IP > address+port number) at different CoS markings. > > [WEI>>] Actually, I have concern on using five tuple(IP address+port > number+dscp) to identify a TWAMP test session. The DSCP is not a constant > value in packet. It could be modified by the routers in the path. For > example, the sender has two sessions: session A=E2=80=99s five tuple is: > Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2. S= ession B=E2=80=99s > five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001= , > DSCP=3Dcs3. The only difference between session A and session B is DSCP. = If > the test packet=E2=80=99s DSCP of session B is modified to cs2 by a route= r in the > path. The five tuples are exactly the same for reflector. It can=E2=80=99= t > differentiate which packet is from session A, which packet is from sessio= n > B. It could mess the reflector=E2=80=99s session sequence number. And als= o, the > sender will be messed because the received reply packet=E2=80=99s five tu= ple are > exactly the same. > > So I think it=E2=80=99s more reasonable to use four tuple to identify a s= ession. > > > > Yes, this would be appreciated by users. Changes in DSCP is a reasonably > common network error that users can detect with continous TWAMP monitorin= g, > thus it is good to not include the DSCP value as part of the "session > identifiier" but instead use 4-tuple with UDP source port to identify > several parallel flows between the same sender and responder. > > *6. Add leaf 'session-packet-send-mode' to > /twamp-light/twamp-light-session-sender/test-session*. This leaf specifie= s > the sender session's packet send mode: continuous or non-continuous.* > > GIM>> As discussed in #3, I think that it is already part of LMAP YANG > model. > > *7. Add leaf 'reflector-light-mode-state' to > /twamp-light/twamp-light-session-sender/test-session*. This leaf indicate= s > the the reflector's mode: stateful or stateless. If the reflector's mode = is > stateful. Two one way packet loss statistics can be got: > one-way-packet-loss-far-end, one-way-packet-loss-near-end.* > > Consideration: > > Only valid data should be presented to user. Otherwise it could misleadin= g > user in some cases. > > GIM>> A in response to #2. > > *8. Modify leaf > /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. > Add a 'when' condition to this leaf. When send-mode is 'continuous', the > leaf number-of-packets is meaningless. So add a 'when' condition to limit > it. Besides, added a default value =E2=80=9810=E2=80=99 to it. When the = send-mode is > 'non-continuous', the session can't work with an empty number-of-packets.= * > > GIM>> As I've noted in #3. Will add default. > > *9. Add leaf time out to > /twamp-light/twamp-light-session-sender/test-session*. A timeout mechanis= m > is needed when the sender session can't get all the reply packets for a > long time.* > > GIM>> Thank you, will add in the next update. > > *10. Modify leaf > /twamp-light/twamp-light-session-sender/test-session*/interval. Change th= e > units from =E2=80=98microseconds=E2=80=99 to =E2=80=98milliseconds=E2=80= =99. Add a default value 1000. * > > Consideration: > > 1). The aim of TWAMP is to measure network quality, but not fast > failure detection. So a millisecond packet interval is enough. > > 2). Interval is a necessary parameter for a session. A sender session > can't work with an empty packet send interval. So added a default value t= o > it. > > GIM>> Thank you. We've made units of interval microseconds in the last > update already. I think that changing to milliseconds may be too > restrictive, limit use cases for TWAMP Test. Will add default value with > the next update. > > [WEI>>] Sorry, I do not see the reason. Are there any user cases to use > microseconds? > > *11. Add leaf 'dscp' to > /twamp-light/twamp-light-session-sender/test-session*. This is the leaf > moved out from grouping session-light-parameters.* > > GIM>> As noted in response #5, the change may limit ability to run > concurrent TWAMP Test sessions per CoS. I consider that to be valuable mo= de > but would like to hear from network operators if that is indeed useful > information. > > > > See my comment above. I argue that it is useful to keep track of changing > DSCP values, and treating DSCP as a metric of the TWAMP Session just like > loss and delay > > *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and > 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to > /twamp-light/twamp-light-session-reflector/test-session*. These three > attributes should be session specific. Different session could have > different values. They are not common attributes.* > > GIM>> Agree, will make it in the next update. > > *13. Add leaf 'dscp' to > /twamp-light/twamp-light-session-reflector/test-session*. This is the lea= f > moved out from grouping session-light-parameters. Besides the movement, > added a 'when' condition to the leaf 'dscp'. This leaf is only valid when > the dscp-handling-mode is 'use-configured-value'.* > > GIM>> As response to #5. > > *14. Modify leaf > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/number-of-packets. > Add a 'when' condition to this leaf. When send-mode is 'continuous', the > leaf number-of-packets is meaningless.* > > GIM>> Similar to #3. > > *15. Modify leaf > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/interval. > Change the units from microseconds to milliseconds.* > > GIM>> I think that microseconds is reasonable. > > *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and > 'one-way-packet-loss-near-end' to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/. > These are the new statistics for stateful reflector.* > > GIM>> Thank you, will be coming in the next update. > > *17. Remove leaf loss-packet in > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats. > The loss packeted is replaced with 'two-way-packet-loss' stated above.* > > GIM>> Agree. > > *18. Modify leaf to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/h= istory-stats*/interval. > Change the units from microseconds to milliseconds.* > > GIM>> I think that will limit applicability of TWAMP Test. > > *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and > 'one-way-packet-loss-near-end' to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/h= istory-stats*/. > These are the new statistics for stateful reflector.* > > GIM>> Agree. > > > > Thanks, > > Wei Luo > > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > > > -- > > > > [image: Accedian.com] > > *Henrik Nydell* > > Sr Manager Global Strategy & Solutions > > > > *Cell* > > *Email* > > *Skype* > > *+46 709845992 <+46%2070%20984%2059%2092>* > > *hnydell@accedian.com * > > *h nydell* > > > > > > > > > > > > > > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > -- > > > > [image: Accedian.com] > > *Henrik Nydell* > > Sr Manager Global Strategy & Solutions > > > > *Cell* > > *Email* > > *Skype* > > *+46 709845992 <+46%2070%20984%2059%2092>* > > *hnydell@accedian.com * > > *h nydell* > > > > > > > > > > > > > > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > --=20 [image: Accedian.com] Henrik Nydell Sr Manager Global Strategy & Solutions Cell Email Skype +46 709845992 hnydell@accedian.com h nydell --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3= =A8ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le secret=20 professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de son= ou de ses=20 destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99il= vous=20 plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en d= =C3=A9truire tout=20 exemplaire. De plus, il vous est strictement interdit de le divulguer, de= =20 le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99= exp=C3=A9diteur.=20 Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the exclusive= =20 use of its addressee(s). If you receive this message in error, please=20 inform sender immediately and destroy any copy thereof. Furthermore, any=20 disclosure, distribution or copying of this message and/or any attachment= =20 hereto without the consent of the sender is strictly prohibited. Thank you. --001a11c019720009ec054d802d45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please see my clarifications inline

Tha= nks
Henrik

On Wed, Apr 19, 2017 at 3:24 AM, Wei Luo S <<= a href=3D"mailto:wei.s.luo@ericsson.com" target=3D"_blank">wei.s.luo@ericss= on.com> wrote:

Please see my comments inline.

=C2=A0

Thanks,

Wei Luo

=C2=A0

From: Henrik Nydell [mailto:hnydell@accedian.com]
Sent: Tuesday, April 18, 2017 7:59 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Wei Luo S <wei.s.luo@ericsson.com>; draft-mirsky-ippm-t= wamp-light-yang@tools.ietf.org; ippm@ietf.org
Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07

=C2=A0

I would ask you to consider adding some more valuabl= e metrics

1) Loss burst size max

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 leaf loss-burst-max {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type int32;<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Highest number of lo=
st packets back-to-back during interval.";
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0}

[WEI] Agree, it=E2=80=99s valuable, I think we shoul= d add it. Besides, I suggest to add one more metrics: loss-burst-min, which= is the minimum =C2=A0number of lost packets back-to-back during interval.<= /p>


=C2=A0[HN] I Ag= ree loss-burst-min is also an important metric for gap analysis
<= br>

=C2=A0

2) Loss burst count (tells how many instances there = was of packet loss during an interval, one "instance" means one o= r more consecutive packets lost.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 leaf loss-burst-count {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type int32;<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Number of occasion=
s with packet loss during interval.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 }

=C2=A0

To further explain the above metrics, consider 60-se= cond interval below with 1 packet per second monitoring, where x means lost= packet and o means recieved.

=C2=A0

= 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 60s

= oooXooXooooXXXXooooooooooXXoooooXoooXooooooooXXXXXXXXXXXXooo=

=C2=A0

This 60s-interval has 22 lost packets ( 22/60 =3D36.= 67% loss)

Loss burst max is 12 packets, number of loss instanc= es are 7

=C2=A0

[WEI] Agree. It should be added. For stateful reflec= tor, two more metrics can be added: loss-burst-count-far-end, loss-burst-co= unt-near-end.

=C2=A0

3) Percentiles are very useful and important. If the= y cannot be "configurable" in the Yang model I would suggest you = to consider adding at least the 95th, 99th and 99.9th percentiles for all d= elay type metrics.=C2=A0

[WEI] Could you explain the meaning of =E2=80=9Cperc= entile=E2=80=9D here?


[HN] Instead of just reporting the min/max/avg values;
+--ro one-way-delay-far-end
       |     |  |  +--ro delay
       |     |  |  |  +--ro min?   yang:gauge32
       |     |  |  |  +--ro max?   yang:gauge32
       |     |  |  |  +--ro avg?   yang:gauge32
       |     |  |  +--ro delay-variation
       |     |  |     +--ro min?   uint32
       |     |  |     +--ro max?   uint32
       |     |  |     +--ro avg?   uint32

A = percentile gives more granularity. Percentile 95 for delay means that out o= f all samples in the interval, if you remove the 5% highest, then the next = largest delay value is p95. So a delay value of 23.412ms at p95 means that = 95% of the delay samples during the interval were lower than or equal to 23= .412ms.

Using percentiles allows for filtering out= spikes, instead reporting on "bulk" delay during an interval. Es= peccially useful for SLA/SLO-based monitoring where you do not necessarily = want to raise an alarm on a max spike that was caused by a single packet be= ing delayed, but instead look at percentile 95 or 99 or 99.5 depending on w= hat resolution you want.

Many protocols and functi= ons use a percentile so define in which range the protocol or function oper= ates well. One example is from the mobile world, where Ericsson and others = define the RAN requirements in terms of delay and delay variation with perc= entiles. I.e it is OK that a few packets break the delay limit, as long as = 99% don't (p99).

Many operators use continous = TWAMP monitoring with quite high packet rates, like 50 packets per second. = With 60 second interval reporting, this means 3,000 samples per interval, g= iving plenty of room to calculate 99.9 percentile (removing 3 highest sampl= es out of the 3,000)

For a standardized Yang model= the best would of course be if these percentiles were not statically defin= ed, but could be configurable depending on what the user wants to see. For = sake of simpicity I think three definable percentiles would be sufficient.<= /div>
percentile-a [0.1 .. 99.9]
percentile-b [0.1 .. 99= .9]
percentile-c [0.1 .. 99.9]

And these three then reported (if implemented= by the TWAMP sender) for both roundtrip, far-end and near-end. and for bot= h delay and delay-variation metrics.


=C2=A0

=C2=A0

=C2=A0

On Thu, Apr 13, 2017 at 6:53 PM, Greg Mirsky <gregimirsky@gmail.c= om> wrote:

Dear All,

the new update of the TWAMP-Lig= ht YANG model=C2=A0has been published. It includes the following:

  • packet loss ratio as decimal64 type with fraction-size 5;
  • session-reflector state parameter in session-sender container;
  • defined continuous and periodic modes to execute a test session and how per= formance metrics are calculated in each of the modes;
    • reporting of one-way packet loss metrics, both near-end and far-end, has de= pendency of reflector's mode.

Some questions still being discussed and we greatly = appreciate suggestions, comments:

  • include percentile in delay and delay-variation containers?
  • default value for session-timeout in session-sender container is 900 second= s. Seems too big. What may be practical? Change units from seconds to centi= seconds or milliseconds?

Regards,

Greg

=C2=A0

On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell <<= a href=3D"mailto:hnydell@accedian.com" target=3D"_blank">hnydell@accedian.c= om> wrote:

Some comments from the "field" as Accedian= has several hundred thousand TWAMP sessions running (continously) at numer= ous Tier one mobile/fixed operators globally.

=C2=A0

On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S <wei.s.luo@ericsson.= com> wrote:

Hi Greg,

=C2=A0

Thanks a lot for your response. Please see my reply inline tagged= [WEI>>].

=C2=A0

Regards,

Wei Luo

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, March 21, 2017 1:16 AM
To: Wei Luo S <wei.s.luo@ericsson.com>
Cc: ippm@ietf.org= ; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org
Subject: Re: Some though on draft-mirsky-ippm-twamp-light-yang-= 07

=C2=A0

Hi Wei Luo,

many thanks for your thorough review and the most he= lpful comments to the TWAMP Light(Test) model. Please find my answers, note= s in-line tagged GIM>>.

=C2=A0

Regards,

Greg

=C2=A0

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.c= om> wrote:

Hi Greg & Adrian,

=C2=A0

This is Wei Luo from Ericsson. I work on TWAMP light= area in Ericsson. The current TWAMP Light YANG model is well defined. Than= ks for your great job.

But by working closely with our customers, we got so= me new user cases on TWAMP light. I believe these user cases are valuable a= nd popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor =C2=A0and co-work with you move this draft f= orward.=C2=A0

I =C2=A0drafted a new version of the TWAMP light YAN= G model based on version ietf-= twamp-light@2017-02-13.yang. Could you please comments on it? Any = discussion is welcome.

The draft yang model and tree is attached. To make y= ou find the updates quickly, I highlighted all the updates in fil= e ietf-twamp-light-weiluo.pdf.

=C2=A0

The following are the list of main updates:

1. Add a new typedef: percent. This is a new type= defined for packet loss ratio.

Consideration:

1). From the customer perspective, packet loss ratio is a more meaningful d= ata. In most of the time, the absolute number is meaningless to user, espec= ially they do the TWAMP test continuously. They are more care about the rat= io than the absolute number. So adding it makes this model more friendly to customer;

2). From the service layer assurance(SLA) perspective, the packet loss rati= o is a major measures. So with adding packet loss ratio in model, the TWAMP= can work in SLA framework more smoothly.

3). It seems some similar protocol=E2=80=99s YANG model has the same defini= tion, e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99= , https://www.mef.net/Assets/Technical_= Specifications/PDF/MEF_39.pdf.

Agreed packet loss is important, however another imp= ortant loss metric is loss burst size (max/min) and number of loss bursts. = A loss burst of 10 consecutive TWAMP-test packets can be deemed more seriou= s than 10 lost packets spread evenly over the report interval.

GIM>> Indeed, packet loss more often expressed= as packet loss ratio rather than as the absolute number. It would be most = helpful to hear from network operators if they see introduction of Packet Loss Ratio into the TWAMP model helpful.

2. Add a new typedef: state-mode. It defines a co= mmon type for stateful/stateless reflector. This type will be used in both = sender session and reflector session.

Consideration:

If the reflector is stateful, the TWAMP light can me= asure more items, e.g. one way packet loss. So for sender, the stats calcul= ation and show is different. When the reflector is stateless, it doesn=E2=80=99t need to calculate the one way packet loss. T= he one way packet loss is invalid and shouldn=E2=80=99t be presented to cus= tomer. When the reflector is stateless, the sender needs to calculate the o= ne way packet loss. And the data should be present to customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree.

GIM>> Yes, if Session-Sender is aware of the m= ode corresponding Session-Reflector operates, the sender may avoid calculat= ion of some performance metrics, e.g., one-way packet loss. On the other hand, the orchestrator is aware of the state-mode and should = be capable to properly use metrics reported by the Session-Sender.

[WEI&= gt;>] Yes, the orchestrator could know that. But from the model side, th= is is not correct.=C2=A0 The model should represent the right behavior and shouldn=E2=80=99t do assumption on orchestrator.

I agree the model should describe both one-way loss = metrics and roundtrip loss metrics, and the sender should be able to use ei= ther mode when calculating, potentially also populating the roundtrip delay= values with proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that would indicate buffer l= oad/CPU load in the TWAMP responders processing time.

3. Add a new typedef: send-mode. This is a new ty= pe for sender session. It makes the sender session can send packet continuo= usly and monitor the network all the time.

Consideration:

The user case is that: the user runs TWAMP light ses= sions to watch links quality continuously. The session number could be very= big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. = In other words, all the performance metrics are calculated based on the pac= kets sent/received within 15mins. This makes the calculation become possibl= e. With the periodical stats data, the Network Management software can do further actions if some abnormal st= ats observed.=C2=A0 This is a more general user case in customer site. Whil= e the non-continuous TWAMP sender session is generally used for debugging p= urpose on a link. =C2=A0

GIM>> I think that support of continuous measu= rement is in LMAP domain, not for TWAMP Test data model. To conduct continu= ous measurement he LMAP Controller, in my opinion, programs the Measurement Agent to perform TWAMP Test session with certain set of pa= rameters and repeat it without any interval (interval =3D 0).=

=C2=A0

Many operators use TWAMP in continous mode, not only= with Accedian test points and report at fixed intervals, typically ranging= from 5s to 5 or 15 minutes, with 1-minute being the most popular granulari= ty currently. The advantage is that the result calculation can be handled separately from the TWAMP-test sendi= ng/recieving, so that there is no parallelism required to monitor 24/7. If = a start-stop-based methodology is used, the sender needs to start up the ne= w test session even before the previous one has ended, since the previous session needs to wait X seconds (or at l= east Y 100s of milliseconds) before it stops waiting for packets to come ba= ck. And this new session needs to have a different signature in order for t= he sender to discern which packets belong to the previous interval and which belong to the current.=

=C2=A0

In a continous test-model, the sender can just simpl= y record the sequence number of the last packet transmitted in the interval= to be reported, wait for it to come back, or a MAXTIME, then report that r= esult, while continuing to transmit for the next interval.

=C2=A0

If the "interval=3D=3D0" parameter is inte= nded to be used for continous type tests, then what parameter should indica= te to the sender at what intervals to produce results? =C2=A0=

4. Add a new group: packet-loss-statistics. It gr= ouping two packet loss statistics: loss-count and loss-ratio. This group wi= ll be used in RO stats tree.

GIM>> I'd like to continue discussion.=C2= =A0

[WEI>>] OK.

5. Move leaf dscp out from grouping session-light= -parameters. The leaf dscp is only valid when the dscp-handling-mode is use= -configured-value. A when condition shall be added to it. So it can=E2=80=99t be in this group.

GIM>> I'm concerned that then the model wi= ll not be able to support concurrent TWAMP Test sessions between the same p= air of Test Points (IP address+port number) at different CoS markings.=C2=A0

[WEI&= gt;>] Actually, I have concern on using five tuple(IP address+port numbe= r+dscp) to identify a TWAMP test session. The DSCP is not a constant value in packet. It could be modified by the routers in the pat= h. For example, the sender has two sessions: session A=E2=80=99s five tuple= is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2= . Session B=E2=80=99s five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs3. The only difference between sess= ion A and session B is DSCP. If the test packet=E2=80=99s DSCP of session B= is modified to cs2 by a router in the path. The five tuples are exactly th= e same for reflector. It can=E2=80=99t differentiate which packet is from session A, which packet is from session B. It could mess th= e reflector=E2=80=99s session sequence number. And also, the sender will be= messed because the received reply packet=E2=80=99s five tuple are exactly = the same.

So I = think it=E2=80=99s more reasonable to use four tuple to identify a session.=

=C2=A0

Yes, this would be appreciated by users. Changes in = DSCP is a reasonably common network error that users can detect with contin= ous TWAMP monitoring, thus it is good to not include the DSCP value as part= of the "session identifiier" but instead use 4-tuple with UDP source port to identify several parallel flow= s between the same sender and responder.=C2=A0

6. Add leaf 'session-packet-send-mode' to= /twamp-light/twamp-light-session-sender/test-session*. This leaf spec= ifies the sender session's packet send mode: continuous or non-continuo= us.

GIM>> As discussed in #3, I think that it is a= lready part of LMAP YANG model.=C2=A0

7. Add leaf 'reflector-light-mode-state' = to /twamp-light/twamp-light-session-sender/test-session*. This leaf in= dicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can b= e got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.

Consideration: =C2=A0

Only valid data should be presented to user. Otherwi= se it could misleading user in some cases.

GIM>> A in response to #2.=C2=A0=

8. Modify leaf /twamp-light/twamp-light-sess= ion-sender/test-session*/number-of-packets. Add a 'when' condi= tion to this leaf. When send-mode is 'continuous', the leaf number-= of-packets is meaningless. So add a 'when' condition to limit it.=C2=A0 Besid= es, added a default value =E2=80=9810=E2=80=99 to it. When the send-mode is= 'non-continuous', the session can't work with an empty number-= of-packets.

GIM>> As I've noted in #3. Will add defaul= t.=C2=A0

9. Add leaf time out to /twamp-light/twamp-light-= session-sender/test-session*. A timeout mechanism is needed when the s= ender session can't get all the reply packets for a long time.

GIM>> Thank you, will add in the next update.= =C2=A0

10. Modify leaf /twamp-light/twamp-light-ses= sion-sender/test-session*/interval. Change the units from =E2=80=98mic= roseconds=E2=80=99 to =E2=80=98milliseconds=E2=80=99. Add a default value 1= 000.

Consideration:

=C2=A0=C2=A0=C2=A0 1). The aim of TWAMP is to measur= e network quality, but not fast failure detection. So a millisecond packet = interval is enough.

=C2=A0=C2=A0=C2=A0 2). Interval is a necessary param= eter for a session. A sender session can't work with an empty packet se= nd interval. So added a default value to it.

GIM>> Thank you. We've made units of inter= val microseconds in the last update already. I think that changing to milli= seconds may be too restrictive, limit use cases for TWAMP Test. Will add default value with the next update.

[WEI&= gt;>] Sorry, I do not see the reason. Are there any user cases to use mi= croseconds?

11. Add leaf 'dscp' to /twamp-light/twamp= -light-session-sender/test-session*. This is the leaf moved out from g= rouping session-light-parameters.

GIM>> As noted in response #5, the change may = limit ability to run concurrent TWAMP Test sessions per CoS. I consider tha= t to be valuable mode but would like to hear from network operators if that is indeed useful information.=C2=A0

=C2=A0

See my comment above. I argue that it is useful to k= eep track of changing DSCP values, and treating DSCP as a metric of the TWA= MP Session just like loss and delay=C2=A0

12. Move leaves 'ref-wait', 'reflecto= r-light-mode-state' and 'dscp-handling-mode' from /twamp-light/= twamp-light-session-reflector to /twamp-light/twamp-light-session= -reflector/test-session*. These three attributes should be session specific. Different session could= have different values. They are not common attributes.

GIM>> Agree, will make it in the next update.= =C2=A0

13. Add leaf 'dscp' to /twamp-light/twamp= -light-session-reflector/test-session*. This is the leaf moved ou= t from grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only v= alid when the dscp-handling-mode is 'use-configured-value'.<= /u>

GIM>> As response to #5.=C2=A0

14. Modify leaf /twamp-light-state/twamp-lig= ht-session-sender-state/test-session-state*/current-stats/number-= of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.

GIM>> Similar to #3.=C2=A0

15. Modify leaf /twamp-light-state/twamp-lig= ht-session-sender-state/test-session-state*/current-stats/interva= l. Change the units from microseconds to milliseconds.

GIM>> I think that microseconds is reasonable.= =C2=A0

16. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/current-stats/. These are the new statistics for stateful reflector.

GIM>> Thank you, will be coming in the next up= date.=C2=A0

17. Remove leaf loss-packet in /twamp-light-state= /twamp-light-session-sender-state/test-session-state*/current-stats. The loss packeted is replaced with 'two-way-packet-loss' stated above.

GIM>> Agree.=C2=A0

18. Modify leaf to /twamp-light-state/twamp-= light-session-sender-state/test-session-state*/history-stats*/int= erval. Change the units from microseconds to milliseconds.

GIM>> I think that will limit applicability of= TWAMP Test.=C2=A0

19. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/history-stats*/. These are the new statistics for stateful reflector.

GIM>> Agree.

=C2=A0

Thanks,

Wei Luo

=C2=A0


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



=C2=A0

--

=C2=A0=

3D"Accedian.com"

Henrik Nydell

Sr Manager Global Strategy & Solutions<= /span>

=C2=A0=

Cell=

Email

Skype

+46 709845992

hnydell@accedian.com

h<= /span>nydell

=C2=A0

= =C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0=

=C2=A0

=C2=A0

Avis de confidentialit=C3= =A9

Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

Confidentiality notice

This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.


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

=C2=A0



=C2=A0

--

=C2=A0=

3D"Accedian.com"

Henrik Nydell

Sr Manager Global Strategy & Solutions<= /span>

=C2=A0=

Cell=

Email

Skype

+46 709845992<= /span>

hnydell@accedian.com

h<= /span>nydell

=C2=A0

= =C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0=

=C2=A0

=C2=A0

Avis de confidentialit=C3= =A9

Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

Confidentiality notice

This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.




--


Henrik Nydell

Sr Manager Global Strategy & Solutions=


Cell

Email

Skype

+46 709845992=

hnydell@accedian.com=

hnydell



= =C2= =A0 =C2=A0 =C2=A0 =C2=A0



<= /div>

Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

--001a11c019720009ec054d802d45-- From nobody Wed Apr 19 05:24:27 2017 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 92B16127077; Wed, 19 Apr 2017 05:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 BWZjbdo9sSoy; Wed, 19 Apr 2017 05:24:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CCD12943D; Wed, 19 Apr 2017 05:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3568; q=dns/txt; s=iport; t=1492604663; x=1493814263; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4QLjqj/M4sPCSRGAIj9IRPg5yki0u5+ivENzUr3aB+A=; b=ejjSLBrK9XDxrwg26k6Mz6MFA1oLjHbM5XsveBDJBngnwqvBzjZ5hNrg PoTEScAap8S5eWvoKjCisR4syxUAenRgpQspZH+g6jSaimxq5rephgbve EgeDAlt/XgwRRUXePUmR1mcpixO9GQfWGtOZxhzYXXn9qxJJnJp652RBw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAACEVvdY/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgykrgWwHjXWRY5Vigg+GJAKDfD8YAQIBAQEBAQEBayiFFQEBAQE?= =?us-ascii?q?DOi0SDAQCAQgRBAEBHwkHMhQJCAIEAQ0FCIoRrHeLLQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2ELoIlgV2DGYo8BZ0tAZJkkVSUDwEfOIEFYxWFKhyBY3WICIENAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.37,221,1488844800"; d="scan'208";a="232944912" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 12:24:22 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3JCOMuY021080 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Apr 2017 12:24:22 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 07:24:21 -0500 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.1210.000; Wed, 19 Apr 2017 07:24:21 -0500 From: "Frank Brockners (fbrockne)" To: "Ruediger.Geib@telekom.de" , "acmorton@att.com" , "Brian Trammell (IETF)" CC: "ippm-chairs@ietf.org" , "ippm@ietf.org" , "ietf@trammell.ch" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ALTeVSHHK04UeHAEB7HUBtbKGqypeAgAAD3ACAAAfTAIAAIx6AgAA2hgCAAJuA4IAAxDyAgAAcNwCAABufgIAA1nmggA01g4CABATw0IADbGAAgARQ/ICABOIu0IAAf0OAgAAKzQCAALtNgP///VsA Date: Wed, 19 Apr 2017 12:24:21 +0000 Message-ID: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> In-Reply-To: <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> 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.190.230] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 19 Apr 2017 12:24:26 -0000 Just echo'ing and agreeing to what was said below and earlier: IMHO the sta= tement of making it the responsibility of the operator to avoid IOAM data f= ields to be carried beyond the IOAM domain should really be the gateway of = last resort. One should rather try to design the encapsulation of IOAM data= into the various carrier protocols in a way that additional provisions to = avoid leaking of IOAM data don't necessarily need to be put in by an operat= or. Like what Brian and Ruediger said, this is obviously beyond IPPM docume= nts on IOAM data fields but would need to be tackled by carrier protocol sp= ecific specifications. For the text in the IOAM data-draft we probably want= to call out the fact that carrier protocol design should consider this req= uirement. How about: "Designers of carrier protocols for IOAM designers must consider to put mec= hanisms in place to ensure that in-situ OAM data stays within an IOAM domai= n. In addition, the operator of such a domain is expected to put provisions= in place to ensure that IOAM data does not leak beyond the edge of an IOAM= domain, e.g. using for example packet filtering methods. The operator shou= ld consider potential operational impact of IOAM to mechanisms such as ECMP= processing (e.g. load-balancing schemes based on packet length could be im= pacted by the increased packet size due to IOAM), path MTU (i.e. ensure tha= t the MTU of all links within a domain is sufficiently large to support the= increased packet size due to IOAM) and ICMP message handling (i.e. in case= of a native IPv6 transport, IOAM support for ICMPv6 Echo Request/Reply cou= ld desired which would translate into ICMPv6 extensions to enable IOAM data= fields to be copied from an Echo Request message to an Echo Reply message)= ." Thoughts? Thanks, Frank -----Original Message----- From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 Sent: Mittwoch, 19. April 2017 09:15 To: acmorton@att.com Cc: ippm-chairs@ietf.org; ippm@ietf.org; ietf@trammell.ch; Frank Brockners = (fbrockne) Subject: AW: [ippm] Vote at IPPM session Hi Al, is a non-iOAM network operator able to detect standard ipv6 packets with iO= AM extensions, if the receiving operators equipment is configured to suppor= t standard ipv6 protocol only? The pre-condition here is "non-iOAM domain" = at the receiving side. My point is, if a domain isn't interested in support= ing the iOAM extensions, is it obliged to operate iOAM aware equipment to d= etect undesired traffic at network boundaries? I'm not sure, whether this is an IPPM discussion. Is there any other IPPM p= rotocol or packet content requiring a discard of traffic at a domain bounda= ry? Regards, Ruediger [ACM]=20 IOM, there is a general message to convey for all future protocol developme= nt. Something like "sufficient provisions should be made to restrict the iO= AM traffic to the intended domain." We could provide guidance to interconnecting network operators, as well, ef= fectively allowing them to discard traffic containing unexpected iOAM data.= This would be applicable to non-iOAM network operators, but might be more = important for interconnecting operators who have established their own iOAM= domain. This is similar to the approach we used for BMWG test traffic: there are v4 and v6 address spaces dedicated for isolated test environments= , and any packet with testing addresses observed on the Internet may be dis= carded. From nobody Wed Apr 19 08:51:14 2017 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 ACA66129B02 for ; Wed, 19 Apr 2017 08:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 V8rwrUindr7Y for ; Wed, 19 Apr 2017 08:51:09 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D58129AD4 for ; Wed, 19 Apr 2017 08:51:09 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:1078:d135:c9d5:f7ca]) by smtp-cloud6.xs4all.net with ESMTP id AFr41v00a5PoXKq01Fr5r0; Wed, 19 Apr 2017 17:51:07 +0200 To: "Frank Brockners (fbrockne)" , "Ruediger.Geib@telekom.de" , "acmorton@att.com" , "Brian Trammell (IETF)" References: <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> Cc: "ippm-chairs@ietf.org" , "ippm@ietf.org" From: "Bert Wijnen (IETF)" Message-ID: <4f09658a-92d6-671e-2e50-966052606ef9@bwijnen.net> Date: Wed, 19 Apr 2017 17:51:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 19 Apr 2017 15:51:13 -0000 Inline On 19/04/2017 14:24, Frank Brockners (fbrockne) wrote: > Just echo'ing and agreeing to what was said below and earlier: IMHO the statement of making it the responsibility of the operator to avoid IOAM data fields to be carried beyond the IOAM domain should really be the gateway of last resort. One should rather try to design the encapsulation of IOAM data into the various carrier protocols in a way that additional provisions to avoid leaking of IOAM data don't necessarily need to be put in by an operator. Agreed. No need to put extra burden on the operators if we can avoid it. I do wonder though.... were we not thinking of also having IOAM end to end? Maybe that was some other proposal and I am mixed up. > Like what Brian and Ruediger said, this is obviously beyond IPPM documents on IOAM data fields but would need to be tackled by carrier protocol specific specifications. For the text in the IOAM data-draft we probably want to call out the fact that carrier protocol design should consider this requirement. How about: > > "Designers of carrier protocols for IOAM designers must consider to put mechanisms in 2 times "designers". I suggest to remove the 2nd occurance. > place to ensure that in-situ OAM data stays within an IOAM domain. In addition, the operator of such a domain is expected to put provisions in place to ensure that IOAM data does not leak beyond the edge of an IOAM domain, e.g. using for example packet filtering methods. The operator should consider potential operational impact of IOAM to mechanisms such as ECMP processing (e.g. load-balancing schemes based on packet length could be impacted by the increased packet size due to IOAM), path MTU (i.e. ensure that the MTU of all links within a domain is sufficiently large to support the increased packet size due to IOAM) and ICMP message handling (i.e. in case of a native IPv6 transport, IOAM support for ICMPv6 Echo Request/Reply could desired which would translate into ICMPv6 extensions to enable IOAM data fields to be copied from an Echo Request message to an Echo Reply message)." > > Thoughts? see above, Bert > Thanks, Frank > > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Mittwoch, 19. April 2017 09:15 > To: acmorton@att.com > Cc: ippm-chairs@ietf.org; ippm@ietf.org; ietf@trammell.ch; Frank Brockners (fbrockne) > Subject: AW: [ippm] Vote at IPPM session > > Hi Al, > > is a non-iOAM network operator able to detect standard ipv6 packets with iOAM extensions, if the receiving operators equipment is configured to support standard ipv6 protocol only? The pre-condition here is "non-iOAM domain" at the receiving side. My point is, if a domain isn't interested in supporting the iOAM extensions, is it obliged to operate iOAM aware equipment to detect undesired traffic at network boundaries? > > I'm not sure, whether this is an IPPM discussion. Is there any other IPPM protocol or packet content requiring a discard of traffic at a domain boundary? > > Regards, > > Ruediger > > > [ACM] > > IOM, there is a general message to convey for all future protocol development. Something like "sufficient provisions should be made to restrict the iOAM traffic to the intended domain." > > We could provide guidance to interconnecting network operators, as well, effectively allowing them to discard traffic containing unexpected iOAM data. This would be applicable to non-iOAM network operators, but might be more important for interconnecting operators who have established their own iOAM domain. > > This is similar to the approach we used for BMWG test traffic: > there are v4 and v6 address spaces dedicated for isolated test environments, and any packet with testing addresses observed on the Internet may be discarded. > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From nobody Wed Apr 19 13:03:00 2017 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 03E12128D40; Wed, 19 Apr 2017 13:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.9 X-Spam-Level: X-Spam-Status: No, score=-4.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, 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 B9lXqlf83zAE; Wed, 19 Apr 2017 13:02:57 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 5C7E212894A; Wed, 19 Apr 2017 13:02:57 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3JJt4lj029849; Wed, 19 Apr 2017 16:02:54 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 29xe0bh8t4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Apr 2017 16:02:54 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3JK2qUG012209; Wed, 19 Apr 2017 16:02:53 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3JK2gJ4012038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Apr 2017 16:02:47 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 19 Apr 2017 20:02:31 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v3JK2VFA004977; Wed, 19 Apr 2017 15:02:31 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v3JK2NkC004626; Wed, 19 Apr 2017 15:02:23 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id A8647E08B9; Wed, 19 Apr 2017 16:02:22 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Wed, 19 Apr 2017 16:02:22 -0400 From: "MORTON, ALFRED C (AL)" To: "Ruediger.Geib@telekom.de" CC: "ippm-chairs@ietf.org" , "ippm@ietf.org" , "ietf@trammell.ch" , "fbrockne@cisco.com" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ANywb7w7Y7CUWYR5PjBqbNA6GqudOAgAAD3QCAAAfSAIAAIx6AgAA2hgCAAPdoAIAAaFWAgAAcNwD//8lsgIAC5LeAgAt5d4CABF/eAIADEXMAgARQ+4CABTbyAIAAKoCA///CZvCAAQO0gIAAkNsg Date: Wed, 19 Apr 2017 20:02:21 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> In-Reply-To: <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.249.244] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-19_16:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704190165 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 19 Apr 2017 20:02:59 -0000 Hi R=FCdiger, short reply in-line, Al > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Wednesday, April 19, 2017 3:15 AM > To: MORTON, ALFRED C (AL) > Cc: ippm-chairs@ietf.org; ippm@ietf.org; ietf@trammell.ch; > fbrockne@cisco.com > Subject: AW: [ippm] Vote at IPPM session >=20 > Hi Al, >=20 > is a non-iOAM network operator able to detect standard ipv6 packets with > iOAM extensions, if the receiving operators equipment is configured to > support standard ipv6 protocol only? The pre-condition here is "non-iOAM > domain" at the receiving side. My point is, if a domain isn't interested > in supporting the iOAM extensions, is it obliged to operate iOAM aware > equipment to detect undesired traffic at network boundaries? [ACM]=20 No, an operator can let the traffic flow if they want. However, if operators find that their network is=20 affected by traffic with iOAM data from another domain, they would be justified to discard that traffic (as long as there is a clear domain limit expressed to=20 iOAM protocol designers of the future, as Frank has suggested). This is the same ability afforded operators by declaring BMWG address space for isolated testing-only, or the various private network address spaces. Plenty of=20 Net10 traffic escapes, and operators are not obliged to drop it, but they certainly can. >=20 > I'm not sure, whether this is an IPPM discussion. Is there any other > IPPM protocol or packet content requiring a discard of traffic at a > domain boundary? >=20 > Regards, >=20 > Ruediger >=20 >=20 > [ACM] >=20 > IOM, there is a general message to convey for all future protocol > development. Something like "sufficient provisions should be made to > restrict the iOAM traffic to the intended domain." >=20 > We could provide guidance to interconnecting network operators, as well, > effectively allowing them to discard traffic containing unexpected iOAM > data. This would be applicable to non-iOAM network operators, but might > be more important for interconnecting operators who have established > their own iOAM domain. >=20 > This is similar to the approach we used for BMWG test traffic: > there are v4 and v6 address spaces dedicated for isolated test > environments, and any packet with testing addresses observed on the > Internet may be discarded. >=20 From nobody Wed Apr 19 20:36:16 2017 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 23B1A129B6F for ; Wed, 19 Apr 2017 20:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, TRACKER_ID=1.306, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01] 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 hNjLRRJRicYy for ; Wed, 19 Apr 2017 20:36:09 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 231A1129412 for ; Wed, 19 Apr 2017 20:36:07 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id y11so365803oie.0 for ; Wed, 19 Apr 2017 20:36:07 -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=AiU8rwFvV6I5zuvsV2BNyeDMaWjZmOh3z/WIQcHfKPg=; b=kf/Rth5gIffEyi8wUsfVTcaZCh5CvzgEO+tSiejlz2HzyKdySGGP4b1eIHTJcYtK4s EadshChd0e2/UXG4lhEMYbGUbuZEafIh7Ij12DZN6v+14POd/CMCR9ZDeBJUfPEP/RR9 59fdh/Uh7npS+11sTkUAjr4huZXLw7uv2gEbZINdLYnunHX/vo2KgLomFllKM0nyu7sH 2t4QBVayZ7ni/q8lbXGhurgCgbWxIoVehLcCoBrBOhc+9GCcM5s0ciF+zD6xhHWtbo2Y qvCEDzUDnOuscbYbPeHjtCv479s3DRKKJHN0pRNdMpuuLZAFz1XcHlY9npeGTvz432E4 Hs5A== 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=AiU8rwFvV6I5zuvsV2BNyeDMaWjZmOh3z/WIQcHfKPg=; b=YlVTJupo9KjiY/v4akqMWpZ8mEigrpINEmpJ9YVFJ63mWK6VI3qbab9G/KxZgjz88Z GEDzkolXaiUouuXf+n7p/Nt2kZFBNFn60IdmdIQ0owt1VYXnRzjBLOCpCzAmdXRLaKKC 2p625WyteU83tGXgtEXzsTuFaDwoBqq7fzsOiVY4I6KOtHrgmtFwA99R5ovHeK/qzPY+ 5d9TQ68ATC4dBz8ZniuZjYBISL4F9p25iLAmr2P5Ba344AlJmejdkm2H7cJXoTVmA9v5 VigOW2AP7fPRh/NL6nN2N9M5ihYo3jwg86GOYW5/kSVXt+vuOoIB7qe8ZM/IXVM9K3dB hvVg== X-Gm-Message-State: AN3rC/58cyLCPEJiViCJDbrA2tQyIptMSRkReD4vVtMhjqyPkRsw/BMp 0Fe0muT77jUjNYXwTaFBlfNLyKsO7/aI X-Received: by 10.202.235.196 with SMTP id j187mr2906038oih.167.1492659366275; Wed, 19 Apr 2017 20:36:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.178 with HTTP; Wed, 19 Apr 2017 20:36:05 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Wed, 19 Apr 2017 20:36:05 -0700 Message-ID: To: Henrik Nydell Cc: Wei Luo S , "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113cf63e4c30d0054d90d78d Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 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, 20 Apr 2017 03:36:14 -0000 --001a113cf63e4c30d0054d90d78d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Henrik, your comments and suggestions that reflect practical experience of TWAMP deployment in network operation is the most valuable, thank you. We need to take a closer look at how to support the percentile. As you've suggested, operator may have option to configure percentile for each performance metric you've listed with default values for the set being 95, 99, and 99.9. That might give the flexibility and avoid extra configuration if the default values are acceptable. What do you think? And I wonder whether very low percentile levels have any practical use. Consider the following: typedef percentile { type decimal64 { fraction-digits 1; } description "Percentile"; } grouping twamp-session-percentile { description "Percentile grouping"; leaf first-percentile { type percentile { range "90.0 ... 99.9"; } default 95.0; description ""; } leaf second-percentile { type percentile { range "90.0 ... 99.9"; } default 99.0; description ""; } leaf third-percentile { type percentile { range "90.0 ... 99.9"; } default 99.9; description ""; } } Best regards, Greg On Wed, Apr 19, 2017 at 12:43 AM, Henrik Nydell wrote: > Please see my clarifications inline > > Thanks > Henrik > > On Wed, Apr 19, 2017 at 3:24 AM, Wei Luo S wrote= : > >> Please see my comments inline. >> >> >> >> Thanks, >> >> Wei Luo >> >> >> >> *From:* Henrik Nydell [mailto:hnydell@accedian.com] >> *Sent:* Tuesday, April 18, 2017 7:59 PM >> *To:* Greg Mirsky >> *Cc:* Wei Luo S ; draft-mirsky-ippm-twamp-light- >> yang@tools.ietf.org; ippm@ietf.org >> *Subject:* Re: [ippm] Some though on draft-mirsky-ippm-twamp-light- >> yang-07 >> >> >> >> I would ask you to consider adding some more valuable metrics >> >> 1) Loss burst size max >> >> >> >> leaf loss-burst-max { >> >> type int32; >> >> description >> >> "Highest number of lost packets back-to-back during inte= rval."; >> >> } >> >> [WEI] Agree, it=E2=80=99s valuable, I think we should add it. Besides, I= suggest >> to add one more metrics: loss-burst-min, which is the minimum number of >> lost packets back-to-back during interval. >> > > [HN] I Agree loss-burst-min is also an important metric for gap analysis > > >> >> 2) Loss burst count (tells how many instances there was of packet loss >> during an interval, one "instance" means one or more consecutive packets >> lost. >> >> >> >> leaf loss-burst-count { >> >> type int32; >> >> description >> >> "Number of occasions with packet loss during interval."; >> >> } >> >> >> >> To further explain the above metrics, consider 60-second interval below >> with 1 packet per second monitoring, where x means lost packet and o mea= ns >> recieved. >> >> >> >> 0 60s >> >> oooXooXooooXXXXooooooooooXXoooooXoooXooooooooXXXXXXXXXXXXooo >> >> >> >> This 60s-interval has 22 lost packets ( 22/60 =3D36.67% loss) >> >> Loss burst max is 12 packets, number of loss instances are 7 >> >> >> >> [WEI] Agree. It should be added. For stateful reflector, two more metric= s >> can be added: loss-burst-count-far-end, loss-burst-count-near-end. >> >> >> >> 3) Percentiles are very useful and important. If they cannot be >> "configurable" in the Yang model I would suggest you to consider adding = at >> least the 95th, 99th and 99.9th percentiles for all delay type metrics. >> >> [WEI] Could you explain the meaning of =E2=80=9Cpercentile=E2=80=9D here= ? >> > > [HN] Instead of just reporting the min/max/avg values; > > +--ro one-way-delay-far-end > | | | +--ro delay > | | | | +--ro min? yang:gauge32 > | | | | +--ro max? yang:gauge32 > | | | | +--ro avg? yang:gauge32 > | | | +--ro delay-variation > | | | +--ro min? uint32 > | | | +--ro max? uint32 > | | | +--ro avg? uint32 > > > A percentile gives more granularity. Percentile 95 for delay means that > out of all samples in the interval, if you remove the 5% highest, then th= e > next largest delay value is p95. So a delay value of 23.412ms at p95 mean= s > that 95% of the delay samples during the interval were lower than or equa= l > to 23.412ms. > > Using percentiles allows for filtering out spikes, instead reporting on > "bulk" delay during an interval. Especcially useful for SLA/SLO-based > monitoring where you do not necessarily want to raise an alarm on a max > spike that was caused by a single packet being delayed, but instead look = at > percentile 95 or 99 or 99.5 depending on what resolution you want. > > Many protocols and functions use a percentile so define in which range th= e > protocol or function operates well. One example is from the mobile world, > where Ericsson and others define the RAN requirements in terms of delay a= nd > delay variation with percentiles. I.e it is OK that a few packets break t= he > delay limit, as long as 99% don't (p99). > > Many operators use continous TWAMP monitoring with quite high packet > rates, like 50 packets per second. With 60 second interval reporting, thi= s > means 3,000 samples per interval, giving plenty of room to calculate 99.9 > percentile (removing 3 highest samples out of the 3,000) > > For a standardized Yang model the best would of course be if these > percentiles were not statically defined, but could be configurable > depending on what the user wants to see. For sake of simpicity I think > three definable percentiles would be sufficient. > percentile-a [0.1 .. 99.9] > percentile-b [0.1 .. 99.9] > percentile-c [0.1 .. 99.9] > > And these three then reported (if implemented by the TWAMP sender) for > both roundtrip, far-end and near-end. and for both delay and > delay-variation metrics. > > > > >> >> >> >> >> On Thu, Apr 13, 2017 at 6:53 PM, Greg Mirsky >> wrote: >> >> Dear All, >> >> the new update of the TWAMP-Light YANG model >> has >> been published. It includes the following: >> >> - packet loss ratio as decimal64 type with fraction-size 5; >> - session-reflector state parameter in session-sender container; >> - defined continuous and periodic modes to execute a test session and >> how performance metrics are calculated in each of the modes; >> - reporting of one-way packet loss metrics, both near-end and >> far-end, has dependency of reflector's mode. >> >> Some questions still being discussed and we greatly appreciate >> suggestions, comments: >> >> - include percentile in delay and delay-variation containers? >> - default value for session-timeout in session-sender container is >> 900 seconds. Seems too big. What may be practical? Change units from >> seconds to centiseconds or milliseconds? >> >> Regards, >> >> Greg >> >> >> >> On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell >> wrote: >> >> Some comments from the "field" as Accedian has several hundred thousand >> TWAMP sessions running (continously) at numerous Tier one mobile/fixed >> operators globally. >> >> >> >> On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S >> wrote: >> >> Hi Greg, >> >> >> >> Thanks a lot for your response. Please see my reply inline tagged [WEI>>= ]. >> >> >> >> Regards, >> >> Wei Luo >> >> >> >> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >> *Sent:* Tuesday, March 21, 2017 1:16 AM >> *To:* Wei Luo S >> *Cc:* ippm@ietf.org; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org >> *Subject:* Re: Some though on draft-mirsky-ippm-twamp-light-yang-07 >> >> >> >> Hi Wei Luo, >> >> many thanks for your thorough review and the most helpful comments to th= e >> TWAMP Light(Test) model. Please find my answers, notes in-line tagged GI= M>>. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S >> wrote: >> >> Hi Greg & Adrian, >> >> >> >> This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. >> The current TWAMP Light YANG model is well defined. Thanks for your grea= t >> job. >> >> But by working closely with our customers, we got some new user cases on >> TWAMP light. I believe these user cases are valuable and popular enough = to >> be modeled in TWAMP Light YANG. I hope I can be a contributor and co-wo= rk >> with you move this draft forward. >> >> I drafted a new version of the TWAMP light YANG model based on version >> ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any >> discussion is welcome. >> >> The draft yang model and tree is attached. To make you find the updates >> quickly, I highlighted all the updates in file >> ietf-twamp-light-weiluo.pdf. >> >> >> >> The following are the list of main updates: >> >> *1. Add a new typedef: percent. This is a new type defined for packet >> loss ratio.* >> >> Consideration: >> >> 1). From the customer perspective, packet loss ratio is a more meaningfu= l >> data. In most of the time, the absolute number is meaningless to user, >> especially they do the TWAMP test continuously. They are more care about >> the ratio than the absolute number. So adding it makes this model more >> friendly to customer; >> >> 2). From the service layer assurance(SLA) perspective, the packet loss >> ratio is a major measures. So with adding packet loss ratio in model, th= e >> TWAMP can work in SLA framework more smoothly. >> >> 3). It seems some similar protocol=E2=80=99s YANG model has the same def= inition, >> e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99, >> https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf. >> >> Agreed packet loss is important, however another important loss metric i= s >> loss burst size (max/min) and number of loss bursts. A loss burst of 10 >> consecutive TWAMP-test packets can be deemed more serious than 10 lost >> packets spread evenly over the report interval. >> >> GIM>> Indeed, packet loss more often expressed as packet loss ratio >> rather than as the absolute number. It would be most helpful to hear fro= m >> network operators if they see introduction of Packet Loss Ratio into the >> TWAMP model helpful. >> >> *2. Add a new typedef: state-mode. It defines a common type for >> stateful/stateless reflector. This type will be used in both sender sess= ion >> and reflector session.* >> >> Consideration: >> >> If the reflector is stateful, the TWAMP light can measure more items, >> e.g. one way packet loss. So for sender, the stats calculation and show = is >> different. When the reflector is stateless, it doesn=E2=80=99t need to c= alculate >> the one way packet loss. The one way packet loss is invalid and shouldn= =E2=80=99t >> be presented to customer. When the reflector is stateless, the sender ne= eds >> to calculate the one way packet loss. And the data should be present to >> customer. So this is used as a =E2=80=98when=E2=80=99 condition in the m= odel=E2=80=99s RO tree. >> >> GIM>> Yes, if Session-Sender is aware of the mode corresponding >> Session-Reflector operates, the sender may avoid calculation of some >> performance metrics, e.g., one-way packet loss. On the other hand, the >> orchestrator is aware of the state-mode and should be capable to properl= y >> use metrics reported by the Session-Sender. >> >> [WEI>>] Yes, the orchestrator could know that. But from the model side, >> this is not correct. The model should represent the right behavior and >> shouldn=E2=80=99t do assumption on orchestrator. >> >> I agree the model should describe both one-way loss metrics and roundtri= p >> loss metrics, and the sender should be able to use either mode when >> calculating, potentially also populating the roundtrip delay values with >> proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that >> would indicate buffer load/CPU load in the TWAMP responders processing t= ime. >> >> *3. Add a new typedef: send-mode. This is a new type for sender session. >> It makes the sender session can send packet continuously and monitor the >> network all the time.* >> >> Consideration: >> >> The user case is that: the user runs TWAMP light sessions to watch links >> quality continuously. The session number could be very big. These TWAMP >> sessions are managed by SLA framework or similar. SLA retrieves the stat= s >> from TWAMP periodically, e.g. 15mins. In other words, all the performanc= e >> metrics are calculated based on the packets sent/received within 15mins. >> This makes the calculation become possible. With the periodical stats da= ta, >> the Network Management software can do further actions if some abnormal >> stats observed. This is a more general user case in customer site. Whil= e >> the non-continuous TWAMP sender session is generally used for debugging >> purpose on a link. >> >> GIM>> I think that support of continuous measurement is in LMAP domain, >> not for TWAMP Test data model. To conduct continuous measurement he LMAP >> Controller, in my opinion, programs the Measurement Agent to perform TWA= MP >> Test session with certain set of parameters and repeat it without any >> interval (interval =3D 0). >> >> >> >> Many operators use TWAMP in continous mode, not only with Accedian test >> points and report at fixed intervals, typically ranging from 5s to 5 or = 15 >> minutes, with 1-minute being the most popular granularity currently. The >> advantage is that the result calculation can be handled separately from = the >> TWAMP-test sending/recieving, so that there is no parallelism required t= o >> monitor 24/7. If a start-stop-based methodology is used, the sender need= s >> to start up the new test session even before the previous one has ended, >> since the previous session needs to wait X seconds (or at least Y 100s o= f >> milliseconds) before it stops waiting for packets to come back. And this >> new session needs to have a different signature in order for the sender = to >> discern which packets belong to the previous interval and which belong t= o >> the current. >> >> >> >> In a continous test-model, the sender can just simply record the sequenc= e >> number of the last packet transmitted in the interval to be reported, wa= it >> for it to come back, or a MAXTIME, then report that result, while >> continuing to transmit for the next interval. >> >> >> >> If the "interval=3D=3D0" parameter is intended to be used for continous = type >> tests, then what parameter should indicate to the sender at what interva= ls >> to produce results? >> >> *4. Add a new group: packet-loss-statistics. It grouping two packet loss >> statistics: loss-count and loss-ratio. This group will be used in RO sta= ts >> tree.* >> >> GIM>> I'd like to continue discussion. >> >> [WEI>>] OK. >> >> *5. Move leaf dscp out from grouping session-light-parameters. The leaf >> dscp is only valid when the dscp-handling-mode is use-configured-value. = A >> when condition shall be added to it. So it can=E2=80=99t be in this grou= p.* >> >> GIM>> I'm concerned that then the model will not be able to support >> concurrent TWAMP Test sessions between the same pair of Test Points (IP >> address+port number) at different CoS markings. >> >> [WEI>>] Actually, I have concern on using five tuple(IP address+port >> number+dscp) to identify a TWAMP test session. The DSCP is not a constan= t >> value in packet. It could be modified by the routers in the path. For >> example, the sender has two sessions: session A=E2=80=99s five tuple is: >> Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2. = Session B=E2=80=99s >> five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D5000= 1, >> DSCP=3Dcs3. The only difference between session A and session B is DSCP.= If >> the test packet=E2=80=99s DSCP of session B is modified to cs2 by a rout= er in the >> path. The five tuples are exactly the same for reflector. It can=E2=80= =99t >> differentiate which packet is from session A, which packet is from sessi= on >> B. It could mess the reflector=E2=80=99s session sequence number. And al= so, the >> sender will be messed because the received reply packet=E2=80=99s five t= uple are >> exactly the same. >> >> So I think it=E2=80=99s more reasonable to use four tuple to identify a = session. >> >> >> >> Yes, this would be appreciated by users. Changes in DSCP is a reasonably >> common network error that users can detect with continous TWAMP monitori= ng, >> thus it is good to not include the DSCP value as part of the "session >> identifiier" but instead use 4-tuple with UDP source port to identify >> several parallel flows between the same sender and responder. >> >> *6. Add leaf 'session-packet-send-mode' to >> /twamp-light/twamp-light-session-sender/test-session*. This leaf specifi= es >> the sender session's packet send mode: continuous or non-continuous.* >> >> GIM>> As discussed in #3, I think that it is already part of LMAP YANG >> model. >> >> *7. Add leaf 'reflector-light-mode-state' to >> /twamp-light/twamp-light-session-sender/test-session*. This leaf indicat= es >> the the reflector's mode: stateful or stateless. If the reflector's mode= is >> stateful. Two one way packet loss statistics can be got: >> one-way-packet-loss-far-end, one-way-packet-loss-near-end.* >> >> Consideration: >> >> Only valid data should be presented to user. Otherwise it could >> misleading user in some cases. >> >> GIM>> A in response to #2. >> >> *8. Modify leaf >> /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. >> Add a 'when' condition to this leaf. When send-mode is 'continuous', the >> leaf number-of-packets is meaningless. So add a 'when' condition to limi= t >> it. Besides, added a default value =E2=80=9810=E2=80=99 to it. When the= send-mode is >> 'non-continuous', the session can't work with an empty number-of-packets= .* >> >> GIM>> As I've noted in #3. Will add default. >> >> *9. Add leaf time out to >> /twamp-light/twamp-light-session-sender/test-session*. A timeout mechani= sm >> is needed when the sender session can't get all the reply packets for a >> long time.* >> >> GIM>> Thank you, will add in the next update. >> >> *10. Modify leaf >> /twamp-light/twamp-light-session-sender/test-session*/interval. Change t= he >> units from =E2=80=98microseconds=E2=80=99 to =E2=80=98milliseconds=E2=80= =99. Add a default value 1000. * >> >> Consideration: >> >> 1). The aim of TWAMP is to measure network quality, but not fast >> failure detection. So a millisecond packet interval is enough. >> >> 2). Interval is a necessary parameter for a session. A sender sessio= n >> can't work with an empty packet send interval. So added a default value = to >> it. >> >> GIM>> Thank you. We've made units of interval microseconds in the last >> update already. I think that changing to milliseconds may be too >> restrictive, limit use cases for TWAMP Test. Will add default value with >> the next update. >> >> [WEI>>] Sorry, I do not see the reason. Are there any user cases to use >> microseconds? >> >> *11. Add leaf 'dscp' to >> /twamp-light/twamp-light-session-sender/test-session*. This is the leaf >> moved out from grouping session-light-parameters.* >> >> GIM>> As noted in response #5, the change may limit ability to run >> concurrent TWAMP Test sessions per CoS. I consider that to be valuable m= ode >> but would like to hear from network operators if that is indeed useful >> information. >> >> >> >> See my comment above. I argue that it is useful to keep track of changin= g >> DSCP values, and treating DSCP as a metric of the TWAMP Session just lik= e >> loss and delay >> >> *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and >> 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to >> /twamp-light/twamp-light-session-reflector/test-session*. These three >> attributes should be session specific. Different session could have >> different values. They are not common attributes.* >> >> GIM>> Agree, will make it in the next update. >> >> *13. Add leaf 'dscp' to >> /twamp-light/twamp-light-session-reflector/test-session*. This is the le= af >> moved out from grouping session-light-parameters. Besides the movement, >> added a 'when' condition to the leaf 'dscp'. This leaf is only valid whe= n >> the dscp-handling-mode is 'use-configured-value'.* >> >> GIM>> As response to #5. >> >> *14. Modify leaf >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats/number-of-packets. >> Add a 'when' condition to this leaf. When send-mode is 'continuous', the >> leaf number-of-packets is meaningless.* >> >> GIM>> Similar to #3. >> >> *15. Modify leaf >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats/interval. >> Change the units from microseconds to milliseconds.* >> >> GIM>> I think that microseconds is reasonable. >> >> *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and >> 'one-way-packet-loss-near-end' to >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats/. >> These are the new statistics for stateful reflector.* >> >> GIM>> Thank you, will be coming in the next update. >> >> *17. Remove leaf loss-packet in >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats. >> The loss packeted is replaced with 'two-way-packet-loss' stated above.* >> >> GIM>> Agree. >> >> *18. Modify leaf to >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= history-stats*/interval. >> Change the units from microseconds to milliseconds.* >> >> GIM>> I think that will limit applicability of TWAMP Test. >> >> *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and >> 'one-way-packet-loss-near-end' to >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= history-stats*/. >> These are the new statistics for stateful reflector.* >> >> GIM>> Agree. >> >> >> >> Thanks, >> >> Wei Luo >> >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> >> >> >> >> -- >> >> >> >> [image: Accedian.com] >> >> *Henrik Nydell* >> >> Sr Manager Global Strategy & Solutions >> >> >> >> *Cell* >> >> *Email* >> >> *Skype* >> >> *+46 709845992 <+46%2070%20984%2059%2092>* >> >> *hnydell@accedian.com * >> >> *h nydell* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Avis de confidentialit=C3=A9 >> >> Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce >> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g= =C3=A9es par le >> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclu= sif de son ou de >> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur= et en d=C3=A9truire tout >> exemplaire. De plus, il vous est strictement interdit de le divulguer, d= e >> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. >> Merci. >> >> Confidentiality notice >> >> This e-mail message and any attachment hereto contain confidential >> information which may be privileged and which is intended for the exclus= ive >> use of its addressee(s). If you receive this message in error, please >> inform sender immediately and destroy any copy thereof. Furthermore, any >> disclosure, distribution or copying of this message and/or any attachmen= t >> hereto without the consent of the sender is strictly prohibited. Thank y= ou. >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> >> >> >> >> >> >> -- >> >> >> >> [image: Accedian.com] >> >> *Henrik Nydell* >> >> Sr Manager Global Strategy & Solutions >> >> >> >> *Cell* >> >> *Email* >> >> *Skype* >> >> *+46 709845992 <+46%2070%20984%2059%2092>* >> >> *hnydell@accedian.com * >> >> *h nydell* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Avis de confidentialit=C3=A9 >> >> Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce >> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g= =C3=A9es par le >> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclu= sif de son ou de >> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur= et en d=C3=A9truire tout >> exemplaire. De plus, il vous est strictement interdit de le divulguer, d= e >> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. >> Merci. >> >> Confidentiality notice >> >> This e-mail message and any attachment hereto contain confidential >> information which may be privileged and which is intended for the exclus= ive >> use of its addressee(s). If you receive this message in error, please >> inform sender immediately and destroy any copy thereof. Furthermore, any >> disclosure, distribution or copying of this message and/or any attachmen= t >> hereto without the consent of the sender is strictly prohibited. Thank y= ou. >> > > > > -- > > > [image: Accedian.com] > > Henrik Nydell > > Sr Manager Global Strategy & Solutions > > Cell > > Email > > Skype > > +46 709845992 <+46%2070%20984%2059%2092> > > hnydell@accedian.com > > h nydell > > > > > > > > > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > --001a113cf63e4c30d0054d90d78d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Henrik,
your comments and suggestions that reflect = practical experience of TWAMP deployment in network operation is the most v= aluable, thank you.
We need to take a closer look at how to suppo= rt the percentile. As you've suggested, operator may have option to con= figure percentile for each performance metric you've listed with defaul= t values for the set being 95, 99, and 99.9. That might give the flexibilit= y and avoid extra configuration if the default values are acceptable. What = do you think? And I wonder whether very low percentile levels have any prac= tical use. Consider the following:
=C2=A0 =C2=A0typedef perc= entile {
=C2=A0 =C2=A0 type decimal64 {
=C2=A0 =C2=A0 fraction-= digits 1;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 description "Percent= ile";
=C2=A0 =C2=A0}

grouping= twamp-session-percentile {
=C2=A0 =C2=A0description "Percen= tile grouping";
=C2=A0 =C2=A0leaf first-percentile {
=C2=A0 =C2=A0 =C2=A0 type percentile {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 range "90.0 ... 99.9";
=C2=A0 =C2=A0 =C2= =A0 }
=C2=A0 =C2=A0 =C2=A0 default 95.0;
=C2=A0 =C2= =A0 =C2=A0 description "";
=C2=A0 =C2=A0}
=C2=A0 =C2=A0leaf second-percentile {
=C2=A0 =C2=A0 =C2=A0 type= percentile {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 range "90.0= ... 99.9";
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 = =C2=A0 default 99.0;
=C2=A0 =C2=A0 =C2=A0 description ""= ;;
=C2=A0 =C2=A0}
=C2=A0 =C2=A0leaf third-pe= rcentile {
=C2=A0 =C2=A0 =C2=A0 type percentile {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 range "90.0 ... 99.9";
= =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 default 99.9;
=C2=A0 =C2=A0 =C2=A0 description "";
=C2=A0 =C2= =A0}
}

Best regards,
Gre= g

On W= ed, Apr 19, 2017 at 12:43 AM, Henrik Nydell <hnydell@accedian.com= > wrote:
Pleas= e see my clarifications inline

Thanks
Henrik

On Wed, Apr 19, 2017 at 3:24 AM, Wei Luo S <wei.s.luo@ericsson.= com> wrote:

Please see my comments inline.

=C2=A0

Thanks,

Wei Luo

=C2=A0

From: Henrik Nydell [mailto:hnydell@accedian.com]
Sent: Tuesday, April 18, 2017 7:59 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Wei Luo S <wei.s.luo@ericsson.com>; draft-mirsky-ippm-t= wamp-light-yang@tools.ietf.org; ippm@ietf.org
Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07

=C2=A0

I would ask you to consider adding some more valuabl= e metrics

1) Loss burst size max

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 leaf loss-burst-max {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type int32;<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Highest number of lo=
st packets back-to-back during interval.";
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0}

[WEI] Agree, it=E2=80=99s valuable, I think we shoul= d add it. Besides, I suggest to add one more metrics: loss-burst-min, which= is the minimum =C2=A0number of lost packets back-to-back during interval.<= /p>


=C2=A0[H= N] I Agree loss-burst-min is also an important metric for gap analysis

=C2=A0

2) Loss burst count (tells how many instances there = was of packet loss during an interval, one "instance" means one o= r more consecutive packets lost.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 leaf loss-burst-count {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type int32;<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Number of occasion=
s with packet loss during interval.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 }

=C2=A0

To further explain the above metrics, consider 60-se= cond interval below with 1 packet per second monitoring, where x means lost= packet and o means recieved.

=C2=A0

= 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 60s

= oooXooXooooXXXXooooooooooXXoooooXoooXooooooooXXXXXXXXXXXXooo=

=C2=A0

This 60s-interval has 22 lost packets ( 22/60 =3D36.= 67% loss)

Loss burst max is 12 packets, number of loss instanc= es are 7

=C2=A0

[WEI] Agree. It should be added. For stateful reflec= tor, two more metrics can be added: loss-burst-count-far-end, loss-burst-co= unt-near-end.

=C2=A0

3) Percentiles are very useful and important. If the= y cannot be "configurable" in the Yang model I would suggest you = to consider adding at least the 95th, 99th and 99.9th percentiles for all d= elay type metrics.=C2=A0

[WEI] Could you explain the meaning of =E2=80=9Cperc= entile=E2=80=9D here?


[HN] Instead of just reporting the min/max/avg values;
<= div>
=
+--ro one-way-delay-far-end
       |     |  |  +--ro delay
       |     |  |  |  +--ro min?   yang:gauge32
       |     |  |  |  +--ro max?   yang:gauge32
       |     |  |  |  +--ro avg?   yang:gauge32
       |     |  |  +--ro delay-variation
       |     |  |     +--ro min?   uint32
       |     |  |     +--ro max?   uint32
       |     |  |     +--ro avg?   uint32

A = percentile gives more granularity. Percentile 95 for delay means that out o= f all samples in the interval, if you remove the 5% highest, then the next = largest delay value is p95. So a delay value of 23.412ms at p95 means that = 95% of the delay samples during the interval were lower than or equal to 23= .412ms.

Using percentiles allows for filtering out= spikes, instead reporting on "bulk" delay during an interval. Es= peccially useful for SLA/SLO-based monitoring where you do not necessarily = want to raise an alarm on a max spike that was caused by a single packet be= ing delayed, but instead look at percentile 95 or 99 or 99.5 depending on w= hat resolution you want.

Many protocols and functi= ons use a percentile so define in which range the protocol or function oper= ates well. One example is from the mobile world, where Ericsson and others = define the RAN requirements in terms of delay and delay variation with perc= entiles. I.e it is OK that a few packets break the delay limit, as long as = 99% don't (p99).

Many operators use continous = TWAMP monitoring with quite high packet rates, like 50 packets per second. = With 60 second interval reporting, this means 3,000 samples per interval, g= iving plenty of room to calculate 99.9 percentile (removing 3 highest sampl= es out of the 3,000)

For a standardized Yang model= the best would of course be if these percentiles were not statically defin= ed, but could be configurable depending on what the user wants to see. For = sake of simpicity I think three definable percentiles would be sufficient.<= /div>
percentile-a [0.1 .. 99.9]
percentile-b [0.1 .. 99= .9]
percentile-c [0.1 .. 99.9]

And these three then reported (if implemented= by the TWAMP sender) for both roundtrip, far-end and near-end. and for bot= h delay and delay-variation metrics.

<= /div>

=C2=A0

<= u>

=C2=A0

=C2=A0

On Thu, Apr 13, 2017 at 6:53 PM, Greg Mirsky <gregimirsky@gmail.c= om> wrote:

Dear All,

the new update of the TWAMP-Lig= ht YANG model=C2=A0has been published. It includes the following:

  • packet loss ratio as decimal64 type with fraction-size 5;
  • session-reflector state parameter in session-sender container;
  • defined continuous and periodic modes to execute a test session and how per= formance metrics are calculated in each of the modes;
    • reporting of one-way packet loss metrics, both near-end and far-end, has de= pendency of reflector's mode.

Some questions still being discussed and we greatly = appreciate suggestions, comments:

  • include percentile in delay and delay-variation containers?
  • default value for session-timeout in session-sender container is 900 second= s. Seems too big. What may be practical? Change units from seconds to centi= seconds or milliseconds?

Regards,

Greg

=C2=A0

On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell <<= a href=3D"mailto:hnydell@accedian.com" target=3D"_blank">hnydell@accedian.c= om> wrote:

Some comments from the "field" as Accedian= has several hundred thousand TWAMP sessions running (continously) at numer= ous Tier one mobile/fixed operators globally.

=C2=A0

On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S <wei.s.luo@ericsson.= com> wrote:

Hi Greg,

=C2=A0

Thanks a lot for your response. Please see my reply inline tagged= [WEI>>].

=C2=A0

Regards,

Wei Luo

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, March 21, 2017 1:16 AM
To: Wei Luo S <wei.s.luo@ericsson.com>
Cc: ippm@ietf.org= ; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org
Subject: Re: Some though on draft-mirsky-ippm-twamp-light-yang-= 07

=C2=A0

Hi Wei Luo,

many thanks for your thorough review and the most he= lpful comments to the TWAMP Light(Test) model. Please find my answers, note= s in-line tagged GIM>>.

=C2=A0

Regards,

Greg

=C2=A0

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.c= om> wrote:

Hi Greg & Adrian,

=C2=A0

This is Wei Luo from Ericsson. I work on TWAMP light= area in Ericsson. The current TWAMP Light YANG model is well defined. Than= ks for your great job.

But by working closely with our customers, we got so= me new user cases on TWAMP light. I believe these user cases are valuable a= nd popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor =C2=A0and co-work with you move this draft f= orward.=C2=A0

I =C2=A0drafted a new version of the TWAMP light YAN= G model based on version ietf-= twamp-light@2017-02-13.yang. Could you please comments on it? Any = discussion is welcome.

The draft yang model and tree is attached. To make y= ou find the updates quickly, I highlighted all the updates in fil= e ietf-twamp-light-weiluo.pdf.

=C2=A0

The following are the list of main updates:

1. Add a new typedef: percent. This is a new type= defined for packet loss ratio.

Consideration:

1). From the customer perspective, packet loss ratio is a more meaningful d= ata. In most of the time, the absolute number is meaningless to user, espec= ially they do the TWAMP test continuously. They are more care about the rat= io than the absolute number. So adding it makes this model more friendly to customer;

2). From the service layer assurance(SLA) perspective, the packet loss rati= o is a major measures. So with adding packet loss ratio in model, the TWAMP= can work in SLA framework more smoothly.

3). It seems some similar protocol=E2=80=99s YANG model has the same defini= tion, e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99= , https://www.mef.net/Assets/Technical_= Specifications/PDF/MEF_39.pdf.

Agreed packet loss is important, however another imp= ortant loss metric is loss burst size (max/min) and number of loss bursts. = A loss burst of 10 consecutive TWAMP-test packets can be deemed more seriou= s than 10 lost packets spread evenly over the report interval.

GIM>> Indeed, packet loss more often expressed= as packet loss ratio rather than as the absolute number. It would be most = helpful to hear from network operators if they see introduction of Packet Loss Ratio into the TWAMP model helpful.

2. Add a new typedef: state-mode. It defines a co= mmon type for stateful/stateless reflector. This type will be used in both = sender session and reflector session.

Consideration:

If the reflector is stateful, the TWAMP light can me= asure more items, e.g. one way packet loss. So for sender, the stats calcul= ation and show is different. When the reflector is stateless, it doesn=E2=80=99t need to calculate the one way packet loss. T= he one way packet loss is invalid and shouldn=E2=80=99t be presented to cus= tomer. When the reflector is stateless, the sender needs to calculate the o= ne way packet loss. And the data should be present to customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree.

GIM>> Yes, if Session-Sender is aware of the m= ode corresponding Session-Reflector operates, the sender may avoid calculat= ion of some performance metrics, e.g., one-way packet loss. On the other hand, the orchestrator is aware of the state-mode and should = be capable to properly use metrics reported by the Session-Sender.

[WEI&= gt;>] Yes, the orchestrator could know that. But from the model side, th= is is not correct.=C2=A0 The model should represent the right behavior and shouldn=E2=80=99t do assumption on orchestrator.

I agree the model should describe both one-way loss = metrics and roundtrip loss metrics, and the sender should be able to use ei= ther mode when calculating, potentially also populating the roundtrip delay= values with proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that would indicate buffer l= oad/CPU load in the TWAMP responders processing time.

3. Add a new typedef: send-mode. This is a new ty= pe for sender session. It makes the sender session can send packet continuo= usly and monitor the network all the time.

Consideration:

The user case is that: the user runs TWAMP light ses= sions to watch links quality continuously. The session number could be very= big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. = In other words, all the performance metrics are calculated based on the pac= kets sent/received within 15mins. This makes the calculation become possibl= e. With the periodical stats data, the Network Management software can do further actions if some abnormal st= ats observed.=C2=A0 This is a more general user case in customer site. Whil= e the non-continuous TWAMP sender session is generally used for debugging p= urpose on a link. =C2=A0

GIM>> I think that support of continuous measu= rement is in LMAP domain, not for TWAMP Test data model. To conduct continu= ous measurement he LMAP Controller, in my opinion, programs the Measurement Agent to perform TWAMP Test session with certain set of pa= rameters and repeat it without any interval (interval =3D 0).=

=C2=A0

Many operators use TWAMP in continous mode, not only= with Accedian test points and report at fixed intervals, typically ranging= from 5s to 5 or 15 minutes, with 1-minute being the most popular granulari= ty currently. The advantage is that the result calculation can be handled separately from the TWAMP-test sendi= ng/recieving, so that there is no parallelism required to monitor 24/7. If = a start-stop-based methodology is used, the sender needs to start up the ne= w test session even before the previous one has ended, since the previous session needs to wait X seconds (or at l= east Y 100s of milliseconds) before it stops waiting for packets to come ba= ck. And this new session needs to have a different signature in order for t= he sender to discern which packets belong to the previous interval and which belong to the current.=

=C2=A0

In a continous test-model, the sender can just simpl= y record the sequence number of the last packet transmitted in the interval= to be reported, wait for it to come back, or a MAXTIME, then report that r= esult, while continuing to transmit for the next interval.

=C2=A0

If the "interval=3D=3D0" parameter is inte= nded to be used for continous type tests, then what parameter should indica= te to the sender at what intervals to produce results? =C2=A0=

4. Add a new group: packet-loss-statistics. It gr= ouping two packet loss statistics: loss-count and loss-ratio. This group wi= ll be used in RO stats tree.

GIM>> I'd like to continue discussion.=C2= =A0

[WEI>>] OK.

5. Move leaf dscp out from grouping session-light= -parameters. The leaf dscp is only valid when the dscp-handling-mode is use= -configured-value. A when condition shall be added to it. So it can=E2=80=99t be in this group.

GIM>> I'm concerned that then the model wi= ll not be able to support concurrent TWAMP Test sessions between the same p= air of Test Points (IP address+port number) at different CoS markings.=C2=A0

[WEI&= gt;>] Actually, I have concern on using five tuple(IP address+port numbe= r+dscp) to identify a TWAMP test session. The DSCP is not a constant value in packet. It could be modified by the routers in the pat= h. For example, the sender has two sessions: session A=E2=80=99s five tuple= is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2= . Session B=E2=80=99s five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs3. The only difference between sess= ion A and session B is DSCP. If the test packet=E2=80=99s DSCP of session B= is modified to cs2 by a router in the path. The five tuples are exactly th= e same for reflector. It can=E2=80=99t differentiate which packet is from session A, which packet is from session B. It could mess th= e reflector=E2=80=99s session sequence number. And also, the sender will be= messed because the received reply packet=E2=80=99s five tuple are exactly = the same.

So I = think it=E2=80=99s more reasonable to use four tuple to identify a session.=

=C2=A0

Yes, this would be appreciated by users. Changes in = DSCP is a reasonably common network error that users can detect with contin= ous TWAMP monitoring, thus it is good to not include the DSCP value as part= of the "session identifiier" but instead use 4-tuple with UDP source port to identify several parallel flow= s between the same sender and responder.=C2=A0

6. Add leaf 'session-packet-send-mode' to= /twamp-light/twamp-light-session-sender/test-session*. This leaf spec= ifies the sender session's packet send mode: continuous or non-continuo= us.

GIM>> As discussed in #3, I think that it is a= lready part of LMAP YANG model.=C2=A0

7. Add leaf 'reflector-light-mode-state' = to /twamp-light/twamp-light-session-sender/test-session*. This leaf in= dicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can b= e got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.

Consideration: =C2=A0

Only valid data should be presented to user. Otherwi= se it could misleading user in some cases.

GIM>> A in response to #2.=C2=A0=

8. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. Add a 'when' condi= tion to this leaf. When send-mode is 'continuous', the leaf number-= of-packets is meaningless. So add a 'when' condition to limit it.=C2=A0 Besid= es, added a default value =E2=80=9810=E2=80=99 to it. When the send-mode is= 'non-continuous', the session can't work with an empty number-= of-packets.

GIM>> As I've noted in #3. Will add defaul= t.=C2=A0

9. Add leaf time out to /twamp-light/twamp-light-= session-sender/test-session*. A timeout mechanism is needed when the s= ender session can't get all the reply packets for a long time.

GIM>> Thank you, will add in the next update.= =C2=A0

10. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/interval. Change the units from =E2=80=98mic= roseconds=E2=80=99 to =E2=80=98milliseconds=E2=80=99. Add a default value 1= 000.

Consideration:

=C2=A0=C2=A0=C2=A0 1). The aim of TWAMP is to measur= e network quality, but not fast failure detection. So a millisecond packet = interval is enough.

=C2=A0=C2=A0=C2=A0 2). Interval is a necessary param= eter for a session. A sender session can't work with an empty packet se= nd interval. So added a default value to it.

GIM>> Thank you. We've made units of inter= val microseconds in the last update already. I think that changing to milli= seconds may be too restrictive, limit use cases for TWAMP Test. Will add default value with the next update.

[WEI&= gt;>] Sorry, I do not see the reason. Are there any user cases to use mi= croseconds?

11. Add leaf 'dscp' to /twamp-light/twamp= -light-session-sender/test-session*. This is the leaf moved out from g= rouping session-light-parameters.

GIM>> As noted in response #5, the change may = limit ability to run concurrent TWAMP Test sessions per CoS. I consider tha= t to be valuable mode but would like to hear from network operators if that is indeed useful information.=C2=A0

=C2=A0

See my comment above. I argue that it is useful to k= eep track of changing DSCP values, and treating DSCP as a metric of the TWA= MP Session just like loss and delay=C2=A0

12. Move leaves 'ref-wait', 'reflecto= r-light-mode-state' and 'dscp-handling-mode' from /twamp-light/= twamp-light-session-reflector to /twamp-light/twamp-light-session= -reflector/test-session*. These three attributes should be session specific. Different session could= have different values. They are not common attributes.

GIM>> Agree, will make it in the next update.= =C2=A0

13. Add leaf 'dscp' to /twamp-light/twamp= -light-session-reflector/test-session*. This is the leaf moved out fro= m grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only v= alid when the dscp-handling-mode is 'use-configured-value'.<= /u>

GIM>> As response to #5.=C2=A0

14. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/number-= of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.

GIM>> Similar to #3.=C2=A0

15. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/interva= l. Change the units from microseconds to milliseconds.

GIM>> I think that microseconds is reasonable.= =C2=A0

16. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/current-stats/. These are the new statistics for stateful reflector.

GIM>> Thank you, will be coming in the next up= date.=C2=A0

17. Remove leaf loss-packet in /twamp-light-state= /twamp-light-session-sender-state/test-session-state*/current-sta= ts. The loss packeted is replaced with 'two-way-packet-loss' stated above.

GIM>> Agree.=C2=A0

18. Modify leaf to /twamp-light-state/twamp-light= -session-sender-state/test-session-state*/history-stats*/int= erval. Change the units from microseconds to milliseconds.

GIM>> I think that will limit applicability of= TWAMP Test.=C2=A0

19. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/history-stats*/. These are the new statistics for stateful reflector.

GIM>> Agree.

=C2=A0

Thanks,

Wei Luo

=C2=A0


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



=C2=A0

--

=C2=A0=

3D=

Henrik Nydell

Sr Manager Global Strategy & Solutions<= /span>

=C2=A0=

Cell=

Email

Skype

+46 709845992

hnydell@accedian.com

h<= /span>nydell

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0=

=C2=A0

=C2=A0

Avis de confidentialit=C3= =A9

Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

Confidentiality notice

This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.


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

=C2=A0



=C2=A0

--

=C2=A0=

3D=

Henrik Nydell

Sr Manager Global Strategy & Solutions<= /span>

=C2=A0=

Cell=

Email

Skype

+46 709845992<= /span>

hnydell@accedian.com

h<= /span>nydell

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0=

=C2=A0

=C2=A0

Avis de confidentialit=C3= =A9

Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

Confidentiality notice

This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.




--
=


<= tbody><= /tbody>

3D"Accedian.=

Henrik Nyd= ell

Sr Manager Global Strategy & Solutions


= <= /table>

=C2=A0 =C2=A0<= /a> =C2= =A0 =C2=A0




Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

--001a113cf63e4c30d0054d90d78d-- From nobody Thu Apr 20 00:22:54 2017 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 D5D07129440; Thu, 20 Apr 2017 00:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 nAU1SvE1LlWQ; Thu, 20 Apr 2017 00:22:51 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1171288B8; Thu, 20 Apr 2017 00:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1492672970; x=1524208970; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Mv0XOnAWXLA4WNKW5Ticc6yykjV/0HArAcJvJJF9S0M=; b=8R++7fASgjV40bCfoi/Q0X+wFBZ1iA/8a1vjtHhSzPI5gE8BMK/EWKwg xIFq9rVy4Udq/Pqqe76AoNkCcWBDuUYEIneW3JSK+3zBCsC7Ytl6w096N SBPZ6FcwnHmXA4IC/2cfhKhv9TkKjujCbvCNOSflMqyZVAX2XVFFfSIQq Cg3iB7L4Gq7AZ2YX5nihdT2D1aiaBY/3eGnoBb6TRSiYIZm1GljOzMnsr gLHQqLizC/b/suEtKPAuIQE1mX4htc0VAqajh+Wi7PfMpr1xxNWKYb841 E/MN3ILHooGMf+RsT6qWy70dNKZxDRvafXchUej7UBvRFvUmkaEboICFw A==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT21.telekom.de with ESMTP/TLS/RC4-SHA; 20 Apr 2017 09:22:43 +0200 X-IronPort-AV: E=Sophos;i="5.37,224,1488841200"; d="scan'208";a="591792051" Received: from he101654.emea1.cds.t-internal.com ([10.134.226.15]) by qde0ps.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2017 09:22:43 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101654.emea1.cds.t-internal.com (10.134.226.15) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Apr 2017 09:22:43 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Thu, 20 Apr 2017 09:22:43 +0200 From: To: CC: , , , Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ANPZAWv+5YD0yHKUp0Ir+32KGqudOAgAAD3QCAAAfSAIAAIx6AgAA2hgCAAPdoAIAAaFWAgAAcNwD//8lsgIAC5LeAgAt5d4CABF/eAIADEXMAgARQ+4CABTbyAIAAKoCA///CZvCAAQO0gIAAkNsggAC4LCA= Date: Thu, 20 Apr 2017 07:22:43 +0000 Message-ID: <69831a3f7b4b42989dc85d3f8e920843@HE101653.emea1.cds.t-internal.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.165.158] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 20 Apr 2017 07:22:53 -0000 Hi Al, IOAM parameters are not the same as private address space. Routers operate = IP addresses and an access list doesn't require detection of a type of para= meter which isn't supported. The access list controls whether values of a k= nown parameter are ok. IOAM requires detection of an unknown type of parame= ter at a domain boundary. A behavior often requested in that case is transf= er, not discard.=20 An interconnection router likely operates an access list to protect the own= domain, but interconnection routers are no firewalls (be liberal in what y= ou accept....). There are two scenarios which may worry: - IOAM-domain passes traffic to non-IOAM domain=20 or IOAM domain respectively and IOAM parameters=20 may still be present. - IOAM-domain passes traffic to non-IOAM domain=20 which passes packets containing IOAM unmodified=20 to another IOAM domain. To me, the latter is the less desirable one.=20 Regards, R=FCdiger > is a non-iOAM network operator able to detect standard ipv6 packets=20 > with iOAM extensions, if the receiving operators equipment is=20 > configured to support standard ipv6 protocol only? The pre-condition=20 > here is "non-iOAM domain" at the receiving side. My point is, if a=20 > domain isn't interested in supporting the iOAM extensions, is it=20 > obliged to operate iOAM aware equipment to detect undesired traffic at ne= twork boundaries? [ACM] No, an operator can let the traffic flow if they want. However, if operators find that their network is affected by traffic with i= OAM data from another domain, they would be justified to discard that traff= ic (as long as there is a clear domain limit expressed to iOAM protocol des= igners of the future, as Frank has suggested). [ACM] This is the same ability afforded operators by declaring BMWG address space= for isolated testing-only, or the various private network address spaces. = Plenty of Net10 traffic escapes, and operators are not obliged to drop it, = but they certainly can. From nobody Thu Apr 20 01:54:49 2017 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 D1D3812EB98; Thu, 20 Apr 2017 01:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 eq-8HtRi3HVx; Thu, 20 Apr 2017 01:54:46 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA7A12EB84; Thu, 20 Apr 2017 01:54:45 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3K8sfY5024995; Thu, 20 Apr 2017 09:54:41 +0100 Received: from 950129200 (251.129.113.87.dyn.plus.net [87.113.129.251]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3K8seuB024983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Apr 2017 09:54:41 +0100 Reply-To: From: "Adrian Farrel" To: , Cc: , References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B! 309F97543CF25F71AE7@njm texg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> <69831a3f7b4b42989dc85d3f8e920843@HE101653.emea1.cds.t-internal.com> In-Reply-To: <69831a3f7b4b42989dc85d3f8e920843@HE101653.emea1.cds.t-internal.com> Date: Thu, 20 Apr 2017 09:54:40 +0100 Message-ID: <001e01d2b9b3$bfb35050$3f19f0f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3Ooq+i0V2uDTKsntzdbDryWnJDQIGbTuQAhzFMcMCAqiNpgJZUHRiAczg8HQCom8n2QGF54TAAb4MqMABFXUytwGaPkqGAuvO8TYDDF8SAQGwfxGGArM0lpYBJhUk1wHmYm5WAY6WDkABuHd+WwEMCmhDATqmZ2qf1i6KkA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23018.005 X-TM-AS-Result: No--7.425-10.0-31-10 X-imss-scan-details: No--7.425-10.0-31-10 X-TMASE-MatchedRID: cgbqQT5W8hc4HKI/yaqRm0hEDfw/93Bu0w14HFJQjaNbPFrWoLhfEnq8 FiyB7cW91rH4Rg0AOT23bDVOqdmpGSLCoCz4vNpfw2taljzThMbu7HnTLhHZ2BeSI+j1pykvgsI JV9NWYtYP8eO9N+y3M8YuRmlLZKSC7h1xPdlpOhxKTcBICU/vrQGZ/+APXW9ks8Ugk20TKUSjxY yRBa/qJX3mXSdV7KK4OubYLCVnBVEgBwKKRHe+r/Akgk+L6DeIfejJLhUad82kawAfcONolg79A 0DdoN9KVpmhknIyKfk= Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 20 Apr 2017 08:54:48 -0000 > There are two scenarios which may worry: > > - IOAM-domain passes traffic to non-IOAM domain > or IOAM domain respectively and IOAM parameters > may still be present. This is the one where the non-iOAM router gets a packet containing iOAM data and misbehaves in some way... - crash - mis-forward (including broken ECMP) - black-hole > - IOAM-domain passes traffic to non-IOAM domain > which passes packets containing IOAM unmodified > to another IOAM domain. This is the one where the downstream domain is caused to execute behavior under the control of the upstream domain. It is clear (to me) that in both cases the downstream domain will want to protect itself (and so, to some extent, Frank is right that the operator of the downstream domain will want to take precautions), but my concern is to make it simple to take those precautions, build them into the protocols themselves, and allow innocent legacy networks to continue undisturbed in the presence of iOAM in other networks. I understand that to some extent all of this discussion goes with the encapsulation/use-cases and not with the fundamental generic encoding of iOAM data. However, I think that the question applies to all applications of iOAM and so clear statements in the base document are necessary. Adrian From nobody Fri Apr 21 07:18:11 2017 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 CCA0F12944C for ; Fri, 21 Apr 2017 07:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TRACKER_ID=1.306, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian-com.20150623.gappssmtp.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 8_4sf95HCgNK for ; Fri, 21 Apr 2017 07:18:05 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 499A3129493 for ; Fri, 21 Apr 2017 07:18:05 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id y11so64847486oie.0 for ; Fri, 21 Apr 2017 07:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S6v0H61NqXgxvVjJeGqxZWnE4ybzDjM6aa+l7zb9Rf8=; b=Bx8/P/nssdqPdvtbvOINiouoN9oaXwQRhpP7YC+i7QzMs7LrFfj1no7FIOvNNjdSOv s+nRdkYXoFfDLLxnx0mI28aRMsfmFRwGZyj3CDq/+35rGbeOt0BGlvWu8Y/z6KG0SWXe iyPP6mpTyNaw/2UNZCQpVSZWCByG/dzhjsccCcNbglTb8bTstvAEwPmnJSQPjfUM/bHY F1wv2/6/XkVtx1tbP9tPztRNfAGBHPcJ1KvZ5j7M0RvhfaNK+NaG5Ujb3cywTenMrXhH 8iF80cBYC2ufsee3woYYiXV/REknssRUMP9huAuSPlMwYtQjyxLbt2o9bcjVueQnb8oq Y+zA== 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=S6v0H61NqXgxvVjJeGqxZWnE4ybzDjM6aa+l7zb9Rf8=; b=LzFmOqzzfV5VD43kdhQrvusQn3zWubOqws7dm+p40bwt+/VFn462vlcHfQCPH/tIbu UulzukzwZF4axMfCb1YbU9sBad8ZucA1ZlX3ZvxUnDgikB7Xdmy9TJrVRMYhl4KdOvX0 2kOs8JQmjjhGpJdj4rsV7HIz+lGQleIF3s6IysPzuUtR97EEQvTiLD6ZI6G/f51sZs3q Fh/t7uviOFd+p2w9g7eIfvz15FT5HZRyMbCz3NXeXezhQC1h9Y5z5uC+PfO0KlzPfOqf 3LyZ0lsek47jPAKLx5AzE5E17sjp8M9Yo9sx7CxtzJeMMqUUacCYd1NyImletIpIazNa cu2Q== X-Gm-Message-State: AN3rC/4kX+TeQSl4bZvbS93Vp0YCZITnvBVh26LGVxoK7M22U0D2p6Ni BkgBnYQEqjrbZhx5eRlz5C+ufwtw2ljrlJyiNAZ+Nc8Jxws20GgSxk/WhNbkcHk2GcyNSDrOJw3 h X-Received: by 10.157.62.76 with SMTP id h12mr7774490otg.95.1492784284393; Fri, 21 Apr 2017 07:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.9.151 with HTTP; Fri, 21 Apr 2017 07:18:03 -0700 (PDT) In-Reply-To: References: From: Henrik Nydell Date: Fri, 21 Apr 2017 16:18:03 +0200 Message-ID: To: Greg Mirsky Cc: Wei Luo S , "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=f403045e3cf8ff7af2054dadec1d Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 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, 21 Apr 2017 14:18:10 -0000 --f403045e3cf8ff7af2054dadec1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for a late reply Greg, see my comments inline below On Thu, Apr 20, 2017 at 5:36 AM, Greg Mirsky wrote: > Hi Henrik, > your comments and suggestions that reflect practical experience of TWAMP > deployment in network operation is the most valuable, thank you. > We need to take a closer look at how to support the percentile. As you've > suggested, operator may have option to configure percentile for each > performance metric you've listed with default values for the set being 95= , > 99, and 99.9. That might give the flexibility and avoid extra configurati= on > if the default values are acceptable. What do you think? And I wonder > whether very low percentile levels have any practical use. Consider the > following: > typedef percentile { > type decimal64 { > fraction-digits 1; > } > description "Percentile"; > } > > grouping twamp-session-percentile { > description "Percentile grouping"; > leaf first-percentile { > type percentile { > range "90.0 ... 99.9"; > } > default 95.0; > description ""; > } > leaf second-percentile { > type percentile { > range "90.0 ... 99.9"; > } > default 99.0; > description ""; > } > leaf third-percentile { > type percentile { > range "90.0 ... 99.9"; > } > default 99.9; > description ""; > } > } > > [HN] I think the model could allow two decimal points, even if it (today) is unlikely that you have so many samples in an interval that it makes sense to calculate the such values (99.99%-ile) As for low percentiles, I see no reason to limit the Yang model to 90 ... 99, even though those are the by far most common ones in use. For synchronization protocols (like NTP) for example, there is often a requirement that the "lucky packets" i.e the ones with the fastest roundtrip time through the network are the ones that are important, and a specific algorithm may work properly as long as at least one out of ten packets arrive with the lowest possible roundtrip latency. To set an service level objective (threshold) for such a requirement one could use a low percentile like delay 10%, and chose to alert if the current interval is very different from the previous interval. The default values of 95, 99 and 99.9 I think makes sense. > Best regards, > Greg > > On Wed, Apr 19, 2017 at 12:43 AM, Henrik Nydell > wrote: > >> Please see my clarifications inline >> >> Thanks >> Henrik >> >> On Wed, Apr 19, 2017 at 3:24 AM, Wei Luo S >> wrote: >> >>> Please see my comments inline. >>> >>> >>> >>> Thanks, >>> >>> Wei Luo >>> >>> >>> >>> *From:* Henrik Nydell [mailto:hnydell@accedian.com] >>> *Sent:* Tuesday, April 18, 2017 7:59 PM >>> *To:* Greg Mirsky >>> *Cc:* Wei Luo S ; draft-mirsky-ippm-twamp-light= - >>> yang@tools.ietf.org; ippm@ietf.org >>> *Subject:* Re: [ippm] Some though on draft-mirsky-ippm-twamp-light- >>> yang-07 >>> >>> >>> >>> I would ask you to consider adding some more valuable metrics >>> >>> 1) Loss burst size max >>> >>> >>> >>> leaf loss-burst-max { >>> >>> type int32; >>> >>> description >>> >>> "Highest number of lost packets back-to-back during int= erval."; >>> >>> } >>> >>> [WEI] Agree, it=E2=80=99s valuable, I think we should add it. Besides, = I suggest >>> to add one more metrics: loss-burst-min, which is the minimum number o= f >>> lost packets back-to-back during interval. >>> >> >> [HN] I Agree loss-burst-min is also an important metric for gap analysi= s >> >> >>> >>> 2) Loss burst count (tells how many instances there was of packet loss >>> during an interval, one "instance" means one or more consecutive packet= s >>> lost. >>> >>> >>> >>> leaf loss-burst-count { >>> >>> type int32; >>> >>> description >>> >>> "Number of occasions with packet loss during interval."= ; >>> >>> } >>> >>> >>> >>> To further explain the above metrics, consider 60-second interval below >>> with 1 packet per second monitoring, where x means lost packet and o me= ans >>> recieved. >>> >>> >>> >>> 0 60s >>> >>> oooXooXooooXXXXooooooooooXXoooooXoooXooooooooXXXXXXXXXXXXooo >>> >>> >>> >>> This 60s-interval has 22 lost packets ( 22/60 =3D36.67% loss) >>> >>> Loss burst max is 12 packets, number of loss instances are 7 >>> >>> >>> >>> [WEI] Agree. It should be added. For stateful reflector, two more >>> metrics can be added: loss-burst-count-far-end, loss-burst-count-near-e= nd. >>> >>> >>> >>> 3) Percentiles are very useful and important. If they cannot be >>> "configurable" in the Yang model I would suggest you to consider adding= at >>> least the 95th, 99th and 99.9th percentiles for all delay type metrics. >>> >>> [WEI] Could you explain the meaning of =E2=80=9Cpercentile=E2=80=9D her= e? >>> >> >> [HN] Instead of just reporting the min/max/avg values; >> >> +--ro one-way-delay-far-end >> | | | +--ro delay >> | | | | +--ro min? yang:gauge32 >> | | | | +--ro max? yang:gauge32 >> | | | | +--ro avg? yang:gauge32 >> | | | +--ro delay-variation >> | | | +--ro min? uint32 >> | | | +--ro max? uint32 >> | | | +--ro avg? uint32 >> >> >> A percentile gives more granularity. Percentile 95 for delay means that >> out of all samples in the interval, if you remove the 5% highest, then t= he >> next largest delay value is p95. So a delay value of 23.412ms at p95 mea= ns >> that 95% of the delay samples during the interval were lower than or equ= al >> to 23.412ms. >> >> Using percentiles allows for filtering out spikes, instead reporting on >> "bulk" delay during an interval. Especcially useful for SLA/SLO-based >> monitoring where you do not necessarily want to raise an alarm on a max >> spike that was caused by a single packet being delayed, but instead look= at >> percentile 95 or 99 or 99.5 depending on what resolution you want. >> >> Many protocols and functions use a percentile so define in which range >> the protocol or function operates well. One example is from the mobile >> world, where Ericsson and others define the RAN requirements in terms of >> delay and delay variation with percentiles. I.e it is OK that a few pack= ets >> break the delay limit, as long as 99% don't (p99). >> >> Many operators use continous TWAMP monitoring with quite high packet >> rates, like 50 packets per second. With 60 second interval reporting, th= is >> means 3,000 samples per interval, giving plenty of room to calculate 99.= 9 >> percentile (removing 3 highest samples out of the 3,000) >> >> For a standardized Yang model the best would of course be if these >> percentiles were not statically defined, but could be configurable >> depending on what the user wants to see. For sake of simpicity I think >> three definable percentiles would be sufficient. >> percentile-a [0.1 .. 99.9] >> percentile-b [0.1 .. 99.9] >> percentile-c [0.1 .. 99.9] >> >> And these three then reported (if implemented by the TWAMP sender) for >> both roundtrip, far-end and near-end. and for both delay and >> delay-variation metrics. >> >> >> >> >>> >>> >>> >>> >>> On Thu, Apr 13, 2017 at 6:53 PM, Greg Mirsky >>> wrote: >>> >>> Dear All, >>> >>> the new update of the TWAMP-Light YANG model >>> has >>> been published. It includes the following: >>> >>> - packet loss ratio as decimal64 type with fraction-size 5; >>> - session-reflector state parameter in session-sender container; >>> - defined continuous and periodic modes to execute a test session >>> and how performance metrics are calculated in each of the modes; >>> - reporting of one-way packet loss metrics, both near-end and >>> far-end, has dependency of reflector's mode. >>> >>> Some questions still being discussed and we greatly appreciate >>> suggestions, comments: >>> >>> - include percentile in delay and delay-variation containers? >>> - default value for session-timeout in session-sender container is >>> 900 seconds. Seems too big. What may be practical? Change units from >>> seconds to centiseconds or milliseconds? >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell >>> wrote: >>> >>> Some comments from the "field" as Accedian has several hundred thousand >>> TWAMP sessions running (continously) at numerous Tier one mobile/fixed >>> operators globally. >>> >>> >>> >>> On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S >>> wrote: >>> >>> Hi Greg, >>> >>> >>> >>> Thanks a lot for your response. Please see my reply inline tagged >>> [WEI>>]. >>> >>> >>> >>> Regards, >>> >>> Wei Luo >>> >>> >>> >>> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >>> *Sent:* Tuesday, March 21, 2017 1:16 AM >>> *To:* Wei Luo S >>> *Cc:* ippm@ietf.org; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org >>> *Subject:* Re: Some though on draft-mirsky-ippm-twamp-light-yang-07 >>> >>> >>> >>> Hi Wei Luo, >>> >>> many thanks for your thorough review and the most helpful comments to >>> the TWAMP Light(Test) model. Please find my answers, notes in-line tagg= ed >>> GIM>>. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S >>> wrote: >>> >>> Hi Greg & Adrian, >>> >>> >>> >>> This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. >>> The current TWAMP Light YANG model is well defined. Thanks for your gre= at >>> job. >>> >>> But by working closely with our customers, we got some new user cases o= n >>> TWAMP light. I believe these user cases are valuable and popular enough= to >>> be modeled in TWAMP Light YANG. I hope I can be a contributor and co-w= ork >>> with you move this draft forward. >>> >>> I drafted a new version of the TWAMP light YANG model based on version >>> ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any >>> discussion is welcome. >>> >>> The draft yang model and tree is attached. To make you find the updates >>> quickly, I highlighted all the updates in file >>> ietf-twamp-light-weiluo.pdf. >>> >>> >>> >>> The following are the list of main updates: >>> >>> *1. Add a new typedef: percent. This is a new type defined for packet >>> loss ratio.* >>> >>> Consideration: >>> >>> 1). From the customer perspective, packet loss ratio is a more >>> meaningful data. In most of the time, the absolute number is meaningles= s to >>> user, especially they do the TWAMP test continuously. They are more car= e >>> about the ratio than the absolute number. So adding it makes this model >>> more friendly to customer; >>> >>> 2). From the service layer assurance(SLA) perspective, the packet loss >>> ratio is a major measures. So with adding packet loss ratio in model, t= he >>> TWAMP can work in SLA framework more smoothly. >>> >>> 3). It seems some similar protocol=E2=80=99s YANG model has the same de= finition, >>> e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99, >>> https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf. >>> >>> Agreed packet loss is important, however another important loss metric >>> is loss burst size (max/min) and number of loss bursts. A loss burst of= 10 >>> consecutive TWAMP-test packets can be deemed more serious than 10 lost >>> packets spread evenly over the report interval. >>> >>> GIM>> Indeed, packet loss more often expressed as packet loss ratio >>> rather than as the absolute number. It would be most helpful to hear fr= om >>> network operators if they see introduction of Packet Loss Ratio into th= e >>> TWAMP model helpful. >>> >>> *2. Add a new typedef: state-mode. It defines a common type for >>> stateful/stateless reflector. This type will be used in both sender ses= sion >>> and reflector session.* >>> >>> Consideration: >>> >>> If the reflector is stateful, the TWAMP light can measure more items, >>> e.g. one way packet loss. So for sender, the stats calculation and show= is >>> different. When the reflector is stateless, it doesn=E2=80=99t need to = calculate >>> the one way packet loss. The one way packet loss is invalid and shouldn= =E2=80=99t >>> be presented to customer. When the reflector is stateless, the sender n= eeds >>> to calculate the one way packet loss. And the data should be present to >>> customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree. >>> >>> GIM>> Yes, if Session-Sender is aware of the mode corresponding >>> Session-Reflector operates, the sender may avoid calculation of some >>> performance metrics, e.g., one-way packet loss. On the other hand, the >>> orchestrator is aware of the state-mode and should be capable to proper= ly >>> use metrics reported by the Session-Sender. >>> >>> [WEI>>] Yes, the orchestrator could know that. But from the model side, >>> this is not correct. The model should represent the right behavior and >>> shouldn=E2=80=99t do assumption on orchestrator. >>> >>> I agree the model should describe both one-way loss metrics and >>> roundtrip loss metrics, and the sender should be able to use either mod= e >>> when calculating, potentially also populating the roundtrip delay value= s >>> with proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values >>> that would indicate buffer load/CPU load in the TWAMP responders proces= sing >>> time. >>> >>> *3. Add a new typedef: send-mode. This is a new type for sender session= . >>> It makes the sender session can send packet continuously and monitor th= e >>> network all the time.* >>> >>> Consideration: >>> >>> The user case is that: the user runs TWAMP light sessions to watch link= s >>> quality continuously. The session number could be very big. These TWAMP >>> sessions are managed by SLA framework or similar. SLA retrieves the sta= ts >>> from TWAMP periodically, e.g. 15mins. In other words, all the performan= ce >>> metrics are calculated based on the packets sent/received within 15mins= . >>> This makes the calculation become possible. With the periodical stats d= ata, >>> the Network Management software can do further actions if some abnormal >>> stats observed. This is a more general user case in customer site. Whi= le >>> the non-continuous TWAMP sender session is generally used for debugging >>> purpose on a link. >>> >>> GIM>> I think that support of continuous measurement is in LMAP domain, >>> not for TWAMP Test data model. To conduct continuous measurement he LMA= P >>> Controller, in my opinion, programs the Measurement Agent to perform TW= AMP >>> Test session with certain set of parameters and repeat it without any >>> interval (interval =3D 0). >>> >>> >>> >>> Many operators use TWAMP in continous mode, not only with Accedian test >>> points and report at fixed intervals, typically ranging from 5s to 5 or= 15 >>> minutes, with 1-minute being the most popular granularity currently. Th= e >>> advantage is that the result calculation can be handled separately from= the >>> TWAMP-test sending/recieving, so that there is no parallelism required = to >>> monitor 24/7. If a start-stop-based methodology is used, the sender nee= ds >>> to start up the new test session even before the previous one has ended= , >>> since the previous session needs to wait X seconds (or at least Y 100s = of >>> milliseconds) before it stops waiting for packets to come back. And thi= s >>> new session needs to have a different signature in order for the sender= to >>> discern which packets belong to the previous interval and which belong = to >>> the current. >>> >>> >>> >>> In a continous test-model, the sender can just simply record the >>> sequence number of the last packet transmitted in the interval to be >>> reported, wait for it to come back, or a MAXTIME, then report that resu= lt, >>> while continuing to transmit for the next interval. >>> >>> >>> >>> If the "interval=3D=3D0" parameter is intended to be used for continous= type >>> tests, then what parameter should indicate to the sender at what interv= als >>> to produce results? >>> >>> *4. Add a new group: packet-loss-statistics. It grouping two packet los= s >>> statistics: loss-count and loss-ratio. This group will be used in RO st= ats >>> tree.* >>> >>> GIM>> I'd like to continue discussion. >>> >>> [WEI>>] OK. >>> >>> *5. Move leaf dscp out from grouping session-light-parameters. The leaf >>> dscp is only valid when the dscp-handling-mode is use-configured-value.= A >>> when condition shall be added to it. So it can=E2=80=99t be in this gro= up.* >>> >>> GIM>> I'm concerned that then the model will not be able to support >>> concurrent TWAMP Test sessions between the same pair of Test Points (IP >>> address+port number) at different CoS markings. >>> >>> [WEI>>] Actually, I have concern on using five tuple(IP address+port >>> number+dscp) to identify a TWAMP test session. The DSCP is not a consta= nt >>> value in packet. It could be modified by the routers in the path. For >>> example, the sender has two sessions: session A=E2=80=99s five tuple is= : >>> Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2.= Session B=E2=80=99s >>> five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D500= 01, >>> DSCP=3Dcs3. The only difference between session A and session B is DSCP= . If >>> the test packet=E2=80=99s DSCP of session B is modified to cs2 by a rou= ter in the >>> path. The five tuples are exactly the same for reflector. It can=E2=80= =99t >>> differentiate which packet is from session A, which packet is from sess= ion >>> B. It could mess the reflector=E2=80=99s session sequence number. And a= lso, the >>> sender will be messed because the received reply packet=E2=80=99s five = tuple are >>> exactly the same. >>> >>> So I think it=E2=80=99s more reasonable to use four tuple to identify a= session. >>> >>> >>> >>> Yes, this would be appreciated by users. Changes in DSCP is a reasonabl= y >>> common network error that users can detect with continous TWAMP monitor= ing, >>> thus it is good to not include the DSCP value as part of the "session >>> identifiier" but instead use 4-tuple with UDP source port to identify >>> several parallel flows between the same sender and responder. >>> >>> *6. Add leaf 'session-packet-send-mode' to >>> /twamp-light/twamp-light-session-sender/test-session*. This leaf specif= ies >>> the sender session's packet send mode: continuous or non-continuous.* >>> >>> GIM>> As discussed in #3, I think that it is already part of LMAP YANG >>> model. >>> >>> *7. Add leaf 'reflector-light-mode-state' to >>> /twamp-light/twamp-light-session-sender/test-session*. This leaf indica= tes >>> the the reflector's mode: stateful or stateless. If the reflector's mod= e is >>> stateful. Two one way packet loss statistics can be got: >>> one-way-packet-loss-far-end, one-way-packet-loss-near-end.* >>> >>> Consideration: >>> >>> Only valid data should be presented to user. Otherwise it could >>> misleading user in some cases. >>> >>> GIM>> A in response to #2. >>> >>> *8. Modify leaf >>> /twamp-light/twamp-light-session-sender/test-session*/number-of-packets= . >>> Add a 'when' condition to this leaf. When send-mode is 'continuous', th= e >>> leaf number-of-packets is meaningless. So add a 'when' condition to lim= it >>> it. Besides, added a default value =E2=80=9810=E2=80=99 to it. When th= e send-mode is >>> 'non-continuous', the session can't work with an empty number-of-packet= s.* >>> >>> GIM>> As I've noted in #3. Will add default. >>> >>> *9. Add leaf time out to >>> /twamp-light/twamp-light-session-sender/test-session*. A timeout mechan= ism >>> is needed when the sender session can't get all the reply packets for a >>> long time.* >>> >>> GIM>> Thank you, will add in the next update. >>> >>> *10. Modify leaf >>> /twamp-light/twamp-light-session-sender/test-session*/interval. Change = the >>> units from =E2=80=98microseconds=E2=80=99 to =E2=80=98milliseconds=E2= =80=99. Add a default value 1000. * >>> >>> Consideration: >>> >>> 1). The aim of TWAMP is to measure network quality, but not fast >>> failure detection. So a millisecond packet interval is enough. >>> >>> 2). Interval is a necessary parameter for a session. A sender >>> session can't work with an empty packet send interval. So added a defau= lt >>> value to it. >>> >>> GIM>> Thank you. We've made units of interval microseconds in the last >>> update already. I think that changing to milliseconds may be too >>> restrictive, limit use cases for TWAMP Test. Will add default value wit= h >>> the next update. >>> >>> [WEI>>] Sorry, I do not see the reason. Are there any user cases to use >>> microseconds? >>> >>> *11. Add leaf 'dscp' to >>> /twamp-light/twamp-light-session-sender/test-session*. This is the leaf >>> moved out from grouping session-light-parameters.* >>> >>> GIM>> As noted in response #5, the change may limit ability to run >>> concurrent TWAMP Test sessions per CoS. I consider that to be valuable = mode >>> but would like to hear from network operators if that is indeed useful >>> information. >>> >>> >>> >>> See my comment above. I argue that it is useful to keep track of >>> changing DSCP values, and treating DSCP as a metric of the TWAMP Sessio= n >>> just like loss and delay >>> >>> *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and >>> 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to >>> /twamp-light/twamp-light-session-reflector/test-session*. These three >>> attributes should be session specific. Different session could have >>> different values. They are not common attributes.* >>> >>> GIM>> Agree, will make it in the next update. >>> >>> *13. Add leaf 'dscp' to >>> /twamp-light/twamp-light-session-reflector/test-session*. This is the l= eaf >>> moved out from grouping session-light-parameters. Besides the movement, >>> added a 'when' condition to the leaf 'dscp'. This leaf is only valid wh= en >>> the dscp-handling-mode is 'use-configured-value'.* >>> >>> GIM>> As response to #5. >>> >>> *14. Modify leaf >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /current-stats/number-of-packets. >>> Add a 'when' condition to this leaf. When send-mode is 'continuous', th= e >>> leaf number-of-packets is meaningless.* >>> >>> GIM>> Similar to #3. >>> >>> *15. Modify leaf >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /current-stats/interval. >>> Change the units from microseconds to milliseconds.* >>> >>> GIM>> I think that microseconds is reasonable. >>> >>> *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' an= d >>> 'one-way-packet-loss-near-end' to >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /current-stats/. >>> These are the new statistics for stateful reflector.* >>> >>> GIM>> Thank you, will be coming in the next update. >>> >>> *17. Remove leaf loss-packet in >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /current-stats. >>> The loss packeted is replaced with 'two-way-packet-loss' stated above.* >>> >>> GIM>> Agree. >>> >>> *18. Modify leaf to >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /history-stats*/interval. >>> Change the units from microseconds to milliseconds.* >>> >>> GIM>> I think that will limit applicability of TWAMP Test. >>> >>> *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' an= d >>> 'one-way-packet-loss-near-end' to >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /history-stats*/. >>> These are the new statistics for stateful reflector.* >>> >>> GIM>> Agree. >>> >>> >>> >>> Thanks, >>> >>> Wei Luo >>> >>> >>> >>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> [image: Accedian.com] >>> >>> *Henrik Nydell* >>> >>> Sr Manager Global Strategy & Solutions >>> >>> >>> >>> *Cell* >>> >>> *Email* >>> >>> *Skype* >>> >>> *+46 709845992 <+46%2070%20984%2059%2092>* >>> >>> *hnydell@accedian.com * >>> >>> *h nydell* >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Avis de confidentialit=C3=A9 >>> >>> Les informations contenues dans le pr=C3=A9sent message et dans toute p= i=C3=A8ce >>> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9= g=C3=A9es par le >>> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage excl= usif de son ou de >>> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >>> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteu= r et en d=C3=A9truire tout >>> exemplaire. De plus, il vous est strictement interdit de le divulguer, = de >>> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2= =80=99exp=C3=A9diteur. >>> Merci. >>> >>> Confidentiality notice >>> >>> This e-mail message and any attachment hereto contain confidential >>> information which may be privileged and which is intended for the exclu= sive >>> use of its addressee(s). If you receive this message in error, please >>> inform sender immediately and destroy any copy thereof. Furthermore, an= y >>> disclosure, distribution or copying of this message and/or any attachme= nt >>> hereto without the consent of the sender is strictly prohibited. Thank = you. >>> >>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> [image: Accedian.com] >>> >>> *Henrik Nydell* >>> >>> Sr Manager Global Strategy & Solutions >>> >>> >>> >>> *Cell* >>> >>> *Email* >>> >>> *Skype* >>> >>> *+46 709845992 <+46%2070%20984%2059%2092>* >>> >>> *hnydell@accedian.com * >>> >>> *h nydell* >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Avis de confidentialit=C3=A9 >>> >>> Les informations contenues dans le pr=C3=A9sent message et dans toute p= i=C3=A8ce >>> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9= g=C3=A9es par le >>> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage excl= usif de son ou de >>> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >>> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteu= r et en d=C3=A9truire tout >>> exemplaire. De plus, il vous est strictement interdit de le divulguer, = de >>> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2= =80=99exp=C3=A9diteur. >>> Merci. >>> >>> Confidentiality notice >>> >>> This e-mail message and any attachment hereto contain confidential >>> information which may be privileged and which is intended for the exclu= sive >>> use of its addressee(s). If you receive this message in error, please >>> inform sender immediately and destroy any copy thereof. Furthermore, an= y >>> disclosure, distribution or copying of this message and/or any attachme= nt >>> hereto without the consent of the sender is strictly prohibited. Thank = you. >>> >> >> >> >> -- >> >> >> [image: Accedian.com] >> >> Henrik Nydell >> >> Sr Manager Global Strategy & Solutions >> >> Cell >> >> Email >> >> Skype >> >> +46 709845992 <+46%2070%20984%2059%2092> >> >> hnydell@accedian.com >> >> h nydell >> >> >> >> >> >> >> >> >> >> Avis de confidentialit=C3=A9 >> >> Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce >> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g= =C3=A9es par le >> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclu= sif de son ou de >> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur= et en d=C3=A9truire tout >> exemplaire. De plus, il vous est strictement interdit de le divulguer, d= e >> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. >> Merci. >> >> Confidentiality notice >> >> This e-mail message and any attachment hereto contain confidential >> information which may be privileged and which is intended for the exclus= ive >> use of its addressee(s). If you receive this message in error, please >> inform sender immediately and destroy any copy thereof. Furthermore, any >> disclosure, distribution or copying of this message and/or any attachmen= t >> hereto without the consent of the sender is strictly prohibited. Thank y= ou. >> > > --=20 [image: Accedian.com] Henrik Nydell Sr Manager Global Strategy & Solutions Cell Email Skype +46 709845992 hnydell@accedian.com h nydell --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3= =A8ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le secret=20 professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de son= ou de ses=20 destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99il= vous=20 plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en d= =C3=A9truire tout=20 exemplaire. De plus, il vous est strictement interdit de le divulguer, de= =20 le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99= exp=C3=A9diteur.=20 Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the exclusive= =20 use of its addressee(s). If you receive this message in error, please=20 inform sender immediately and destroy any copy thereof. Furthermore, any=20 disclosure, distribution or copying of this message and/or any attachment= =20 hereto without the consent of the sender is strictly prohibited. Thank you. --f403045e3cf8ff7af2054dadec1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for a late reply Greg, see my comments inline below<= div class=3D"gmail_extra">
On Thu, Apr 20, 20= 17 at 5:36 AM, Greg Mirsky <gregimirsky@gmail.com> wrote= :
Hi Henrik,
your co= mments and suggestions that reflect practical experience of TWAMP deploymen= t in network operation is the most valuable, thank you.
We need t= o take a closer look at how to support the percentile. As you've sugges= ted, operator may have option to configure percentile for each performance = metric you've listed with default values for the set being 95, 99, and = 99.9. That might give the flexibility and avoid extra configuration if the = default values are acceptable. What do you think? And I wonder whether very= low percentile levels have any practical use. Consider the following:
=C2=A0 =C2=A0typedef percentile {
=C2=A0 =C2=A0 type decimal64 {
=C2=A0 =C2=A0 fraction-digits 1;
=C2=A0 =C2=A0 }
<= div>=C2=A0 =C2=A0 description "Percentile";<= /div>
=C2=A0 =C2=A0}

grouping twamp-sess= ion-percentile {
=C2=A0 =C2=A0description "Percentile groupi= ng";
=C2=A0 =C2=A0leaf first-percentile {
=C2=A0 = =C2=A0 =C2=A0 type percentile {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 range "90.0 ... 99.9";
=C2=A0 =C2=A0 =C2=A0 }
=
=C2=A0 =C2=A0 =C2=A0 default 95.0;
=C2=A0 =C2=A0 =C2=A0 = description "";
=C2=A0 =C2=A0}
=C2=A0 = =C2=A0leaf second-percentile {
=C2=A0 =C2=A0 =C2=A0 type percenti= le {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 range "90.0 ... 99.9= ";
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 def= ault 99.0;
=C2=A0 =C2=A0 =C2=A0 description "";
=C2=A0 =C2=A0}
=C2=A0 =C2=A0leaf third-percentile {=
=C2=A0 =C2=A0 =C2=A0 type percentile {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 range "90.0 ... 99.9";
=C2=A0 =C2= =A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 default 99.9;
=C2= =A0 =C2=A0 =C2=A0 description "";
=C2=A0 =C2=A0}
<= /div>
}

[HN] I think the mo= del could allow two decimal points, even if it (today) is unlikely that you= have so many samples in an interval that it makes sense to calculate the s= uch values (99.99%-ile)

As for low percentiles, I = see no reason to limit the Yang model to 90 ... 99, even though those are t= he by far most common ones in use. For synchronization protocols (like NTP)= for example, there is often a requirement that the "lucky packets&quo= t; i.e the ones with the fastest roundtrip time through the network are the= ones that are important, and a specific algorithm may work properly as lon= g as at least one out of ten packets arrive with the lowest possible roundt= rip latency. To set an service level objective (threshold) for such a requi= rement one could use a low percentile like delay 10%, and chose to alert if= the current interval is very different from the previous interval.

The default values of 95, 99 and 99.9 I think makes sense= .=C2=A0
=C2=A0
Best regards,
Greg

On Wed, Apr 19, 2017 at 12:43 AM, Henrik Nydell &l= t;hnydell@accedia= n.com> wrote:
Please see my clarifications inline

Thanks
Henrik

On Wed, Apr 19, 2017 at 3:24 AM, Wei Luo S <wei.s.luo@ericsson.com= > wrote:

Please see my comments inline.

=C2=A0

Thanks,

Wei Luo

=C2=A0

From: Henrik Nydell [mailto:hnydell@accedian.com]
Sent: Tuesday, April 18, 2017 7:59 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Wei Luo S <wei.s.luo@ericsson.com>; draft-mirsky-ippm-t= wamp-light-yang@tools.ietf.org; ippm@ietf.org
Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07

=C2=A0

I would ask you to consider adding some more valuabl= e metrics

1) Loss burst size max

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 leaf loss-burst-max {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type int32;<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Highest number of lo=
st packets back-to-back during interval.";
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0}

[WEI] Agree, it=E2=80=99s valuable, I think we shoul= d add it. Besides, I suggest to add one more metrics: loss-burst-min, which= is the minimum =C2=A0number of lost packets back-to-back during interval.<= /p>


=C2=A0[H= N] I Agree loss-burst-min is also an important metric for gap analysis

=C2=A0

2) Loss burst count (tells how many instances there = was of packet loss during an interval, one "instance" means one o= r more consecutive packets lost.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 leaf loss-burst-count {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type int32;<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Number of occasion=
s with packet loss during interval.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 }

=C2=A0

To further explain the above metrics, consider 60-se= cond interval below with 1 packet per second monitoring, where x means lost= packet and o means recieved.

=C2=A0

= 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 60s

= oooXooXooooXXXXooooooooooXXoooooXoooXooooooooXXXXXXXXXXXXooo=

=C2=A0

This 60s-interval has 22 lost packets ( 22/60 =3D36.= 67% loss)

Loss burst max is 12 packets, number of loss instanc= es are 7

=C2=A0

[WEI] Agree. It should be added. For stateful reflec= tor, two more metrics can be added: loss-burst-count-far-end, loss-burst-co= unt-near-end.

=C2=A0

3) Percentiles are very useful and important. If the= y cannot be "configurable" in the Yang model I would suggest you = to consider adding at least the 95th, 99th and 99.9th percentiles for all d= elay type metrics.=C2=A0

[WEI] Could you explain the meaning of =E2=80=9Cperc= entile=E2=80=9D here?


[HN] Instead of just reporting the min/max/avg values;
<= div>
+--ro one-way-delay-far-end
       |     |  |  +--ro delay
       |     |  |  |  +--ro min?   yang:gauge32
       |     |  |  |  +--ro max?   yang:gauge32
       |     |  |  |  +--ro avg?   yang:gauge32
       |     |  |  +--ro delay-variation
       |     |  |     +--ro min?   uint32
       |     |  |     +--ro max?   uint32
       |     |  |     +--ro avg?   uint32

A = percentile gives more granularity. Percentile 95 for delay means that out o= f all samples in the interval, if you remove the 5% highest, then the next = largest delay value is p95. So a delay value of 23.412ms at p95 means that = 95% of the delay samples during the interval were lower than or equal to 23= .412ms.

Using percentiles allows for filtering out= spikes, instead reporting on "bulk" delay during an interval. Es= peccially useful for SLA/SLO-based monitoring where you do not necessarily = want to raise an alarm on a max spike that was caused by a single packet be= ing delayed, but instead look at percentile 95 or 99 or 99.5 depending on w= hat resolution you want.

Many protocols and functi= ons use a percentile so define in which range the protocol or function oper= ates well. One example is from the mobile world, where Ericsson and others = define the RAN requirements in terms of delay and delay variation with perc= entiles. I.e it is OK that a few packets break the delay limit, as long as = 99% don't (p99).

Many operators use continous = TWAMP monitoring with quite high packet rates, like 50 packets per second. = With 60 second interval reporting, this means 3,000 samples per interval, g= iving plenty of room to calculate 99.9 percentile (removing 3 highest sampl= es out of the 3,000)

For a standardized Yang model= the best would of course be if these percentiles were not statically defin= ed, but could be configurable depending on what the user wants to see. For = sake of simpicity I think three definable percentiles would be sufficient.<= /div>
percentile-a [0.1 .. 99.9]
percentile-b [0.1 .. 99= .9]
percentile-c [0.1 .. 99.9]

And these three then reported (if implemented= by the TWAMP sender) for both roundtrip, far-end and near-end. and for bot= h delay and delay-variation metrics.


=C2=A0

=C2=A0

=C2=A0

On Thu, Apr 13, 2017 at 6:53 PM, Greg Mirsky <gregimirsky@gmail.c= om> wrote:

Dear All,

the new update of the TWAMP-Lig= ht YANG model=C2=A0has been published. It includes the following:

  • packet loss ratio as decimal64 type with fraction-size 5;
  • session-reflector state parameter in session-sender container;
  • defined continuous and periodic modes to execute a test session and how per= formance metrics are calculated in each of the modes;
    • reporting of one-way packet loss metrics, both near-end and far-end, has de= pendency of reflector's mode.

Some questions still being discussed and we greatly = appreciate suggestions, comments:

  • include percentile in delay and delay-variation containers?
  • default value for session-timeout in session-sender container is 900 second= s. Seems too big. What may be practical? Change units from seconds to centi= seconds or milliseconds?

Regards,

Greg

=C2=A0

On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell <<= a href=3D"mailto:hnydell@accedian.com" target=3D"_blank">hnydell@accedian.c= om> wrote:

Some comments from the "field" as Accedian= has several hundred thousand TWAMP sessions running (continously) at numer= ous Tier one mobile/fixed operators globally.

=C2=A0

On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S <wei.s.luo@ericsson.= com> wrote:

Hi Greg,

=C2=A0

Thanks a lot for your response. Please see my reply inline tagged= [WEI>>].

=C2=A0

Regards,

Wei Luo

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, March 21, 2017 1:16 AM
To: Wei Luo S <wei.s.luo@ericsson.com>
Cc: ippm@ietf.org= ; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org
Subject: Re: Some though on draft-mirsky-ippm-twamp-light-yang-= 07

=C2=A0

Hi Wei Luo,

many thanks for your thorough review and the most he= lpful comments to the TWAMP Light(Test) model. Please find my answers, note= s in-line tagged GIM>>.

=C2=A0

Regards,

Greg

=C2=A0

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.c= om> wrote:

Hi Greg & Adrian,

=C2=A0

This is Wei Luo from Ericsson. I work on TWAMP light= area in Ericsson. The current TWAMP Light YANG model is well defined. Than= ks for your great job.

But by working closely with our customers, we got so= me new user cases on TWAMP light. I believe these user cases are valuable a= nd popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor =C2=A0and co-work with you move this draft f= orward.=C2=A0

I =C2=A0drafted a new version of the TWAMP light YAN= G model based on version ietf-= twamp-light@2017-02-13.yang. Could you please comments on it? Any = discussion is welcome.

The draft yang model and tree is attached. To make y= ou find the updates quickly, I highlighted all the updates in fil= e ietf-twamp-light-weiluo.pdf.

=C2=A0

The following are the list of main updates:

1. Add a new typedef: percent. This is a new type= defined for packet loss ratio.

Consideration:

1). From the customer perspective, packet loss ratio is a more meaningful d= ata. In most of the time, the absolute number is meaningless to user, espec= ially they do the TWAMP test continuously. They are more care about the rat= io than the absolute number. So adding it makes this model more friendly to customer;

2). From the service layer assurance(SLA) perspective, the packet loss rati= o is a major measures. So with adding packet loss ratio in model, the TWAMP= can work in SLA framework more smoothly.

3). It seems some similar protocol=E2=80=99s YANG model has the same defini= tion, e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99= , https://www.mef.net/Assets/Technical_= Specifications/PDF/MEF_39.pdf.

Agreed packet loss is important, however another imp= ortant loss metric is loss burst size (max/min) and number of loss bursts. = A loss burst of 10 consecutive TWAMP-test packets can be deemed more seriou= s than 10 lost packets spread evenly over the report interval.

GIM>> Indeed, packet loss more often expressed= as packet loss ratio rather than as the absolute number. It would be most = helpful to hear from network operators if they see introduction of Packet Loss Ratio into the TWAMP model helpful.

2. Add a new typedef: state-mode. It defines a co= mmon type for stateful/stateless reflector. This type will be used in both = sender session and reflector session.

Consideration:

If the reflector is stateful, the TWAMP light can me= asure more items, e.g. one way packet loss. So for sender, the stats calcul= ation and show is different. When the reflector is stateless, it doesn=E2=80=99t need to calculate the one way packet loss. T= he one way packet loss is invalid and shouldn=E2=80=99t be presented to cus= tomer. When the reflector is stateless, the sender needs to calculate the o= ne way packet loss. And the data should be present to customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree.

GIM>> Yes, if Session-Sender is aware of the m= ode corresponding Session-Reflector operates, the sender may avoid calculat= ion of some performance metrics, e.g., one-way packet loss. On the other hand, the orchestrator is aware of the state-mode and should = be capable to properly use metrics reported by the Session-Sender.

[WEI&= gt;>] Yes, the orchestrator could know that. But from the model side, th= is is not correct.=C2=A0 The model should represent the right behavior and shouldn=E2=80=99t do assumption on orchestrator.

I agree the model should describe both one-way loss = metrics and roundtrip loss metrics, and the sender should be able to use ei= ther mode when calculating, potentially also populating the roundtrip delay= values with proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that would indicate buffer l= oad/CPU load in the TWAMP responders processing time.

3. Add a new typedef: send-mode. This is a new ty= pe for sender session. It makes the sender session can send packet continuo= usly and monitor the network all the time.

Consideration:

The user case is that: the user runs TWAMP light ses= sions to watch links quality continuously. The session number could be very= big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. = In other words, all the performance metrics are calculated based on the pac= kets sent/received within 15mins. This makes the calculation become possibl= e. With the periodical stats data, the Network Management software can do further actions if some abnormal st= ats observed.=C2=A0 This is a more general user case in customer site. Whil= e the non-continuous TWAMP sender session is generally used for debugging p= urpose on a link. =C2=A0

GIM>> I think that support of continuous measu= rement is in LMAP domain, not for TWAMP Test data model. To conduct continu= ous measurement he LMAP Controller, in my opinion, programs the Measurement Agent to perform TWAMP Test session with certain set of pa= rameters and repeat it without any interval (interval =3D 0).=

=C2=A0

Many operators use TWAMP in continous mode, not only= with Accedian test points and report at fixed intervals, typically ranging= from 5s to 5 or 15 minutes, with 1-minute being the most popular granulari= ty currently. The advantage is that the result calculation can be handled separately from the TWAMP-test sendi= ng/recieving, so that there is no parallelism required to monitor 24/7. If = a start-stop-based methodology is used, the sender needs to start up the ne= w test session even before the previous one has ended, since the previous session needs to wait X seconds (or at l= east Y 100s of milliseconds) before it stops waiting for packets to come ba= ck. And this new session needs to have a different signature in order for t= he sender to discern which packets belong to the previous interval and which belong to the current.=

=C2=A0

In a continous test-model, the sender can just simpl= y record the sequence number of the last packet transmitted in the interval= to be reported, wait for it to come back, or a MAXTIME, then report that r= esult, while continuing to transmit for the next interval.

=C2=A0

If the "interval=3D=3D0" parameter is inte= nded to be used for continous type tests, then what parameter should indica= te to the sender at what intervals to produce results? =C2=A0=

4. Add a new group: packet-loss-statistics. It gr= ouping two packet loss statistics: loss-count and loss-ratio. This group wi= ll be used in RO stats tree.

GIM>> I'd like to continue discussion.=C2= =A0

[WEI>>] OK.

5. Move leaf dscp out from grouping session-light= -parameters. The leaf dscp is only valid when the dscp-handling-mode is use= -configured-value. A when condition shall be added to it. So it can=E2=80=99t be in this group.

GIM>> I'm concerned that then the model wi= ll not be able to support concurrent TWAMP Test sessions between the same p= air of Test Points (IP address+port number) at different CoS markings.=C2=A0

[WEI&= gt;>] Actually, I have concern on using five tuple(IP address+port numbe= r+dscp) to identify a TWAMP test session. The DSCP is not a constant value in packet. It could be modified by the routers in the pat= h. For example, the sender has two sessions: session A=E2=80=99s five tuple= is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2= . Session B=E2=80=99s five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs3. The only difference between sess= ion A and session B is DSCP. If the test packet=E2=80=99s DSCP of session B= is modified to cs2 by a router in the path. The five tuples are exactly th= e same for reflector. It can=E2=80=99t differentiate which packet is from session A, which packet is from session B. It could mess th= e reflector=E2=80=99s session sequence number. And also, the sender will be= messed because the received reply packet=E2=80=99s five tuple are exactly = the same.

So I = think it=E2=80=99s more reasonable to use four tuple to identify a session.=

=C2=A0

Yes, this would be appreciated by users. Changes in = DSCP is a reasonably common network error that users can detect with contin= ous TWAMP monitoring, thus it is good to not include the DSCP value as part= of the "session identifiier" but instead use 4-tuple with UDP source port to identify several parallel flow= s between the same sender and responder.=C2=A0

6. Add leaf 'session-packet-send-mode' to= /twamp-light/twamp-light-session-sender/test-session*. This leaf spec= ifies the sender session's packet send mode: continuous or non-continuo= us.

GIM>> As discussed in #3, I think that it is a= lready part of LMAP YANG model.=C2=A0

7. Add leaf 'reflector-light-mode-state' = to /twamp-light/twamp-light-session-sender/test-session*. This leaf in= dicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can b= e got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.

Consideration: =C2=A0

Only valid data should be presented to user. Otherwi= se it could misleading user in some cases.

GIM>> A in response to #2.=C2=A0=

8. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. Add a 'when' condi= tion to this leaf. When send-mode is 'continuous', the leaf number-= of-packets is meaningless. So add a 'when' condition to limit it.=C2=A0 Besid= es, added a default value =E2=80=9810=E2=80=99 to it. When the send-mode is= 'non-continuous', the session can't work with an empty number-= of-packets.

GIM>> As I've noted in #3. Will add defaul= t.=C2=A0

9. Add leaf time out to /twamp-light/twamp-light-= session-sender/test-session*. A timeout mechanism is needed when the s= ender session can't get all the reply packets for a long time.

GIM>> Thank you, will add in the next update.= =C2=A0

10. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/interval. Change the units from =E2=80=98mic= roseconds=E2=80=99 to =E2=80=98milliseconds=E2=80=99. Add a default value 1= 000.

Consideration:

=C2=A0=C2=A0=C2=A0 1). The aim of TWAMP is to measur= e network quality, but not fast failure detection. So a millisecond packet = interval is enough.

=C2=A0=C2=A0=C2=A0 2). Interval is a necessary param= eter for a session. A sender session can't work with an empty packet se= nd interval. So added a default value to it.

GIM>> Thank you. We've made units of inter= val microseconds in the last update already. I think that changing to milli= seconds may be too restrictive, limit use cases for TWAMP Test. Will add default value with the next update.

[WEI&= gt;>] Sorry, I do not see the reason. Are there any user cases to use mi= croseconds?

11. Add leaf 'dscp' to /twamp-light/twamp= -light-session-sender/test-session*. This is the leaf moved out from g= rouping session-light-parameters.

GIM>> As noted in response #5, the change may = limit ability to run concurrent TWAMP Test sessions per CoS. I consider tha= t to be valuable mode but would like to hear from network operators if that is indeed useful information.=C2=A0

=C2=A0

See my comment above. I argue that it is useful to k= eep track of changing DSCP values, and treating DSCP as a metric of the TWA= MP Session just like loss and delay=C2=A0

12. Move leaves 'ref-wait', 'reflecto= r-light-mode-state' and 'dscp-handling-mode' from /twamp-light/= twamp-light-session-reflector to /twamp-light/twamp-light-session= -reflector/test-session*. These three attributes should be session specific. Different session could= have different values. They are not common attributes.

GIM>> Agree, will make it in the next update.= =C2=A0

13. Add leaf 'dscp' to /twamp-light/twamp= -light-session-reflector/test-session*. This is the leaf moved out fro= m grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only v= alid when the dscp-handling-mode is 'use-configured-value'.<= /u>

GIM>> As response to #5.=C2=A0

14. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/number-= of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.

GIM>> Similar to #3.=C2=A0

15. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/interva= l. Change the units from microseconds to milliseconds.

GIM>> I think that microseconds is reasonable.= =C2=A0

16. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/. These are the new statistics for stateful reflector.

GIM>> Thank you, will be coming in the next up= date.=C2=A0

17. Remove leaf loss-packet in /twamp-light-state= /twamp-light-session-sender-state/test-session-state*/current-sta= ts. The loss packeted is replaced with 'two-way-packet-loss' stated above.

GIM>> Agree.=C2=A0

18. Modify leaf to /twamp-light-state/twamp-light= -session-sender-state/test-session-state*/history-stats*/int= erval. Change the units from microseconds to milliseconds.

GIM>> I think that will limit applicability of= TWAMP Test.=C2=A0

19. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-session-state*/history-stats*/. These are the new statistics for stateful reflector.

GIM>> Agree.

=C2=A0

Thanks,

Wei Luo

=C2=A0


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



=C2=A0

--

=C2=A0=

Cell

Email

Skype

+46 709845992

hnydell@accedian.com

hnydell

3D"Accedian.com"

Henrik Nydell

Sr Manager Global Strategy & Solutions<= /span>

=C2=A0=

Cell=

Email

Skype

+46 709845992

hnydell@accedian.com

h<= /span>nydell

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0=

=

=C2=A0

=C2=A0

Avis de confidentialit=C3= =A9

Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

Confidentiality notice

This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.


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

=C2=A0



=C2=A0

--

=C2=A0=

3D"Accedian.com"

Henrik Nydell

Sr Manager Global Strategy & Solutions<= /span>

=C2=A0=

Cell=

Email

Skype

+46 709845992<= /span>

hnydell@accedian.com

h<= /span>nydell

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0=

=

=C2=A0

=C2=A0

Avis de confidentialit=C3= =A9

Les informations contenue= s dans le pr=C3=A9sent message et dans toute pi=C3=A8ce qui lui est jointe = sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le secret= professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de so= n ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s= =E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3= =A9diteur et en d=C3=A9truire tout exemplaire. De plus, il vous est stricte= ment interdit de le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99exp=C3=A9diteur. Merci.=

Confidentiality notice

This e-mail message and any attachment h= ereto contain confidential information which may be privileged and which is= intended for the exclusive use of its addressee(s). If you receive this me= ssage in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, dis= tribution or copying of this message and/or any attachment hereto without t= he consent of the sender is strictly prohibited. Thank you.

=


--
<= div dir=3D"ltr">


3D"Accedian.com"

Henrik Nydell

Sr Manager Global Strat= egy & Solutions


Cell

Email

Skype

+46 709845992

hnydell@accedian.com

hnydell



= =C2=A0= =C2=A0 =C2=A0= =C2=A0


<= /div>

=

Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.




--
=


= <= /table>

3D"Accedian.com"<= /span>

Henrik Nydell

Sr Manager Global Strategy & Solutions

Ce= ll

Email

Skype

=

+46 709845992

hny= dell@accedian.com

hnydell



<= p dir=3D"ltr" style=3D"line-height:1.5213031578947367;margin-top:0pt;margin= -bottom:0pt"> =C2=A0 =C2=A0 =C2=A0= =C2=A0



Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

--f403045e3cf8ff7af2054dadec1d-- From nobody Sun Apr 23 04:44:18 2017 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 2B8E11292F5; Sun, 23 Apr 2017 04:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 zb4t-8unIzgp; Sun, 23 Apr 2017 04:44:15 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33280127863; Sun, 23 Apr 2017 04:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5240; q=dns/txt; s=iport; t=1492947855; x=1494157455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=R43T9Pz+2klWcl81bpYgK7yYPKUhl54w9ooQqO5XeSk=; b=lFYWiOrUvxl1Vd5Rmjm2xgJ5bikgB0b1m4gdLezNRpskTEAT/r4VhY/b vVtKVRWJz7/vdqFNww7eiKw5kQwwz/RcTfQirjjg6b0vtAIFvhewmQVQZ hpJb5nIXmRB9J6tuiI/72rQ4PaUSyJZTpBjBib4jWD/6t+uZiDxlsYiIX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQAkk/xY/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFZFllWWCDyELhXgCGoNyPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQEhEToLBQcEAgEIDgMEAQEBAgIjAwICAiULFAEICAIEDgWKFAgOq?= =?us-ascii?q?xuCJosTAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4MjgiWBXSuCboQ0I4MGLoI?= =?us-ascii?q?xBZZJhngBkwWRV5QYAR84PkhjFUQRAYZWdYZ6gS+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,239,1488844800"; d="scan'208";a="415739879" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2017 11:44:14 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3NBiDet013099 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 23 Apr 2017 11:44:13 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 23 Apr 2017 07:44:13 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sun, 23 Apr 2017 07:44:13 -0400 From: "Carlos Pignataro (cpignata)" To: Al Morton CC: "Ruediger.Geib@telekom.de" , "ippm-chairs@ietf.org" , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSqBXsR2UglBUivky7lwWMt8jJvaGsFiIAgABoVYCAABw3AIAAG56AgAKShYCAC3l4gIAEX90AgAMRcwCABFD7gIAFNvIAgAAqgICAAArNAIAAu02AgADWd4CABb4lAA== Date: Sun, 23 Apr 2017 11:44:12 +0000 Message-ID: <9C575ED7-E248-4D6D-855A-2F20926709DF@cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.212.155] Content-Type: text/plain; charset="utf-8" Content-ID: <97BFDC2441ECF443A0A8FEA002F4A766@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 23 Apr 2017 11:44:17 -0000 SGksDQoNClRoaXMgaXMgYSB2ZXJ5IHVzZWZ1bCBkaXNjdXNzaW9uIOKAlCBhbHRob3VnaCBvbiB0 aGUgdGFpbC1lbmQgc2VlbXMgdG8gYmUgZGl2ZXJnaW5nIGZyb20gdGhlIG9yaWdpbmFsIGdvYWwu IEkgc3VnZ2VzdCB0aGF0IHdlIHNob3VsZCBwcm9iYWJseSBub3QgdGFrZSB0aGlzIGRpc2N1c3Np b24gaW50byBhbGwgaW50ZXItZG9tYWluIHBlcm11dGF0aW9ucy4NCg0KSW4gb3RoZXIgd29yZHMs IGlzIHRoZXJlIHNvbWUgY2FzZSB0aGF0IHRoZSBvcmlnaW5hbCB0ZXh0IGRvZXMgbm90IGNvdmVy PyBUaGUgdGV4dCBpbmNsdWRlcyDigJxtZWNoYW5pc21zIGluIHBsYWNlIHRvIGVuc3VyZSB0aGF0 IGluLXNpdHUgT0FNIGRhdGEgc3RheXMgd2l0aGluIGFuIElPQU0gZG9tYWlu4oCdIGFuZCDigJxw cm92aXNpb25zIGluIHBsYWNlIHRvIGVuc3VyZSB0aGF0IElPQU0gZGF0YSBkb2VzIG5vdCBsZWFr IGJleW9uZCB0aGUgZWRnZSBvZiBhbiBJT0FNIGRvbWFpbuKAnS4NCg0KVGhlIGlkZWEgaXMgdGhh dCBhbiBJT0FNIERvbWFpbiBzaG91bGQgdGFrZSBjYXJlIG9mIGNvbnNpZGVyYXRpb25zIGJlY2F1 c2Ugb2YgZS5nLiwgaW5jcmVhc2VkIHBhY2tldCBzaXplcyB3aXRoaW4gaXRzIGRvbWFpbiwgYW5k IHByZXZlbnQgbGVha2FnZS4NCg0KSW4gbWFueSBkZXBsb3ltZW50cywgdGhlIGxhdHRlciAoaS5l LiwgImVuc3VyaW5nIHRoYXQgaU9BTSBkYXRhIHN0YXlzIHdpdGhpbiB0aGUgZG9tYWluLCBhbmQg ZG9lcyBub3QgbGVhayBiZXlvbmQgdGhlIGV4aXQgZWRnZeKAnSkgd291bGQgYmUgYSBuYXR1cmFs IGNoYXJhY3RlcmlzdGljIG9mIHRoZSBlbmNhcHN1bGF0aW9uLiBGb3IgZXhhbXBsZSwgd2hlbiB1 c2luZyBJT0FNIHdpdGggTlNILCBhbiBJT0FNIGRvbWFpbiB3b3VsZCBiZSBhbiBTRkMgZG9tYWlu LCBhbmQgdGh1cyByZW1vdmluZyBOU0ggZW5jYXAgd2lsbCBhbHNvIGVuc3VyZSBJT0FNIGRvZXMg bm90IGxlYWsuIFNhbWUgd2l0aCBWeExBTi1HUEUsIGV0Yy4NCg0KQnV0IG5ldC1uZXQsIEnigJlk IHJlY29tbWVuZCB3ZSBkZWZpbmUgdGhlIElPQU0gZG9tYWluIGJlaGF2aW9yIGFuZCBub3QgYWxs IG90aGVyIHBvc3NpYmxlIHZpZXdzLg0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCj4gT24g QXByIDE5LCAyMDE3LCBhdCA0OjAyIFBNLCBNT1JUT04sIEFMRlJFRCBDIChBTCkgPGFjbW9ydG9u QGF0dC5jb20+IHdyb3RlOg0KPiANCj4gSGkgUsO8ZGlnZXIsDQo+IHNob3J0IHJlcGx5IGluLWxp bmUsDQo+IEFsDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFJ1 ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSBbbWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZV0N Cj4+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTksIDIwMTcgMzoxNSBBTQ0KPj4gVG86IE1PUlRP TiwgQUxGUkVEIEMgKEFMKQ0KPj4gQ2M6IGlwcG0tY2hhaXJzQGlldGYub3JnOyBpcHBtQGlldGYu b3JnOyBpZXRmQHRyYW1tZWxsLmNoOw0KPj4gZmJyb2NrbmVAY2lzY28uY29tDQo+PiBTdWJqZWN0 OiBBVzogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uDQo+PiANCj4+IEhpIEFsLA0KPj4gDQo+ PiBpcyBhIG5vbi1pT0FNIG5ldHdvcmsgb3BlcmF0b3IgYWJsZSB0byBkZXRlY3Qgc3RhbmRhcmQg aXB2NiBwYWNrZXRzIHdpdGgNCj4+IGlPQU0gZXh0ZW5zaW9ucywgaWYgdGhlIHJlY2VpdmluZyBv cGVyYXRvcnMgZXF1aXBtZW50IGlzIGNvbmZpZ3VyZWQgdG8NCj4+IHN1cHBvcnQgc3RhbmRhcmQg aXB2NiBwcm90b2NvbCBvbmx5PyBUaGUgcHJlLWNvbmRpdGlvbiBoZXJlIGlzICJub24taU9BTQ0K Pj4gZG9tYWluIiBhdCB0aGUgcmVjZWl2aW5nIHNpZGUuIE15IHBvaW50IGlzLCBpZiBhIGRvbWFp biBpc24ndCBpbnRlcmVzdGVkDQo+PiBpbiBzdXBwb3J0aW5nIHRoZSBpT0FNIGV4dGVuc2lvbnMs IGlzIGl0IG9ibGlnZWQgdG8gb3BlcmF0ZSBpT0FNIGF3YXJlDQo+PiBlcXVpcG1lbnQgdG8gZGV0 ZWN0IHVuZGVzaXJlZCB0cmFmZmljIGF0IG5ldHdvcmsgYm91bmRhcmllcz8NCj4gW0FDTV0gDQo+ IE5vLCBhbiBvcGVyYXRvciBjYW4gbGV0IHRoZSB0cmFmZmljIGZsb3cgaWYgdGhleSB3YW50Lg0K PiBIb3dldmVyLCBpZiBvcGVyYXRvcnMgZmluZCB0aGF0IHRoZWlyIG5ldHdvcmsgaXMgDQo+IGFm ZmVjdGVkIGJ5IHRyYWZmaWMgd2l0aCBpT0FNIGRhdGEgZnJvbSBhbm90aGVyIGRvbWFpbiwNCj4g dGhleSB3b3VsZCBiZSBqdXN0aWZpZWQgdG8gZGlzY2FyZCB0aGF0IHRyYWZmaWMNCj4gKGFzIGxv bmcgYXMgdGhlcmUgaXMgYSBjbGVhciBkb21haW4gbGltaXQgZXhwcmVzc2VkIHRvIA0KPiBpT0FN IHByb3RvY29sIGRlc2lnbmVycyBvZiB0aGUgZnV0dXJlLCBhcyBGcmFuayBoYXMNCj4gc3VnZ2Vz dGVkKS4NCj4gDQo+IFRoaXMgaXMgdGhlIHNhbWUgYWJpbGl0eSBhZmZvcmRlZCBvcGVyYXRvcnMg YnkgZGVjbGFyaW5nDQo+IEJNV0cgYWRkcmVzcyBzcGFjZSBmb3IgaXNvbGF0ZWQgdGVzdGluZy1v bmx5LCBvciB0aGUNCj4gdmFyaW91cyBwcml2YXRlIG5ldHdvcmsgYWRkcmVzcyBzcGFjZXMuIFBs ZW50eSBvZiANCj4gTmV0MTAgdHJhZmZpYyBlc2NhcGVzLCBhbmQgb3BlcmF0b3JzIGFyZSBub3Qg b2JsaWdlZA0KPiB0byBkcm9wIGl0LCBidXQgdGhleSBjZXJ0YWlubHkgY2FuLg0KPiANCj4+IA0K Pj4gSSdtIG5vdCBzdXJlLCB3aGV0aGVyIHRoaXMgaXMgYW4gSVBQTSBkaXNjdXNzaW9uLiBJcyB0 aGVyZSBhbnkgb3RoZXINCj4+IElQUE0gcHJvdG9jb2wgb3IgcGFja2V0IGNvbnRlbnQgcmVxdWly aW5nIGEgZGlzY2FyZCBvZiB0cmFmZmljIGF0IGENCj4+IGRvbWFpbiBib3VuZGFyeT8NCj4+IA0K Pj4gUmVnYXJkcywNCj4+IA0KPj4gUnVlZGlnZXINCj4+IA0KPj4gDQo+PiBbQUNNXQ0KPj4gDQo+ PiBJT00sIHRoZXJlIGlzIGEgZ2VuZXJhbCBtZXNzYWdlIHRvIGNvbnZleSBmb3IgYWxsIGZ1dHVy ZSBwcm90b2NvbA0KPj4gZGV2ZWxvcG1lbnQuIFNvbWV0aGluZyBsaWtlICJzdWZmaWNpZW50IHBy b3Zpc2lvbnMgc2hvdWxkIGJlIG1hZGUgdG8NCj4+IHJlc3RyaWN0IHRoZSBpT0FNIHRyYWZmaWMg dG8gdGhlIGludGVuZGVkIGRvbWFpbi4iDQo+PiANCj4+IFdlIGNvdWxkIHByb3ZpZGUgZ3VpZGFu Y2UgdG8gaW50ZXJjb25uZWN0aW5nIG5ldHdvcmsgb3BlcmF0b3JzLCBhcyB3ZWxsLA0KPj4gZWZm ZWN0aXZlbHkgYWxsb3dpbmcgdGhlbSB0byBkaXNjYXJkIHRyYWZmaWMgY29udGFpbmluZyB1bmV4 cGVjdGVkIGlPQU0NCj4+IGRhdGEuIFRoaXMgd291bGQgYmUgYXBwbGljYWJsZSB0byBub24taU9B TSBuZXR3b3JrIG9wZXJhdG9ycywgYnV0IG1pZ2h0DQo+PiBiZSBtb3JlIGltcG9ydGFudCBmb3Ig aW50ZXJjb25uZWN0aW5nIG9wZXJhdG9ycyB3aG8gaGF2ZSBlc3RhYmxpc2hlZA0KPj4gdGhlaXIg b3duIGlPQU0gZG9tYWluLg0KPj4gDQo+PiBUaGlzIGlzIHNpbWlsYXIgdG8gdGhlIGFwcHJvYWNo IHdlIHVzZWQgZm9yIEJNV0cgdGVzdCB0cmFmZmljOg0KPj4gdGhlcmUgYXJlIHY0IGFuZCB2NiBh ZGRyZXNzIHNwYWNlcyBkZWRpY2F0ZWQgZm9yIGlzb2xhdGVkIHRlc3QNCj4+IGVudmlyb25tZW50 cywgYW5kIGFueSBwYWNrZXQgd2l0aCB0ZXN0aW5nIGFkZHJlc3NlcyBvYnNlcnZlZCBvbiB0aGUN Cj4+IEludGVybmV0IG1heSBiZSBkaXNjYXJkZWQuDQo+PiANCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+ IGlwcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHBtDQoNCg== From nobody Sun Apr 23 04:53:58 2017 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 DB28E129423; Sun, 23 Apr 2017 04:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 MMXpuveeTxFL; Sun, 23 Apr 2017 04:53:55 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328C91292F5; Sun, 23 Apr 2017 04:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2874; q=dns/txt; s=iport; t=1492948435; x=1494158035; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Hp5x8ShwmLcDxY9Buk9+e9mkfIlPvNftS8xpKKOD3t4=; b=XGYrGY3JTeyIQHjYZuTYaUEabtogmqiKvmCKL+sPcPvk8VYUIii6RXzu ug1M1ghyNqPtNzf+WJQ6TcHqPuZuEINjpE5wOrECDVldu4Y7zJ8bGJxqI ACFzzXwHvKBhk+OpBkrCmgjKeyheaQFMg+oDChpKqaJ/CjbksRBWkbYnu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAQBZlfxY/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFZFlcJR1gg8hC4JCgzYCGoNyPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEhEToLBQsCAQgYAgImAgICJQsVEAIEDgWKFAgOqxOCJosTA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VIgV0rgjo0hFeDBi6CMQWWSYZ4AZM?= =?us-ascii?q?FkVeUGAEfOIEGYxVEEQGEVAMcgWN1iCmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,239,1488844800"; d="scan'208";a="416429080" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2017 11:53:54 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3NBrsDT025895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 23 Apr 2017 11:53:54 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 23 Apr 2017 07:53:52 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sun, 23 Apr 2017 07:53:53 -0400 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel CC: "Ruediger.Geib@telekom.de" , Al Morton , "ippm-chairs@ietf.org" , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSqBXsR2UglBUivky7lwWMt8jJvaGsFiIAgABoVYCAABw3AIAAG56AgAKShYCAC3l4gIAEX90AgAMRcwCABFD7gIAFNvIAgAAqgICAAArNAIAAu02AgADWd4CAAL4YgIAAGbEAgATpDwA= Date: Sun, 23 Apr 2017 11:53:53 +0000 Message-ID: <40154BD2-82B6-4E0C-966D-E4CC5824C247@cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B! 309F97543CF25F71AE7@njm texg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> <69831a3f7b4b42989dc85d3f8e920843@HE101653.emea1.cds.t-internal.com> <001e01d2b9b3$bfb35050$3f19f0f0$@olddog.co.uk> In-Reply-To: <001e01d2b9b3$bfb35050$3f19f0f0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.212.155] Content-Type: text/plain; charset="utf-8" Content-ID: <7F739E74D510984CB2DE7472F29EF41E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 23 Apr 2017 11:53:57 -0000 SGkgQWRyaWFuLA0KDQo+IE9uIEFwciAyMCwgMjAxNywgYXQgNDo1NCBBTSwgQWRyaWFuIEZhcnJl bCA8YWRyaWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQo+IA0KPj4gVGhlcmUgYXJlIHR3byBzY2Vu YXJpb3Mgd2hpY2ggbWF5IHdvcnJ5Og0KPj4gDQo+PiAtIElPQU0tZG9tYWluIHBhc3NlcyB0cmFm ZmljIHRvIG5vbi1JT0FNIGRvbWFpbg0KPj4gIG9yIElPQU0gZG9tYWluIHJlc3BlY3RpdmVseSBh bmQgSU9BTSBwYXJhbWV0ZXJzDQo+PiAgbWF5IHN0aWxsIGJlIHByZXNlbnQuDQo+IA0KPiBUaGlz IGlzIHRoZSBvbmUgd2hlcmUgdGhlIG5vbi1pT0FNIHJvdXRlciBnZXRzIGEgcGFja2V0IGNvbnRh aW5pbmcgaU9BTSBkYXRhIGFuZA0KPiBtaXNiZWhhdmVzIGluIHNvbWUgd2F5Li4uDQo+IC0gY3Jh c2gNCg0KSeKAmWQgaW1hZ2luZSBibGFtZSBmb3Igc29mdHdhcmUgYnVncyB0cmlnZ2VyZWQgYnkg bGVnYWwgcGFja2V0cyBpcyBvdXRzaWRlIG9mIHNjb3BlIG9mIHdoYXQgYSBzcGVjaWZpY2F0aW9u IGNhbiBvd24uIDotKQ0KDQpUaGF0IHNhaWQsIHJ1bm5pbmcgKG5vbi1jcmFzaGluZykgY29kZSBp cyBpbXBvcnRhbnQgYW5kIGhlbmNlIElPQU0gaW4gQml0cy1uLWJ5dGVzIHdhcyB1c2VmdWwuIEFu IG9wcG9ydHVuaXR5IGZvciB0aGUgSGFja2F0aG9uIGFzIHdlbGwhDQoNCj4gLSBtaXMtZm9yd2Fy ZCAoaW5jbHVkaW5nIGJyb2tlbiBFQ01QKQ0KPiAtIGJsYWNrLWhvbGUNCj4gDQo+PiAtIElPQU0t ZG9tYWluIHBhc3NlcyB0cmFmZmljIHRvIG5vbi1JT0FNIGRvbWFpbg0KPj4gIHdoaWNoIHBhc3Nl cyBwYWNrZXRzIGNvbnRhaW5pbmcgSU9BTSB1bm1vZGlmaWVkDQo+PiAgdG8gYW5vdGhlciBJT0FN IGRvbWFpbi4NCj4gDQo+IFRoaXMgaXMgdGhlIG9uZSB3aGVyZSB0aGUgZG93bnN0cmVhbSBkb21h aW4gaXMgY2F1c2VkIHRvIGV4ZWN1dGUgYmVoYXZpb3IgdW5kZXINCj4gdGhlIGNvbnRyb2wgb2Yg dGhlIHVwc3RyZWFtIGRvbWFpbi4NCj4gDQo+IEl0IGlzIGNsZWFyICh0byBtZSkgdGhhdCBpbiBi b3RoIGNhc2VzIHRoZSBkb3duc3RyZWFtIGRvbWFpbiB3aWxsIHdhbnQgdG8NCj4gcHJvdGVjdCBp dHNlbGYgKGFuZCBzbywgdG8gc29tZSBleHRlbnQsIEZyYW5rIGlzIHJpZ2h0IHRoYXQgdGhlIG9w ZXJhdG9yIG9mIHRoZQ0KPiBkb3duc3RyZWFtIGRvbWFpbiB3aWxsIHdhbnQgdG8gdGFrZSBwcmVj YXV0aW9ucyksIGJ1dCBteSBjb25jZXJuIGlzIHRvIG1ha2UgaXQNCj4gc2ltcGxlIHRvIHRha2Ug dGhvc2UgcHJlY2F1dGlvbnMsIGJ1aWxkIHRoZW0gaW50byB0aGUgcHJvdG9jb2xzIHRoZW1zZWx2 ZXMsIGFuZA0KPiBhbGxvdyBpbm5vY2VudCBsZWdhY3kgbmV0d29ya3MgdG8gY29udGludWUgdW5k aXN0dXJiZWQgaW4gdGhlIHByZXNlbmNlIG9mIGlPQU0NCj4gaW4gb3RoZXIgbmV0d29ya3MuDQo+ IA0KPiBJIHVuZGVyc3RhbmQgdGhhdCB0byBzb21lIGV4dGVudCBhbGwgb2YgdGhpcyBkaXNjdXNz aW9uIGdvZXMgd2l0aCB0aGUNCj4gZW5jYXBzdWxhdGlvbi91c2UtY2FzZXMgYW5kIG5vdCB3aXRo IHRoZSBmdW5kYW1lbnRhbCBnZW5lcmljIGVuY29kaW5nIG9mIGlPQU0NCj4gZGF0YS4gSG93ZXZl ciwgSSB0aGluayB0aGF0IHRoZSBxdWVzdGlvbiBhcHBsaWVzIHRvIGFsbCBhcHBsaWNhdGlvbnMg b2YgaU9BTSBhbmQNCj4gc28gY2xlYXIgc3RhdGVtZW50cyBpbiB0aGUgYmFzZSBkb2N1bWVudCBh cmUgbmVjZXNzYXJ5Lg0KDQpZZXMuIEFncmVlZC4gU29tZSBvZiB0aGlzIGlzIGluZGVlZCBlbmNh cC1zcGVjaWZpYywgYnV0IHRoZSByZXF1aXJlbWVudCBhbmQgY29uc2lkZXJhdGlvbiBpcyBicm9h ZGx5IGFwcGxpY2FibGUuDQoNClRoZSAtZGF0YSBkcmFmdCB3aWxsIGluY2x1ZGUgRnJhbmvigJlz IHByb3Bvc2FsIGFuZCByZXZpZXcgY29tbWVudHMgb24gaXQuDQoNClRoYW5rcyENCg0KQ2FybG9z Lg0KDQo+IA0KPiBBZHJpYW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlwcG1AaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg== From nobody Tue Apr 25 07:45:19 2017 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 574081314B2 for ; Tue, 25 Apr 2017 07:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 Znnw8MMuhqOl for ; Tue, 25 Apr 2017 07:45:08 -0700 (PDT) Received: from nm35-vm3.bullet.mail.gq1.yahoo.com (nm35-vm3.bullet.mail.gq1.yahoo.com [98.136.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F148131B5B for ; Tue, 25 Apr 2017 07:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493131377; bh=QeLYV5VGgSCOBU3zQ3cTUJxCnDBC7nDk/FIXRZwe1SU=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=rVfjaBcyKAET9aHN3F1Zt9tzEGgMqtO6cPPCb5beb0jMdvU/GO8o4rqKfZW2Mlthmfi1fW/5rXujGs+ZTv9OAex+LShx1n5zbsDZ76Xla1tDITJmhSjKbcToIPphxCyrHrWCpxvHsiV6WDigSAm/HDlTcX17UIa/TZ7lLeD6pEgFLa9AyvqhdM/Suc5iaiN3pfc4UE2vhZL1GAZzR3cZKz+Gb+H+sWBZxOTHGWtiCt/N+6hh23+U9tlEghc5POxlupbIoploRrqm5ldQWKw4CuFPf5JXdAllFivLZvyKkq5YbLuerEoyAHvMz6pBPYkv31fMLYElQyYScGRFIUZjbA== Received: from [127.0.0.1] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2017 14:42:57 -0000 Received: from [98.137.12.189] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2017 14:40:07 -0000 Received: from [98.137.12.222] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2017 14:40:07 -0000 Received: from [127.0.0.1] by omp1030.mail.gq1.yahoo.com with NNFMP; 25 Apr 2017 14:40:07 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 963740.2032.bm@omp1030.mail.gq1.yahoo.com X-YMail-OSG: m7T23NgVM1n7XMpn5LsqiXsWpxdXWXcz0BhHwBDVBSJ7WicQKNFqmvF72wR2Ch8 TIWJ7sENTOrCwaOEZSj1o08tKTBWFOY0npxHmEsHpRX96UyuuaRrsrMz5qOS19fPtmqgfjzGg_SW ICbiRgvZghNWjR3HF5xu2iDXF1eanxXbhjXjGkOw_9KJwk34hZW2QybKG2Vzm_tn.QE54eJ_N0rD 1LkiNOK625MqbZwWz0chuzAugQ8UZw1wNRNXYSpmhOhSsvskROHGL58hzPre0aJNjqc1_bHJiEro sYccp6Z1ZxsqVmGmAMgjAPLu3ejzcyGPRu0BisAas53AhbpBI7vBdJ_VeRuHL48UyNytbOIPm14A aTk0bk11_F2RhMlU33ZkPKl8VWwmF0i1qDU.bj92D2uWD06lvM72gtwTCQ4joGycXSFFxk9YaEW8 lMCcRhD.LTJZTRQMu1QQgfDDt0odtEym0IH3R23kSki9SHdCX4kiD4VM_htcBgWx82g4_4TOwEzc efNe8cypzItWZL3IQ9N13w.rB0DUNbIs3lGXZLlPcVNFRTKIHGY0YgF34Xvo1 Received: from jws300067.mail.gq1.yahoo.com by sendmailws115.mail.gq1.yahoo.com; Tue, 25 Apr 2017 14:40:07 +0000; 1493131207.535 Date: Tue, 25 Apr 2017 14:40:07 +0000 (UTC) From: Reply-To: To: The IESG , Warren Kumari , Cc: , Bill Cerveny , , , Message-ID: <1028302357.10142631.1493131207282@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1028302357.10142631.1493131207282.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9408 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 25 Apr 2017 14:45:10 -0000 Warren, You may have missed my response to your comments in all the emails going back and forth. I am resending. Please let me know what you think. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- Warren, I am responding to your Comments below. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Sat, 4/8/17, Warren Kumari wrote: Subject: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org Date: Saturday, April 8, 2017, 10:01 AM > Warren Kumari has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. > The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > The document says that packet sequence number are optional ("measurements based on optional sequence numbers and timing may be embedded in each > packet"), but doesn't say what should be put in the PSNTP field if I'm not using them. It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets > (the exmaple just has a dash). This means that I cannot create an interoperable implementation from this document alone. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / > ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out > of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). How is this? Current Text ---------------- 1.6 IPv6 Transition Technologies In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed. The PDM header is not expected to work in such scenarios. It is likely that an IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. New Text ------------ 1.6 Full Support of IPv6 Functionality In the path to full implementation of native IPv6, transition technologies such as translation or tunneling may be employed. The PDM header may not work in such scenarios. It is likely that an IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. It is also possible that some devices in the network may not correctly handle multiple IPv6 Extension Headers, including the IPv6 Destination Option. For example, adding the PDM header to a packet may push the layer 4 information to a point in the packet where it is not routed correctly. This kind of situation is expected to become rare over time. > In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions > overhead from larger packets, but nothing about the additional processing time. How about if we add the following to Appendix C after the first paragraph: As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM. Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal. > In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it > gets some number of "nonsensical" sequence numbers." -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic. I think what we were thinking is that there may be, in the future, middle boxes (for example, firewalls) which might be able to detect nonsensical sequence numbers. So, they would not be the ones who initiated the use of PDM as a covert channel. Is there a better way to say this? > Another example is section 4.4 Timing Attacks: "Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM. Consent is common in enterprises and with > some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. The addition "Consent to be Measured" is so that people know that along with the many benefits of accurate measurements, there are some inevitable small risks. > In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This > feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite. How about if we add something to explain further "Consent to be Measured". Sentence below: "The actual content of "Consent to be Measured" will differ by site but it SHOULD make clear that the traffic is being measured for quality of service and to assist in diagnostics as well as to make clear that there may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session. " > I don't understand Section 3.6 Dynamic Configuration Options. "If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating > system MAY also have a dynamic configuration option to change the configuration setting as needed." I don't understand how an implementing OS could not have a default (unless this were random). If the > default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled). > Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off.", so I'm very confused what > 3.6 is trying to say... I agree that paragraph is confusing. I suggest deleting it since section 3.5.1 already discusses defaults. Current text ---------------- 3.6 Dynamic Configuration Options If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed. If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP address only. These are at the discretion of the implementation. New text ----------- 3.6 Filtering of PDM If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP address only. These are at the discretion of the implementation. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Tue Apr 25 10:10:02 2017 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 8E926129A8D for ; Tue, 25 Apr 2017 10:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 u2SIoJMjFuv6 for ; Tue, 25 Apr 2017 10:09:34 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 275131316DE for ; Tue, 25 Apr 2017 10:08:49 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id f76so70530925qke.2 for ; Tue, 25 Apr 2017 10:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XmzH3Juwmcrau4+xRv8akySPwLJKmz7RSNNTPnGLL/I=; b=KKbW9AgMOVKBXJxsmzrgRnyaRM9AByJHxndJnkrPk6ZAbkkYt3zXZyMCO5bSk0NnGW j79ngZ1szB6nHpnOeOqknYco6OeoQZnA7qznKMF2Ye/atqjoyRtffHhQSe6CpFqP077Q f5OBUM7hZL7WTcMvw4XY8VakHPLF/AW7qCIvLLXKKaZwYHOM62hgbcb7H7Ibr9a94YFa /V9KTTAwXmjS6bXZ8Pj2VfaIcUxC1LgtqT4e1L3IGiwNxQy5Y6c7U03TnFH7oQGkWHXH 3FL3iah+50N7wKgk4P9ErntCJZW8biA0TaFUYHr1QN42B4hmw9FL/32ksCzOppAZ0Y6u kuDg== 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=XmzH3Juwmcrau4+xRv8akySPwLJKmz7RSNNTPnGLL/I=; b=rAVb/84r7C/MVsuDKGaXkEHeLty8479Fvs5BVV3pfej/U5jPN1CwIZ6EY+Ino4gVoH kxdaVfIzl7cq1j+7OU+VV4+yLmHUi2+wUDKr62lCeAQeSWAP57lCsUSpNtf98mo9LmVg KCSs3zWZPg7ZEmqEXtWOWh/yNm5Z5WprjieL+uQR+Nl1w0AJQkvKxtOQQA1w3XyMcT0m n/QV9OGoE7cKMTjfk1aF9m5pPngO5gLnmwSDzbI6PvDD9w17mxjWOz+xMrUiksbpE4Lt 67yWXWn6sjODhyerpa+GFiSmjBTNL1OmByygRJVy3lqIpsXcT2Za7ukaewp/8UrgKk6v WWjg== X-Gm-Message-State: AN3rC/6oA0RhPmfGeyuqgAWdyYZ+ZM5r5U+v42J+16lkuUHGCYc7bNxO gL2C4yD3eull93lW/HBLjIQ/fnQAS36/ X-Received: by 10.55.75.68 with SMTP id y65mr29432132qka.2.1493140127913; Tue, 25 Apr 2017 10:08:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.154 with HTTP; Tue, 25 Apr 2017 10:08:07 -0700 (PDT) In-Reply-To: <1028302357.10142631.1493131207282@mail.yahoo.com> References: <1028302357.10142631.1493131207282.ref@mail.yahoo.com> <1028302357.10142631.1493131207282@mail.yahoo.com> From: Warren Kumari Date: Tue, 25 Apr 2017 13:08:07 -0400 Message-ID: To: Nalini Elkins Cc: The IESG , draft-ietf-ippm-6man-pdm-option@ietf.org, Bill Cerveny , ippm-chairs@ietf.org, "MORTON, ALFRED C (AL)" , ippm@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 25 Apr 2017 17:09:44 -0000 Ah, I was wondering why y'all hadn't updated the draft -- I actually drafted (and then abandoned) an email asking this morning. I did respond to the original, on April 12th - perhaps it got lost / eaten? Copied and pasted below: ------- Warren Kumari Apr 12 (13 days ago) to Nalini, ALFRED, IESG, draft-ietf-ipp., Bill, ippm-chairs, ippm Mostly good -- I think that "where is it not routed correctly" seems a little odd - that feels like it means the packet may be routed to the wrong place - perhaps "where it is not visible to filtering logic, and may be dropped" ? Otherwise good. > > > > In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions > > overhead from larger packets, but nothing about the additional processing time. > > > How about if we add the following to Appendix C after the first paragraph: > > As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM. Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal. Great. > > > > > In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it > > gets some number of "nonsensical" sequence numbers." -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic. > > I think what we were thinking is that there may be, in the future, middle boxes (for example, firewalls) which might be able to detect nonsensical sequence numbers. So, they would not be the ones who > initiated the use of PDM as a covert channel. Is there a better way to say this? Yeah, that was not clear to me from the text -- it would then also not be the implementation which would stop using PDM, it would be the middle box which would (presumably) block it. Perhaps say something like: If a PDM aware middle box detects some number of "nonsensical" sequence numbers it could take action to block (or alert on) this traffic." > > > > Another example is section 4.4 Timing Attacks: "Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM. Consent is common in enterprises and with > > some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. > > The addition "Consent to be Measured" is so that people know that along with the many benefits of accurate measurements, there are some inevitable small risks. > > > > In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This > > feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite. > > > How about if we add something to explain further "Consent to be Measured". Sentence below: > > "The actual content of "Consent to be Measured" will differ by site but it SHOULD make clear that the traffic is being measured for quality of service and to assist in diagnostics as well as to make clear that there > may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session. " I still don't love this, but am OK with it. > > > > I don't understand Section 3.6 Dynamic Configuration Options. "If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating > > system MAY also have a dynamic configuration option to change the configuration setting as needed." I don't understand how an implementing OS could not have a default (unless this were random). If the > > default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled). > > > Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off.", so I'm very confused what > > 3.6 is trying to say... > > I agree that paragraph is confusing. I suggest deleting it since section 3.5.1 already discusses defaults. > > Current text > ---------------- > > 3.6 Dynamic Configuration Options > > If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to > change the configuration setting as needed. > > If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP > address only. These are at the discretion of the implementation. > > > New text > ----------- > > 3.6 Filtering of PDM > > If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP > address only. These are at the discretion of the implementation. WFM. ----- On Tue, Apr 25, 2017 at 10:40 AM, wrote: > Warren, > > You may have missed my response to your comments in all the emails going back and forth. > > I am resending. Please let me know what you think. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -------------------------------------------- > Warren, > > I am responding to your Comments below. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -------------------------------------------- > On Sat, 4/8/17, Warren Kumari > wrote: > > Subject: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) > To: "The IESG" > Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org > > Date: Saturday, April 8, 2017, 10:01 AM > > > Warren Kumari has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. > >> The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > >> The document says that packet sequence number are optional ("measurements based on optional sequence numbers and timing may be embedded in each >> packet"), but doesn't say what should be put in the PSNTP field if I'm not using them. It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets >> (the exmaple just has a dash). This means that I cannot create an interoperable implementation from this document alone. > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- > >> This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / >> ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out >> of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). > > How is this? > > Current Text > ---------------- > > 1.6 IPv6 Transition Technologies > > In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed. The PDM header is not expected to work in such scenarios. It is likely that an > IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. > > New Text > ------------ > > 1.6 Full Support of IPv6 Functionality > > In the path to full implementation of native IPv6, transition technologies such as translation or tunneling may be employed. The PDM header may not work in such scenarios. It is likely that an > IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. > > It is also possible that some devices in the network may not correctly handle multiple IPv6 Extension Headers, including the IPv6 Destination Option. For example, adding the PDM header to a packet > may push the layer 4 information to a point in the packet where it is not routed correctly. This kind of situation is expected to become rare over time. > > >> In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions >> overhead from larger packets, but nothing about the additional processing time. > > > How about if we add the following to Appendix C after the first paragraph: > > As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM. Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal. > > > >> In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it >> gets some number of "nonsensical" sequence numbers." -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic. > > I think what we were thinking is that there may be, in the future, middle boxes (for example, firewalls) which might be able to detect nonsensical sequence numbers. So, they would not be the ones who > initiated the use of PDM as a covert channel. Is there a better way to say this? > > >> Another example is section 4.4 Timing Attacks: "Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM. Consent is common in enterprises and with >> some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. > > The addition "Consent to be Measured" is so that people know that along with the many benefits of accurate measurements, there are some inevitable small risks. > > >> In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This >> feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite. > > > How about if we add something to explain further "Consent to be Measured". Sentence below: > > "The actual content of "Consent to be Measured" will differ by site but it SHOULD make clear that the traffic is being measured for quality of service and to assist in diagnostics as well as to make clear that there > may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session. " > > >> I don't understand Section 3.6 Dynamic Configuration Options. "If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating >> system MAY also have a dynamic configuration option to change the configuration setting as needed." I don't understand how an implementing OS could not have a default (unless this were random). If the >> default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled). > >> Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off.", so I'm very confused what >> 3.6 is trying to say... > > I agree that paragraph is confusing. I suggest deleting it since section 3.5.1 already discusses defaults. > > Current text > ---------------- > > 3.6 Dynamic Configuration Options > > If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to > change the configuration setting as needed. > > If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP > address only. These are at the discretion of the implementation. > > > New text > ----------- > > 3.6 Filtering of PDM > > If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP > address only. These are at the discretion of the implementation. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Apr 25 11:34:22 2017 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 26F49129476 for ; Tue, 25 Apr 2017 11:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 SjyFVvRy05Ur for ; Tue, 25 Apr 2017 11:34:13 -0700 (PDT) Received: from nm43-vm1.bullet.mail.gq1.yahoo.com (nm43-vm1.bullet.mail.gq1.yahoo.com [67.195.87.216]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F99131776 for ; Tue, 25 Apr 2017 11:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493145248; bh=WeDeY9kr3+0ns+M0l+Wl4KtwYh5CIzDYK+tpinYZZfU=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=rgh8nyO6j4WbTXEs+N9c6LCFv+rw93IVCSnSevQ7e13G4GXHMKBQSrEn0n35woJtLf46VQVFWoJie+o5dXtgVsLWnQNpeTA6gUXwNIrzAcBrFDAzKPxv84UM+BjujPSN71bx9oZuhMeDRsmO4A54CE7Bifo76TLoWPYl80VkqdoOfxsvfWfuZ908x8+qaW0QQ7th49Fhc1EeKhyuh68URgkglDcy1yk9x4N/g88NkMp0EQlX6Sgu/76MxdMqrttKfUgCFIC/G1ZUO/BBI/O43tR7Q/hFR9fSiSw2rrkEnZTR7frVKaoThV3GJ7N8YKlnryK2wum2F1/nYU1wA+LE/g== Received: from [127.0.0.1] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2017 18:34:08 -0000 Received: from [98.137.12.56] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2017 18:31:26 -0000 Received: from [98.137.12.205] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2017 18:31:26 -0000 Received: from [127.0.0.1] by omp1013.mail.gq1.yahoo.com with NNFMP; 25 Apr 2017 18:31:26 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 666406.8190.bm@omp1013.mail.gq1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws300009.mail.gq1.yahoo.com by sendmailws149.mail.gq1.yahoo.com; Tue, 25 Apr 2017 18:31:25 +0000; 1493145085.634 Date: Tue, 25 Apr 2017 18:31:25 +0000 (UTC) From: Reply-To: To: Nalini Elkins , Warren Kumari Cc: The IESG , , Bill Cerveny , , " ALFRED C (AL)MORTON" , Message-ID: <1104337766.6511349.1493145085252@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1104337766.6511349.1493145085252.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9408 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 25 Apr 2017 18:34:15 -0000 Warren, Thanks so much! Will use your words: "where it is not visible to filtering logic, and may = be dropped"=20 I believe that was the only change. I am making all changes in my working copy & will update as one big change. My plan is to do one set of comments (per AD) per day. Sorry, I got behin= d in working through the comments. Tomorrow, I will be doing Mirja's comments. Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Tue, 4/25/17, Warren Kumari wrote: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-op= tion-09: (with DISCUSS and COMMENT) To: "Nalini Elkins" Cc: "The IESG" , draft-ietf-ippm-6man-pdm-option@ietf.org, = "Bill Cerveny" , ippm-chairs@ietf.org, "MORTON, ALFRED = C (AL)" , ippm@ietf.org Date: Tuesday, April 25, 2017, 10:08 AM =20 Ah, I was wondering why y'all hadn't updated the draft -- I actually drafted (and then abandoned) an email asking this morning. =20 I did respond to the original, on April 12th - perhaps it got lost / eaten? =20 Copied and pasted below: =20 ------- =20 Warren Kumari Apr 12 (13 days ago) to Nalini, ALFRED, IESG, draft-ietf-ipp., Bill, ippm-chairs, ippm =20 Mostly good -- I think that "where is it not routed correctly" seems a little odd - that feels like it means the packet may be routed to the wrong place - perhaps "where it is not visible to filtering logic, and may be dropped" ? Otherwise good. =20 > > >=C2=A0 > In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions >=C2=A0 > overhead from larger packets, but nothing about the additional processing time. > > > How about if we add the following to Appendix C after the first paragraph: > > As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM.=C2=A0 Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal. =20 Great. =20 > > > >=C2=A0 > In addition, much of the security advice feels like sops, simply to appease security people.=C2=A0 For example,=C2=A0 in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it >=C2=A0 > gets some number of "nonsensical" sequence numbers."=C2=A0 -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic. > >=C2=A0 I think what we were thinking is that there may be, in the future, middle boxes (for example, firewalls) which might be able to detect nonsensical sequence numbers.=C2=A0 So, they would not be the ones who >=C2=A0 initiated the use of PDM as a covert channel.=C2=A0 Is there a better way to say this? =20 Yeah, that was not clear to me from the text -- it would then also not be the implementation which would stop using PDM, it would be the middle box which would (presumably) block it. Perhaps say something like: If a PDM aware middle box detects some number of "nonsensical" sequence numbers it could take action to block (or alert on) this traffic." =20 > > >=C2=A0 > Another example is section 4.4 Timing Attacks: "Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM.=C2=A0 Consent is common in enterprises and with >=C2=A0 > some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. > >=C2=A0 The addition "Consent to be Measured"=C2=A0 is so that people know that along with the many benefits of accurate measurements, there are some inevitable small risks. > > >=C2=A0 > In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This >=C2=A0 > feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite. > > >=C2=A0 How about if we add something to explain further "Consent to be Measured".=C2=A0 Sentence below: > >=C2=A0 "The actual content of "Consent to be Measured" will differ by site but it SHOULD make clear that the traffic is being measured for quality of service and to assist in diagnostics as well as to make clear that there >=C2=A0 may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session. " =20 I still don't love this, but am OK with it. =20 > > >=C2=A0 > I don't understand Section 3.6 Dynamic Configuration Options. "If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating >=C2=A0 > system MAY also have a dynamic configuration option to change the configuration setting as needed." I don't understand how an implementing OS could not have a default (unless this were random). If the >=C2=A0 > default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled). > >=C2=A0 > Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The=C2=A0 default value of PDM is off.", so I'm very confused what >=C2=A0 > 3.6 is trying to say... > >=C2=A0 I agree that paragraph is confusing.=C2=A0 I suggest deleting it since section 3.5.1 already discusses defaults. > >=C2=A0 Current text >=C2=A0 ---------------- > >=C2=A0 3.6 Dynamic Configuration Options > >=C2=A0 =C2=A0 If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating system MAY also have a dynamic configuration option to >=C2=A0 =C2=A0 change the configuration setting as needed. > >=C2=A0 =C2=A0 If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >=C2=A0 =C2=A0 address only.=C2=A0 These are at the discretion of the implementation. > > >=C2=A0 New text >=C2=A0 ----------- > >=C2=A0 3.6 Filtering of PDM > >=C2=A0 =C2=A0 If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >=C2=A0 =C2=A0 address only.=C2=A0 These are at the discretion of the implementation. =20 WFM. =20 ----- =20 On Tue, Apr 25, 2017 at 10:40 AM,=C2=A0 wrote: > Warren, > > You may have missed my response to your comments in all the emails going back and forth. > > I am resending.=C2=A0 =C2=A0 Please let me know what you think. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -------------------------------------------- > Warren, > > I am responding to your Comments below. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -------------------------------------------- > On Sat, 4/8/17, Warren Kumari > wrote: > >=C2=A0 Subject: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) >=C2=A0 To: "The IESG" >=C2=A0 Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" ,=C2=A0 "Bill Cerveny" ,=C2=A0 ippm-chairs@ietf.org,=C2=A0 acmorton@att.com,=C2=A0 ippm@ietf.org > >=C2=A0 Date: Saturday, April 8, 2017, 10:01=C2=A0 AM > >=C2=A0 > Warren Kumari has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. > >> The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > > >=C2=A0 > > ---------------------------------------------------------------------- >=C2=A0 > DISCUSS: >=C2=A0=20 > > ---------------------------------------------------------------------- > >> The document says that packet sequence number are optional ("measurements based on optional sequence numbers and timing may be embedded in each >> packet"), but doesn't say what should be put in the PSNTP field if I'm not using them. It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets >> (the exmaple just has a dash).=C2=A0 This means that I cannot create an interoperable implementation from this document alone. > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- > >> This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / >> ACLs. This is not just a theoretical issue - see RFC7872 for real world examples.=C2=A0 This means that if I connect to a remote machine and enable this, I may lock myself out >> of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). > > How is this? > > Current Text > ---------------- > > 1.6 IPv6 Transition Technologies > >=C2=A0 =C2=A0 In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed.=C2=A0 The PDM header is not expected to work in such scenarios.=C2=A0 It is likely that an >=C2=A0 =C2=A0 IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. > > New Text > ------------ > > 1.6 Full Support of IPv6 Functionality > >=C2=A0 =C2=A0 In the path to full implementation of native IPv6, transition technologies such as translation or tunneling may be employed.=C2=A0 The PDM header may not work in such scenarios.=C2=A0 It is likely that an >=C2=A0 =C2=A0 IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. > >=C2=A0 =C2=A0 It is also possible that some devices in the network may not correctly handle multiple IPv6 Extension Headers, including the IPv6 Destination Option.=C2=A0 For example, adding the PDM header to a packet >=C2=A0 =C2=A0 may push the layer 4 information to a point in the packet where it is not routed correctly.=C2=A0 This kind of situation is expected to become rare over time. > > >> In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions >> overhead from larger packets, but nothing about the additional processing time. > > > How about if we add the following to Appendix C after the first paragraph: > > As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM.=C2=A0 Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal. > > > >> In addition, much of the security advice feels like sops, simply to appease security people.=C2=A0 For example,=C2=A0 in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it >> gets some number of "nonsensical" sequence numbers."=C2=A0 -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic. > > I think what we were thinking is that there may be, in the future, middle boxes (for example, firewalls) which might be able to detect nonsensical sequence numbers.=C2=A0 So, they would not be the ones who > initiated the use of PDM as a covert channel.=C2=A0 Is there a better way to say this? > > >> Another example is section 4.4 Timing Attacks: "Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM.=C2=A0 Consent is common in enterprises and with >> some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. > > The addition "Consent to be Measured"=C2=A0 is so that people know that along with the many benefits of accurate measurements, there are some inevitable small risks. > > >> In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This >> feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite. > > > How about if we add something to explain further "Consent to be Measured".=C2=A0 Sentence below: > > "The actual content of "Consent to be Measured" will differ by site but it SHOULD make clear that the traffic is being measured for quality of service and to assist in diagnostics as well as to make clear that there > may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session. " > > >> I don't understand Section 3.6 Dynamic Configuration Options. "If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating >> system MAY also have a dynamic configuration option to change the configuration setting as needed." I don't understand how an implementing OS could not have a default (unless this were random). If the >> default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled). > >> Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The=C2=A0 default value of PDM is off.", so I'm very confused what >> 3.6 is trying to say... > >=C2=A0 I agree that paragraph is confusing.=C2=A0 I suggest deleting it since section 3.5.1 already discusses defaults. > > Current text > ---------------- > > 3.6 Dynamic Configuration Options > >=C2=A0 =C2=A0 If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating system MAY also have a dynamic configuration option to >=C2=A0 =C2=A0 change the configuration setting as needed. > >=C2=A0 =C2=A0 If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >=C2=A0 =C2=A0 address only.=C2=A0 These are at the discretion of the implementation. > > > New text > ----------- > > 3.6 Filtering of PDM > >=C2=A0 =C2=A0 If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP >=C2=A0 =C2=A0 address only.=C2=A0 These are at the discretion of the implementation. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm =20 =20 =20 --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. =C2=A0 ---maf =20 From nobody Wed Apr 26 02:22:15 2017 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 2DF9012945D; Wed, 26 Apr 2017 02:22:14 -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 AkQrOmp-A0_K; Wed, 26 Apr 2017 02:22:12 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 272AA12932A; Wed, 26 Apr 2017 02:22:12 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id j201so201760294oih.2; Wed, 26 Apr 2017 02:22:12 -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=pbhasdIB8FmR9aT5JnU/UmEKHbhA2qOTsf5lQf/PZPU=; b=Y+jwg6xfSC291iG2CODfe/2f2TMpXSPWVDrK+8xD5RNEv4CrGiHr8cE5JcGRXxRWqo BAsRBT/U3aDi7VYBkAKwbw8FECEOqIlQF2VqnVxbTqRzUouT1pRqGP94ZXD0KoDtvfey G45Ae/cbxMOEHesgfVC4CNwvhXsXQJdTM9FTlSUe3UwrIwN1T42RpEPddwv696IsNkGI qmSmMFJm2FRUK/pfhkrUxY1+4Pr7Tbs3wgzx3+Lzn4GLKf6hUkxmy361JtDHveNkWiNY qsZyRvBD/10grPd4H8HdLmOHs66bxEygTBN6n7nmpyZSkLgV7Tv3WRvKJ185rcMjQrCW DuNw== 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=pbhasdIB8FmR9aT5JnU/UmEKHbhA2qOTsf5lQf/PZPU=; b=FcEcyVh/xG0/Kw7Q+s1p6cl40gPvAliIf5S738ZSw6QOtU52hnefIB2PhksBKOGp2A iOdpKuYyv+rq3l9QNGvhToS4RcLO73DlpnSRjloMglbDd8FHgxwR//LGeRLd5QH7CGyv 4HfgHR3gx47LtSsw5PmczaaCDgy3mFUF3dzoNJoM6iG1MAudVNJ4OJMPrUOkf1AwAmTV IvD9l2pIrp2g6smGLmZolnA4gCI61tZDQ/5O2NCCOfcJAC1vzzhmEzBfEH0HCS+uuATw 5kjELDmWj0yotn0ZyicginNIXBUyfez0HIDXS25v3rgblAgPetlhZOSDQIp3xDmumH0t zLTg== X-Gm-Message-State: AN3rC/62ajp99k1ZVMqMGZcj3DmJEjkEvXs0wlRDc3/xcDqJ8pkFh9IV 0xftHS2Mr1zZWtJ9b31bf+zcK7CFGg== X-Received: by 10.157.9.177 with SMTP id q46mr10928512otd.50.1493198531411; Wed, 26 Apr 2017 02:22:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.118 with HTTP; Wed, 26 Apr 2017 02:22:10 -0700 (PDT) In-Reply-To: <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> From: Greg Mirsky Date: Wed, 26 Apr 2017 02:22:10 -0700 Message-ID: To: Adrian Farrel Cc: "Brian Trammell (IETF)" , "Frank Brockners (fbrockne)" , IPPM Chairs , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113e45160b45d2054e0e6002 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 26 Apr 2017 09:22:14 -0000 --001a113e45160b45d2054e0e6002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian, et. al, I strongly believe that having agreed upon list of requirements that answer questions What? and Where? rather than How? is the most beneficial and not only for the discussion of applicability of in-situ OAM. What needs to be solved, measured that is not ameasureable by already existing OAM methods? I think that if we can compile such list, then it will be more clear what value may be added by developing new hybrid OAM method. Regards, Greg On Wed, Mar 29, 2017 at 2:32 PM, Adrian Farrel wrote: > > > There were several questions related to scope and applicability in th= e > WG > > discussion =E2=80=93 and even more recently on the list. Those can easi= ly be > addressed by > > adding paragraph on applicability to draft-brockners-inband-oam-data = =E2=80=93 > there > > isn=E2=80=99t a need for a dedicated requirements document. > > > > I tend to agree with this, although "a paragraph" seems a little thin t= o > me. I think > > there were some valid points made in that discussion about the scope of > the > > proposal that should be addressed: is IOAM meant for use > tunnel-end-to-tunnel- > > end environment, end-host-to-end-host, within a single network and/or > across > > the Internet. What I would suggest is adding a section to the data > model draft on > > applicability and assumptions about the environment -- both about the > devices > > adding IOAM signals to traffic as well as those consuming these signals > from the > > wire and analyzing them (possibly with the cooperation of devices not o= n > the > > wire) -- submitting a new revision, and we can run a more formal > adoption call on > > that. > > Although I was one of the people raising the "need" for the scope and > requirements, I don't have a strong leading on whether this needs to be i= n > a separate document on folded into the data format document. So Brian's > proposal would work for me. > > Thus, I'd love to see this scoping text drafted and floated to the list a= s > an email or in a revision of the data format document. > > Cheers, > Adrian > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --001a113e45160b45d2054e0e6002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian, et. al,
I strongly believe that having agre= ed upon list of requirements that answer questions What? and Where? rather = than How? is the most beneficial and not only for the discussion of applica= bility of in-situ OAM. What needs to be solved, measured that is not ameasu= reable by already existing OAM methods? I think that if we can compile such= list, then it will be more clear what value may be added by developing new= hybrid OAM method.

Regards,
Greg
<= /div>

On Wed, Mar = 29, 2017 at 2:32 PM, Adrian Farrel <adrian@olddog.co.uk> w= rote:
> > There we= re several questions related to scope and applicability in the WG
> discussion =E2=80=93 and even more recently on the list. Those can eas= ily be addressed by
> adding paragraph on applicability to draft-brockners-inband-oam-d= ata =E2=80=93 there
> isn=E2=80=99t a need for a dedicated requirements document.
>
> I tend to agree with this, although "a paragraph" seems a li= ttle thin to me. I think
> there were some valid points made in that discussion about the scope o= f the
> proposal that should be addressed: is IOAM meant for use tunnel-end-to= -tunnel-
> end environment,=C2=A0 end-host-to-end-host, within a single network a= nd/or across
> the Internet.=C2=A0 What I would suggest is adding a section to the da= ta model draft on
> applicability and assumptions about the environment -- both about the = devices
> adding IOAM signals to traffic as well as those consuming these signal= s from the
> wire and analyzing them (possibly with the cooperation of devices not = on the
> wire) -- submitting a new revision, and we can run a more formal adopt= ion call on
> that.

Although I was one of the people raising the "need" for th= e scope and requirements, I don't have a strong leading on whether this= needs to be in a separate document on folded into the data format document= . So Brian's proposal would work for me.

Thus, I'd love to see this scoping text drafted and floated to the list= as an email or in a revision of the data format document.

Cheers,
Adrian

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

--001a113e45160b45d2054e0e6002-- From nobody Wed Apr 26 06:13:44 2017 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 213DA129B8D; Wed, 26 Apr 2017 06:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 LXxRmVwYpFFT; Wed, 26 Apr 2017 06:13:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18248129479; Wed, 26 Apr 2017 06:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13824; q=dns/txt; s=iport; t=1493212417; x=1494422017; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mqn3CrLRBe2TmKlF6dRRaHCBBYSDAYz2GgPUQSf9J6A=; b=MHFCtLFu5XFwLniWNWaL/vfZfQcl0sQAXeps9w8Kg1ffeWCcriUUxRsi zr+c4RF4UqNoYF0uyRC+J79HAga30l/aTAJjNVhEbON6yGlEzhyH1Z6vv vcVD7tV6tvIchBaG0PJ3RGhjO52loShNs/zKekXloKGJI0nMMIFqUqeqP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AgAonABZ/4sNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYYEMB4NhihaRJyGIIYgThTeCDyEBCoV4AhqECD8YAQIBAQE?= =?us-ascii?q?BAQEBayiFFQEBAQECAQEBIUsLEAIBCBEDAQIBJwMCAgIfBgsUCQgCBAENBYoDA?= =?us-ascii?q?w0IDqougiYrhxkNg18BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZUgV4rC4JkglG?= =?us-ascii?q?BWBEBPBaCUC6CMQWJQZNSOwGHGIcnhEuRXosZiQ0BHzh/CGUVRBIBhll1hkeBI?= =?us-ascii?q?YENAQEB?= X-IronPort-AV: E=Sophos; i="5.37,254,1488844800"; d="scan'208,217"; a="19865636" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2017 13:13:36 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3QDDZwX004083 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 13:13:35 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 09:13:34 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 09:13:34 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky , Adrian Farrel CC: IPPM Chairs , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSqBXsR2UglBUivky7lwWMt8jJvaGsFiIAgABoVYCAABw3AIArNV0A///9mQA= Date: Wed, 26 Apr 2017 13:13:34 +0000 Message-ID: <1FCCBA3C-4553-4310-974B-3002A983BE7A@cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.185] Content-Type: multipart/alternative; boundary="_000_1FCCBA3C45534310974B3002A983BE7Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 26 Apr 2017 13:13:39 -0000 --_000_1FCCBA3C45534310974B3002A983BE7Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBHcmVnLA0KDQpTb21ldGhpbmcgbGlrZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tcmVxdWlyZW1lbnRzLTAzPw0KDQpGb3IgdGhlIHJl Y29yZCwgbXkgb3BpbmlvbjogcGVyZmVjdGluZyByZXF1aXJlbWVudHMgaXMgcGVyaGFwcyBub3Qg dGhlIGJlc3QgdXNlIG9mIFdHIGN5Y2xlcy4gSG93ZXZlciwgcGxhY2luZyByZXF1aXJlbWVudHMg YXMgYSBzZXJpYWxpemVkIHJlcXVpc2l0ZSBiZWZvcmUgcHJvZ3Jlc3NpbmcgcHJvdG9jb2wgd29y ayBpcyBjZXJ0YWlubHkgaGFybWZ1bCBpbiB0aGlzIGNhc2UuDQoNClRoYW5rcywNCg0KLS0gQ2Fy bG9zLg0KDQpGcm9tOiBpcHBtIDxpcHBtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBH cmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBBcHJp bCAyNiwgMjAxNyBhdCA1OjIyIEFNDQpUbzogQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5j by51az4NCkNjOiBJUFBNIENoYWlycyA8aXBwbS1jaGFpcnNAaWV0Zi5vcmc+LCAiaXBwbUBpZXRm Lm9yZyIgPGlwcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2lwcG1dIFZvdGUgYXQgSVBQTSBz ZXNzaW9uDQoNCkhpIEFkcmlhbiwgZXQuIGFsLA0KSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgaGF2 aW5nIGFncmVlZCB1cG9uIGxpc3Qgb2YgcmVxdWlyZW1lbnRzIHRoYXQgYW5zd2VyIHF1ZXN0aW9u cyBXaGF0PyBhbmQgV2hlcmU/IHJhdGhlciB0aGFuIEhvdz8gaXMgdGhlIG1vc3QgYmVuZWZpY2lh bCBhbmQgbm90IG9ubHkgZm9yIHRoZSBkaXNjdXNzaW9uIG9mIGFwcGxpY2FiaWxpdHkgb2YgaW4t c2l0dSBPQU0uIFdoYXQgbmVlZHMgdG8gYmUgc29sdmVkLCBtZWFzdXJlZCB0aGF0IGlzIG5vdCBh bWVhc3VyZWFibGUgYnkgYWxyZWFkeSBleGlzdGluZyBPQU0gbWV0aG9kcz8gSSB0aGluayB0aGF0 IGlmIHdlIGNhbiBjb21waWxlIHN1Y2ggbGlzdCwgdGhlbiBpdCB3aWxsIGJlIG1vcmUgY2xlYXIg d2hhdCB2YWx1ZSBtYXkgYmUgYWRkZWQgYnkgZGV2ZWxvcGluZyBuZXcgaHlicmlkIE9BTSBtZXRo b2QuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFdlZCwgTWFyIDI5LCAyMDE3IGF0IDI6MzIgUE0s IEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cu Y28udWs+PiB3cm90ZToNCj4gPiBUaGVyZSB3ZXJlIHNldmVyYWwgcXVlc3Rpb25zIHJlbGF0ZWQg dG8gc2NvcGUgYW5kIGFwcGxpY2FiaWxpdHkgaW4gdGhlIFdHDQo+IGRpc2N1c3Npb24g4oCTIGFu ZCBldmVuIG1vcmUgcmVjZW50bHkgb24gdGhlIGxpc3QuIFRob3NlIGNhbiBlYXNpbHkgYmUgYWRk cmVzc2VkIGJ5DQo+IGFkZGluZyBwYXJhZ3JhcGggb24gYXBwbGljYWJpbGl0eSB0byBkcmFmdC1i cm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhIOKAkyB0aGVyZQ0KPiBpc27igJl0IGEgbmVlZCBmb3Ig YSBkZWRpY2F0ZWQgcmVxdWlyZW1lbnRzIGRvY3VtZW50Lg0KPg0KPiBJIHRlbmQgdG8gYWdyZWUg d2l0aCB0aGlzLCBhbHRob3VnaCAiYSBwYXJhZ3JhcGgiIHNlZW1zIGEgbGl0dGxlIHRoaW4gdG8g bWUuIEkgdGhpbmsNCj4gdGhlcmUgd2VyZSBzb21lIHZhbGlkIHBvaW50cyBtYWRlIGluIHRoYXQg ZGlzY3Vzc2lvbiBhYm91dCB0aGUgc2NvcGUgb2YgdGhlDQo+IHByb3Bvc2FsIHRoYXQgc2hvdWxk IGJlIGFkZHJlc3NlZDogaXMgSU9BTSBtZWFudCBmb3IgdXNlIHR1bm5lbC1lbmQtdG8tdHVubmVs LQ0KPiBlbmQgZW52aXJvbm1lbnQsICBlbmQtaG9zdC10by1lbmQtaG9zdCwgd2l0aGluIGEgc2lu Z2xlIG5ldHdvcmsgYW5kL29yIGFjcm9zcw0KPiB0aGUgSW50ZXJuZXQuICBXaGF0IEkgd291bGQg c3VnZ2VzdCBpcyBhZGRpbmcgYSBzZWN0aW9uIHRvIHRoZSBkYXRhIG1vZGVsIGRyYWZ0IG9uDQo+ IGFwcGxpY2FiaWxpdHkgYW5kIGFzc3VtcHRpb25zIGFib3V0IHRoZSBlbnZpcm9ubWVudCAtLSBi b3RoIGFib3V0IHRoZSBkZXZpY2VzDQo+IGFkZGluZyBJT0FNIHNpZ25hbHMgdG8gdHJhZmZpYyBh cyB3ZWxsIGFzIHRob3NlIGNvbnN1bWluZyB0aGVzZSBzaWduYWxzIGZyb20gdGhlDQo+IHdpcmUg YW5kIGFuYWx5emluZyB0aGVtIChwb3NzaWJseSB3aXRoIHRoZSBjb29wZXJhdGlvbiBvZiBkZXZp Y2VzIG5vdCBvbiB0aGUNCj4gd2lyZSkgLS0gc3VibWl0dGluZyBhIG5ldyByZXZpc2lvbiwgYW5k IHdlIGNhbiBydW4gYSBtb3JlIGZvcm1hbCBhZG9wdGlvbiBjYWxsIG9uDQo+IHRoYXQuDQoNCkFs dGhvdWdoIEkgd2FzIG9uZSBvZiB0aGUgcGVvcGxlIHJhaXNpbmcgdGhlICJuZWVkIiBmb3IgdGhl IHNjb3BlIGFuZCByZXF1aXJlbWVudHMsIEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBsZWFkaW5nIG9u IHdoZXRoZXIgdGhpcyBuZWVkcyB0byBiZSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IG9uIGZvbGRl ZCBpbnRvIHRoZSBkYXRhIGZvcm1hdCBkb2N1bWVudC4gU28gQnJpYW4ncyBwcm9wb3NhbCB3b3Vs ZCB3b3JrIGZvciBtZS4NCg0KVGh1cywgSSdkIGxvdmUgdG8gc2VlIHRoaXMgc2NvcGluZyB0ZXh0 IGRyYWZ0ZWQgYW5kIGZsb2F0ZWQgdG8gdGhlIGxpc3QgYXMgYW4gZW1haWwgb3IgaW4gYSByZXZp c2lvbiBvZiB0aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQuDQoNCkNoZWVycywNCkFkcmlhbg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWls aW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0K --_000_1FCCBA3C45534310974B3002A983BE7Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBNaW5jaG8i Ow0KCXBhbm9zZS0xOjIgMiA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBo LCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2lu LXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJn aW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0K CWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RGVhciBHcmVnLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlNvbWV0aGluZyBsaWtlDQo8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tcmVxdWlyZW1l bnRzLTAzIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtaW5i YW5kLW9hbS1yZXF1aXJlbWVudHMtMDM8L2E+PyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PkZvciB0aGUgcmVjb3JkLCBteSBvcGluaW9uOiBwZXJmZWN0aW5nIHJlcXVpcmVtZW50cyBpcyBw ZXJoYXBzIG5vdCB0aGUgYmVzdCB1c2Ugb2YgV0cgY3ljbGVzLiBIb3dldmVyLCBwbGFjaW5nIHJl cXVpcmVtZW50cyBhcyBhIHNlcmlhbGl6ZWQgcmVxdWlzaXRlIGJlZm9yZSBwcm9ncmVzc2luZyBw cm90b2NvbCB3b3JrIGlzDQogY2VydGFpbmx5IGhhcm1mdWwgaW4gdGhpcyBjYXNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4tLSBD YXJsb3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2si PkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+aXBwbSAmbHQ7aXBwbS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg R3JlZyBNaXJza3kgJmx0O2dyZWdpbWlyc2t5QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+V2VkbmVzZGF5LCBBcHJpbCAyNiwgMjAxNyBhdCA1OjIyIEFNPGJyPg0KPGI+VG86IDwvYj5B ZHJpYW4gRmFycmVsICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0Ozxicj4NCjxiPkNjOiA8L2I+ SVBQTSBDaGFpcnMgJmx0O2lwcG0tY2hhaXJzQGlldGYub3JnJmd0OywgJnF1b3Q7aXBwbUBpZXRm Lm9yZyZxdW90OyAmbHQ7aXBwbUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtpcHBtXSBWb3RlIGF0IElQUE0gc2Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQWRyaWFuLCBldC4gYWwsIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3Ryb25nbHkgYmVsaWV2 ZSB0aGF0IGhhdmluZyBhZ3JlZWQgdXBvbiBsaXN0IG9mIHJlcXVpcmVtZW50cyB0aGF0IGFuc3dl ciBxdWVzdGlvbnMgV2hhdD8gYW5kIFdoZXJlPyByYXRoZXIgdGhhbiBIb3c/IGlzIHRoZSBtb3N0 IGJlbmVmaWNpYWwgYW5kIG5vdCBvbmx5IGZvciB0aGUgZGlzY3Vzc2lvbiBvZiBhcHBsaWNhYmls aXR5IG9mIGluLXNpdHUgT0FNLiBXaGF0IG5lZWRzIHRvIGJlIHNvbHZlZCwgbWVhc3VyZWQNCiB0 aGF0IGlzIG5vdCBhbWVhc3VyZWFibGUgYnkgYWxyZWFkeSBleGlzdGluZyBPQU0gbWV0aG9kcz8g SSB0aGluayB0aGF0IGlmIHdlIGNhbiBjb21waWxlIHN1Y2ggbGlzdCwgdGhlbiBpdCB3aWxsIGJl IG1vcmUgY2xlYXIgd2hhdCB2YWx1ZSBtYXkgYmUgYWRkZWQgYnkgZGV2ZWxvcGluZyBuZXcgaHli cmlkIE9BTSBtZXRob2QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5HcmVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDI5LCAyMDE3IGF0IDI6MzIgUE0sIEFkcmlh biBGYXJyZWwgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0YXJnZXQ9 Il9ibGFuayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0OyBUaGVyZSB3ZXJl IHNldmVyYWwgcXVlc3Rpb25zIHJlbGF0ZWQgdG8gc2NvcGUgYW5kIGFwcGxpY2FiaWxpdHkgaW4g dGhlIFdHPGJyPg0KJmd0OyBkaXNjdXNzaW9uIOKAkyBhbmQgZXZlbiBtb3JlIHJlY2VudGx5IG9u IHRoZSBsaXN0LiBUaG9zZSBjYW4gZWFzaWx5IGJlIGFkZHJlc3NlZCBieTxicj4NCiZndDsgYWRk aW5nIHBhcmFncmFwaCBvbiBhcHBsaWNhYmlsaXR5IHRvIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQt b2FtLWRhdGEg4oCTIHRoZXJlPGJyPg0KJmd0OyBpc27igJl0IGEgbmVlZCBmb3IgYSBkZWRpY2F0 ZWQgcmVxdWlyZW1lbnRzIGRvY3VtZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEkgdGVuZCB0byBh Z3JlZSB3aXRoIHRoaXMsIGFsdGhvdWdoICZxdW90O2EgcGFyYWdyYXBoJnF1b3Q7IHNlZW1zIGEg bGl0dGxlIHRoaW4gdG8gbWUuIEkgdGhpbms8YnI+DQomZ3Q7IHRoZXJlIHdlcmUgc29tZSB2YWxp ZCBwb2ludHMgbWFkZSBpbiB0aGF0IGRpc2N1c3Npb24gYWJvdXQgdGhlIHNjb3BlIG9mIHRoZTxi cj4NCiZndDsgcHJvcG9zYWwgdGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkOiBpcyBJT0FNIG1lYW50 IGZvciB1c2UgdHVubmVsLWVuZC10by10dW5uZWwtPGJyPg0KJmd0OyBlbmQgZW52aXJvbm1lbnQs Jm5ic3A7IGVuZC1ob3N0LXRvLWVuZC1ob3N0LCB3aXRoaW4gYSBzaW5nbGUgbmV0d29yayBhbmQv b3IgYWNyb3NzPGJyPg0KJmd0OyB0aGUgSW50ZXJuZXQuJm5ic3A7IFdoYXQgSSB3b3VsZCBzdWdn ZXN0IGlzIGFkZGluZyBhIHNlY3Rpb24gdG8gdGhlIGRhdGEgbW9kZWwgZHJhZnQgb248YnI+DQom Z3Q7IGFwcGxpY2FiaWxpdHkgYW5kIGFzc3VtcHRpb25zIGFib3V0IHRoZSBlbnZpcm9ubWVudCAt LSBib3RoIGFib3V0IHRoZSBkZXZpY2VzPGJyPg0KJmd0OyBhZGRpbmcgSU9BTSBzaWduYWxzIHRv IHRyYWZmaWMgYXMgd2VsbCBhcyB0aG9zZSBjb25zdW1pbmcgdGhlc2Ugc2lnbmFscyBmcm9tIHRo ZTxicj4NCiZndDsgd2lyZSBhbmQgYW5hbHl6aW5nIHRoZW0gKHBvc3NpYmx5IHdpdGggdGhlIGNv b3BlcmF0aW9uIG9mIGRldmljZXMgbm90IG9uIHRoZTxicj4NCiZndDsgd2lyZSkgLS0gc3VibWl0 dGluZyBhIG5ldyByZXZpc2lvbiwgYW5kIHdlIGNhbiBydW4gYSBtb3JlIGZvcm1hbCBhZG9wdGlv biBjYWxsIG9uPGJyPg0KJmd0OyB0aGF0Ljxicj4NCjxicj4NCkFsdGhvdWdoIEkgd2FzIG9uZSBv ZiB0aGUgcGVvcGxlIHJhaXNpbmcgdGhlICZxdW90O25lZWQmcXVvdDsgZm9yIHRoZSBzY29wZSBh bmQgcmVxdWlyZW1lbnRzLCBJIGRvbid0IGhhdmUgYSBzdHJvbmcgbGVhZGluZyBvbiB3aGV0aGVy IHRoaXMgbmVlZHMgdG8gYmUgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBvbiBmb2xkZWQgaW50byB0 aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQuIFNvIEJyaWFuJ3MgcHJvcG9zYWwgd291bGQgd29yayBm b3IgbWUuPGJyPg0KPGJyPg0KVGh1cywgSSdkIGxvdmUgdG8gc2VlIHRoaXMgc2NvcGluZyB0ZXh0 IGRyYWZ0ZWQgYW5kIGZsb2F0ZWQgdG8gdGhlIGxpc3QgYXMgYW4gZW1haWwgb3IgaW4gYSByZXZp c2lvbiBvZiB0aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4N CkFkcmlhbjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KaXBwbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXBw bUBpZXRmLm9yZyI+aXBwbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1FCCBA3C45534310974B3002A983BE7Aciscocom_-- From nobody Wed Apr 26 06:22:25 2017 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 E4831129ABE; Wed, 26 Apr 2017 06:22:23 -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 TpameF4-FyGB; Wed, 26 Apr 2017 06:22:19 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7DE7129B94; Wed, 26 Apr 2017 06:22:13 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id w12so72460oiw.3; Wed, 26 Apr 2017 06:22:13 -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=UOogPdIdazqFJP+mrdy7PMTgM1Y/+euwcfRPK/YVjdY=; b=IX954RXUUtaSgyQ0vnLvBUlrqdqbrYmPcQEEc+c+jpVoqlt0SNzUFcdoVOcilxkosy +cc/JyoX5oxYtedy1dgz3UHD4hUjjEBP7LbwBeqdGpqo2mSVdLr6qZQeOp0wL97TeW7D 0PscrSyzBhgvoCpos2mV3RoLPj/Jmxr/n7UfHivH65CEiwHsu8StU1hbg0feK0EsyI1K RmFqNYOrU6abk8Yd0o56kA0u0+B9vjIBqFOzZJwpOAJE3o9Csg2wFT1N90LTaViSDeiH 7O3dw0j2md6LkJ+uUlFqoXGg7gwtcaFc93yGsqKaaznL7AevyJMslYBZv7i/s2eLzId7 sgjw== 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=UOogPdIdazqFJP+mrdy7PMTgM1Y/+euwcfRPK/YVjdY=; b=A4e3Zz4oDZAIL+/q1AYiy0cLbKYIv35Iv3WQjVcchDAuLHCbxF/hINk5l5uawso7y9 mNVLRvKrpcsBNx7Q5LGbOtlCuszYcRgYr9j6+UhONjZQ9D1WHukywpTmA2iyqmiZtjzN kc4qo/CpF1ktsnJmG/klPM9XJMDolNnZs7UjTyZV3UQxBnVkTf7/0R/QAugIa9HaLYRK pXr1HPH0FPAyZpYWyRBEkLqAuimuM9+b4sg3YfSUWM437t2Obk+WtwuCOij1pV1Va50U grlcDseoOuvcQzbHzG2D4eMJdF/M22uqPW+60R71G8r8uoLo3Y3AF3u4b+8iIX1FlcUB XM0w== X-Gm-Message-State: AN3rC/5LncrKKOLN2b4nhio4OlFqCX+qUNir0t5MHidgnHs12CUrJm/1 3Od/lbMXfXVqSOUenYMylT0K91HAvQ== X-Received: by 10.157.82.148 with SMTP id f20mr20709271oth.23.1493212933196; Wed, 26 Apr 2017 06:22:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.118 with HTTP; Wed, 26 Apr 2017 06:22:12 -0700 (PDT) In-Reply-To: <1FCCBA3C-4553-4310-974B-3002A983BE7A@cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <1FCCBA3C-4553-4310-974B-3002A983BE7A@cisco.com> From: Greg Mirsky Date: Wed, 26 Apr 2017 06:22:12 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: Adrian Farrel , IPPM Chairs , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=f40304355554751267054e11ba01 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 26 Apr 2017 13:22:24 -0000 --f40304355554751267054e11ba01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Carlos, thank you for the reference. I've never called for perfecting but for rough consensus on what problem we need to address. How, IMHO, is secondary. And that is what may be not working in this discussion - we've been presented answer to how do measurement before we have reached an agreement that there's a problem to be solved. Regards, Greg On Wed, Apr 26, 2017 at 6:13 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Dear Greg, > > > > Something like https://tools.ietf.org/html/draft-brockners-inband-oam- > requirements-03? > > > > For the record, my opinion: perfecting requirements is perhaps not the > best use of WG cycles. However, placing requirements as a serialized > requisite before progressing protocol work is certainly harmful in this > case. > > > > Thanks, > > > > -- Carlos. > > > > *From: *ippm on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Wednesday, April 26, 2017 at 5:22 AM > *To: *Adrian Farrel > *Cc: *IPPM Chairs , "ippm@ietf.org" > *Subject: *Re: [ippm] Vote at IPPM session > > > > Hi Adrian, et. al, > > I strongly believe that having agreed upon list of requirements that > answer questions What? and Where? rather than How? is the most beneficial > and not only for the discussion of applicability of in-situ OAM. What nee= ds > to be solved, measured that is not ameasureable by already existing OAM > methods? I think that if we can compile such list, then it will be more > clear what value may be added by developing new hybrid OAM method. > > > > Regards, > > Greg > > > > On Wed, Mar 29, 2017 at 2:32 PM, Adrian Farrel > wrote: > > > > There were several questions related to scope and applicability in th= e > WG > > discussion =E2=80=93 and even more recently on the list. Those can easi= ly be > addressed by > > adding paragraph on applicability to draft-brockners-inband-oam-data = =E2=80=93 > there > > isn=E2=80=99t a need for a dedicated requirements document. > > > > I tend to agree with this, although "a paragraph" seems a little thin t= o > me. I think > > there were some valid points made in that discussion about the scope of > the > > proposal that should be addressed: is IOAM meant for use > tunnel-end-to-tunnel- > > end environment, end-host-to-end-host, within a single network and/or > across > > the Internet. What I would suggest is adding a section to the data > model draft on > > applicability and assumptions about the environment -- both about the > devices > > adding IOAM signals to traffic as well as those consuming these signals > from the > > wire and analyzing them (possibly with the cooperation of devices not o= n > the > > wire) -- submitting a new revision, and we can run a more formal > adoption call on > > that. > > Although I was one of the people raising the "need" for the scope and > requirements, I don't have a strong leading on whether this needs to be i= n > a separate document on folded into the data format document. So Brian's > proposal would work for me. > > Thus, I'd love to see this scoping text drafted and floated to the list a= s > an email or in a revision of the data format document. > > Cheers, > Adrian > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > --f40304355554751267054e11ba01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Carlos,
thank you for the reference.=C2=A0
<= div>I've never called for perfecting but for rough consensus on what pr= oblem we need to address. How, IMHO, is secondary. And that is what may be = not working in this discussion - we've been presented answer to how do = measurement before we have reached an agreement that there's a problem = to be solved.

Regards,
Greg
<= div class=3D"gmail_extra">
On Wed, Apr 26, 20= 17 at 6:13 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Dear Greg,

=C2=A0

Something like https://tools.ietf.org/html/draft-brockners-inband-oam-requiremen= ts-03?

=C2=A0

For the record, my opinion: perfecting requirements is perhaps not the bes= t use of WG cycles. However, placing requirements as a serialized requisite= before progressing protocol work is certainly harmful in this case.

=C2=A0

Thanks,

=C2=A0

-- Carlos.

=C2=A0

F= rom: ippm <ippm-bounces@ietf.org> = on behalf of Greg Mirsky <gregimirsky@gmail.com>
Date: Wednesday, April 26, 2017 at 5:22 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: IPPM Chairs <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Subject: Re: [ippm] Vote at IPPM session=

=C2=A0

Hi Adrian, et. al,

I strongly believe that having agreed upon list of r= equirements that answer questions What? and Where? rather than How? is the = most beneficial and not only for the discussion of applicability of in-situ= OAM. What needs to be solved, measured that is not ameasureable by already existing OAM methods? I think that if = we can compile such list, then it will be more clear what value may be adde= d by developing new hybrid OAM method.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Mar 29, 2017 at 2:32 PM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

> > There were several questions related to sc= ope and applicability in the WG
> discussion =E2=80=93 and even more recently on the list. Those can eas= ily be addressed by
> adding paragraph on applicability to draft-brockners-inband-oam-d= ata =E2=80=93 there
> isn=E2=80=99t a need for a dedicated requirements document.
>
> I tend to agree with this, although "a paragraph" seems a li= ttle thin to me. I think
> there were some valid points made in that discussion about the scope o= f the
> proposal that should be addressed: is IOAM meant for use tunnel-end-to= -tunnel-
> end environment,=C2=A0 end-host-to-end-host, within a single network a= nd/or across
> the Internet.=C2=A0 What I would suggest is adding a section to the da= ta model draft on
> applicability and assumptions about the environment -- both about the = devices
> adding IOAM signals to traffic as well as those consuming these signal= s from the
> wire and analyzing them (possibly with the cooperation of devices not = on the
> wire) -- submitting a new revision, and we can run a more formal adopt= ion call on
> that.

Although I was one of the people raising the "need" for the scope= and requirements, I don't have a strong leading on whether this needs = to be in a separate document on folded into the data format document. So Br= ian's proposal would work for me.

Thus, I'd love to see this scoping text drafted and floated to the list= as an email or in a revision of the data format document.

Cheers,
Adrian

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

=C2=A0


--f40304355554751267054e11ba01-- From nobody Wed Apr 26 07:27:36 2017 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 3B62C129C6D; Wed, 26 Apr 2017 07:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 DcZLZ0Q2-N-M; Wed, 26 Apr 2017 07:27:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E12129B89; Wed, 26 Apr 2017 07:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18152; q=dns/txt; s=iport; t=1493216486; x=1494426086; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+ZGw2Ll63ZyNOLwR2cxB6+lHxFnhMgYXo2UdEydajUw=; b=N++9tlFg/BxJlm5lRg6J3LD+QqpEPFXb2yM4JpQz3SiT6RkiF+XTh13E z7vLcldjPipEE7rTf94PVfwhcygl9L9liNZyOSr5Xmy0iPlq3IgHM704G GbsuMCP4k5t0DzAiBeyY4QJ4eP8gn5MFN0HmqE2R/pkpvFu15dM3j//2/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAQB2rABZ/4YNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYYEMB4NhihaRSYghiBOFN4IPIQEKhXgCGoQKPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUVAQEBAQIBAQEhSwsQAgEIEQMBAgEnAwICAh8GCxQJCAIEDgWKAwMNC?= =?us-ascii?q?A6qKYImK4cYDYNfAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGVIFeK4JvglOBXhE?= =?us-ascii?q?BPBaCUC6CMQWJQZNSOwGHGIcnhEuRXosZiQ0BHzh/CGUVRBIBhCGCOHWGR4Ehg?= =?us-ascii?q?Q0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,254,1488844800"; d="scan'208,217";a="241488007" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2017 14:21:25 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3QELOD3022644 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 14:21:24 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 10:21:23 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 10:21:23 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Adrian Farrel , IPPM Chairs , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSqBXsR2UglBUivky7lwWMt8jJvaGsFiIAgABoVYCAABw3AIArNV0A///9mQCAAEV4AIAAEImA Date: Wed, 26 Apr 2017 14:21:23 +0000 Message-ID: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <1FCCBA3C-4553-4310-974B-3002A983BE7A@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.185] Content-Type: multipart/alternative; boundary="_000_B73302F65DCC404A944C743934B40F9Bciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 26 Apr 2017 14:27:34 -0000 --_000_B73302F65DCC404A944C743934B40F9Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KSSBhZ3JlZSB0aGF0IGEgc2hhcmVkIHVuZGVyc3RhbmRpbmcgYW5kIGFsaWdubWVu dCBvbiB0aGUgcHJvYmxlbSBzcGFjZSBpcyBjcml0aWNhbGx5IGltcG9ydGFudC4gTXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IHdlIGhhdmUgYWxyZWFkeSBiZWVuIGRvaW5nIHRoYXQgZXh0ZW5zaXZl bHksIGluY2x1ZGluZyB0aGUgd29yayBvbiBwb3RlbnRpYWwgY2hhcnRlciB0ZXh0IGRpc2N1c3Nl ZCBpbiBPcHNhd2cuIFRoYXQgd2FzLCBmb3IgZXhhbXBsZSwgYSBkaXNjdXNzaW9uIHNvbGVseSBh Ym91dCB0aGUgcHJvYmxlbSB0byBiZSBzb2x2ZWQuDQoNCldoYXQgY29uY2VybnMgbWUgaXMgdGhl IHN0cmljdCBzZXJpYWxpemF0aW9uIGFuZCB3YXRlcmZhbGwgeW91IHNlZW0gdG8gYmUgYWR2b2Nh dGluZyBmb3IuDQoNCuKAlCBDYXJsb3MuDQoNCk9uIEFwciAyNiwgMjAxNywgYXQgOToyMiBBTSwg R3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21h aWwuY29tPj4gd3JvdGU6DQoNCkRlYXIgQ2FybG9zLA0KdGhhbmsgeW91IGZvciB0aGUgcmVmZXJl bmNlLg0KSSd2ZSBuZXZlciBjYWxsZWQgZm9yIHBlcmZlY3RpbmcgYnV0IGZvciByb3VnaCBjb25z ZW5zdXMgb24gd2hhdCBwcm9ibGVtIHdlIG5lZWQgdG8gYWRkcmVzcy4gSG93LCBJTUhPLCBpcyBz ZWNvbmRhcnkuIEFuZCB0aGF0IGlzIHdoYXQgbWF5IGJlIG5vdCB3b3JraW5nIGluIHRoaXMgZGlz Y3Vzc2lvbiAtIHdlJ3ZlIGJlZW4gcHJlc2VudGVkIGFuc3dlciB0byBob3cgZG8gbWVhc3VyZW1l bnQgYmVmb3JlIHdlIGhhdmUgcmVhY2hlZCBhbiBhZ3JlZW1lbnQgdGhhdCB0aGVyZSdzIGEgcHJv YmxlbSB0byBiZSBzb2x2ZWQuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFdlZCwgQXByIDI2LCAy MDE3IGF0IDY6MTMgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lz Y28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiB3cm90ZToNCkRlYXIgR3JlZywNCg0K U29tZXRoaW5nIGxpa2UgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyb2NrbmVy cy1pbmJhbmQtb2FtLXJlcXVpcmVtZW50cy0wMz8NCg0KRm9yIHRoZSByZWNvcmQsIG15IG9waW5p b246IHBlcmZlY3RpbmcgcmVxdWlyZW1lbnRzIGlzIHBlcmhhcHMgbm90IHRoZSBiZXN0IHVzZSBv ZiBXRyBjeWNsZXMuIEhvd2V2ZXIsIHBsYWNpbmcgcmVxdWlyZW1lbnRzIGFzIGEgc2VyaWFsaXpl ZCByZXF1aXNpdGUgYmVmb3JlIHByb2dyZXNzaW5nIHByb3RvY29sIHdvcmsgaXMgY2VydGFpbmx5 IGhhcm1mdWwgaW4gdGhpcyBjYXNlLg0KDQpUaGFua3MsDQoNCi0tIENhcmxvcy4NCg0KRnJvbTog aXBwbSA8aXBwbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmc+ PiBvbiBiZWhhbGYgb2YgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86 Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgQXByaWwgMjYsIDIwMTcg YXQgNToyMiBBTQ0KVG86IEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRv OmFkcmlhbkBvbGRkb2cuY28udWs+Pg0KQ2M6IElQUE0gQ2hhaXJzIDxpcHBtLWNoYWlyc0BpZXRm Lm9yZzxtYWlsdG86aXBwbS1jaGFpcnNAaWV0Zi5vcmc+PiwgImlwcG1AaWV0Zi5vcmc8bWFpbHRv OmlwcG1AaWV0Zi5vcmc+IiA8aXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uDQoNCkhpIEFkcmlhbiwgZXQu IGFsLA0KSSBzdHJvbmdseSBiZWxpZXZlIHRoYXQgaGF2aW5nIGFncmVlZCB1cG9uIGxpc3Qgb2Yg cmVxdWlyZW1lbnRzIHRoYXQgYW5zd2VyIHF1ZXN0aW9ucyBXaGF0PyBhbmQgV2hlcmU/IHJhdGhl ciB0aGFuIEhvdz8gaXMgdGhlIG1vc3QgYmVuZWZpY2lhbCBhbmQgbm90IG9ubHkgZm9yIHRoZSBk aXNjdXNzaW9uIG9mIGFwcGxpY2FiaWxpdHkgb2YgaW4tc2l0dSBPQU0uIFdoYXQgbmVlZHMgdG8g YmUgc29sdmVkLCBtZWFzdXJlZCB0aGF0IGlzIG5vdCBhbWVhc3VyZWFibGUgYnkgYWxyZWFkeSBl eGlzdGluZyBPQU0gbWV0aG9kcz8gSSB0aGluayB0aGF0IGlmIHdlIGNhbiBjb21waWxlIHN1Y2gg bGlzdCwgdGhlbiBpdCB3aWxsIGJlIG1vcmUgY2xlYXIgd2hhdCB2YWx1ZSBtYXkgYmUgYWRkZWQg YnkgZGV2ZWxvcGluZyBuZXcgaHlicmlkIE9BTSBtZXRob2QuDQoNClJlZ2FyZHMsDQpHcmVnDQoN Ck9uIFdlZCwgTWFyIDI5LCAyMDE3IGF0IDI6MzIgUE0sIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBv bGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+PiB3cm90ZToNCj4gPiBUaGVy ZSB3ZXJlIHNldmVyYWwgcXVlc3Rpb25zIHJlbGF0ZWQgdG8gc2NvcGUgYW5kIGFwcGxpY2FiaWxp dHkgaW4gdGhlIFdHDQo+IGRpc2N1c3Npb24g4oCTIGFuZCBldmVuIG1vcmUgcmVjZW50bHkgb24g dGhlIGxpc3QuIFRob3NlIGNhbiBlYXNpbHkgYmUgYWRkcmVzc2VkIGJ5DQo+IGFkZGluZyBwYXJh Z3JhcGggb24gYXBwbGljYWJpbGl0eSB0byBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRh IOKAkyB0aGVyZQ0KPiBpc27igJl0IGEgbmVlZCBmb3IgYSBkZWRpY2F0ZWQgcmVxdWlyZW1lbnRz IGRvY3VtZW50Lg0KPg0KPiBJIHRlbmQgdG8gYWdyZWUgd2l0aCB0aGlzLCBhbHRob3VnaCAiYSBw YXJhZ3JhcGgiIHNlZW1zIGEgbGl0dGxlIHRoaW4gdG8gbWUuIEkgdGhpbmsNCj4gdGhlcmUgd2Vy ZSBzb21lIHZhbGlkIHBvaW50cyBtYWRlIGluIHRoYXQgZGlzY3Vzc2lvbiBhYm91dCB0aGUgc2Nv cGUgb2YgdGhlDQo+IHByb3Bvc2FsIHRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZDogaXMgSU9BTSBt ZWFudCBmb3IgdXNlIHR1bm5lbC1lbmQtdG8tdHVubmVsLQ0KPiBlbmQgZW52aXJvbm1lbnQsICBl bmQtaG9zdC10by1lbmQtaG9zdCwgd2l0aGluIGEgc2luZ2xlIG5ldHdvcmsgYW5kL29yIGFjcm9z cw0KPiB0aGUgSW50ZXJuZXQuICBXaGF0IEkgd291bGQgc3VnZ2VzdCBpcyBhZGRpbmcgYSBzZWN0 aW9uIHRvIHRoZSBkYXRhIG1vZGVsIGRyYWZ0IG9uDQo+IGFwcGxpY2FiaWxpdHkgYW5kIGFzc3Vt cHRpb25zIGFib3V0IHRoZSBlbnZpcm9ubWVudCAtLSBib3RoIGFib3V0IHRoZSBkZXZpY2VzDQo+ IGFkZGluZyBJT0FNIHNpZ25hbHMgdG8gdHJhZmZpYyBhcyB3ZWxsIGFzIHRob3NlIGNvbnN1bWlu ZyB0aGVzZSBzaWduYWxzIGZyb20gdGhlDQo+IHdpcmUgYW5kIGFuYWx5emluZyB0aGVtIChwb3Nz aWJseSB3aXRoIHRoZSBjb29wZXJhdGlvbiBvZiBkZXZpY2VzIG5vdCBvbiB0aGUNCj4gd2lyZSkg LS0gc3VibWl0dGluZyBhIG5ldyByZXZpc2lvbiwgYW5kIHdlIGNhbiBydW4gYSBtb3JlIGZvcm1h bCBhZG9wdGlvbiBjYWxsIG9uDQo+IHRoYXQuDQoNCkFsdGhvdWdoIEkgd2FzIG9uZSBvZiB0aGUg cGVvcGxlIHJhaXNpbmcgdGhlICJuZWVkIiBmb3IgdGhlIHNjb3BlIGFuZCByZXF1aXJlbWVudHMs IEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBsZWFkaW5nIG9uIHdoZXRoZXIgdGhpcyBuZWVkcyB0byBi ZSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IG9uIGZvbGRlZCBpbnRvIHRoZSBkYXRhIGZvcm1hdCBk b2N1bWVudC4gU28gQnJpYW4ncyBwcm9wb3NhbCB3b3VsZCB3b3JrIGZvciBtZS4NCg0KVGh1cywg SSdkIGxvdmUgdG8gc2VlIHRoaXMgc2NvcGluZyB0ZXh0IGRyYWZ0ZWQgYW5kIGZsb2F0ZWQgdG8g dGhlIGxpc3QgYXMgYW4gZW1haWwgb3IgaW4gYSByZXZpc2lvbiBvZiB0aGUgZGF0YSBmb3JtYXQg ZG9jdW1lbnQuDQoNCkNoZWVycywNCkFkcmlhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8 bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwcG0NCg0KDQoNCg== --_000_B73302F65DCC404A944C743934B40F9Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KR3JlZywNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYWdyZWUgdGhhdCBhIHNoYXJl ZCB1bmRlcnN0YW5kaW5nIGFuZCBhbGlnbm1lbnQgb24gdGhlIHByb2JsZW0gc3BhY2UgaXMgY3Jp dGljYWxseSBpbXBvcnRhbnQuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB3ZSBoYXZlIGFscmVh ZHkgYmVlbiBkb2luZyB0aGF0IGV4dGVuc2l2ZWx5LCBpbmNsdWRpbmcgdGhlIHdvcmsgb24gcG90 ZW50aWFsIGNoYXJ0ZXIgdGV4dCBkaXNjdXNzZWQgaW4gT3BzYXdnLiBUaGF0IHdhcywgZm9yDQog ZXhhbXBsZSwgYSBkaXNjdXNzaW9uIHNvbGVseSBhYm91dCB0aGUgcHJvYmxlbSB0byBiZSBzb2x2 ZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5XaGF0IGNvbmNlcm5zIG1lIGlzIHRoZSBzdHJpY3Qgc2VyaWFsaXphdGlvbiBhbmQgd2F0 ZXJmYWxsIHlvdSBzZWVtIHRvIGJlIGFkdm9jYXRpbmcgZm9yLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCUIENhcmxvcy48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgMjYsIDIwMTcsIGF0IDk6MjIgQU0s IEdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiBj bGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9IiI+RGVhciBDYXJsb3MsDQo8ZGl2IGNsYXNzPSIiPnRoYW5rIHlvdSBm b3IgdGhlIHJlZmVyZW5jZS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSd2ZSBuZXZlciBj YWxsZWQgZm9yIHBlcmZlY3RpbmcgYnV0IGZvciByb3VnaCBjb25zZW5zdXMgb24gd2hhdCBwcm9i bGVtIHdlIG5lZWQgdG8gYWRkcmVzcy4gSG93LCBJTUhPLCBpcyBzZWNvbmRhcnkuIEFuZCB0aGF0 IGlzIHdoYXQgbWF5IGJlIG5vdCB3b3JraW5nIGluIHRoaXMgZGlzY3Vzc2lvbiAtIHdlJ3ZlIGJl ZW4gcHJlc2VudGVkIGFuc3dlciB0byBob3cgZG8gbWVhc3VyZW1lbnQgYmVmb3JlIHdlIGhhdmUg cmVhY2hlZA0KIGFuIGFncmVlbWVudCB0aGF0IHRoZXJlJ3MgYSBwcm9ibGVtIHRvIGJlIHNvbHZl ZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBXZWQsIEFwciAyNiwgMjAxNyBhdCA2OjEzIEFNLCBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSkNCjxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNw aWduYXRhQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNwaWduYXRhQGNpc2Nv LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 Im1fLTU2MDkzOTQwMzExNTE2NjU3NDNXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSIgY2xh c3M9IiI+RGVhciBHcmVnLDx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiIGNsYXNzPSIiPjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFz cz0iIj48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiIGNsYXNzPSIiPlNvbWV0aGluZyBs aWtlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJz LWluYmFuZC1vYW0tcmVxdWlyZW1lbnRzLTAzIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvPHdiciBjbGFzcz0iIj5kcmFmdC1icm9ja25lcnMt aW5iYW5kLW9hbS08d2JyIGNsYXNzPSIiPnJlcXVpcmVtZW50cy0wMzwvYT4/DQo8dSBjbGFzcz0i Ij48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIiBjbGFzcz0i Ij48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIiBjbGFzcz0iIj5Gb3IgdGhlIHJlY29yZCwgbXkgb3BpbmlvbjogcGVyZmVjdGlu ZyByZXF1aXJlbWVudHMgaXMgcGVyaGFwcyBub3QgdGhlIGJlc3QgdXNlIG9mIFdHIGN5Y2xlcy4g SG93ZXZlciwgcGxhY2luZyByZXF1aXJlbWVudHMgYXMgYSBzZXJpYWxpemVkIHJlcXVpc2l0ZSBi ZWZvcmUgcHJvZ3Jlc3NpbmcgcHJvdG9jb2wNCiB3b3JrIGlzIGNlcnRhaW5seSBoYXJtZnVsIGlu IHRoaXMgY2FzZS48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIiBjbGFzcz0iIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIiBjbGFzcz0iIj5UaGFua3MsPHUgY2xhc3M9 IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSIgY2xhc3M9 IiI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSIgY2xhc3M9IiI+LS0gQ2FybG9zLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0i Ij48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiIGNsYXNzPSIiPjx1IGNsYXNzPSIiPjwv dT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPkZyb206DQo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsiIGNsYXNzPSIiPmlwcG0gJmx0OzxhIGhy ZWY9Im1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5pcHBtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgR3JlZyBNaXJza3kg Jmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEFwcmlsIDI2LCAyMDE3IGF0IDU6MjIgQU08 YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5UbzogPC9iPkFkcmlhbiBGYXJyZWwgJmx0OzxhIGhy ZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ YWRyaWFuQG9sZGRvZy5jby51azwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6 IDwvYj5JUFBNIENoYWlycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG0tY2hhaXJzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aXBwbS1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0Oywg JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5pcHBtQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pcHBtQGlldGYub3JnPC9hPiZndDs8c3Bh biBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OiA8L2I+UmU6IFtp cHBtXSBWb3RlIGF0IElQUE0gc2Vzc2lvbjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+ PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFkcmlhbiwgZXQuIGFs LCA8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBz dHJvbmdseSBiZWxpZXZlIHRoYXQgaGF2aW5nIGFncmVlZCB1cG9uIGxpc3Qgb2YgcmVxdWlyZW1l bnRzIHRoYXQgYW5zd2VyIHF1ZXN0aW9ucyBXaGF0PyBhbmQgV2hlcmU/IHJhdGhlciB0aGFuIEhv dz8gaXMgdGhlIG1vc3QgYmVuZWZpY2lhbCBhbmQgbm90IG9ubHkgZm9yIHRoZSBkaXNjdXNzaW9u IG9mIGFwcGxpY2FiaWxpdHkgb2YgaW4tc2l0dSBPQU0uIFdoYXQgbmVlZHMgdG8gYmUgc29sdmVk LCBtZWFzdXJlZA0KIHRoYXQgaXMgbm90IGFtZWFzdXJlYWJsZSBieSBhbHJlYWR5IGV4aXN0aW5n IE9BTSBtZXRob2RzPyBJIHRoaW5rIHRoYXQgaWYgd2UgY2FuIGNvbXBpbGUgc3VjaCBsaXN0LCB0 aGVuIGl0IHdpbGwgYmUgbW9yZSBjbGVhciB3aGF0IHZhbHVlIG1heSBiZSBhZGRlZCBieSBkZXZl bG9waW5nIG5ldyBoeWJyaWQgT0FNIG1ldGhvZC48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1 IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkdyZWc8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Img1Ij4N CjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5i c3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBXZWQsIE1hciAyOSwgMjAxNyBhdCAyOjMyIFBNLCBBZHJpYW4gRmFycmVsICZsdDs8 YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+Jmd0OyB3cm90ZTo8dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjY2NjY2NjIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7ICZndDsgVGhlcmUgd2VyZSBzZXZlcmFsIHF1ZXN0aW9ucyByZWxhdGVkIHRvIHNj b3BlIGFuZCBhcHBsaWNhYmlsaXR5IGluIHRoZSBXRzxiciBjbGFzcz0iIj4NCiZndDsgZGlzY3Vz c2lvbiDigJMgYW5kIGV2ZW4gbW9yZSByZWNlbnRseSBvbiB0aGUgbGlzdC4gVGhvc2UgY2FuIGVh c2lseSBiZSBhZGRyZXNzZWQgYnk8YnIgY2xhc3M9IiI+DQomZ3Q7IGFkZGluZyBwYXJhZ3JhcGgg b24gYXBwbGljYWJpbGl0eSB0byBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS08d2JyIGNsYXNz PSIiPmRhdGEg4oCTIHRoZXJlPGJyIGNsYXNzPSIiPg0KJmd0OyBpc27igJl0IGEgbmVlZCBmb3Ig YSBkZWRpY2F0ZWQgcmVxdWlyZW1lbnRzIGRvY3VtZW50LjxiciBjbGFzcz0iIj4NCiZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7IEkgdGVuZCB0byBhZ3JlZSB3aXRoIHRoaXMsIGFsdGhvdWdoICZxdW90 O2EgcGFyYWdyYXBoJnF1b3Q7IHNlZW1zIGEgbGl0dGxlIHRoaW4gdG8gbWUuIEkgdGhpbms8YnIg Y2xhc3M9IiI+DQomZ3Q7IHRoZXJlIHdlcmUgc29tZSB2YWxpZCBwb2ludHMgbWFkZSBpbiB0aGF0 IGRpc2N1c3Npb24gYWJvdXQgdGhlIHNjb3BlIG9mIHRoZTxiciBjbGFzcz0iIj4NCiZndDsgcHJv cG9zYWwgdGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkOiBpcyBJT0FNIG1lYW50IGZvciB1c2UgdHVu bmVsLWVuZC10by10dW5uZWwtPGJyIGNsYXNzPSIiPg0KJmd0OyBlbmQgZW52aXJvbm1lbnQsJm5i c3A7IGVuZC1ob3N0LXRvLWVuZC1ob3N0LCB3aXRoaW4gYSBzaW5nbGUgbmV0d29yayBhbmQvb3Ig YWNyb3NzPGJyIGNsYXNzPSIiPg0KJmd0OyB0aGUgSW50ZXJuZXQuJm5ic3A7IFdoYXQgSSB3b3Vs ZCBzdWdnZXN0IGlzIGFkZGluZyBhIHNlY3Rpb24gdG8gdGhlIGRhdGEgbW9kZWwgZHJhZnQgb248 YnIgY2xhc3M9IiI+DQomZ3Q7IGFwcGxpY2FiaWxpdHkgYW5kIGFzc3VtcHRpb25zIGFib3V0IHRo ZSBlbnZpcm9ubWVudCAtLSBib3RoIGFib3V0IHRoZSBkZXZpY2VzPGJyIGNsYXNzPSIiPg0KJmd0 OyBhZGRpbmcgSU9BTSBzaWduYWxzIHRvIHRyYWZmaWMgYXMgd2VsbCBhcyB0aG9zZSBjb25zdW1p bmcgdGhlc2Ugc2lnbmFscyBmcm9tIHRoZTxiciBjbGFzcz0iIj4NCiZndDsgd2lyZSBhbmQgYW5h bHl6aW5nIHRoZW0gKHBvc3NpYmx5IHdpdGggdGhlIGNvb3BlcmF0aW9uIG9mIGRldmljZXMgbm90 IG9uIHRoZTxiciBjbGFzcz0iIj4NCiZndDsgd2lyZSkgLS0gc3VibWl0dGluZyBhIG5ldyByZXZp c2lvbiwgYW5kIHdlIGNhbiBydW4gYSBtb3JlIGZvcm1hbCBhZG9wdGlvbiBjYWxsIG9uPGJyIGNs YXNzPSIiPg0KJmd0OyB0aGF0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFsdGhvdWdo IEkgd2FzIG9uZSBvZiB0aGUgcGVvcGxlIHJhaXNpbmcgdGhlICZxdW90O25lZWQmcXVvdDsgZm9y IHRoZSBzY29wZSBhbmQgcmVxdWlyZW1lbnRzLCBJIGRvbid0IGhhdmUgYSBzdHJvbmcgbGVhZGlu ZyBvbiB3aGV0aGVyIHRoaXMgbmVlZHMgdG8gYmUgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBvbiBm b2xkZWQgaW50byB0aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQuIFNvIEJyaWFuJ3MgcHJvcG9zYWwg d291bGQgd29yayBmb3IgbWUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGh1cywgSSdk IGxvdmUgdG8gc2VlIHRoaXMgc2NvcGluZyB0ZXh0IGRyYWZ0ZWQgYW5kIGZsb2F0ZWQgdG8gdGhl IGxpc3QgYXMgYW4gZW1haWwgb3IgaW4gYSByZXZpc2lvbiBvZiB0aGUgZGF0YSBmb3JtYXQgZG9j dW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2hlZXJzLDxiciBjbGFzcz0iIj4N CkFkcmlhbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzx3YnIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpp cHBtIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aXBwbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0i IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3 YnIgY2xhc3M9IiI+bGlzdGluZm8vaXBwbTwvYT48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUg Y2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B73302F65DCC404A944C743934B40F9Bciscocom_-- From nobody Wed Apr 26 07:48:07 2017 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 0C39112EB68; Wed, 26 Apr 2017 07:48:04 -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 DtRwoYrIJDzM; Wed, 26 Apr 2017 07:48:01 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2567012EB62; Wed, 26 Apr 2017 07:48:01 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id y11so3415294oie.0; Wed, 26 Apr 2017 07:48:01 -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=6l4IVFd21bCAQTF7ytoCOi0EMomh5drv0b11SCi6rCw=; b=RDAnfpucbfxXSrm4oF56sSOnTH5P4w8ymeQ8neugNeY/JM0sVOwMw8luH2F3S7AOgV D1HWmhZv77vTDjl90KxuNDs0BCX1APJ9pIVdzB4KuutNt3lYXjMSHYupIaohoh6I8AJa xkz0JJm+Eo5irfHRaNPTwHSBSGsvn0MOQgNcDkFNG5w8NX4HnuMcLDP/hxzrHFqOYHEv iNvxmzsAFUvJHfSW768JM6DCQs+YpHXqc2rxW/ARUZQxlBNsSt7I7YvShAxGejRqEqBn nqZXteaEF4RVJWht4Yhg1lYJlkYDWTAVrucMyX24KrGxq5+CXT/aAgKQG9k8uqgH3prE RDsw== 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=6l4IVFd21bCAQTF7ytoCOi0EMomh5drv0b11SCi6rCw=; b=OmI0nXbdxzSwIdGqHcB2iZt1OKHBIfckAgpgQfHmmyflIp4xY16IQqoffqmnHYiGdk /jtjak7FRrIO7nONbBDju2WD6IqKifQS7ndnuuAaFD1mpiDNdIUaspyqsEVqKincrfse CCOPh6WatjwObfP6beBB9B86Unhmm5fd8b4gqR8ohtDylzQTCkBYXeP72i8K0Sy10z/j FkrRqXbPwaXNpZTtAKv1Af0uefRTq+1srfoxlOf4JnytJ7ZRe9nuFoa1R3L36MBk7cL7 FRNLVlIoJ3QUdRQEwYSgBwzEOiPSDcAu21hPUJdQhVxST7I9JI/wlMC4jvWezK1JYiBB fORA== X-Gm-Message-State: AN3rC/6J5EAB8hv6r2CR7knvM0d81jd2C36mraHvh40kPyA3ZrKJFonx +Uyt4H6mdDu5C57uqpXx4PonOgifIA== X-Received: by 10.202.97.85 with SMTP id v82mr69469oib.214.1493218080349; Wed, 26 Apr 2017 07:48:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.118 with HTTP; Wed, 26 Apr 2017 07:47:59 -0700 (PDT) In-Reply-To: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <1FCCBA3C-4553-4310-974B-3002A983BE7A@cisco.com> From: Greg Mirsky Date: Wed, 26 Apr 2017 07:47:59 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: Adrian Farrel , IPPM Chairs , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113d45f4406ed8054e12ed6a Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 26 Apr 2017 14:48:04 -0000 --001a113d45f4406ed8054e12ed6a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Carlos, thank you for the reference to the discussion in opsawg after the meeting in Seoul. After reading through I was left with expectation of the followup but I couldn't find any update since last January. I believe it will be beneficial for all interested to have joint discussion thread. Regards, Greg On Wed, Apr 26, 2017 at 7:21 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Greg, > > I agree that a shared understanding and alignment on the problem space is > critically important. My understanding is that we have already been doing > that extensively, including the work on potential charter text discussed = in > Opsawg. That was, for example, a discussion solely about the problem to b= e > solved. > > What concerns me is the strict serialization and waterfall you seem to be > advocating for. > > =E2=80=94 Carlos. > > On Apr 26, 2017, at 9:22 AM, Greg Mirsky wrote: > > Dear Carlos, > thank you for the reference. > I've never called for perfecting but for rough consensus on what problem > we need to address. How, IMHO, is secondary. And that is what may be not > working in this discussion - we've been presented answer to how do > measurement before we have reached an agreement that there's a problem to > be solved. > > Regards, > Greg > > On Wed, Apr 26, 2017 at 6:13 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Dear Greg, >> >> >> >> Something like https://tools.ietf.org/html/dr >> aft-brockners-inband-oam-requirements-03? >> >> >> >> For the record, my opinion: perfecting requirements is perhaps not the >> best use of WG cycles. However, placing requirements as a serialized >> requisite before progressing protocol work is certainly harmful in this >> case. >> >> >> >> Thanks, >> >> >> >> -- Carlos. >> >> >> >> *From: *ippm on behalf of Greg Mirsky < >> gregimirsky@gmail.com> >> *Date: *Wednesday, April 26, 2017 at 5:22 AM >> *To: *Adrian Farrel >> *Cc: *IPPM Chairs , "ippm@ietf.org" >> *Subject: *Re: [ippm] Vote at IPPM session >> >> >> >> Hi Adrian, et. al, >> >> I strongly believe that having agreed upon list of requirements that >> answer questions What? and Where? rather than How? is the most beneficia= l >> and not only for the discussion of applicability of in-situ OAM. What ne= eds >> to be solved, measured that is not ameasureable by already existing OAM >> methods? I think that if we can compile such list, then it will be more >> clear what value may be added by developing new hybrid OAM method. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Wed, Mar 29, 2017 at 2:32 PM, Adrian Farrel >> wrote: >> >> > > There were several questions related to scope and applicability in >> the WG >> > discussion =E2=80=93 and even more recently on the list. Those can eas= ily be >> addressed by >> > adding paragraph on applicability to draft-brockners-inband-oam-data = =E2=80=93 >> there >> > isn=E2=80=99t a need for a dedicated requirements document. >> > >> > I tend to agree with this, although "a paragraph" seems a little thin >> to me. I think >> > there were some valid points made in that discussion about the scope o= f >> the >> > proposal that should be addressed: is IOAM meant for use >> tunnel-end-to-tunnel- >> > end environment, end-host-to-end-host, within a single network and/or >> across >> > the Internet. What I would suggest is adding a section to the data >> model draft on >> > applicability and assumptions about the environment -- both about the >> devices >> > adding IOAM signals to traffic as well as those consuming these signal= s >> from the >> > wire and analyzing them (possibly with the cooperation of devices not >> on the >> > wire) -- submitting a new revision, and we can run a more formal >> adoption call on >> > that. >> >> Although I was one of the people raising the "need" for the scope and >> requirements, I don't have a strong leading on whether this needs to be = in >> a separate document on folded into the data format document. So Brian's >> proposal would work for me. >> >> Thus, I'd love to see this scoping text drafted and floated to the list >> as an email or in a revision of the data format document. >> >> Cheers, >> Adrian >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> >> > > > --001a113d45f4406ed8054e12ed6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jon,
apologies for the extended delay to address yo= ur comment. I'd like to add the following just before the Section 2.1:<= /div>
   Implementations of OWAMP and/or TWAMP MAY provide a configurati=
on
   knob to bypass the timestamp format negotiation process and to use
   the locally configured values instead.
Hope it captures the idea of and addresses your comment.

Regards,
Greg

<= div class=3D"gmail_extra">
On Mon, Mar 20, 20= 17 at 10:34 AM, Greg Mirsky <gregimirsky@gmail.com> wrot= e:
Hi Jon,
thank you= for kind consideration of the draft and thoughtful comment. Indeed, TWAMP = Test, and the time stamp format to be used, may be controlled by means othe= r than TWAMP Control, e.g., local configurable knob exposed via data model = or CLI. I'll work on text updates for the next version.

<= /div>
Regards,
Greg

On Fri,= Mar 17, 2017 at 2:01 PM, Jon Mitchell <jrmitche@puck.nether.net> wrote:
Reviewer: Jon Mitchel= l
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's<= br>
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These
comments were written with the intent of improving the operational
aspects of the
IETF drafts. Comments that are not addressed in last call may be
included in AD reviews
during the IESG review.=C2=A0 Document editors and WG chairs should treat these comments
just like any other last call comments.

Ready with Nits - this draft adds the ability to use PTP timestamps as
an alternative to NTP timestamps for active performance measurement
protocols OWAMP and TWAMP.=C2=A0 Although this draft does a good job of
discussing interoperability for both sides of the session having or
not having support for this operational capability, in several places
it states that if a send/receiver support this capability it must be
set to 1 in the flags.=C2=A0 However, only for TWAMP Light mode, this seems=
configurable.=C2=A0 This may just be my interpretation, but it probably
should state that local implementations MAY provide a configurable
knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even if
the capability is supported by the implementation.




--001a113d09de8f0dbb054cd28017-- From nobody Mon Apr 10 09:41:01 2017 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 C45A91296C6; Mon, 10 Apr 2017 09:40:52 -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 66WOeN6v-gTL; Mon, 10 Apr 2017 09:40:50 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 8E6FA129566; Mon, 10 Apr 2017 09:40:50 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b187so154839491oif.0; Mon, 10 Apr 2017 09:40:50 -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=a6m239Tsdy27cV5lAFh1uSx3arunxUdkB9xHNVcx9Us=; b=V0NoWUD5ij9zDTx2ltTpiHAa9d1SiQ77F7270Qo4zj72mng0U8eoLcfmH1L9wM0uPy QkPepvg1bpDuI2aR+mrriEGcoaDHbdp9A8R+EGGmuUJMIClzTdIHu/tWZ69ODs5+2hUe kGxcjgBTFketcnASHYHhMDf5AJ6R7Wu6ZHaAjnxwrJeymDo2MboY+/KkAFX10qzkIy5r lMxXKaNbNiopVB8uU5wgSplXQ24TiIFaVpCpK1m5fd6XYKb2HJ7wgxFgmYAfyjhSMoHy a8e0AK7AtSxim/ohhOeUVtBdUtDQZ4iF9bvL5RPT1ex1u42xupoAi019paEsDhNiYHIW Ofxw== 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=a6m239Tsdy27cV5lAFh1uSx3arunxUdkB9xHNVcx9Us=; b=XrdPVmpkahypYSYvzSO1XeLTchLQf+fbTrz22N0tWKP+Qm6r63uMXAXSWSlUnyXYWG pay8xoF5vvZjMzu6Yb+RukXKUXHetOSdFW3KXYWINmokULqwwRR73nzzgn4WuR6GMkJc XYtC5T9ceTsAvXjpyYT49pQhqFtPUz5B88iQH5z8lC7Dss9m31yFC08LYpdAeQrQXnLj n48kQK6OCypw3XPZzecKQGZrJf6HiOswdAxZt6gpSAqobOCckyGa6j21IphJ6KzxBxXy Wra8i8/n2alTPgyvZSqYMfhXRHJkSIDu1B4l2hH75mD4wNpjNWn0pWyhckG0kth7FTrg /RFw== X-Gm-Message-State: AFeK/H0oUCN5J5pv3qplzUlX039yGFv548cxx2F/YjdINgOWjaEGTtc3srRnx9N9zPjQKAR1sXneIxgE746ltg== X-Received: by 10.202.192.65 with SMTP id q62mr17217553oif.124.1491842449835; Mon, 10 Apr 2017 09:40:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.165 with HTTP; Mon, 10 Apr 2017 09:40:49 -0700 (PDT) In-Reply-To: <149183390250.3076.7292862107229671405.idtracker@ietfa.amsl.com> References: <149183390250.3076.7292862107229671405.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 10 Apr 2017 09:40:49 -0700 Message-ID: To: Benoit Claise Cc: The IESG , draft-ietf-ippm-twamp-time-format@ietf.org, Bill Cerveny , IPPM Chairs , "ippm@ietf.org" , Jon Mitchell Content-Type: multipart/alternative; boundary=001a113dd53a488ee7054cd2a3d4 Archived-At: Subject: Re: [ippm] Benoit Claise's No Objection on draft-ietf-ippm-twamp-time-format-05: (with COMMENT) 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, 10 Apr 2017 16:40:53 -0000 --001a113dd53a488ee7054cd2a3d4 Content-Type: text/plain; charset=UTF-8 Hi Benoit, thank you for the review and gentle reminder. I've prepared text to address Jon's suggestion by adding the following text: Implementations of OWAMP and/or TWAMP MAY provide a configuration knob to bypass the timestamp format negotiation process and to use the locally configured values instead. Hope it captures the idea. Regards, Greg On Mon, Apr 10, 2017 at 7:18 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-ippm-twamp-time-format-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Good feedback from Jon Mitchell, in his OPS-DIR review: > > Indeed, TWAMP Test, and the time stamp format to be used, may be > controlled by means other than TWAMP Control, e.g., local configurable > knob exposed via data model or CLI. I'll work on text updates for the > next version. > > Regards, > Greg > > On Fri, Mar 17, 2017 at 2:01 PM, Jon Mitchell > wrote: > > Reviewer: Jon Mitchell > Review result: Has Nits > > I have reviewed this document as part of the Operational > directorate's > > ongoing effort to review all IETF documents being processed by the > IESG. These > comments were written with the intent of improving the operational > aspects of the > IETF drafts. Comments that are not addressed in last call may be > included in AD reviews > during the IESG review. Document editors and WG chairs should > treat > these comments > just like any other last call comments. > > Ready with Nits - this draft adds the ability to use PTP timestamps > as > an alternative to NTP timestamps for active performance measurement > protocols OWAMP and TWAMP. Although this draft does a good job of > discussing interoperability for both sides of the session having or > not having support for this operational capability, in several > places > it states that if a send/receiver support this capability it must > be > set to 1 in the flags. However, only for TWAMP Light mode, this > seems > configurable. This may just be my interpretation, but it probably > should state that local implementations MAY provide a configurable > knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even > if > the capability is supported by the implementation. > > > --001a113dd53a488ee7054cd2a3d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,
thank you for the review and gentle reminde= r. I've prepared text to address Jon's suggestion by adding the fol= lowing text:
   Implementations of OWAMP and/or TWAMP MAY provide =
a configuration
   knob to bypass the timestamp format negotiation process and to use
   the locally configured values instead.
Hope it captures the idea.

Regard= s,
Greg

On Mon, Apr 10, 2017 at 7:18 AM, Benoit Claise <bclaise@cisco.= com> wrote:
Benoit Claise h= as entered the following ballot position for
draft-ietf-ippm-twamp-time-format-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Good feedback from Jon Mitchell, in his OPS-DIR review:

Indeed, TWAMP Test, and the time stamp format to be used, may be
controlled by means other than TWAMP Control, e.g., local configurable
knob exposed via data model or CLI. I'll work on text updates for the next version.

Regards,
Greg

On Fri, Mar 17, 2017 at 2:01 PM, Jon Mitchell <jrmitche@puck.nether.net>
wrote:

=C2=A0 =C2=A0 Reviewer: Jon Mitchell
=C2=A0 =C2=A0 Review result: Has Nits

=C2=A0 =C2=A0 I have reviewed this document as part of the Operational
directorate's

=C2=A0 =C2=A0 ongoing effort to review all IETF documents being processed b= y the
=C2=A0 =C2=A0 IESG.=C2=A0 These
=C2=A0 =C2=A0 comments were written with the intent of improving the operat= ional
=C2=A0 =C2=A0 aspects of the
=C2=A0 =C2=A0 IETF drafts. Comments that are not addressed in last call may= be
=C2=A0 =C2=A0 included in AD reviews
=C2=A0 =C2=A0 during the IESG review.=C2=A0 Document editors and WG chairs = should
treat
=C2=A0 =C2=A0 these comments
=C2=A0 =C2=A0 just like any other last call comments.

=C2=A0 =C2=A0 Ready with Nits - this draft adds the ability to use PTP time= stamps
as
=C2=A0 =C2=A0 an alternative to NTP timestamps for active performance measu= rement
=C2=A0 =C2=A0 protocols OWAMP and TWAMP.=C2=A0 Although this draft does a g= ood job of
=C2=A0 =C2=A0 discussing interoperability for both sides of the session hav= ing or
=C2=A0 =C2=A0 not having support for this operational capability, in severa= l
places
=C2=A0 =C2=A0 it states that if a send/receiver support this capability it = must
be
=C2=A0 =C2=A0 set to 1 in the flags.=C2=A0 However, only for TWAMP Light mo= de, this
seems
=C2=A0 =C2=A0 configurable.=C2=A0 This may just be my interpretation, but i= t probably
=C2=A0 =C2=A0 should state that local implementations MAY provide a configu= rable
=C2=A0 =C2=A0 knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2= even
if
=C2=A0 =C2=A0 the capability is supported by the implementation.



--001a113dd53a488ee7054cd2a3d4-- From nobody Mon Apr 10 09:48:36 2017 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 74E8A129AB8 for ; Mon, 10 Apr 2017 09:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 E0VsRw6YiAxR for ; Mon, 10 Apr 2017 09:48:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567C1127A91 for ; Mon, 10 Apr 2017 09:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18730; q=dns/txt; s=iport; t=1491842902; x=1493052502; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=km4TaG7ffaD2hO/AIZONhrCz0x5OW3NtJVaqim00CAo=; b=glFxa1K5pb+0xuGWgApAnLL4p9N044WL1R7yi6vByDXQtc+ruvID9NUk VNXXlTSpYZdWmVX9xxiU+8hcJ/lrV/OSTtN2mODKQePqS5PGkkHqvPKF8 UWqFuHtRT2XxONZKnxBBRwKqwo2QSH9Ga4vVqMtGjOYS0OFvWQTrWSm17 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAQCCtutY/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrYYELB4NfihORR5VXgg8hC4JCgzYCGoNJPxgBAgEBAQEBAQF?= =?us-ascii?q?rHQuFFQEBAQECAQEBIREzBwsFBwQCAQgRBAEBAwIREgMCAgIlCxQBCAgCBA4FC?= =?us-ascii?q?BOJbAgOqQWCJop9AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VFhHCDF4ERCgc?= =?us-ascii?q?BW4JHgl8FiSqTUQGGf4tQggiFLooUiGOLHAEfOH0IWxVBhFscgWN1AYchDxeBC?= =?us-ascii?q?oENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="13231201" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 16:48:20 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3AGmKuk020649 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 16:48:20 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 11:48:20 -0500 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.1210.000; Mon, 10 Apr 2017 11:48:20 -0500 From: "Frank Brockners (fbrockne)" To: "adrian@olddog.co.uk" CC: "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ALTeVSHHK04UeHAEB7HUBtbKGqypeAgAAD3ACAAAfTAIAAIx6AgAA2hgCAAJuA4IAAxDyAgAAcNwCAABufgIAA1nmggAsC85CAAc6ygIAEb/Fg Date: Mon, 10 Apr 2017 16:48:20 +0000 Message-ID: <4dc3569a45464f17b16371410a18c478@XCH-RCD-008.cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <5e4cb5e81cb04f39856b1f055fa3e831@XCH-RCD-008.cisco.com> <0a2501d2afb5$c70412c0$550c3840$@olddog.co.uk> In-Reply-To: <0a2501d2afb5$c70412c0$550c3840$@olddog.co.uk> 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.190.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 10 Apr 2017 16:48:35 -0000 SGkgQWRyaWFuLA0KDQp0aGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgaW5saW5l ICgiLi4uRkIiKS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFkcmlhbiBG YXJyZWwgW21haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrXSANClNlbnQ6IEZyZWl0YWcsIDcuIEFw cmlsIDIwMTcgMTc6NDQNClRvOiBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVA Y2lzY28uY29tPg0KQ2M6IGlwcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbaXBwbV0gVm90ZSBh dCBJUFBNIHNlc3Npb24NCg0KSGkgRnJhbmssDQoNClRoYW5rcyBmb3Igd3JpdGluZyB0aGlzIHRl eHQuIEl0IGlzIGEgZ29vZCBjbGFyaWZpY2F0aW9uIG9mIHRoZSBpbnRlbmRlZCBzY29wZSBhbmQs IEkgdGhpbmssIHdpbGwgaGVscCB0aGUgQURzIHdobyBzZWVtZWQgaW4gQ2hpY2FnbyB0byB0aGlu ayB0aGUgaW50ZW5kZWQgc2NvcGUgd2FzIG1vcmUgbGltaXRlZC4NCg0KVGhlIHNlbnRlbmNlIEkg aGF2ZSBzb21lIGNvbmNlcm4gb3ZlciBpczoNCg0KPiAgICBUaGUgb3BlcmF0b3INCj4gICAgb2Yg c3VjaCBhIGRvbWFpbiBNVVNUIHB1dCBwcm92aXNpb25zIGluIHBsYWNlIHRvIGVuc3VyZSB0aGF0 IGluLXNpdHUNCj4gICAgT0FNIGRhdGEgc3RheXMgd2l0aGluIHRoZSBzcGVjaWZpYyBkb21haW4g b25seSAoaS5lLiwgZG9lcyBub3QgbGVhaw0KPiAgICBiZXlvbmQgdGhlIGVkZ2UpIGFuZCBjb25z aWRlciBwb3RlbnRpYWwgaW1wYWN0IG9mIElPQU0gdG8gRUNNUA0KPiAgICBwcm9jZXNzaW5nLCBw YXRoIE1UVSBhbmQgSUNNUCBtZXNzYWdlIGhhbmRsaW5nLg0KDQpUbyB0ZWxsIGFuIG9wZXJhdG9y IHRvIHB1dCBwcm92aXNpb25zIGluIHBsYWNlIHRvIHByb3RlY3QgdGhlbXNlbHZlcyBhZ2FpbnN0 IGEgcHJvdG9jb2wgaXMgYSBiaXQgZGVsaWNhdGUuDQoNCk1heWJlIHlvdSBjb3VsZCBtYWtlIHRo aXMgbGVzcyBzZW5zaXRpdmUgYnkgZXhwbGFpbmluZzoNCg0KLSBXaGljaCBwcm92aXNpb25zIGFy ZSB0aGluZ3MgbGlrZSBwYWNrZXQgZmlsdGVycyB0aGF0IE1VU1QgYmUgY29uZmlndXJlZCANCiAg IGFuZCB3aGVyZSB0aGV5IGhhdmUgdG8gYmUgY29uZmlndXJlZC4gQXJlIHRoZXkgcGFja2V0IGRy b3AgZmlsdGVycz8NCiAgIENhbiB3ZSBhc3N1bWUgdGhhdCBpZiBpT0FNIHRyaWVzIHRvIGVzY2Fw ZSBmcm9tIGEgZG9tYWluIHRoZW4gdGhlcmUNCiAgIGlzIGEgbWlzYmVoYXZpbmcvbWlzY29uZmln dXJlZCBub2RlIHNvbWV3aGVyZT8NCg0KLSBXaGF0ICJjb25zaWRlcmluZyB0aGUgcG90ZW50aWFs IGltcGFjdCIgcmVhbGx5IG1lYW5zLiBJIHRoaW5rIHRoYXQgYXMNCiAgIHdvcmRlZCBpdCBtZWFu cyAidGhpbmsgYWJvdXQgaXQgYW5kIGlmIHlvdSBhcmUgd29ycmllZCwgZG9uJ3QgdXNlIGlPQU0i DQogICB3aGljaCBpcyBwcm9iYWJseSBub3QgdGhlIGVmZmVjdCB5b3Ugd2FudGVkIHRvIGFjaGll dmUgOi0pICBCdXQgb3RoZXJ3aXNlLA0KICAgd2hhdCBpcyB0aGUgb3BlcmF0b3Igc3VwcG9zZWQg dG8gZG8/IFdvcnJ5PyBDb25maWd1cmUgc29tZXRoaW5nPyBUdW5lDQogICBpT0FNIGluIHNvbWUg d2F5Pw0KDQouLi5GQjogU2FyYWggbWVudGlvbmVkIGEgc2ltaWxhciBjb25jZXJuIChzZWUgbXkg ZWFybGllciBlbWFpbCkuICBBbmQgd2hpbGUgdGhlIGRldGFpbGVkIGNvbnNpZGVyYXRpb25zIGZv ciB0aGUgaW1wYWN0IGFyZSB0cmFuc3BvcnQgcHJvdG9jb2wgZGVwZW5kZW50IGFuZCBhcyBzdWNo IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IGF0IGhhbmQgdGhhdCBkaXNjdXNzZXMg dGhlIGRhdGEtZmllbGRzIGFuZCBkYXRhLXR5cGVzIGZvciBJT0FNLCBJIGFncmVlIHRoYXQgaXQg ZG9lcyBtYWtlIHNlbnNlIHRvIHByb3ZpZGUgc29tZSBmdXJ0aGVyIGNsYXJpZmljYXRpb24gYW5k IGF0IGxlYXN0IG1lbnRpb24gYSBjb3VwbGUgb2YgZXhhbXBsZSBjYXNlcy4gDQoNCkhvdyBhYm91 dDogIlRoZSBvcGVyYXRvciBvZiBzdWNoIGEgZG9tYWluIE1VU1QgcHV0IHByb3Zpc2lvbnMgaW4g cGxhY2UgdG8gZW5zdXJlIHRoYXQgaW4tc2l0dSBPQU0gZGF0YSBzdGF5cyB3aXRoaW4gdGhlIHNw ZWNpZmljIGRvbWFpbiBvbmx5IChpLmUuLCBkb2VzIG5vdCBsZWFrIGJleW9uZCB0aGUgZWRnZSkg dXNpbmcgZm9yIGV4YW1wbGUgcGFja2V0IGZpbHRlcmluZyBtZXRob2RzLiBUaGUgb3BlcmF0b3Ig U0hPVUxEIGNvbnNpZGVyIHBvdGVudGlhbCBvcGVyYXRpb25hbCBpbXBhY3Qgb2YgSU9BTSB0byBt ZWNoYW5pc21zIHN1Y2ggYXMgRUNNUCBwcm9jZXNzaW5nIChlLmcuIGxvYWQtYmFsYW5jaW5nIHNj aGVtZXMgYmFzZWQgb24gcGFja2V0IGxlbmd0aCBjb3VsZCBiZSBpbXBhY3RlZCBieSB0aGUgaW5j cmVhc2VkIHBhY2tldCBzaXplIGR1ZSB0byBJT0FNKSwgcGF0aCBNVFUgKGkuZS4gZW5zdXJlIHRo YXQgdGhlIE1UVSBvZiBhbGwgbGlua3Mgd2l0aGluIGEgZG9tYWluIGlzIHN1ZmZpY2llbnRseSBs YXJnZSB0byBzdXBwb3J0IHRoZSBpbmNyZWFzZWQgcGFja2V0IHNpemUgZHVlIHRvIElPQU0pIGFu ZCBJQ01QIG1lc3NhZ2UgaGFuZGxpbmcgKGkuZS4gaW4gY2FzZSBvZiBhIG5hdGl2ZSBJUHY2IHRy YW5zcG9ydCwgSU9BTSBzdXBwb3J0IGZvciBJQ01QdjYgRWNobyBSZXF1ZXN0L1JlcGx5IGNvdWxk IGRlc2lyZWQgd2hpY2ggd291bGQgdHJhbnNsYXRlIGludG8gSUNNUHY2IGV4dGVuc2lvbnMgdG8g ZW5hYmxlIElPQU0gZGF0YSBmaWVsZHMgdG8gYmUgY29waWVkIGZyb20gYW4gRWNobyBSZXF1ZXN0 IG1lc3NhZ2UgdG8gYW4gRWNobyBSZXBseSBtZXNzYWdlKS4iDQoNCg0KDQpJIGFtIGFsc28gbm90 IHN1cmUgYWJvdXQgdGhlIGZ1bGwgZXh0ZW50IG9mIHRoZSBmdW5jdGlvbmFsIHNjb3BlIGhlcmUu DQpDb25zaWRlciBhIHBhY2tldCBnb2luZyBmcm9tIEEgdG8gWi4NCkl0IGVudGVycyB0aGUgaU9B TS1hd2FyZSBkb21haW4gYXQgQiBhbmQgZXhpdHMgYXQgWS4NCllvdSBoYXZlIGNlcnRhaW5seSBk ZWZpbmVkIHRoYXQgSSBjYW4gcnVuIGlPQU0gZnJvbSBCIHRvIFkuDQpJIGNhbm5vdCBxdWl0ZSB0 ZWxsIHdoZXRoZXIgeW91IGludGVuZCB0aGF0IGlPQU0gaXMgb25seSB1c2VkIGlmIEIgaXMgYSBw b2ludCBvZiBlbmNhcHN1bGF0aW9uLiBJbiBvdGhlciB3b3JkcywgaXMgQi4uLlkgYSB0dW5uZWws IG9yIGNhbiBpT0FNIGJlIGFwcGxpZWQgYXQgQiB0byB0aGUgbmF0aXZlIHBhY2tldCB0aGF0IGlz IGZsb3dpbmcgQS4uLlogd2l0aG91dCBmdXJ0aGVyIGVuY2Fwc3VsYXRpb24/DQoNCi4uLkZCOiBX aGF0ICJJT0FNIGRhdGEtZmllbGRzIGVuY2Fwc3VsYXRpb24iIHRyYW5zbGF0ZXMgdG8gaXMgcmVh bGx5IHRyYW5zcG9ydCBwcm90b2NvbCBkZXBlbmRlbnQsIGkuZS4gd2hldGhlciBpdCBpcyBhICJ0 dW5uZWwiIHdpbGwgZGVwZW5kZW50IG9uIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgdXNlZC4gQXMg c3VjaCwgaXQgd291bGQgbmVlZCB0byBiZSBkZWFsdCB3aXRoIGluIHRoZSBJLURzIHRoYXQgc3Bl Y2lmeSB0aGUgdHJhbnNwb3J0LiBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS10cmFuc3BvcnQt MDMgbGlzdHMgYSBjb3VwbGUgb2YgaWRlYXMsIHdoaWNoIHdlIGNvdWxkLCBidXQgZG9uJ3QgaGF2 ZSB0byBsZXZlcmFnZS4gDQoNCkNvbnNpZGVyIHNvbWUgdHJhbnNpdCBub2RlcyBDIGFuZCBYIHdp dGhpbiB0aGUgaU9BTS1hd2FyZSBkb21haW4uIEkgYWxzbyBjYW4ndCB0ZWxsIHdoZXRoZXIgQyBj YW4gYmUgdGhlIGluaXRpYXRpb24gcG9pbnQgZm9yIGlPQU0gYW5kIFggdGhlIHRlcm1pbmF0aW9u IHBvaW50LiBJZiBzbywgY2FuIHRoaXMgYmUgZG9uZSB3aXRob3V0IHJlcXVpcmluZyBhZGRpdGlv bmFsIGVuY2Fwc3VsYXRpb24sIG9yIGRvZXMgQy4uLlggaGF2ZSB0byBiZSBhIHR1bm5lbCB3aXRo aW4gdGhlIGRvbWFpbiAoZWZmZWN0aXZlbHkgY3JlYXRpbmcgYSBsYXllcik/DQoNCi4uLkZCOiBU aGF0IHdvdWxkIGluZGVlZCBsZWFkIHRvIGEgbGF5ZXJlZCBJT0FNIGRlcGxveW1lbnQsIGkuZS4g eW91IGhhdmUgeW91ciBEb21haW4xIHdoaWNoIGlzIChCIHRvIFkpIGFuZCB0aGVuIGhhdmUgYSBz ZWNvbmQgRG9tYWluMiB3aXRoaW4gRG9tYWluMSB3aGljaCBpcyAoWCB0byBDKS4gZHJhZnQtYnJv Y2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wNCBhbHJlYWR5IG1lbnRpb25zIHRoYXQgSU9BTSBjb3Vs ZCBiZSBsYXllcmVkLiBUaGUgc3BlY2lmaWNzIG9uIGluc2VydGlvbi9yZW1vdmFsIG9mIElPQU0g ZGF0YS1maWVsZHMgd291bGQgYWdhaW4gYmUgZGVmaW5lZCBpbiBhbiBJLUQgd2hpY2ggZGVhbHMg d2l0aCBlbmNhcCBmb3IgYSBzcGVjaWZpYyB0cmFuc3BvcnQgcHJvdG9jb2wuDQoNCkkgYW0gYXdh cmUgdGhhdCB0aGVyZSBpcyBhbiBvdmVybGFwIGJldHdlZW4gc2NvcGUgYW5kIHNvbHV0aW9uIGlu IHRoZSBhbnN3ZXJzIHRvIG15IHF1ZXN0aW9ucy4gSSBhbSBub3QgdHJ5aW5nIHRvIGRpZyBpbnRv IHRoZSBzb2x1dGlvbnMsIGJ1dCBJIGFtIGNvbmNlcm5lZCB0aGF0IHdpdGhvdXQgdW5kZXJzdGFu ZGluZyB0aGUgZXh0ZW50IG9mIHRoZSBzY29wZSB3ZSB3aWxsIGVpdGhlciBkZXZlbG9wIHNvbHV0 aW9ucyB0aGF0IGRvbid0IGZpdCB0aGUgaW50ZW5kZWQgc2NvcGUsIG9yIHdlIHdpbGwgZGV2ZWxv cCBzb2x1dGlvbnMgdGhhdCwgd2hlbiBhcHBsaWVkIHRvIHRoZSBmdWxsIHNjb3BlLCBjYXVzZSBh bGFybWluZyB0aGluZ3MgdG8gaGFwcGVuLg0KDQouLi5GQjogQWdyZWVkLiBUaGVyZSBpcyBzb21l IG5lZWQgdG8gaGF2ZSBhICJtZW50YWwgbW9kZWwiIGluIG1pbmQgaG93IHRoZSBJT0FNIGRhdGEt ZmllbGRzIHdvdWxkIGJlIGNhcnJpZWQsIGV2ZW4gdGhvdWdoIHdlIHdvdWxkIG5vdCBiZSBhYmxl IHRvIHRhY2tsZSB0aGUgc3BlY2lmaWNzIG9uIHRoYXQgaW4gdGhlIEktRCBvbiBJT0FNIGRhdGEt ZmllbGRzLiBUaGlzIHdhcyB0aGUgcmVhc29uIHdoeSB3ZSBvcmlnaW5hbGx5IHB1Ymxpc2hlZCBk cmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS10cmFuc3BvcnQgLSBpdCB3YXMgbm90IHRvIHByZWVt cHQgYW55IHN0YW5kYXJkaXphdGlvbiBlZmZvcnQgYnV0IHRvIGp1c3QgcHJvdmlkZSBpZGVhcy9j bGFyaWZpY2F0aW9uIGhvdyB0aGUgZGF0YS1maWVsZHMgd291bGQgYWN0dWFsbHkgYmUgaW5zZXJ0 ZWQgYW5kIGNhcnJpZWQuDQoNCkNoZWVycywgRnJhbmsgDQoNCkNoZWVycywNCkFkcmlhbg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEZyYW5rIEJyb2NrbmVycyAoZmJy b2NrbmUpIFttYWlsdG86ZmJyb2NrbmVAY2lzY28uY29tXQ0KPiBTZW50OiAwNiBBcHJpbCAyMDE3 IDE4OjA5DQo+IFRvOiBBZHJpYW4gRmFycmVsIChhZHJpYW5Ab2xkZG9nLmNvLnVrKSAoYWRyaWFu QG9sZGRvZy5jby51aykNCj4gU3ViamVjdDogRlc6IFtpcHBtXSBWb3RlIGF0IElQUE0gc2Vzc2lv bg0KPiANCj4gSGkgQWRyaWFuLA0KPiANCj4gdGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb25zIGFu ZCBjb250aW51b3VzIGRyaXZlIHRvIGluY2x1ZGUgYSBzY29wZSANCj4gc2VjdGlvbiBpbnRvIGRy YWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEuIERvZXMgdGhlIG5ldyBzZWN0aW9uIDMgDQo+ IChzZWUgYmVsb3cpIG1lZXQgd2hhdCB5b3UgaGFkIGluIG1pbmQ/DQo+IA0KPiBUaGFua3MsIEZy YW5rDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHBtIFttYWls dG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRnJhbmsgQnJvY2tuZXJzDQo+ IChmYnJvY2tuZSkNCj4gU2VudDogRnJlaXRhZywgMzEuIE3DpHJ6IDIwMTcgMDc6MjgNCj4gVG86 IE1PUlRPTiwgQUxGUkVEIEMgKEFMKSA8YWNtb3J0b25AYXR0LmNvbT47IGFkcmlhbkBvbGRkb2cu Y28udWs7IA0KPiAnQnJpYW4gVHJhbW1lbGwgKElFVEYpJyA8aWV0ZkB0cmFtbWVsbC5jaD4NCj4g Q2M6ICdJUFBNIENoYWlycycgPGlwcG0tY2hhaXJzQGlldGYub3JnPjsgaXBwbUBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uDQo+IA0KPiBUaGFua3Mg Zm9yIHRoZSBzdWdnZXN0aW9ucyBhbmQgY29tbWVudHMuIFdlJ3ZlIHBvc3RlZCBhIG5ldyByZXZp c2lvbiANCj4gb2YgZHJhZnQtIGJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEuDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDQudHh0IA0K PiBpbmNsdWRlcyBzZWN0aW9uIDMgb24gU2NvcGUsIEFwcGxpY2FiaWxpdHksIGFuZCBBc3N1bXB0 aW9ucywgY2FwdHVyaW5nIA0KPiB0aGUgZGlzY3Vzc2lvbiB3ZSBoYWQgaW4gdGhlIFdHIG1lZXRp bmcgYW5kIG9uIHRoZSBsaXN0LiBXZSd2ZSBhbHNvIA0KPiB1cGRhdGVkIHRoZSBpbnRyb2R1Y3Rp b24gdG8gcmVmZXIgdG8gUkZDNzc5OSBhbmQgY2xhc3NpZnkgaW4tc2l0dSBPQU0gYXBwcm9wcmlh dGVseSBhcyBoeWJyaWQsIHR5cGUtMSBPQU0uDQo+IA0KPiBGb3IgZXZlcnlvbmUncyBiZW5lZml0 LCBoZXJlIGlzIGEgcXVvdGUgb2YgdGhlIG5ldyBzZWN0aW9uIDM6DQo+IA0KPiAzLiAgU2NvcGUs IEFwcGxpY2FiaWxpdHksIGFuZCBBc3N1bXB0aW9ucw0KPiANCj4gICAgSW4tc2l0dSBPQU0gZGVw bG95bWVudCBhc3N1bWVzIGEgc2V0IG9mIGNvbnRyYWludHMsIHJlcXVpcmVtZW50cywgYW5kDQo+ ICAgIGd1aWRpbmcgcHJpbmNpcGxlcyB3aGljaCBhcmUgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlv bi4NCj4gDQo+ICAgIFNjb3BlOiBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGRhdGEgZmllbGRz IGFuZCBhc3NvY2lhdGVkIGRhdGENCj4gICAgdHlwZXMgZm9yIGluLXNpdHUgT0FNLiAgVGhlIGlu LXNpdHUgT0FNIGRhdGEgZmllbGQgY2FuIGJlIHRyYW5zcG9ydGVkDQo+ICAgIGJ5IGEgdmFyaWV0 eSBvZiB0cmFuc3BvcnQgcHJvdG9jb2xzLCBpbmNsdWRpbmcgTlNILCBTZWdtZW50IFJvdXRpbmcs DQo+ICAgIFZYTEFOLUdQRSwgR2VuZXZlLCBJUHY2LCBvciBJUHY0LiAgRW5jYXBzdWxhdGlvbiBk ZXRhaWxzIGZvciB0aGVzZQ0KPiAgICBkaWZmZXJlbnQgdHJhbnNwb3J0IHByb3RvY29scyBhcmUg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCj4gDQo+ICAgIERlcGxveW1lbnQg ZG9tYWluIChvciBzY29wZSkgb2YgaW4tc2l0dSBPQU0gZGVwbG95bWVudDogSU9BTSBpcyBhDQo+ ICAgIG5ldHdvcmsgZG9tYWluIGZvY3VzZWQgZmVhdHVyZSwgd2l0aCAibmV0d29yayBkb21haW4i IGJlaW5nIGEgc2V0IG9mDQo+ICAgIG5ldHdvcmsgZGV2aWNlcyBvciBlbnRpdGllcyB3aXRoaW4g YSBzaW5nbGUgYWRtaW5pc3RyYXRpb24uICBGb3INCj4gICAgZXhhbXBsZSwgYSBuZXR3b3JrIGRv bWFpbiBjYW4gaW5jbHVkZSBhbiBlbnRlcnByaXNlIGNhbXB1cyB1c2luZw0KPiAgICBwaHlzaWNh bCBjb25uZWN0aW9ucyBiZXR3ZWVuIGRldmljZXMgb3IgYW4gb3ZlcmxheSBuZXR3b3JrIHVzaW5n DQo+ICAgIHZpcnR1YWwgY29ubmVjdGlvbnMgLyB0dW5uZWxzIGZvciBjb25uZWN0aXZpdHkgYmV0 d2VlbiBzYWlkIGRldmljZXMuDQo+ICAgIEEgbmV0d29yayBkb21haW4gaXMgZGVmaW5lZCBieSBp dHMgcGVyaW1pdGVyIG9yIGVkZ2UuICBUaGUgb3BlcmF0b3INCj4gICAgb2Ygc3VjaCBhIGRvbWFp biBNVVNUIHB1dCBwcm92aXNpb25zIGluIHBsYWNlIHRvIGVuc3VyZSB0aGF0IGluLXNpdHUNCj4g ICAgT0FNIGRhdGEgc3RheXMgd2l0aGluIHRoZSBzcGVjaWZpYyBkb21haW4gb25seSAoaS5lLiwg ZG9lcyBub3QgbGVhaw0KPiAgICBiZXlvbmQgdGhlIGVkZ2UpIGFuZCBjb25zaWRlciBwb3RlbnRp YWwgaW1wYWN0IG9mIElPQU0gdG8gRUNNUA0KPiAgICBwcm9jZXNzaW5nLCBwYXRoIE1UVSBhbmQg SUNNUCBtZXNzYWdlIGhhbmRsaW5nLg0KPiANCj4gICAgSW4tc2l0dSBPQU0gY29udHJvbCBwb2lu dHM6IElPQU0gZGF0YSBmaWVsZHMgYXJlIGFkZGVkIHRvIG9yIHJlbW92ZWQNCj4gICAgZnJvbSB0 aGUgbGl2ZSB1c2VyIHRyYWZmaWMgYnkgdGhlIGRldmljZXMgd2hpY2ggZm9ybSB0aGUgZWRnZSBv ZiBhDQo+ICAgIGRvbWFpbi4gIERldmljZXMgd2l0aGluIGFuIElPQU0gZG9tYWluIGNhbiB1cGRh dGUgYW5kL29yIGFkZCBJT0FNDQo+ICAgIGRhdGEtZmllbGRzLiAgRG9tYWluIGVkZ2UgZGV2aWNl cyBjYW4gYmUgaG9zdHMgb3IgbmV0d29yayBkZXZpY2VzLg0KPiANCj4gICAgVHJhZmZpYy1zZXRz IHRoYXQgaW4tc2l0dSBPQU0gaXMgYXBwbGllZCB0bzogSU9BTSBjYW4gYmUgZGVwbG95ZWQgb24N Cj4gICAgYWxsIG9yIG9ubHkgb24gc3Vic2V0cyBvZiB0aGUgbGl2ZSB1c2VyIHRyYWZmaWMuICBJ dCBTSE9VTEQgYmUNCj4gICAgcG9zc2libGUgdG8gZW5hYmxlIGluLXNpdHUgT0FNIG9uIGEgc2Vs ZWN0ZWQgc2V0IG9mIHRyYWZmaWMgKGUuZy4sDQo+ICAgIHBlciBpbnRlcmZhY2UsIGJhc2VkIG9u IGFuIGFjY2VzcyBjb250cm9sIGxpc3Qgb3IgZmxvdyBzcGVjaWZpY2F0aW9uDQo+ICAgIGRlZmlu aW5nIGEgc3BlY2lmaWMgc2V0IG9mIHRyYWZmaWMsIGV0Yy4pICBUaGUgc2VsZWN0ZWQgc2V0IG9m DQo+ICAgIHRyYWZmaWMgY2FuIGFsc28gYmUgYWxsIHRyYWZmaWMuDQo+IA0KPiAgICBFbmNhcHN1 bGF0aW9uIGluZGVwZW5kZW5jZTogRGF0YSBmb3JtYXRzIGZvciBpbi1zaXR1IE9BTSBTSE9VTEQg YmUNCj4gICAgZGVmaW5lZCBpbiBhIHRyYW5zcG9ydC1pbmRlcGVuZGVudCBtYW5uZXIuICBJbi1z aXR1IE9BTSBhcHBsaWVzIHRvIGENCj4gICAgdmFyaWV0eSBvZiBlbmNhcHN1bGF0aW5nIHByb3Rv Y29scy4gIEEgZGVmaW5pdGlvbiBvZiBob3cgSU9BTSBkYXRhDQo+ICAgIGZpZWxkcyBhcmUgY2Fy cmllZCBieSBkaWZmZXJlbnQgdHJhbnNwb3J0IHByb3RvY29scyBpcyBvdXRzaWRlIHRoZQ0KPiAg ICBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gICAgTGF5ZXJpbmc6IElmIHNldmVyYWwg ZW5jYXBzdWxhdGlvbiBwcm90b2NvbHMgKGUuZy4sIGluIGNhc2Ugb2YNCj4gICAgdHVubmVsaW5n KSBhcmUgc3RhY2tlZCBvbiB0b3Agb2YgZWFjaCBvdGhlciwgaW4tc2l0dSBPQU0gZGF0YS1yZWNv cmRzDQo+ICAgIGNvdWxkIGJlIHByZXNlbnQgYXQgZXZlcnkgbGF5ZXIuICBUaGUgYmVoYXZpb3Ig Zm9sbG93cyB0aGUgc2hpcHMtaW4tDQo+ICAgIHRoZS1uaWdodCBtb2RlbC4NCj4gDQo+ICAgIENv bWJpbmF0aW9uIHdpdGggYWN0aXZlIE9BTSBtZWNoYW5pc21zOiBJbi1zaXR1IE9BTSBTSE9VTEQg YmUgdXNhYmxlDQo+ICAgIGZvciBhY3RpdmUgbmV0d29yayBwcm9iaW5nLCBlbmFibGluZyBmb3Ig ZXhhbXBsZSBhIGN1c3RvbWl6ZWQgdmVyc2lvbg0KPiAgICBvZiB0cmFjZXJvdXRlLiAgRGVjYXBz dWxhdGluZyBpbi1zaXR1IE9BTSBub2RlcyBtYXkgaGF2ZSBhbiBhYmlsaXR5DQo+ICAgIHRvIHNl bmQgdGhlIGluLXNpdHUgT0FNIGluZm9ybWF0aW9uIHJldHJpZXZlZCBmcm9tIHRoZSBwYWNrZXQg YmFjayB0bw0KPiAgICB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBvciB0byB0aGUg ZW5jYXBzdWxhdGluZyBub2RlLg0KPiANCj4gICAgSW0tc2l0dSBPQU0gaW1wbGVtZW50YXRpb246 IFRoZSBJT0FNIGRhdGEtZmllbGQgZGVmaW5pdGlvbnMgdGFrZSB0aGUNCj4gICAgc3BlY2lmaWNz IG9mIGRldmljZXMgd2l0aCBoYXJkd2FyZSBkYXRhLXBsYW5lIGFuZCBzb2Z0d2FyZSBkYXRhLXBs YW5lDQo+ICAgIGludG8gYWNjb3VudC4NCj4gDQo+IFRob3VnaHRzL2NvbW1lbnRzPyBXaXRoIHRo ZXNlIGNoYW5nZXMsIGFyZSB3ZSBhYmxlIHRvIGtpY2stb2ZmIGFuIA0KPiBhZG9wdGlvbiBjYWxs Pw0KPiANCj4gVGhhbmtzLCBGcmFuaw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogTU9SVE9OLCBBTEZSRUQgQyAoQUwpIFttYWlsdG86YWNtb3J0b25AYXR0LmNvbV0N Cj4gU2VudDogTWl0dHdvY2gsIDI5LiBNw6RyeiAyMDE3IDE4OjExDQo+IFRvOiBhZHJpYW5Ab2xk ZG9nLmNvLnVrOyAnQnJpYW4gVHJhbW1lbGwgKElFVEYpJyA8aWV0ZkB0cmFtbWVsbC5jaD47IA0K PiBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVAY2lzY28uY29tPg0KPiBDYzog J0lQUE0gQ2hhaXJzJyA8aXBwbS1jaGFpcnNAaWV0Zi5vcmc+OyBpcHBtQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJFOiBbaXBwbV0gVm90ZSBhdCBJUFBNIHNlc3Npb24NCj4gDQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KPiA+IFNlbnQ6IFdlZG5lc2RheSwg TWFyY2ggMjksIDIwMTcgNTozMiBQTQ0KPiA+IFRvOiAnQnJpYW4gVHJhbW1lbGwgKElFVEYpJzsg J0ZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpJw0KPiA+IENjOiAnSVBQTSBDaGFpcnMnOyBpcHBt QGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtpcHBtXSBWb3RlIGF0IElQUE0gc2Vzc2lvbg0K PiA+DQo+ID4gPiA+IFRoZXJlIHdlcmUgc2V2ZXJhbCBxdWVzdGlvbnMgcmVsYXRlZCB0byBzY29w ZSBhbmQgYXBwbGljYWJpbGl0eSANCj4gPiA+ID4gaW4gdGhlIFdHDQo+ID4gPiBkaXNjdXNzaW9u IOKAkyBhbmQgZXZlbiBtb3JlIHJlY2VudGx5IG9uIHRoZSBsaXN0LiBUaG9zZSBjYW4gZWFzaWx5 IA0KPiA+ID4gYmUgYWRkcmVzc2VkIGJ5IGFkZGluZyBwYXJhZ3JhcGggb24gYXBwbGljYWJpbGl0 eSB0byANCj4gPiA+IGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEg4oCTIHRoZXJlIGlz buKAmXQgYSBuZWVkIGZvciBhIA0KPiA+ID4gZGVkaWNhdGVkDQo+IHJlcXVpcmVtZW50cyBkb2N1 bWVudC4NCj4gPiA+DQo+ID4gPiBJIHRlbmQgdG8gYWdyZWUgd2l0aCB0aGlzLCBhbHRob3VnaCAi YSBwYXJhZ3JhcGgiIHNlZW1zIGEgbGl0dGxlIA0KPiA+ID4gdGhpbiB0byBtZS4gSSB0aGluayB0 aGVyZSB3ZXJlIHNvbWUgdmFsaWQgcG9pbnRzIG1hZGUgaW4gdGhhdCANCj4gPiA+IGRpc2N1c3Np b24gYWJvdXQgdGhlIHNjb3BlIG9mIHRoZSBwcm9wb3NhbCB0aGF0IHNob3VsZCBiZSBhZGRyZXNz ZWQ6DQo+ID4gPiBpcyBJT0FNIG1lYW50IGZvciB1c2UgdHVubmVsLWVuZC0gdG8tdHVubmVsLSBl bmQgZW52aXJvbm1lbnQsIA0KPiA+ID4gZW5kLWhvc3QtdG8tZW5kLWhvc3QsIHdpdGhpbiBhIHNp bmdsZSBuZXR3b3JrIGFuZC9vciBhY3Jvc3MgdGhlIA0KPiA+ID4gSW50ZXJuZXQuICBXaGF0IEkg d291bGQgc3VnZ2VzdCBpcyBhZGRpbmcgYSBzZWN0aW9uIHRvIHRoZSBkYXRhIA0KPiA+ID4gbW9k ZWwgZHJhZnQgb24gYXBwbGljYWJpbGl0eSBhbmQgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGVudmly b25tZW50DQo+ID4gPiAtLSBib3RoIGFib3V0IHRoZSBkZXZpY2VzIGFkZGluZyBJT0FNIHNpZ25h bHMgdG8gdHJhZmZpYyBhcyB3ZWxsIA0KPiA+ID4gYXMgdGhvc2UgY29uc3VtaW5nIHRoZXNlIHNp Z25hbHMgZnJvbSB0aGUgd2lyZSBhbmQgYW5hbHl6aW5nIHRoZW0gDQo+ID4gPiAocG9zc2libHkg d2l0aCB0aGUgY29vcGVyYXRpb24gb2YgZGV2aWNlcyBub3Qgb24gdGhlDQo+ID4gPiB3aXJlKSAt LSBzdWJtaXR0aW5nIGEgbmV3IHJldmlzaW9uLCBhbmQgd2UgY2FuIHJ1biBhIG1vcmUgZm9ybWFs IA0KPiA+ID4gYWRvcHRpb24gY2FsbCBvbiB0aGF0Lg0KPiA+DQo+ID4gQWx0aG91Z2ggSSB3YXMg b25lIG9mIHRoZSBwZW9wbGUgcmFpc2luZyB0aGUgIm5lZWQiIGZvciB0aGUgc2NvcGUgDQo+ID4g YW5kIHJlcXVpcmVtZW50cywgSSBkb24ndCBoYXZlIGEgc3Ryb25nIGxlYWRpbmcgb24gd2hldGhl ciB0aGlzIA0KPiA+IG5lZWRzIHRvIGJlIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQgb24gZm9sZGVk IGludG8gdGhlIGRhdGEgZm9ybWF0IA0KPiA+IGRvY3VtZW50LiBTbyBCcmlhbidzIHByb3Bvc2Fs IHdvdWxkIHdvcmsgZm9yIG1lLg0KPiA+DQo+ID4gVGh1cywgSSdkIGxvdmUgdG8gc2VlIHRoaXMg c2NvcGluZyB0ZXh0IGRyYWZ0ZWQgYW5kIGZsb2F0ZWQgdG8gdGhlIA0KPiA+IGxpc3QgYXMgYW4g ZW1haWwgb3IgaW4gYSByZXZpc2lvbiBvZiB0aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQuDQo+ID4N Cj4gPiBDaGVlcnMsDQo+ID4gQWRyaWFuDQo+IFtBQ01dDQo+IA0KPiArMSBmb3IgYWRkaW5nIGEg U2NvcGUgc2VjdGlvbiB0bw0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJv Y2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wMg0KPiANCj4gSSBmZWx0IHRoYXQgSSB1bmRlcnN0b29k IHRoZSBzY29wZSBnb2luZyBpbnRvIHRoZSBkaXNjdXNzaW9uIE1vbmRheSANCj4gYW5kIHRoZSBh cHBsaWNhYmxlIChyZXN0cmljdGVkKSBkb21haW4gKEkgZGlkIHRoZSBob21ld29yaywgdGhlIHNp bmdsZSANCj4gZHJhZnQgRnJhbmsgaW50cm9kdWNlZCBvbiB0aGUgbWFpbGluZyBsaXN0IHdhcyBb MF0gKS4NCj4gDQo+IFNvbWUgYWRkaXRpb25hbCBxdWVzdGlvbnMgaGF2ZSBiZWVuIHJhaXNlZCAo ZS5nLiwgIndoZXJlIHdpbGwgT0FNIGJlIA0KPiBpbnNlcnRlZCBhbmQgcmVtb3ZlZD8iKSBhbmQg SSdkIGxpa2UgdG8gc2VlIHRob3NlIGl0ZW1zIHNvcnRlZC1vdXQgDQo+IGJlZm9yZSB3ZSBnbyB2 ZXJ5IGZhciAodGhlIGFkdmFudGFnZSBvZiB3aWRlciByZXZpZXcpLg0KPiANCj4gVGhlIHJlcXVp cmVtZW50cyBkcmFmdCBvbmx5IGNhbWUtdXAgd2hlbiBJIGFza2VkIHNvbWUgcXVlc3Rpb25zIG9u IHRoZSBsaXN0Lg0KPiBGcmFuayBtZW50aW9uZWQgdGhhdCB0aGUgb3VyIGxpc3QgZGlzY3Vzc2lv biBvbiBlcXVpdmFsZW50IHRyZWF0bWVudCANCj4gb2YgT0FNICYgbm9uLU9BTSBwYWNrZXRzICgi Y2xhc3MgQyIpIHdhcyBhZGRlZCB0byB0aGUgcmVxdWlyZW1lbnRzIA0KPiBkb2N1bWVudCwgYW5k IHRoYXQgc2hvdWxkIG1vdmUgdG8gLW9hbS1kYXRhLSB0b28uDQo+IA0KPiBJdCB3b3VsZCBiZSBn b29kIHRvIGhhdmUgYSB2ZXJzaW9uIG9mIHRoZSBzY29wZSB0byByZXZpZXcgQVNBUC4NCj4gDQo+ IHRoYW5rcyBhbmQgcmVnYXJkcywNCj4gQWwNCj4gDQo+IFswXSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wMg0KPiANCj4gDQo+IA0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBpcHBtIG1haWxpbmcgbGlzdA0KPiA+IGlwcG1AaWV0Zi5vcmcNCj4gPiBodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ID4gM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lwcG0mZD1Ed0lHYVEmYz1MRllaLQ0KPiA+DQo+IG85X0hV TWVNVFNRaWN2aklnJnI9T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZtPUdhcXVjenRLNTdmVGozdnlZ Y01uSA0KPiBHOVlLDQo+ID4gTDENCj4gdFZrQVNRNUMzS2g2M29vQSZzPU1lc002QkZaeUVrVlBx c0dxMkhvNExLU19BNG50ZjVYNWhMMFN4MFJzZGMmZQ0KPiA9DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlw cG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBt DQoNCg== From nobody Tue Apr 11 09:18:02 2017 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 9F4F61274D0; Tue, 11 Apr 2017 09:17:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149192747464.15682.3691319250872731449.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 09:17:54 -0700 Archived-At: Subject: [ippm] Kathleen Moriarty's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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, 11 Apr 2017 16:17:55 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Warren's discuss and comments and have a few additional comments to add. Kind of related to Warren's discuss, I kept looking for a limitation to the scope for this work in the draft and didn't get to one until the end of the security considerations section. The text there wasn't quite clear enough for me. It seems that this might only be used for small periods of time while troubleshooting, is that correct? It also seems like this has to be end-to-end, is that right? And if it does need to be end-to-end, is the user aware of this troubleshooting so that they are not sending traffic that contains sensitive data that should remain confidential (security or privacy implications may also exist if this is not the case). If the scope were limited, I would not have as many security concerns. Network reconnaissance may or may not be an issue. I don't think it is, but I need to better understand the scope of use for this option. nit: s/IPSec/IPsec/g From nobody Tue Apr 11 12:08:31 2017 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 AA05212EB7C; Tue, 11 Apr 2017 12:08:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149193770359.15734.4861642631751879658.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 12:08:23 -0700 Archived-At: Subject: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 11 Apr 2017 19:08:24 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 3.2.1. The option length seems to be wrong here. This will make the parser parse incorrectly onto a following option or worse. I think this MUST be set to 10 instead of 16 (Or some field is missing from the description of the option) 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. * Section 3.2.1. The option does not seem to state an alignment requirement, but I think one is required to properly align the multi-byte PSN and Delta fields. Can you please specify one. * Section 5 The IANA considerations section needs to be more specific as you are requesting a specific type of option. e.g. This draft requests an Destination Option Type assignment with the act bits set to 00 and the chg bit set to 0 from the ... ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 1.6 I am not sure where this inference comes from. Can you please clarify? It is likely that an IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. * Section 3.1 This text is not correct as the PDM option is not an implementation of the Destination options *header*. The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is an implementation of the Destination Options Header. Suggest rewording to The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is implemented as an IPv6 Option carried in the Destination Options Header. From nobody Tue Apr 11 15:00:18 2017 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 CB7EA12947E for ; Tue, 11 Apr 2017 15:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 XQJfpGKtgsWb for ; Tue, 11 Apr 2017 15:00:15 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 1242A128768 for ; Tue, 11 Apr 2017 15:00:10 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id d131so9444277qkc.3 for ; Tue, 11 Apr 2017 15:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F4oHGQmRCBzX0EpmngZ6CprcBViZcyWQJBxHDxKQH2Y=; b=NVuLj0yHKwKPM8RyrU534PgRYxuwy5w8CMgkdgAu64wWt4uG9HJoDsg7kp88E1SlNg dH70Q3qxktlcfk4rXMg5IWVoLDiAdpoOaeCOiykUasfK+EvCM5LvLi998/oBRAXu7+fh 33S7AKoLhkIvXVutenAkA6iryVqNwowobZerlQxp/V9KRA1o9yM6kj4kbnaH5640kptI IvdqmT9dkmHxG5sX3SbO3VhoXMCraxg6tcXZ5pY0Pil4HlR+/34sWEoM3CJPpsBzPG6c 5X7b7O3LLaVCXn/zIpc4RnBeP9oEaw/QnubDzx5ybTBh9qULSfpjHwjioLtf2MDZ0GlR /IsQ== 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=F4oHGQmRCBzX0EpmngZ6CprcBViZcyWQJBxHDxKQH2Y=; b=rM1tPBWmAzr/dkO6pV0HJB1D6pYSBB9Kd2JcyBt+bt0yE+FtX4b7rYn+fa+xz+w2qG Kadw0CQRxcLLG96Zw5WLGPf62KcB+XvWtU9ZVLsCnHWGb7pN7Opu3bEzIuSemNfxzibi 0UQDQArQ5UR8vkNh6iH+k1evOY1Jr50x4FSFxNSwckG/5M+6d0+OHKmaGalk+9y4BOwb 2c6U2Mhg/qbq+bJjfk+azZcSo+n9ZBMEp1MZIJRFAt+zaRdjWbCn6TOhsN35HfRTfQMi mPjGb6rM9vgyj/ckwIdhRmZLeekGCpON0Ihlcwknw3qiSHB2DMNE4MDXlHzhVv7pRJHe HyXg== X-Gm-Message-State: AFeK/H3PA3s/vCTFp2sG021YmXLsxWb64hJuEH3A5JwAbh2AeNhKI5vHq7KPSamq8xT8kF5UOimqp8x1R/v2smkR X-Received: by 10.55.90.70 with SMTP id o67mr62266112qkb.251.1491948009022; Tue, 11 Apr 2017 15:00:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.136 with HTTP; Tue, 11 Apr 2017 14:59:28 -0700 (PDT) In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F6C64C@njmtexg5.research.att.com> References: <471466896.449269.1491673422679.ref@mail.yahoo.com> <471466896.449269.1491673422679@mail.yahoo.com> <4D7F4AD313D3FC43A053B309F97543CF25F6C64C@njmtexg5.research.att.com> From: Warren Kumari Date: Tue, 11 Apr 2017 17:59:28 -0400 Message-ID: To: "MORTON, ALFRED C (AL)" Cc: "nalini.elkins@insidethestack.com" , The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , "ippm@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 11 Apr 2017 22:00:17 -0000 On Sat, Apr 8, 2017 at 1:51 PM, MORTON, ALFRED C (AL) wrote: > Hi Nalini and Warren, > (doc shepherd chiming-in) > > Perhaps: > Abstract > > To assess performance problems, this document describes optional > headers embedded in each packet that provide sequence numbers and timestamps > as a basis for measurements. > ... I prefer Al's text, but either is fine with me. The discuss also said: "It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets (the exmaple just has a dash). This means that I cannot create an interoperable implementation from this document alone." For example, when I send my first packet with PDM in it (Section B.1.1 Step 1) I have not yet received any packets with a sequence number, so I don't know what to put in the PSNLR field -- I think that this need to be specified (perhaps 0? 0xFFFF?) W > > Al > > >> -----Original Message----- >> From: nalini.elkins@insidethestack.com >> [mailto:nalini.elkins@insidethestack.com] >> Sent: Saturday, April 08, 2017 1:44 PM >> To: The IESG; Warren Kumari >> Cc: draft-ietf-ippm-6man-pdm-option@ietf.org; MORTON, ALFRED C (AL); >> Bill Cerveny; ippm-chairs@ietf.org; ippm@ietf.org >> Subject: Re: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option- >> 09: (with DISCUSS and COMMENT) >> >> Warren, >> >> Thanks for your comments. I will respond to the comments section ASAP. >> >> But, this is for the DISCUSS >> >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > --------------------------------------------------------------------- >> - >> >> > The document says that packet sequence number are optional >> ("measurements based on optional sequence numbers and timing may be >> embedded in each packet"), but doesn't say what should >> > be put in the PSNTP field if I'm not using them. It also doesn't say >> what I should put in the PSNLR field if I haven't received any PDM >> packets (the exmaple just has a dash). This means that I cannot create >> an >> > interoperable implementation from this document alone. >> >> What we meant to say is that the entire Destination Option is optional, >> not that the packet sequence numbers are optional. >> >> Current wording >> --------------------- >> Abstract >> >> To assess performance problems, measurements based on optional >> sequence numbers and timing may be embedded in each packet. Such >> measurements may be interpreted in real-time or after the fact. An >> implementation of the existing IPv6 Destination Options extension >> header, the Performance and Diagnostic Metrics (PDM) Destination >> Options extension header as well as the field limits, calculations, >> and usage of the PDM in measurement are included in this document. >> >> >> Proposed wording >> ------------------------ >> >> Abstract >> >> To assess performance problems, measurements based on >> sequence numbers and timing may be embedded in each packet. Such >> measurements may be interpreted in real-time or after the fact. An >> implementation of the existing IPv6 Destination Options extension >> header, the Performance and Diagnostic Metrics (PDM) Destination >> Options extension header as well as the field limits, calculations, >> and usage of the PDM in measurement are included in this document. >> The use of the PDM Destination Option is optional. That is, an >> implementation >> may choose not to support it. >> >> Thanks, >> >> Nalini Elkins >> CEO and Founder >> Inside Products, Inc. >> www.insidethestack.com >> (831) 659-8360 >> >> -------------------------------------------- >> On Sat, 4/8/17, Warren Kumari wrote: >> >> Subject: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: >> (with DISCUSS and COMMENT) >> To: "The IESG" >> Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" >> , "Bill Cerveny" , ippm- >> chairs@ietf.org, acmorton@att.com, ippm@ietf.org >> Date: Saturday, April 8, 2017, 10:01 AM >> >> Warren Kumari has entered the following >> ballot position for >> draft-ietf-ippm-6man-pdm-option-09: >> Discuss >> >> When responding, please keep the >> subject line intact and reply to all >> email addresses included in the To and >> CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIFaQ&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=De_5hrtDljLJ3VK66tjLHiANTN9 >> K7XMPe5kXd0FjUcU&s=d8aytJtECiLj4P1KOB1q5ORq2jEapXFca8_c6YatAnw&e= >> for more information about IESG DISCUSS >> and COMMENT positions. >> >> >> The document, along with other ballot >> positions, can be found here: >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2D6man-2Dpdm- >> 2Doption_&d=DwIFaQ&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=De_5hrtDljLJ3VK66tjLHiANTN9 >> K7XMPe5kXd0FjUcU&s=4Wpy1AmRHeyuVk_zDbqENoerkIYf2AxQTHqp1eTejcI&e= >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> The document says that packet sequence >> number are optional ("measurements >> based on optional sequence numbers and >> timing may be embedded in each >> packet"), but doesn't say what should >> be put in the PSNTP field if I'm >> not using them. It also doesn't say >> what I should put in the PSNLR field >> if I haven't received any PDM packets >> (the exmaple just has a dash). This >> means that I cannot create an >> interoperable implementation from this >> document alone. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This document defines a new IPv6 >> Destination Option. Adding this to a >> packet pushes the L4 information >> further out, potentially making it >> unavailable to the forwarding engine / >> ACLs. This is not just a >> theoretical issue - see RFC7872 for >> real world examples. This means that >> if I connect to a remote machine and >> enable this, I may lock myself out >> of the machine (return packets may not >> make it back to me); this should >> be noted (perhaps by expanding on >> section 1.6). In addition, enabling PDM >> will (almost definitely) add some >> processing / transmit time, and so will >> perturb the very thing being measured - >> I believe that the document >> should note this. Appendix C mentions >> overhead from larger packets, but >> nothing about the additional processing >> time. >> >> In addition, much of the security >> advice feels like sops, simply to >> appease security people. For example, >> in "PDM as a Covert Channel" we >> find: "Having said that, an >> implementation SHOULD stop using PDM if it >> gets some number of "nonsensical" >> sequence numbers." -- seeing as it >> would be the attacker using PDM as a >> convert channel, this is like saying >> attackers must set the evil bit on all >> attack traffic. >> >> Another example is section 4.4 Timing >> Attacks: >> "Even so, if using PDM, we introduce >> the concept of user "Consent to be >> Measured" as a pre-requisite for using >> PDM. Consent is common in >> enterprises and with some subscription >> services. So, if with PDM, we >> recommend that the user SHOULD consent >> to its use." - this has nothing to >> do with timing attacks. In addition a >> concept is introduced, but not >> really explained - it is then claimed >> that this is common in enterprises >> (true), and that users SHOULD consent >> (or should have already consented) >> to being monitored. This feels like it >> was sprinkled on like security >> fairy dust to make security people >> happy, and (for me) does the >> opposite. >> >> >> I don't understand Section 3.6 Dynamic >> Configuration Options. >> "If implemented, each operating system >> MUST have a default configuration >> parameter, e.g. >> diag_header_sys_default_value=yes/no. The operating >> system MAY also have a dynamic >> configuration option to change the >> configuration setting as needed." >> I don't understand how an implementing >> OS could not have a default >> (unless this were random). If the >> default were no, presumably it would >> *have* to have a dynamic option to >> change the config (or it could never >> be enabled). >> Section 3.5.1 says: "The PDM >> destination options extension header MUST be >> explicitly turned on by each >> stack on a host node by administrative >> action. The default value of PDM >> is off.", so I'm very confused what 3.6 >> is trying to say... >> >> >> -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Apr 11 16:41:15 2017 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 7691D128D2E for ; Tue, 11 Apr 2017 16:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 p2dpo9Tw5QcF for ; Tue, 11 Apr 2017 16:41:07 -0700 (PDT) Received: from nm40-vm10.bullet.mail.gq1.yahoo.com (nm40-vm10.bullet.mail.gq1.yahoo.com [98.136.216.251]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1DC128ACA for ; Tue, 11 Apr 2017 16:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1491954063; bh=FaTZtNC2qA9yZJNY7dzeaGkyBUwC7N3hrSrAHZNc/aw=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=kRdUCKWxqH4L69/UX2mQn1VSCzvVnXOn/aJ1ssA0rXoTjd3hEksaqgCS+yxoF8emECD3mpg4pOPx6YBZ8uzH2Y+8y+1mph40Gk0WSvXhw7I3zIhvRla+U4MuJVildgqfGIicHt9OdLgSvqmOsLKWLwCXNyqGOnyMNTbgKur+UY9ogqi7j2S8B5OyW/HpwBsZ6gdTNvLml+rhvayGtrLIOLe+OaslVQL24QNAEErhoZiFHlJ7uH23uD5Hojm/rpbeCGMa5cM9fBma+Fuu9Nm6Rb3vyIRaYls/H695axJbh1/dqGrRmFrs0UZuV3U52iIXL30F1+C7Doyji8qzZJayCQ== Received: from [127.0.0.1] by nm40.bullet.mail.gq1.yahoo.com with NNFMP; 11 Apr 2017 23:41:03 -0000 Received: from [98.137.12.175] by nm40.bullet.mail.gq1.yahoo.com with NNFMP; 11 Apr 2017 23:38:03 -0000 Received: from [98.137.12.205] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 11 Apr 2017 23:38:03 -0000 Received: from [127.0.0.1] by omp1013.mail.gq1.yahoo.com with NNFMP; 11 Apr 2017 23:38:03 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 595722.42873.bm@omp1013.mail.gq1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws300008.mail.gq1.yahoo.com by sendmailws107.mail.gq1.yahoo.com; Tue, 11 Apr 2017 23:36:23 +0000; 1491953783.240 Date: Tue, 11 Apr 2017 23:36:22 +0000 (UTC) From: Reply-To: To: " ALFRED C (AL)MORTON" , Warren Kumari Cc: "nalini.elkins@insidethestack.com" , The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , "ippm@ietf.org" Message-ID: <1417210962.39039.1491953782886@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1417210962.39039.1491953782886.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9386 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 11 Apr 2017 23:41:09 -0000 -------------------------------------------- On Tue, 4/11/17, Warren Kumari wrote: Subject: Re: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09= : (with DISCUSS and COMMENT) To: "MORTON, ALFRED C (AL)" Cc: "nalini.elkins@insidethestack.com" ,= "The IESG" , "draft-ietf-ippm-6man-pdm-option@ietf.org" , "Bill Cerveny" , "ippm-chairs@ietf.org" , "ippm@ietf.org" Date: Tuesday, April 11, 2017, 2:59 PM =20 On Sat, Apr 8, 2017 at 1:51 PM, MORTON, ALFRED C (AL) wrote: >> Hi Nalini and Warren, >> (doc shepherd chiming-in) >> >> Perhaps: >> Abstract >> >>=C2=A0 =C2=A0 To assess performance problems,=C2=A0this document describe= s optional > >=C2=A0 =C2=A0headers embedded in each packet that provide sequence numbe= rs and timestamps >>=C2=A0 =C2=A0 as a basis for measurements. >>=C2=A0 =C2=A0 ... =20 > I prefer Al's text, but either is fine with me. I prefer Al's text also but with a minor change. Timestamps are not sent = but rather deltas. So, the new sentence is: To assess performance problems,=C2=A0this document describes optional =C2=A0headers embedded in each packet that provide sequence numbers and tim= ing information as a basis for measurements. =C2=A0 ... > The discuss also said: "It also doesn't say what I should put in the PSN= LR field if I haven't received any PDM packets (the exmaple just has > a dash). This means that I cannot create an interoperable implementation = from this document alone." > For example, when I send my first packet with PDM in it (Section B.1.1 St= ep 1) I have not yet received any packets with a sequence number, so > I don't know what to put in the PSNLR=C2=A0 field -- I think that this ne= ed to be specified (perhaps 0? 0xFFFF?) Yes. In section 3.2.1 (PDM Layout) Existing Text ------------------ Packet Sequence Number Last Received (PSNLR) 16-bit unsigned integer. This is the PSNTP of the packet last received = on the 5-tuple. Add ----- This field is initialized to 0. Thanks, Nalini =20 > > Al > > >> -----Original Message----- >> From: nalini.elkins@insidethestack.com >> [mailto:nalini.elkins@insidethestack.com] >> Sent: Saturday, April 08, 2017 1:44 PM >> To: The IESG; Warren Kumari >> Cc: draft-ietf-ippm-6man-pdm-option@ietf.org; MORTON, ALFRED C (AL); >> Bill Cerveny; ippm-chairs@ietf.org; ippm@ietf.org >> Subject: Re: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option- >> 09: (with DISCUSS and COMMENT) >> >> Warren, >> >> Thanks for your comments.=C2=A0 I will respond to the comments section ASAP. >> >>=C2=A0 But, this is for the DISCUSS >> >> > ---------------------------------------------------------------------- >> > DISCUSS: >>=C2=A0 > --------------------------------------------------------------------- >> - >> >> > The document says that packet sequence number are optional >> ("measurements based on optional sequence numbers and timing may be >> embedded in each packet"), but doesn't say what should >> >=C2=A0 be put in the PSNTP field if I'm not using them. It also doesn't say >> what I should put in the PSNLR field if I haven't received any PDM >> packets (the exmaple just has a dash). This means that I cannot create >> an >> >=C2=A0 interoperable implementation from this document alone. >> >> What we meant to say is that the entire Destination Option is optional, >> not that the packet sequence numbers are optional. >> >> Current wording >> --------------------- >> Abstract >> >>=C2=A0 =C2=A0 To assess performance problems,=C2=A0 measurements based on optional >>=C2=A0 =C2=A0 sequence numbers and timing may be embedded in each packet.=C2=A0 Such >>=C2=A0 =C2=A0 measurements may be interpreted in real-time or after the fact. An >>=C2=A0 =C2=A0 implementation of the existing IPv6 Destination Options extension >>=C2=A0 =C2=A0 header, the Performance and Diagnostic Metrics (PDM) Destination >>=C2=A0 =C2=A0 Options extension header as well as the field limits, calculations, >>=C2=A0 =C2=A0 and usage of the PDM in measurement are included in this document. >> >> >> Proposed wording >> ------------------------ >> >> Abstract >> >>=C2=A0 =C2=A0 To assess performance problems,=C2=A0 measurements based on >>=C2=A0 =C2=A0 sequence numbers and timing may be embedded in each packet.=C2=A0 Such >>=C2=A0 =C2=A0 measurements may be interpreted in real-time or after the fact. An >>=C2=A0 =C2=A0 implementation of the existing IPv6 Destination Options extension >>=C2=A0 =C2=A0 header, the Performance and Diagnostic Metrics (PDM) Destination >>=C2=A0 =C2=A0 Options extension header as well as the field limits, calculations, >>=C2=A0 =C2=A0 and usage of the PDM in measurement are included in this document. >>=C2=A0 =C2=A0 The use of the PDM Destination Option is optional.=C2=A0 That is, an >> implementation >>=C2=A0 =C2=A0 may choose not to support it. >> >> Thanks, >> >> Nalini Elkins >> CEO and Founder >> Inside Products, Inc. >> www.insidethestack.com >> (831) 659-8360 >> >> -------------------------------------------- >> On Sat, 4/8/17, Warren Kumari wrote: >> >>=C2=A0 Subject: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: >> (with DISCUSS and COMMENT) >>=C2=A0 To: "The IESG" >>=C2=A0 Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" >> , "Bill Cerveny" , ippm- >> chairs@ietf.org, acmorton@att.com, ippm@ietf.org >>=C2=A0 Date: Saturday, April 8, 2017, 10:01 AM >> >>=C2=A0 Warren Kumari has entered the following >>=C2=A0 ballot position for >>=C2=A0 draft-ietf-ippm-6man-pdm-option-09: >>=C2=A0 Discuss >> >>=C2=A0 When responding, please keep the >>=C2=A0 subject line intact and reply to all >>=C2=A0 email addresses included in the To and >>=C2=A0 CC lines. (Feel free to cut this >>=C2=A0 introductory paragraph, however.) >> >> >>=C2=A0 Please refer to https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=3DDwIFaQ&c=3DLFY= Z- >> o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DDe_5hrtDljLJ3VK66tjLHiANT= N9 >> K7XMPe5kXd0FjUcU&s=3Dd8aytJtECiLj4P1KOB1q5ORq2jEapXFca8_c6YatAnw&e=3D >>=C2=A0 for more information about IESG DISCUSS >>=C2=A0 and COMMENT positions. >> >> >>=C2=A0 The document, along with other ballot >>=C2=A0 positions, can be found here: >>=C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2D6man-2Dpdm- >> 2Doption_&d=3DDwIFaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DDe_5hrtDljLJ3VK66tjLHiANT= N9 >> K7XMPe5kXd0FjUcU&s=3D4Wpy1AmRHeyuVk_zDbqENoerkIYf2AxQTHqp1eTejcI&e=3D >> >> >> >>=C2=A0 ---------------------------------------------------------------------- >>=C2=A0 DISCUSS: >>=C2=A0 ---------------------------------------------------------------------- >> >>=C2=A0 The document says that packet sequence >>=C2=A0 number are optional ("measurements >>=C2=A0 based on optional sequence numbers and >>=C2=A0 timing may be embedded in each >>=C2=A0 packet"), but doesn't say what should >>=C2=A0 be put in the PSNTP field if I'm >>=C2=A0 not using them. It also doesn't say >>=C2=A0 what I should put in the PSNLR field >>=C2=A0 if I haven't received any PDM packets >>=C2=A0 (the exmaple just has a dash). This >>=C2=A0 means that I cannot create an >>=C2=A0 interoperable implementation from this >>=C2=A0 document alone. >> >> >>=C2=A0 ---------------------------------------------------------------------- >>=C2=A0 COMMENT: >>=C2=A0 ---------------------------------------------------------------------- >> >>=C2=A0 This document defines a new IPv6 >>=C2=A0 Destination Option. Adding this to a >>=C2=A0 packet pushes the L4 information >>=C2=A0 further out, potentially making it >>=C2=A0 unavailable to the forwarding engine / >>=C2=A0 ACLs. This is not just a >>=C2=A0 theoretical issue - see RFC7872 for >>=C2=A0 real world examples. This means that >>=C2=A0 if I connect to a remote machine and >>=C2=A0 enable this, I may lock myself out >>=C2=A0 of the machine (return packets may not >>=C2=A0 make it back to me); this should >>=C2=A0 be noted (perhaps by expanding on >>=C2=A0 section 1.6). In addition, enabling PDM >>=C2=A0 will (almost definitely) add some >>=C2=A0 processing / transmit time, and so will >>=C2=A0 perturb the very thing being measured - >>=C2=A0 I believe that the document >>=C2=A0 should note this. Appendix C mentions >>=C2=A0 overhead from larger packets, but >>=C2=A0 nothing about the additional processing >>=C2=A0 time. >> >>=C2=A0 In addition, much of the security >>=C2=A0 advice feels like sops, simply to >>=C2=A0 appease security people. For example, >>=C2=A0 in "PDM as a Covert Channel" we >>=C2=A0 find: "Having said that, an >>=C2=A0 implementation SHOULD stop using PDM if it >>=C2=A0 gets some number of "nonsensical" >>=C2=A0 sequence numbers."=C2=A0 -- seeing as it >>=C2=A0 would be the attacker using PDM as a >>=C2=A0 convert channel, this is like saying >>=C2=A0 attackers must set the evil bit on all >>=C2=A0 attack traffic. >> >>=C2=A0 Another example is section 4.4 Timing >>=C2=A0 Attacks: >>=C2=A0 "Even so, if using PDM, we introduce >>=C2=A0 the concept of user "Consent to be >>=C2=A0 Measured" as a pre-requisite for using >>=C2=A0 PDM.=C2=A0 Consent is common in >>=C2=A0 enterprises and with some subscription >>=C2=A0 services. So, if with PDM, we >>=C2=A0 recommend that the user SHOULD consent >>=C2=A0 to its use." - this has nothing to >>=C2=A0 do with timing attacks. In addition a >>=C2=A0 concept is introduced, but not >>=C2=A0 really explained - it is then claimed >>=C2=A0 that this is common in enterprises >>=C2=A0 (true), and that users SHOULD consent >>=C2=A0 (or should have already consented) >>=C2=A0 to being monitored. This feels like it >>=C2=A0 was sprinkled on like security >>=C2=A0 fairy dust to make security people >>=C2=A0 happy, and (for me) does the >>=C2=A0 opposite. >> >> >>=C2=A0 I don't understand Section 3.6 Dynamic >>=C2=A0 Configuration Options. >>=C2=A0 "If implemented, each operating system >>=C2=A0 MUST have a default configuration >>=C2=A0 parameter, e.g. >>=C2=A0 diag_header_sys_default_value=3Dyes/no. The operating >>=C2=A0 system MAY also have a dynamic >>=C2=A0 configuration option to change the >>=C2=A0 configuration setting as needed." >>=C2=A0 I don't understand how an implementing >>=C2=A0 OS could not have a default >>=C2=A0 (unless this were random). If the >>=C2=A0 default were no, presumably it would >>=C2=A0 *have* to have a dynamic option to >>=C2=A0 change the config (or it could never >>=C2=A0 be enabled). >>=C2=A0 Section 3.5.1 says: "The PDM >>=C2=A0 destination options extension header MUST be >>=C2=A0 explicitly=C2=A0 turned on by each >>=C2=A0 stack on a host node by administrative >>=C2=A0 action. The=C2=A0 default value of PDM >>=C2=A0 is off.", so I'm very confused what 3.6 >>=C2=A0 is trying to say... >> >> >> =20 =20 =20 --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. =C2=A0 ---maf =20 From nobody Tue Apr 11 17:11:10 2017 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 C8B5D127419; Tue, 11 Apr 2017 17:11:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149195586781.15796.5030067129991289423.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 17:11:07 -0700 Archived-At: Subject: [ippm] Eric Rescorla's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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: Wed, 12 Apr 2017 00:11:08 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think the description of timing attacks could use a bit more work. Specifically: - I am assuming that you should discard rather than using as timestamp sources packets which fail ESP. This shouldn't be an issue for transport mode because you process ESP first, but in tunnel mode you allow either order, so it's a potential issue. - It seems like you could use this technique for fine-grained timing of the cryptographic operations traffic keys as well (cf. Lucky 13), not just long-term keys as you say in S 4.4. Note that both of these attacks are not ameliorated by restricting to host and ports because one assumes that the attacker controls the network per 3552. From nobody Tue Apr 11 18:47:49 2017 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 6BE0B12751F for ; Tue, 11 Apr 2017 18:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 d195WuwEzSAR for ; Tue, 11 Apr 2017 18:47:36 -0700 (PDT) Received: from nm34-vm9.bullet.mail.gq1.yahoo.com (nm34-vm9.bullet.mail.gq1.yahoo.com [98.136.216.138]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9155C1293D8 for ; Tue, 11 Apr 2017 18:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1491961641; bh=fn/cFXTAQ9Wli2XWJRBNgGeRuUj/CLMDUmcO3wioUAI=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=igCvCixWww8s4eUdgX89xvi77yiVlWzf9rCrv77/oOVmJ7wFfV08E9Bju2nNfmk1N0AYuztr9pKnFbGkvPgV1ZF39CwzmioEJGNuigW9GrpYW20kEenPiWKWSUSlBKiTEpnhIJRP70W5e2hP14N5/MBJeYv7+tfsIHnDOKorxY6H3b9vWPpPg0mRMdp3FhGy+3I+x7jJ1Lq/JbyI36A0hJgj8nv0PEW4IqAUZn7myM+9nBemxR0QXlRTcf9dFprNCa2Up7W8yQR2NkwEzaaIq0nO7vuY3cyaJMuA6Q2N3KZt6qjYczrJmFToQNxD5OvJVfBLDDrP3CX+N//d23JuEA== Received: from [127.0.0.1] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 01:47:21 -0000 Received: from [98.137.12.56] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 01:44:37 -0000 Received: from [98.137.12.231] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 01:44:37 -0000 Received: from [127.0.0.1] by omp1039.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 01:44:37 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 45668.46731.bm@omp1039.mail.gq1.yahoo.com X-YMail-OSG: fZLBi6cVM1k_0qALul9yy2ieJyJf.g.AdiAmFQfnlAloNTuHfL5UPX6B966KqBr 4GlG_h5zk9hJVJAqdycVN5Af.XXyNHLPm9V40eePgYf9m75piRV7_DTUMJywZL9X0MjZCmOLgdX6 iFohQVMumxCeTlk9QMQJ.WTOaXnaQ8iNBXaWOQzRIdhD3HlIek58RoNVjZqpLuskdaj.Pd1zcUBu ldv7Cn.jCttA.V83IlP1a4nx5ZFK0fqQ1hTg6zKPnjEf6_JgTb3lnfTVuPMfSCuONdjINcGa.Xhv pqG4QPjN.8TMQ62uVExHBb0lCfFpG78oWJxXnqpEdZiNNzd3DaMA6C0pOX9CEHE5D7WI1mFwWJlX gu4ghD6Qt4Iw1Jy3q3aAvJbJV9UH89SfCT3pmd1GYX5pCEAZrLS_AVN9mumUic.XJav7hxBOzqGw SsK2qB9MIsmPp2Juhs_7ETjt52ZDBXNiEwtZWtHzYc4L2sfpd6s.edhCJA5VO6YEpZp1SJFUmDig 9to2DLZbs9QEGcGOa8IaI8xKIliU7znEedpOlkt5Fu.kkrw-- Received: from jws300065.mail.gq1.yahoo.com by sendmailws142.mail.gq1.yahoo.com; Wed, 12 Apr 2017 01:44:36 +0000; 1491961476.700 Date: Wed, 12 Apr 2017 01:44:36 +0000 (UTC) From: Reply-To: To: The IESG , Suresh Krishnan Cc: , , Bill Cerveny , , Message-ID: <390082457.101550.1491961476458@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <390082457.101550.1491961476458.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9386 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 12 Apr 2017 01:47:38 -0000 Suresh, I am only responding to the DISCUSS section below. Nalini -------------------------------------------- On Tue, 4/11/17, Suresh Krishnan wrote: Subject: Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: = (with DISCUSS and COMMENT) To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att= .com, ippm@ietf.org Date: Tuesday, April 11, 2017, 12:08 PM =20 > Suresh Krishnan has entered the following ballot position for draft-ietf= -ippm-6man-pdm-option-09: Discuss =20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= for more information about IESG DISCUSS and COMMENT positions. =20 > The document, along with other ballot positions, can be found here: https= ://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ =20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- =20 > * Section 3.2.1. =C2=A0 The option length seems to be wrong here. This wi= ll make the parser parse incorrectly onto a following option or worse. I th= ink this MUST be set to 10 instead of 16 (Or some field > is missing from the description of the option) =20 >=C2=A0=C2=A0 8-bit unsigned integer. Length of the option, in octets, excl= uding the Option Type and Option Length fields. This field MUST be set to 1= 6. You are correct.=C2=A0 The option length is 10 not 16.=C2=A0 I will fix th= at. > * Section 3.2.1. >=C2=A0 The option does not seem to state an alignment requirement, but I t= hink one is required to properly align the multi-byte PSN and Delta fields. > Can you please specify one. The alignment for PSN and delta fields follows the alignment requirements f= or all extension headers. >From RFC2460, I see: Each extension header is an integer multiple of 8 octets long, in order to = retain 8-octet alignment for subsequent headers. Multi-octet fields within= each extension header are aligned on their natural boundaries, i.e., fields of width n octets are placed at an integer= multiple of n octets from the start of the header, for n =3D 1, 2, 4, or 8= . The PSN and Delta fields are all on a half-word boundary. So, I think we = are OK. Do you think I should restate the above in the draft? =20 > * Section 5 =20 > The IANA considerations section needs to be more specific as you are requ= esting a specific type of option. =20 > e.g. This draft requests an Destination Option Type assignment with the = act bits set to 00 and the chg bit set to 0 from the ... Current Text ---------------- 5 IANA Considerations This draft requests an Option Type assignment in the Destination Options= and Hop-by-Hop Options sub-registry of Internet Protocol Version 6 (IPv6) Parameters [ref to RFCs and URL below]. http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ip= v6-parameters-2 Hex Value Binary Value Description Reference=20 act chg rest ------------------------------------------------------------------- =20 TBD TBD Performance and [This draft] Diagnostic Metrics=20 (PDM) =20 New Text ---------------- 5 IANA Considerations This draft requests a Destination Option Type assignment with the act bi= ts set to 00 and the chg bit set to 0 from the Destination Options and Hop-by-Hop Options sub-registry of Inte= rnet Protocol Version 6 (IPv6) Parameters [ref to RFCs and URL below]. http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ip= v6-parameters-2 Hex Value Binary Value Description Reference=20 act chg rest ------------------------------------------------------------------------= ------------ =20 TBD 00 0 TBD Performance and [This draft] Diagnostic Metrics=20 (PDM) =20 =20 =C2=A0=20 From nobody Wed Apr 12 07:54:19 2017 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 7D175131707; Wed, 12 Apr 2017 07:54:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149200885746.15718.798617550888585150.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 07:54:17 -0700 Archived-At: Subject: [ippm] Alissa Cooper's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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: Wed, 12 Apr 2017 14:54:17 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The analysis in Sec 4.2 seems to be missing some considerations. In cases where the packet payload is encrypted and the attacker does not have access to the keys, the attacker does not in fact have access to the entire packet, in which case PDM provides more information than a packet without PDM. Also in those cases, it seems like including PDM information would generally make a packet stream more susceptible to traffic analysis insofar as the timing and sequence information may provide additional indicators about the type of application in use, not just the speed of the end host. From nobody Wed Apr 12 08:20:52 2017 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 53A3D131726; Wed, 12 Apr 2017 08:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 osV3CFRSVIFg; Wed, 12 Apr 2017 08:20:49 -0700 (PDT) Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C058131724; Wed, 12 Apr 2017 08:20:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id 4EACD80384; Wed, 12 Apr 2017 11:20:47 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at aws.hosed.org Received: from aws.hosed.org ([127.0.0.1]) by localhost (aws.hosed.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC52U0g33Q7c; Wed, 12 Apr 2017 11:20:47 -0400 (EDT) Received: from divinaair.netscout.com (50-195-106-33-static.hfc.comcastbusiness.net [50.195.106.33]) by aws.hosed.org (Postfix) with ESMTPSA id 0192680383; Wed, 12 Apr 2017 11:20:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sarah B In-Reply-To: Date: Wed, 12 Apr 2017 08:20:46 -0700 Cc: ALFRED MORTON , "adrian@olddog.co.uk" , "Brian Trammell (IETF)" , IPPM Chairs , "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> To: "Frank Brockners (fbrockne)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 12 Apr 2017 15:20:51 -0000 Hi Frank, See below: >=20 > How about: "The operator of such a domain MUST put provisions in place = to ensure that in-situ OAM data stays within the specific domain only = (i.e., does not leak beyond the edge) using for example packet filtering = methods. The operator SHOULD consider potential operational impact of = IOAM to mechanisms such as ECMP processing (e.g. load-balancing schemes = based on packet length could be impacted by the increased packet size = due to IOAM), path MTU (i.e. ensure that the MTU of all links within a = domain is sufficiently large to support the increased packet size due to = IOAM) and ICMP message handling (i.e. in case of a native IPv6 = transport, IOAM support for ICMPv6 Echo Request/Reply could desired = which would translate into ICMPv6 extensions to enable IOAM data fields = to be copied from an Echo Request message to an Echo Reply message)." I think this is a good start; thanks for putting the thought and = effort into it. It makes me a bit uneasy, because there's no way to = ensure it doesn't leak out, but it is what it is. I do appreciate that = you have a MUST, and still offered an example on how to mitigate the = leaks; thanks for taking the feedback into consideration. I also like = that you've pulled out the potential operational impact as a SHOULD, and = in a separate sentence; this makes sense to me. Finally, I think it's = crystal clear that this is domain-specific and limited; that alleviates = my objection from the in-room discussion. :) Thanks Sarah From nobody Wed Apr 12 10:53:37 2017 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 6314A12EB1B; Wed, 12 Apr 2017 10:53:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149201961539.15796.1514751129072606611.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 10:53:35 -0700 Archived-At: Subject: [ippm] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ippm-6man-pdm-option-09=3A_=28with_COMMENT=29?= 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: Wed, 12 Apr 2017 17:53:35 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My main concern is that part of this document read like an advertisement (e.g. "In our experience, valuable time is often lost.." whose experience? The IETF? This is an IETF RFC!). I think most of this text is not needed to understand the option and therefore should simply be removed. More concretely, I propose to remove sections 1.2, 1.3., and 1.5 as well as paragraphs 4-8 of section 1.4 (starting with "In our experience, valuable time is often lost..." to the end). I would also recommend these two changes to shorten the RFC: - section 3.2.3. could just be moved into the appendix. - the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed In general I think another editing pass could help to bring the document more to the point in a couple of cases. But that's not really an issue. Further comments: 1) This text in 3.4.2 is a bit confusing: "As a completely new IP packet will be made, it means that PDM information for that packet does not contain any information from the inner packet, i.e. the PDM information will NOT be based on the transport layer (TCP, UDP, etc) ports etc in the inner header, but will be specific to the ESP flow. If PDM information for the inner packet is desired, the original host sending the inner packet needs to put PDM header in the tunneled packet, and then the PDM information will be specific for that stream." I think what you want to say is something like "A tunnel endpoint that creates a new packet may decide to use PDM independent of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints." Correct? 2) I'm not sure this is really useful to specify normatively in an RFC as this is really implementation specific: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off." I would recommend the following text instead (without normative language): "An implementation should provide an interface to enable or disable the use of PDM. This specification recommends to turn PDM off by default." 3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or what's meant by 'dynamic configuration option'? In any case, I don't think the use of normative language is appropriate here. 4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6. exists twice) OLD "3.6 5-tuple Aging Within the operating system, metrics must be kept on a 5-tuple basis. The question comes of when to stop keeping data or restarting the numbering for a 5-tuple. For example, in the case of TCP, at some point, the connection will terminate. Keeping data in control blocks forever, will have unfortunate consequences for the operating system. So, the recommendation is to use a known aging parameter such as Max Segment Lifetime (MSL) as defined in Transmission Control Protocol [RFC0793] to reuse or drop the control block. The choice of aging parameter is left up to the implementation." NEW "3.6 Information Access and Storage Measurement information provided by PDM must be made accessible for higher layers or the user itself. Similar as activating the use of PDM, the implementation may also provide an interface to indicate if received PDM information should be stored or not. If a packet with PDM information is received and the information should be stored, the upper layers may be notified. Further it is recommend to define a configurable maximum lifetime after which the information can be removed as well as a configurable maximum amount of memory that should be allocated for PDM information." This text also addresses some of the "SYN flood attack" concerns as described in the security considerations section. I would recommend to rewrite this section as well and I would also recommend to not use the term SYN flood as that is clearly associated with TCP only. 5) Also section 4.1 (security consideration): I don't think this sentence is true: " For PDM, the amount of data to be kept is quite small. That is, the control block is quite lightweight." Because you eventually have to hold this data per packet, so it can grow quickly. However, this is also really an implementation question only. You could also just store the delay calculation and not the whole control block, or even an moving average of the delay which only needs a fixed amount of memory for a few values. I really depends what your use case is for the information provided by PDM. From nobody Wed Apr 12 11:30:21 2017 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 841BA12955B; Wed, 12 Apr 2017 11:30:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202181253.15816.14203090201177833141.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 11:30:12 -0700 Archived-At: Subject: [ippm] Benoit Claise's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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: Wed, 12 Apr 2017 18:30:13 -0000 Benoit Claise has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the publication of this document, but it's important to get Warren's COMMENT addressed: This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). From nobody Wed Apr 12 12:08:51 2017 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 55D6912EB53 for ; Wed, 12 Apr 2017 12:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 qgzvdS4WaOj4 for ; Wed, 12 Apr 2017 12:08:38 -0700 (PDT) Received: from nm36-vm5.bullet.mail.gq1.yahoo.com (nm36-vm5.bullet.mail.gq1.yahoo.com [98.136.216.220]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DD512EB3A for ; Wed, 12 Apr 2017 12:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1492024113; bh=b1SRMyR9x+4yEHo0NprYThQDzv8bRzQuYC71hzJk+0U=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=ICJN30tZaWX7DM2q13qk6p6Vu3w3AW6ewELlTSUhBlczh7UvKtQRonlkbqRZcuypKRcfMRIEdAmC6pAB13EtpUMiC8+MkAximD8k0sCDarn7gQ79bdPERxRwpB34CrqQV+IKEUxsk7MLjkfsDUPgo5DMlRRC1GGglj3mmpGWerOLvkoBRrnPZR8iUUONFjXYYm9cdG9AaNp9smFX2dEmPLXcK6aH0BxjWlhwBXStBRaPEhRDfUEtWWWhsl+76BXU8eFO3Ba+GZhUxcwHbs8cWe40yoiQGkrwNvJSxd5iBGXiLsopW58sRgCbvRaTkKjTR2OotUzTDzjyBoCo6y8r0w== Received: from [127.0.0.1] by nm36.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 19:08:33 -0000 Received: from [98.137.12.62] by nm36.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 19:05:33 -0000 Received: from [98.137.12.226] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 19:04:33 -0000 Received: from [127.0.0.1] by omp1034.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 19:04:33 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 492834.88861.bm@omp1034.mail.gq1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws300082.mail.gq1.yahoo.com by sendmailws116.mail.gq1.yahoo.com; Wed, 12 Apr 2017 19:04:33 +0000; 1492023873.113 Date: Wed, 12 Apr 2017 19:04:32 +0000 (UTC) From: Reply-To: To: The IESG , Warren Kumari Cc: , , Bill Cerveny , , Message-ID: <459943993.835318.1492023872585@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <459943993.835318.1492023872585.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9386 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 12 Apr 2017 19:08:39 -0000 Warren, =20 I am responding to your Comments below. =20 Thanks, =20 Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 =20 -------------------------------------------- On Sat, 4/8/17, Warren Kumari wrote: =20 =C2=A0 Subject: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-= 09: (with DISCUSS and COMMENT) =C2=A0 To: "The IESG" =C2=A0 Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" ,=C2=A0 "Bill Cerveny" ,=C2=A0 ippm-chairs@ietf= .org,=C2=A0 acmorton@att.com,=C2=A0 ippm@ietf.org =C2=A0 Date: Saturday, April 8, 2017, 10:01=C2=A0 AM =C2=A0=20 =C2=A0 > Warren Kumari has entered the following ballot position for draft-= ietf-ippm-6man-pdm-option-09: Discuss =C2=A0=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l for more information about IESG DISCUSS and COMMENT positions. =C2=A0=20 > The document, along with other ballot positions, can be found here: http= s://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ =C2=A0=20 =C2=A0=20 =C2=A0 > ---------------------------------------------------------------------- =C2=A0 > DISCUSS: =C2=A0 > ---------------------------------------------------------------------- =C2=A0=20 > The document says that packet sequence number are optional ("measurement= s based on optional sequence numbers and timing may be embedded in each > packet"), but doesn't say what should be put in the PSNTP field if I'm n= ot using them. It also doesn't say what I should put in the PSNLR field if = I haven't received any PDM packets > (the exmaple just has a dash).=C2=A0 This means that I cannot create an = interoperable implementation from this document alone. =C2=A0=20 =C2=A0=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- =C2=A0=20 > This document defines a new IPv6 Destination Option. Adding this to a pa= cket pushes the L4 information further out, potentially making it unavailab= le to the forwarding engine / > ACLs. This is not just a theoretical issue - see RFC7872 for real world = examples.=C2=A0 This means that if I connect to a remote machine and enable= this, I may lock myself out > of the machine (return packets may not make it back to me); this should = be noted (perhaps by expanding on section 1.6). =20 How is this? =20 Current Text ---------------- =20 1.6 IPv6 Transition Technologies =20 =C2=A0=C2=A0 In the path to full implementation of IPv6, transition techno= logies such as translation or tunneling may be employed.=C2=A0=C2=A0 The PD= M header is not expected to work in such scenarios.=C2=A0 It is likely that= an =C2=A0 =C2=A0 IPv6 packet containing PDM will be dropped if using IPv6 tran= sition technologies. =20 New Text ------------ =20 1.6 Full Support of IPv6 Functionality =20 =C2=A0=C2=A0 In the path to full implementation of native IPv6, transition= technologies such as translation or tunneling may be employed.=C2=A0=C2=A0= The PDM header may not work in such scenarios.=C2=A0 It is likely that an =C2=A0 =C2=A0 IPv6 packet containing PDM will be dropped if using IPv6 tran= sition technologies. =20 =C2=A0=C2=A0 It is also possible that some devices in the network may not = correctly handle multiple IPv6 Extension Headers, including the IPv6 Destin= ation Option.=C2=A0=C2=A0 For example, adding the PDM header to a packet =C2=A0 may push the layer 4 information to a point in the packet where it = is not routed correctly.=C2=A0=C2=A0 This kind of situation is expected to = become rare over time. =20 =20 > In addition, enabling PDM will (almost definitely) add some processing /= transmit time, and so will perturb the very thing being measured - I belie= ve that the document should note this. Appendix C mentions > overhead from larger packets, but nothing about the additional processin= g time. How about if we add the following to Appendix C after the first paragraph: As with other diagnostic tools, such as packet traces, a certain amount of = processing time will be required to create and process PDM. Since PDM is = lightweight (has only a few variables), we expect the processing time to be= minimal. =20 =20 > In addition, much of the security advice feels like sops, simply to appe= ase security people.=C2=A0 For example,=C2=A0 in "PDM as a Covert Channel" = we find: "Having said that, an implementation SHOULD stop using PDM if it > gets some number of "nonsensical" sequence numbers."=C2=A0 -- seeing as = it would be the attacker using PDM as a convert channel, this is like sayin= g attackers must set the evil bit on all attack traffic. =20 I think what we were thinking is that there may be, in the future, middle = boxes (for example, firewalls) which might be able to detect nonsensical se= quence numbers.=C2=A0=C2=A0 So, they would not be the ones who initiated the use of PDM as a covert channel.=C2=A0=C2=A0 Is there a bette= r way to say this? =20 =C2=A0=20 > Another example is section 4.4 Timing Attacks: "Even so, if using PDM, w= e introduce the concept of user "Consent to be Measured" as a pre-requisite= for using PDM.=C2=A0 Consent is common in enterprises and with > some subscription services. So, if with PDM, we recommend that the user = SHOULD consent to its use." - this has nothing to do with timing attacks. =20 The addition "Consent to be Measured"=C2=A0 is so that people know that al= ong with the many benefits of accurate measurements, there are some inevita= ble small risks. =20 =20 > In addition a concept is introduced, but not really explained - it is th= en claimed that this is common in enterprises (true), and that users SHOULD= consent (or should have already consented) to being monitored. This > feels like it was sprinkled on like security fairy dust to make security= people happy, and (for me) does the opposite. =C2=A0=20 =20 How about if we add something to explain further "Consent to be Measured".= =C2=A0=C2=A0 Sentence below: =20 "The actual content of "Consent to be Measured" will differ by site but it= SHOULD make clear that the traffic is being measured for quality of servic= e and to assist in diagnostics as well as to make clear that there may be potential risks of certain vulnerabilities if the traffic is captur= ed during a diagnostic session. " =20 =C2=A0=20 > I don't understand Section 3.6 Dynamic Configuration Options. "If implem= ented, each operating system MUST have a default configuration parameter, e= .g. diag_header_sys_default_value=3Dyes/no. The operating > system MAY also have a dynamic configuration option to change the config= uration setting as needed." I don't understand how an implementing OS could= not have a default (unless this were random). If the > default were no, presumably it would *have* to have a dynamic option to = change the config (or it could never be enabled). =20 > Section 3.5.1 says: "The PDM destination options extension header MUST b= e explicitly=C2=A0turned on by each stack on a host node by administrative = action. The=C2=A0 default value of PDM is off.", so I'm very confused what= =20 > 3.6 is trying to say... =C2=A0=20 =C2=A0 I agree that paragraph is confusing.=C2=A0=C2=A0 I suggest deleting = it since section 3.5.1 already discusses defaults.=C2=A0=C2=A0=20 =20 Current text ---------------- =20 3.6 Dynamic Configuration Options =20 =C2=A0=C2=A0 If implemented, each operating system MUST have a default con= figuration parameter, e.g. diag_header_sys_default_value=3Dyes/no. The oper= ating system MAY also have a dynamic configuration option to =C2=A0=C2=A0 change the configuration setting as needed. =20 =C2=A0=C2=A0 If the PDM destination options extension header is used, then= it MAY be turned on for all packets flowing through the host, applied to a= n upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP =C2=A0=C2=A0 address only.=C2=A0 These are at the discretion of the implem= entation. =C2=A0=20 =20 New text ----------- =20 3.6 Filtering of PDM =20 =C2=A0=C2=A0 If the PDM destination options extension header is used, then= it MAY be turned on for all packets flowing through the host, applied to a= n upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP =C2=A0=C2=A0 address only.=C2=A0 These are at the discretion of the implem= entation. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 =20 From nobody Wed Apr 12 12:12:34 2017 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 9092B126B6D; Wed, 12 Apr 2017 12:12:33 -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 yWWpd62YNknp; Wed, 12 Apr 2017 12:12:31 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 11BCD129468; Wed, 12 Apr 2017 12:12:31 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l189so16325601ywb.0; Wed, 12 Apr 2017 12:12:31 -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=KJ1eTsoxpI6NW5a0CQF12NkuhSxQYQE4htkZYI3RoNg=; b=KHh1y4v71ey3ZJmnIdeGVWn1NeEYf59PTnAE42tXHCCtWSmU59d9j48SkgmVI90mkG WEWQw7jYxkZecqbj6ElzBg2e6vcg1MwHOevmq94sikNAGXm75o3y/i431ubCPibT7vf2 XQWY65T1eOLp1uaALHYuXtq5UWrEG75IXbQCAGD3h41+BCHS2svg0U04JUwOi9DPzGYn 9ZM3clAkrQr8USzU/lh8A1b/V4PGRF1g5nIa5KOuzMzDMek1r9h8BxKiCD9if76kxwOG 6Vhfuuj6KJMMmxeFGi/O6NkqCHxaLZraDcJGbC2ximNN3weiHdT27AgH5dzKrT65vcDm XP8A== 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=KJ1eTsoxpI6NW5a0CQF12NkuhSxQYQE4htkZYI3RoNg=; b=MO9R4bATaQo08kzijsQYwudOOXmavwse6Tx/K9U2SGQjjvSM2duHJktA6rjEB0UfaB UW4Lq9pqRuY9Q5LnJF8x/2aOd+n6KXC+fqI73Wi9IgcmEgPtEfeQKDTRVcc9XGgKkroV YN35+RaYJ6YUn+AtmkO7ggIqEokGZwDdG7gGSzUAE/R2swLJojvMBN7YlQ0xGXGflLv+ l914dAOzeN1BSx3Tx/FkpUwgtMxGN5XDn3Zgf7wLZeZmj+gtxXd61DBEmxweUtCm1Siw dJ/7uz1n16wWuOokm6DSv7VAeAvqqThTkcJxLJFRcbeGsCxwQfElP+2KT/xoOhJoAKOv tNQQ== X-Gm-Message-State: AFeK/H3ST3jGrVCp9vOQoi+eIV3YtphyZ/8P+Bopg4qYxIddkfFyDy2UhTdQrqhuRQzTa4PKxkEIou9TDaUP6Q== X-Received: by 10.129.99.87 with SMTP id x84mr43621549ywb.242.1492024350293; Wed, 12 Apr 2017 12:12:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Wed, 12 Apr 2017 12:12:28 -0700 (PDT) In-Reply-To: <149192747464.15682.3691319250872731449.idtracker@ietfa.amsl.com> References: <149192747464.15682.3691319250872731449.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 12 Apr 2017 14:12:28 -0500 Message-ID: To: Kathleen Moriarty Cc: The IESG , draft-ietf-ippm-6man-pdm-option@ietf.org, Bill Cerveny , "ippm-chairs@ietf.org" , "acmorton@att.com" , ippm@ietf.org Content-Type: multipart/alternative; boundary=001a11473c1a655deb054cfcfd8f Archived-At: Subject: Re: [ippm] Kathleen Moriarty's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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, 12 Apr 2017 19:12:33 -0000 --001a11473c1a655deb054cfcfd8f Content-Type: text/plain; charset=UTF-8 Just on this point ... On Tue, Apr 11, 2017 at 11:17 AM, Kathleen Moriarty < Kathleen.Moriarty.ietf@gmail.com> wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-ippm-6man-pdm-option-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Warren's discuss and comments and have a few additional > comments to add. > > Kind of related to Warren's discuss, I kept looking for a limitation to > the scope for this work in the draft and didn't get to one until the end > of the security considerations section. The text there wasn't quite > clear enough for me. It seems that this might only be used for small > periods of time while troubleshooting, is that correct? It also seems > like this has to be end-to-end, is that right? And if it does need to be > end-to-end, is the user aware of this troubleshooting so that they are > not sending traffic that contains sensitive data that should remain > confidential (security or privacy implications may also exist if this is > not the case). > > If the scope were limited, I would not have as many security concerns. > Network reconnaissance may or may not be an issue. I don't think it is, > but I need to better understand the scope of use for this option. > I can imagine this comment being balloted almost word for word on the In-situ OAM work if it doesn't clearly state its own scope, so I'll ask the IPPM folk to pay close attention to Kathleen's comment in working group discussions about the scope of In-situ OAM ... Spencer > nit: > s/IPSec/IPsec/g > > > --001a11473c1a655deb054cfcfd8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just on this point ...

On Tue, Apr 11, 2017 at 11:17 AM, Kathleen Moriarty <= span dir=3D"ltr"><Kathleen.Moriarty.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Kathleen Moriarty has entered the following b= allot position for
draft-ietf-ippm-6man-pdm-option-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/d= oc/draft-ietf-ippm-6man-pdm-option/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I support Warren's discuss and comments and have a few additional
comments to add.

Kind of related to Warren's discuss, I kept looking for a limitation to=
the scope for this work in the draft and didn't get to one until the en= d
of the security considerations section.=C2=A0 The text there wasn't qui= te
clear enough for me.=C2=A0 It seems that this might only be used for small<= br> periods of time while troubleshooting, is that correct?=C2=A0 It also seems=
like this has to be end-to-end, is that right?=C2=A0 And if it does need to= be
end-to-end, is the user aware of this troubleshooting so that they are
not sending traffic that contains sensitive data that should remain
confidential (security or privacy implications may also exist if this is not the case).

If the scope were limited, I would not have as many security concerns.
Network reconnaissance may or may not be an issue.=C2=A0 I don't think = it is,
but I need to better understand the scope of use for this option.

I can imagine this comment being balloted almost= word for word on the In-situ OAM work if it doesn't clearly state its = own scope, so I'll ask the IPPM folk to pay close attention to Kathleen= 's comment in working group discussions about the scope of In-situ OAM = ...

Spencer
=C2=A0
nit:
s/IPSec/IPsec/g



--001a11473c1a655deb054cfcfd8f-- From nobody Wed Apr 12 12:17:56 2017 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 B569F129AA2 for ; Wed, 12 Apr 2017 12:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 5I8lkmI4Njbf for ; Wed, 12 Apr 2017 12:17:45 -0700 (PDT) Received: from nm40-vm10.bullet.mail.gq1.yahoo.com (nm40-vm10.bullet.mail.gq1.yahoo.com [98.136.216.251]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2A5129A9B for ; Wed, 12 Apr 2017 12:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1492024660; bh=0fEHVCfP9k1apHhX8nXuDO/DUqchMCEqqXMLWpnNIvM=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=t6JSQwg7oAl8wIy1Bb9giDhKA47NKe/zFqbbjg7L8ZkPMxE0p85qNvZASZ9Luti0Lk4wLc3gf1+wqSQZmECAH9u2I9uHNviazY0C2tW9N6WyWDN6719bRx2MCAWzsDP67qy+qoj+tzrdyoSyRftzZruQrINfYAMkvg8hTH5CVmI/Zz33vzK5QhaB9DvZV78qHwjCAPFSfCg9hoUprm1pCS9iygks2uQOSpMO1M9JK3/vfL6fmBQ11WfyigDV3jPQiLaGerJLHXiazYmi88ToarnlFAB9/ygyKy8DpVoUJU57ZdRZP/zFVEuuCMmbKFaNZgJK+9ayb25an9PHU/ZCTg== Received: from [127.0.0.1] by nm40.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 19:17:40 -0000 Received: from [98.137.12.57] by nm40.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 19:14:57 -0000 Received: from [98.137.12.194] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 19:14:57 -0000 Received: from [127.0.0.1] by omp1002.mail.gq1.yahoo.com with NNFMP; 12 Apr 2017 19:14:57 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 87009.76200.bm@omp1002.mail.gq1.yahoo.com X-YMail-OSG: PAw621oVM1kk3TKBUFlw7lxVLrXIH5eeAZAZyUa_X3sW45FWS69PbDhNH7PrJEa 7Zp554Onc8IPsGr1__mkzii3UT.VOcmllEM8OBM0OM0hkZ._0BgbDAi4qebq_7tywh2vGvuyXm_D ipLG42HH8spbf9XJtaEzObU86wHJdUWIojNxrRLCRV59zrnOwBrtnDF9qQBReHEoRMVwe7tcg8xj w6uuWd6dW1WGY2hzLHfdrEi7vEaGvqr3O7hqAEFV_vC.tWCEyt4zdBL9OG7FObE_ucvL75tSskyq 5.dhIKdc._67k2nxbIiUc_Gsbc0MV09v9aSQWRlakk1FZ8Ixi8MIz1iN_ylhKAUIAUVF_5PbRouK 2fiOeKuEUqCAp3cKrabvZyrbWaGcMAxpEqYtAT_8vMZf3BqJKBTMCIHF99PKF720c8xYF5LiPO6D RjXNcUBJiB1haeAYlX0nXiRWDbFgyvMuEpQPf_E0mk9BS8rjGYYyaa_nYGEDrAUNaJ6C3Kj7zAQa Pi1LK5VzD.sBBBe2FZhGevMdG3XGfy9ShPVKwu_YIOB9.4io- Received: from jws300072.mail.gq1.yahoo.com by sendmailws101.mail.gq1.yahoo.com; Wed, 12 Apr 2017 19:14:56 +0000; 1492024496.657 Date: Wed, 12 Apr 2017 19:14:56 +0000 (UTC) From: Reply-To: To: The IESG , Suresh Krishnan , Cc: , Bill Cerveny , , , Message-ID: <841586182.842414.1492024496384@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <841586182.842414.1492024496384.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9386 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 12 Apr 2017 19:17:47 -0000 Suresh, Sorry for the top post.=C2=A0 I am responding to your comment on alignment= . I looked again and RFC2460 says: (in the Extension Header section) 4.2 Options Two of the currently-defined extension headers -- the Hop-by-Hop Options= header and the Destination Options header -- carry a variable number of ty= pe-length-value (TLV) encoded "options", of the following format: ... Individual options may have specific alignment requirements, to ensure th= at multi-octet values within Option Data fields fall on natural boundaries.= The alignment requirement of an option is specified using the notation xn+y, meaning the Option Type must appear at= an integer multiple of x octets from the start of the header, plus y octet= s. For example: 2n means any 2-octet offset from the start of the header. 8n+2 means any 8-octet offset from the start of the header, plus 2 = octets. In PDM, what we have is: Alignment: 2n =3D=C2=A0 Scale Delta Time Last Received (SCALEDTLR, 1 octet= ) Alignment: 3n =3D=C2=A0 Scale Delta Time Last Sent (SCALEDTLS, 1 octet) Alignment=C2=A0 4n =3D=C2=A0 Packet Sequence Number This Packet (PSNTP, 2 = octets) Alignment=C2=A0 6n=C2=A0 =3D Packet Sequence Number Last Received (PSNLR, = 2 octets) Alignment=C2=A0 8n=C2=A0 =3D=C2=A0 Delta Time Last Received (DELTATLR, 2 o= ctets) Alignment 10n =3D=C2=A0 Delta Time Last Sent (DELTATLS, 2 octets) =20 With the entire header being 12 bytes.=C2=A0 But in the length code should= be=3D 10 =3D 12 - 2 (taking out option type and length) I will also redo the Figure to take out the numbering as the Figure implies= word boundaries that may not exist in reality.=20 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Tue, 4/11/17,=C2=A0 wrote: Subject: Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-= option-09: (with DISCUSS and COMMENT) To: "The IESG" , "Suresh Krishnan" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org Date: Tuesday, April 11, 2017, 6:44 PM =20 Suresh, =20 I am only responding to the DISCUSS section below. =20 Nalini =20 -------------------------------------------- On Tue, 4/11/17, Suresh Krishnan wrote: =20 =C2=A0 Subject: Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) =C2=A0 To: "The IESG" =C2=A0 Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org =C2=A0 Date: Tuesday, April 11, 2017, 12:08 PM =C2=A0=20 =C2=A0 > Suresh Krishnan has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss =C2=A0=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l for more information about IESG DISCUSS and COMMENT positions. =C2=A0=20 > The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draf= t-ietf-ippm-6man-pdm-option/ =C2=A0=20 > ---------------------------------------------------------------------- > DISCUSS: =C2=A0 > ---------------------------------------------------------------------- =C2=A0=20 > * Section 3.2.1. =C2=A0 The option length seems to be wrong here. This will make the parser parse incorrectly onto a following option or worse. I think this MUST be set to 10 instead of 16 (Or some field > is missing from the description of the option) =C2=A0=20 >=C2=A0=C2=A0 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. =20 You are correct.=C2=A0 The option length is 10 not 16.=C2=A0=C2=A0 I will fix that. =20 =20 > * Section 3.2.1. >=C2=A0 The option does not seem to state an alignment requirement, but I think one is required to properly align the multi-byte PSN and Delta fields. > Can you please specify one. =20 The alignment for PSN and delta fields follows the alignment requirements for all extension headers. =20 >From RFC2460, I see: =20 Each extension header is an integer multiple of 8 octets long, in order to retain 8-octet alignment for subsequent headers.=C2=A0 Multi-octet fields within each extension header are aligned on their natural boundaries, i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n =3D 1, 2, 4, or 8. =20 The PSN and Delta fields are all on a half-word boundary.=C2=A0=C2=A0 So, I think we are OK.=C2=A0=C2=A0 Do you think I should restate the above in the draft? =C2=A0=20 > * Section 5 =C2=A0=20 > The IANA considerations section needs to be more specific as you are requesting a specific type of option. =C2=A0=20 >=C2=A0 e.g. This draft requests an Destination Option Type assignment with the act bits set to 00 and the chg bit set to 0 from the ... =20 Current Text ---------------- =20 5 IANA Considerations =20 =C2=A0=C2=A0 This draft requests an Option Type assignment in the Destination Options and Hop-by-Hop Options sub-registry of Internet Protocol =C2=A0=C2=A0 Version 6 (IPv6) Parameters [ref to RFCs and URL below]. =20 =C2=A0=C2=A0 http://www.iana.org/assignments/ipv6-parameters/ipv6-paramete= rs.xhtml#ipv6-parameters-2 =20 =20 Hex Value=C2=A0 =C2=A0 =C2=A0 Binary Value=C2=A0 =C2=A0 =C2=A0 Description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Reference=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 act chg rest =C2=A0=20 -------------------------------------------------------------------=C2=A0 =20 =C2=A0=C2=A0 TBD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 TBD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Performance and=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [This draft] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diagnostic Metrics=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 (PDM)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =20 =20 New Text ---------------- =20 5 IANA Considerations =20 =C2=A0=C2=A0 This draft requests a Destination Option Type assignment with the act bits set to 00 and the chg bit set to 0 =C2=A0=C2=A0 from the Destination Options and Hop-by-Hop Options sub-registry of Internet Protocol =C2=A0=C2=A0 Version 6 (IPv6) Parameters [ref to RFCs and URL below]. =20 =20 =C2=A0=C2=A0 http://www.iana.org/assignments/ipv6-parameters/ipv6-paramete= rs.xhtml#ipv6-parameters-2 =20 =20 Hex Value=C2=A0 =C2=A0 =C2=A0 Binary Value=C2=A0 =C2=A0 =C2=A0 Description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Reference=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 act chg rest =C2=A0=20 --------------------------------------------------------------------------= ----------=C2=A0 =20 =C2=A0=C2=A0 TBD=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 00=C2=A0=C2=A0 0=C2=A0 =C2=A0 TBD=C2=A0 =C2=A0=20 Performance and=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [This draft] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diagnostic Metrics=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (PDM)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =20 =C2=A0=20 =C2=A0=20 =20 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm =20 From nobody Wed Apr 12 13:27:05 2017 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 B398A1243F3; Wed, 12 Apr 2017 13:26:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202881672.15788.3652794442424287908.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 13:26:56 -0700 Archived-At: Subject: [ippm] Ben Campbell's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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: Wed, 12 Apr 2017 20:26:57 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive Comments: - 1.4, 2nd to last paragraph: Please don't make assumptions about organizational models; different organizations do it differently. Does the motivation still make sense if the organization doesn't follow this model? - 1.5, first paragraph: "The purpose of the PDM is not to supplant all the variables present in all other headers but to provide data which is not available or very difficult to get." How is that different than for any other extension? 3.2.1, PSNTP definition: What are the consequences if people "spoof and insert such packets."? - 3.2.2: Are there really use cases for attosecond precision? - 4.1, last paragraph: Can you provide guidance on selecting a reasonable limit? At least a lower bound so that the limit does not negatively impact the PDM function? -4.2: Could PDM be used to (help) deduce the nature of the application, or possibly network topology? The last paragraph says it will be unhelpful in deducing content; I suspect otherwise. Section 4.4 talks about how it might help timing attacks against key material. Does PDM really offer no more information to an observer than they could get by observing packet intervals of otherwise encrypted traffic? For example, it seems like one could not differentiate between wire-time and processing-time from observation alone. -4.4, 2nd paragraph: Why does the attacker need to induce the host to turn on PDM? What about cases where the host already uses PDM? -- last paragraph:The text recommends that a user SHOULD consent. I think you mean to say that user consent SHOULD be required. They mean very different things. But along those lines, do you expect the average user to make informed consent decisions? At what scope should such decisions be made? Some OSs ask a user if they are willing to share diagnostic info at a global level. Does the guidance about using PDM on limited IP addresses or ports suggest consent apply at a smaller granularity? Editorial Comments: -General: Much of the text reads more like a white paper than an IETF standards-track RFC. This makes some sections seem like advertisements. The heavy use of "we" calls into question whether it documents the opinions of the WG, or the opinions of the authors. It also makes some sections longer than they need to be (e.g. the discussions related to time scaling factors read more like a classroom lecture than a specification.) I recognize that fixing this would require a re-write. I will leave it to the authors, chairs, and AD to decide if that is worthwhile this late in the process. - Abstract: Last sentence is long and convoluted. Please consider breaking it up. - 1.4, list of advantages: How is 5 different than 2? -- 2nd paragraph after end of list: s/"to do"/"to" - 3.2, 2nd paragraph: Please expand DTN - 3.2, last paragraph: The reference to Appendix A is worded in a way that suggests you have to read that section to understand how to implement time scaling factors. That led me to wonder why the appendix was not part of the body. But when I read the appendix, I realized that it really was additional explanation, and not a normative part of the process. Please consider something like the following: OLD: For a full description of this process... NEW: For additional discussion about this process... - 3.4.1, first paragraph: The MAY seems like a statement of fact, not a normative requirement. (Same for 3.4.2) From nobody Wed Apr 12 13:30:25 2017 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 067D412778E; Wed, 12 Apr 2017 13:30: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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202902400.15788.13146815517614965340@ietfa.amsl.com> Date: Wed, 12 Apr 2017 13:30:24 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-twamp-time-format-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: Wed, 12 Apr 2017 20:30:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP) Authors : Greg Mirsky Israel Meilik Filename : draft-ietf-ippm-twamp-time-format-06.txt Pages : 8 Date : 2017-04-12 Abstract: This document describes an OPTIONAL feature for active performance measurement protocols allowing use of the Precision Time Protocol time stamp format defined in IEEE-1588v2-2008, as an alternative to the Network Time Protocol that is currently used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-twamp-time-format-06 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-twamp-time-format-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-twamp-time-format-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 Wed Apr 12 13:33:39 2017 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 59E4812EB05; Wed, 12 Apr 2017 13:33:31 -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 srm7SX5ipz07; Wed, 12 Apr 2017 13:33:21 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 56FAA12EA74; Wed, 12 Apr 2017 13:33:21 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id r203so45254197oib.3; Wed, 12 Apr 2017 13:33:21 -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=1O3mqSH/rEmziyexst2zK/yWD5/gTzs5yyZ/nz9/mxc=; b=HgeIoyVdARSRXuw/oRqlxmP0aZfW8oRKde1WEGwkWFEvqjJWgQictAWAScFlQK5JUa xKnCWwx2pdy5JTeH/eaea8eNFnMpLpFHoNQw8TdjqrKmXXh/iZu1SG2eVWjnb+7mKlTX k4EMbE5OWNFQMu3fXjwwpBFhTkirKKgOaIU9vTMk4sGJzLeZYgORn02MHs376v3IEtxR D9x9B61JrDOjcl81Z2Zg2YKggDkNa3N+X1YS9MSrofofT45h8y0lQ+0D8EPuSx/n2z0e yfQ6CskVfnzYrQPx6OHVA+opF0vtKPpLfinV5UrvHae7Oz7oS61iqf52fqHf+UrwjJEu VY7A== 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=1O3mqSH/rEmziyexst2zK/yWD5/gTzs5yyZ/nz9/mxc=; b=LmVSpWuXpTZjqIB1eGy/KOFNSN/dCcBCQ0YbSZm4zpG5YJFavsfbTj5wRG2ImU6TF+ DJ55ovmClD1f2sH2+S+7aey86uCgwS5AZyGOSlBVkOmVpolXFucDGOQCU9qJSH5FB+V2 I1NGCt9yjH7OA63Qqp49ND6DwTReWEVnQPIK2BKmiD1E889qec2t1BOZf8pbCfxYyJ2E m6jVv7EC1yx0wcWVKGjjgsyegeP1+Kff95UaflVEsRyKJU0WFpqKs8UejIkKVGBb44bP E7GCPE5tXA/iH1zxibs6k5L5nVm0nn1g/NKJpqVXsMisyMKRYfz2+GZxQ5cdm9yNnZDg CgCQ== X-Gm-Message-State: AN3rC/43xb972QYsojHsK0n1+oEq0Vwscgl8RoXDY68BWYt10IfYbBD7PjWfUoXDzLvtqXUbYFgWK88k+F156g== X-Received: by 10.157.68.146 with SMTP id v18mr5539620ote.128.1492029200727; Wed, 12 Apr 2017 13:33:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.165 with HTTP; Wed, 12 Apr 2017 13:33:20 -0700 (PDT) In-Reply-To: <149183390250.3076.7292862107229671405.idtracker@ietfa.amsl.com> References: <149183390250.3076.7292862107229671405.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 12 Apr 2017 13:33:20 -0700 Message-ID: To: Benoit Claise Cc: The IESG , draft-ietf-ippm-twamp-time-format@ietf.org, Bill Cerveny , IPPM Chairs , "ippm@ietf.org" , Jon Mitchell Content-Type: multipart/alternative; boundary=f40304353fd8810874054cfe1e22 Archived-At: Subject: Re: [ippm] Benoit Claise's No Objection on draft-ietf-ippm-twamp-time-format-05: (with COMMENT) 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, 12 Apr 2017 20:33:31 -0000 --f40304353fd8810874054cfe1e22 Content-Type: text/plain; charset=UTF-8 Hi Benoit, the new version of the draft just been uploaded. It includes the the text to address the comment by Jon Mithchell. Regards, Greg On Mon, Apr 10, 2017 at 7:18 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-ippm-twamp-time-format-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Good feedback from Jon Mitchell, in his OPS-DIR review: > > Indeed, TWAMP Test, and the time stamp format to be used, may be > controlled by means other than TWAMP Control, e.g., local configurable > knob exposed via data model or CLI. I'll work on text updates for the > next version. > > Regards, > Greg > > On Fri, Mar 17, 2017 at 2:01 PM, Jon Mitchell > wrote: > > Reviewer: Jon Mitchell > Review result: Has Nits > > I have reviewed this document as part of the Operational > directorate's > > ongoing effort to review all IETF documents being processed by the > IESG. These > comments were written with the intent of improving the operational > aspects of the > IETF drafts. Comments that are not addressed in last call may be > included in AD reviews > during the IESG review. Document editors and WG chairs should > treat > these comments > just like any other last call comments. > > Ready with Nits - this draft adds the ability to use PTP timestamps > as > an alternative to NTP timestamps for active performance measurement > protocols OWAMP and TWAMP. Although this draft does a good job of > discussing interoperability for both sides of the session having or > not having support for this operational capability, in several > places > it states that if a send/receiver support this capability it must > be > set to 1 in the flags. However, only for TWAMP Light mode, this > seems > configurable. This may just be my interpretation, but it probably > should state that local implementations MAY provide a configurable > knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even > if > the capability is supported by the implementation. > > > --f40304353fd8810874054cfe1e22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,
the new version of the draft just been uplo= aded. It includes the the text to address the comment by Jon Mithchell.

Regards,
Greg

On Mon, Apr 10, 2017 at 7:18 AM, Be= noit Claise <bclaise@cisco.com> wrote:
Benoit Claise has entered the following ballot position for draft-ietf-ippm-twamp-time-format-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Good feedback from Jon Mitchell, in his OPS-DIR review:

Indeed, TWAMP Test, and the time stamp format to be used, may be
controlled by means other than TWAMP Control, e.g., local configurable
knob exposed via data model or CLI. I'll work on text updates for the next version.

Regards,
Greg

On Fri, Mar 17, 2017 at 2:01 PM, Jon Mitchell <jrmitche@puck.nether.net>
wrote:

=C2=A0 =C2=A0 Reviewer: Jon Mitchell
=C2=A0 =C2=A0 Review result: Has Nits

=C2=A0 =C2=A0 I have reviewed this document as part of the Operational
directorate's

=C2=A0 =C2=A0 ongoing effort to review all IETF documents being processed b= y the
=C2=A0 =C2=A0 IESG.=C2=A0 These
=C2=A0 =C2=A0 comments were written with the intent of improving the operat= ional
=C2=A0 =C2=A0 aspects of the
=C2=A0 =C2=A0 IETF drafts. Comments that are not addressed in last call may= be
=C2=A0 =C2=A0 included in AD reviews
=C2=A0 =C2=A0 during the IESG review.=C2=A0 Document editors and WG chairs = should
treat
=C2=A0 =C2=A0 these comments
=C2=A0 =C2=A0 just like any other last call comments.

=C2=A0 =C2=A0 Ready with Nits - this draft adds the ability to use PTP time= stamps
as
=C2=A0 =C2=A0 an alternative to NTP timestamps for active performance measu= rement
=C2=A0 =C2=A0 protocols OWAMP and TWAMP.=C2=A0 Although this draft does a g= ood job of
=C2=A0 =C2=A0 discussing interoperability for both sides of the session hav= ing or
=C2=A0 =C2=A0 not having support for this operational capability, in severa= l
places
=C2=A0 =C2=A0 it states that if a send/receiver support this capability it = must
be
=C2=A0 =C2=A0 set to 1 in the flags.=C2=A0 However, only for TWAMP Light mo= de, this
seems
=C2=A0 =C2=A0 configurable.=C2=A0 This may just be my interpretation, but i= t probably
=C2=A0 =C2=A0 should state that local implementations MAY provide a configu= rable
=C2=A0 =C2=A0 knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2= even
if
=C2=A0 =C2=A0 the capability is supported by the implementation.



--f40304353fd8810874054cfe1e22-- From nobody Wed Apr 12 13:34:37 2017 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 35D9812EB40 for ; Wed, 12 Apr 2017 13:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 SUuIiu1icMYZ for ; Wed, 12 Apr 2017 13:34:26 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 A959812EB50 for ; Wed, 12 Apr 2017 13:34:15 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id c45so31879558qtb.1 for ; Wed, 12 Apr 2017 13:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CwPsi5J6r+acYjjYbUwJ/gqq5pgo9mfZPr4lpYMoQs8=; b=G/oR2+R9f/FfPjqkhIMGmOA6Hf0Xr4fDCj6H9LJNQCGeSP5MJQFJNF4E3K2GylZs6q Izpi9x/WqdKu75+pHW0CUiVnAxL/TEV/OdfmnjmGsQ5YAjPrNLsB5fVbeObikQLtzoQM 2akak3WOWYwc1jiFTanXjWRCI4ug1csJtwMmaGs2t1Y0YuJaUfNXHdKvRZK0RcKQf+rk cZN4xAvYEToWvZ1MMMPkEECQm1Qyt86723NWlbNdTuld56zAivV3HeIMQdU4XHOchsao TaF0KeJvz7OF4pwC+QtZtH0vc2wWu1wcngSFbniNvNxpyWb6jSen1pVsrrMzcwvD6aYH lFjA== 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=CwPsi5J6r+acYjjYbUwJ/gqq5pgo9mfZPr4lpYMoQs8=; b=qJqzzZdd/8aSPBjCU14bCe0jinIg6ri6ZRe3y4Kdw54PyvPGtrHTeXFa5kLJU3PkRt t3ppL0Ho0WLFsH7W3QpdDCd45ynfIHvk5vOQmCPEtSspKsnI2rdWQ6JoRFiDGdL4zvHK yMxLlzyFL0p12vKiy9rjN2VDi/9kd0ktE88VbnYs6Lcn6/L+q/0W4YKh8EIGuvs0/E0k oJRPnSVxd/2O4WL38aqmW6bSV9tU8Ae6jeTUb/kZt2JjLB4PSZrK7OSZ8ookEobEqYWu pLyuDpftvOTciQpR+ZB0NVWDbF2mwO9SckXVr8GB9v+DC35B3hRu+IZ3Jl6O4b72mt6l axRA== X-Gm-Message-State: AN3rC/5Fblz7WTupwjkJhvjWNUqMv+2n3rPYe/OFsKH4/E/l215r0kyQBUfTDvchY+/QlF0KQBrSPleyN8J3vnWf X-Received: by 10.200.45.161 with SMTP id p30mr8489238qta.122.1492029254705; Wed, 12 Apr 2017 13:34:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.136 with HTTP; Wed, 12 Apr 2017 13:33:34 -0700 (PDT) In-Reply-To: <459943993.835318.1492023872585@mail.yahoo.com> References: <459943993.835318.1492023872585.ref@mail.yahoo.com> <459943993.835318.1492023872585@mail.yahoo.com> From: Warren Kumari Date: Wed, 12 Apr 2017 16:33:34 -0400 Message-ID: To: Nalini Elkins Cc: The IESG , draft-ietf-ippm-6man-pdm-option@ietf.org, "MORTON, ALFRED C (AL)" , Bill Cerveny , ippm-chairs@ietf.org, ippm@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 12 Apr 2017 20:34:28 -0000 On Wed, Apr 12, 2017 at 3:04 PM, wrote: > Warren, > > I am responding to your Comments below. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -------------------------------------------- > On Sat, 4/8/17, Warren Kumari > wrote: > > Subject: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) > To: "The IESG" > Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org > > Date: Saturday, April 8, 2017, 10:01 AM > > > Warren Kumari has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > The document says that packet sequence number are optional ("measurements based on optional sequence numbers and timing may be embedded in each > > packet"), but doesn't say what should be put in the PSNTP field if I'm not using them. It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets > > (the exmaple just has a dash). This means that I cannot create an interoperable implementation from this document alone. > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / > > ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out > > of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). > > How is this? > > Current Text > ---------------- > > 1.6 IPv6 Transition Technologies > > In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed. The PDM header is not expected to work in such scenarios. It is likely that an > IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. > > New Text > ------------ > > 1.6 Full Support of IPv6 Functionality > > In the path to full implementation of native IPv6, transition technologies such as translation or tunneling may be employed. The PDM header may not work in such scenarios. It is likely that an > IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. > > It is also possible that some devices in the network may not correctly handle multiple IPv6 Extension Headers, including the IPv6 Destination Option. For example, adding the PDM header to a packet > may push the layer 4 information to a point in the packet where it is not routed correctly. This kind of situation is expected to become rare over time. Mostly good -- I think that "where is it not routed correctly" seems a little odd - that feels like it means the packet may be routed to the wrong place - perhaps "where it is not visible to filtering logic, and may be dropped" ? Otherwise good. > > > > In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions > > overhead from larger packets, but nothing about the additional processing time. > > > How about if we add the following to Appendix C after the first paragraph: > > As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM. Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal. Great. > > > > > In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it > > gets some number of "nonsensical" sequence numbers." -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic. > > I think what we were thinking is that there may be, in the future, middle boxes (for example, firewalls) which might be able to detect nonsensical sequence numbers. So, they would not be the ones who > initiated the use of PDM as a covert channel. Is there a better way to say this? Yeah, that was not clear to me from the text -- it would then also not be the implementation which would stop using PDM, it would be the middle box which would (presumably) block it. Perhaps say something like: If a PDM aware middle box detects some number of "nonsensical" sequence numbers it could take action to block (or alert on) this traffic." > > > > Another example is section 4.4 Timing Attacks: "Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM. Consent is common in enterprises and with > > some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. > > The addition "Consent to be Measured" is so that people know that along with the many benefits of accurate measurements, there are some inevitable small risks. > > > > In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This > > feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite. > > > How about if we add something to explain further "Consent to be Measured". Sentence below: > > "The actual content of "Consent to be Measured" will differ by site but it SHOULD make clear that the traffic is being measured for quality of service and to assist in diagnostics as well as to make clear that there > may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session. " I still don't love this, but am OK with it. > > > > I don't understand Section 3.6 Dynamic Configuration Options. "If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating > > system MAY also have a dynamic configuration option to change the configuration setting as needed." I don't understand how an implementing OS could not have a default (unless this were random). If the > > default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled). > > > Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off.", so I'm very confused what > > 3.6 is trying to say... > > I agree that paragraph is confusing. I suggest deleting it since section 3.5.1 already discusses defaults. > > Current text > ---------------- > > 3.6 Dynamic Configuration Options > > If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to > change the configuration setting as needed. > > If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP > address only. These are at the discretion of the implementation. > > > New text > ----------- > > 3.6 Filtering of PDM > > If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP > address only. These are at the discretion of the implementation. WFM. W > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Apr 12 13:36:40 2017 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 930BB129ABD for ; Wed, 12 Apr 2017 13:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 h6H3urWY0kkN for ; Wed, 12 Apr 2017 13:36:17 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 4510312EB50 for ; Wed, 12 Apr 2017 13:36:13 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id n46so31904640qta.2 for ; Wed, 12 Apr 2017 13:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fJKahAuL/7kEP5rYOzvL/B9S7kUxMaxCY431mRjxH/U=; b=0s3Z158q/dO9yOvislmQ8L5wXuHiv0Bp3hx2PZNyuaQuWwtmj7WX1mnDodxZp6jbL+ 9ykaiFAMLxX0oJ6Thsv3fgkjNT9TSLB0NuKQhKXHMjTdLsFTZAP+hYNMzjO1vmVfx2+4 4V02o/B5HnntVrFJmLQoyK0BPEJJr5qeEIlnwqdom/ECP0Z/WX4fBpNOE85cVPgPf+LU 0QscLAQy/2i+6rJWi6DVhNAeIk8zQ/MxecbK9NQdU64sqPiQEMKreqi4kwuIrWfzvBc3 Bg8fvCN8psnHh8FLXLdFmlawPCRs/f+D3xT4J9huEr4DKRtUQjRZL2AWOCkMjP0qQk5O q44A== 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:content-transfer-encoding; bh=fJKahAuL/7kEP5rYOzvL/B9S7kUxMaxCY431mRjxH/U=; b=eXAioV/9VdtxSRccLdm4F8IHJl41SNKLIuNTVRrbdRg0G7fqdbZkUA9g1Q25/8/uFp HEmxL1K/XhFM0kivBXhqHj/TnDIvVXMqlOIOt3RpdPE3pJDsSCW904rV1xI99VZEdHTF GmmfXwyPwOhAIDmdBCFEZx6iHKD3SXfUuINht001W8T9j7oXHHdhRSS3xGAmNsZp4KXd kxCSFLO07v4OWRjy8ws9RaWdaELJuxecQK57+mfflIHMybvJIMMoXRCAoJt77P7hJ2jE 3oLXPBrAaWAgVnL2oTSUBgoQz2VrRRYm15q7dDf52bB+57THpJKBRr4tJKfW/Ks3nw3q HDyg== X-Gm-Message-State: AFeK/H1Ix2XgO/krQjwJ08QfmQtKhhpF67qnp4sX1SrCvSCfQ/yd6jGSPnBKGH9hDJ6LUCDPtDYTaSfCPzxIuI2V X-Received: by 10.237.34.212 with SMTP id q20mr64852818qtc.5.1492029372265; Wed, 12 Apr 2017 13:36:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.136 with HTTP; Wed, 12 Apr 2017 13:35:31 -0700 (PDT) In-Reply-To: <1417210962.39039.1491953782886@mail.yahoo.com> References: <1417210962.39039.1491953782886.ref@mail.yahoo.com> <1417210962.39039.1491953782886@mail.yahoo.com> From: Warren Kumari Date: Wed, 12 Apr 2017 16:35:31 -0400 Message-ID: To: Nalini Elkins Cc: "ALFRED C (AL)MORTON" , The IESG , "draft-ietf-ippm-6man-pdm-option@ietf.org" , Bill Cerveny , "ippm-chairs@ietf.org" , "ippm@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT) 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, 12 Apr 2017 20:36:27 -0000 On Tue, Apr 11, 2017 at 7:36 PM, wrote: > -------------------------------------------- > On Tue, 4/11/17, Warren Kumari wrote: > > Subject: Re: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-= 09: (with DISCUSS and COMMENT) > To: "MORTON, ALFRED C (AL)" > Cc: "nalini.elkins@insidethestack.com" , "The IESG" , "draft-ietf-ippm-6man-pdm-option@ietf.org" <= draft-ietf-ippm-6man-pdm-option@ietf.org>, "Bill Cerveny" , "ippm-chairs@ietf.org" , "ippm@ietf.org" > Date: Tuesday, April 11, 2017, 2:59 PM > > On Sat, Apr 8, 2017 at 1:51 PM, > MORTON, ALFRED C (AL) > wrote: >>> Hi Nalini and Warren, >>> (doc shepherd chiming-in) >>> >>> Perhaps: >>> Abstract >>> >>> To assess performance problems, this document describes optional >> > headers embedded in each packet that provide sequence numbers and ti= mestamps >>> as a basis for measurements. >>> ... > >> I prefer Al's text, but either is fine with me. > > I prefer Al's text also but with a minor change. Timestamps are not sen= t but rather deltas. So, the new sentence is: > > To assess performance problems, this document describes optional > headers embedded in each packet that provide sequence numbers and timing= information > as a basis for measurements. > ... > >> The discuss also said: "It also doesn't say what I should put in the PS= NLR field if I haven't received any PDM packets (the exmaple just has >> a dash). This means that I cannot create an interoperable implementation= from this document alone." >> For example, when I send my first packet with PDM in it (Section B.1.1 S= tep 1) I have not yet received any packets with a sequence number, so >> I don't know what to put in the PSNLR field -- I think that this need t= o be specified (perhaps 0? 0xFFFF?) > > Yes. In section 3.2.1 (PDM Layout) > > Existing Text > ------------------ > > Packet Sequence Number Last Received (PSNLR) > > 16-bit unsigned integer. This is the PSNTP of the packet last receive= d on the 5-tuple. > > Add > ----- > This field is initialized to 0. Okey dokey. I'm happy to clear my DISCUSS once a new revision is published. (I'm new here and the DISCUSS page says: "If revisions are required, it is customary for the Area Director to clear their DISCUSS only when the revision containing the necessary emendations has been published in the Internet-Drafts repository." ) W > > > Thanks, > Nalini > > > > > > > Al > > > > > >> -----Original Message----- > >> From: nalini.elkins@insidethestack.com > >> [mailto:nalini.elkins@insidethestack.com] > >> Sent: Saturday, April 08, 2017 1:44 > PM > >> To: The IESG; Warren Kumari > >> Cc: draft-ietf-ippm-6man-pdm-option@ietf.org; > MORTON, ALFRED C (AL); > >> Bill > Cerveny; ippm-chairs@ietf.org; > ippm@ietf.org > >> Subject: Re: Warren Kumari's > Discuss on draft-ietf-ippm-6man-pdm-option- > >> 09: (with DISCUSS and COMMENT) > >> > >> Warren, > >> > >> Thanks for > your comments. I will respond to the comments section > ASAP. > >> > >> > But, this is for the DISCUSS > >> > >> > > ---------------------------------------------------------------------- > >> > DISCUSS: > >> > > --------------------------------------------------------------------- > >> - > >> > >> > The document says that packet > sequence number are optional > >> > ("measurements based on optional sequence numbers and > timing may be > >> embedded in each > packet"), but doesn't say what should > >> > be put in the PSNTP field if > I'm not using them. It also doesn't say > >> what I should put in the PSNLR field > if I haven't received any PDM > >> > packets (the exmaple just has a dash). This means that I > cannot create > >> an > >> > interoperable implementation > from this document alone. > >> > >> What we meant to say is that the > entire Destination Option is optional, > >> not that the packet sequence numbers > are optional. > >> > >> Current wording > >> --------------------- > >> Abstract > >> > >> To assess performance problems, > measurements based on optional > >> > sequence numbers and timing may be embedded in each > packet. Such > >> measurements > may be interpreted in real-time or after the fact. An > >> implementation of the existing > IPv6 Destination Options extension > >> header, the Performance and > Diagnostic Metrics (PDM) Destination > >> Options extension header as well > as the field limits, calculations, > >> and usage of the PDM in > measurement are included in this document. > >> > >> > >> Proposed wording > >> ------------------------ > >> > >> Abstract > >> > >> To > assess performance problems, measurements based on > >> sequence numbers and timing may > be embedded in each packet. Such > >> measurements may be interpreted > in real-time or after the fact. An > >> implementation of the existing > IPv6 Destination Options extension > >> header, the Performance and > Diagnostic Metrics (PDM) Destination > >> Options extension header as well > as the field limits, calculations, > >> and usage of the PDM in > measurement are included in this document. > >> The use of the PDM Destination > Option is optional. That is, an > >> > implementation > >> may choose not > to support it. > >> > >> Thanks, > >> > >> Nalini Elkins > >> > CEO and Founder > >> Inside Products, > Inc. > >> www.insidethestack.com > >> (831) 659-8360 > >> > >> > -------------------------------------------- > >> On Sat, 4/8/17, Warren Kumari > wrote: > >> > >> > Subject: Warren Kumari's Discuss on > draft-ietf-ippm-6man-pdm-option-09: > >> > (with DISCUSS and COMMENT) > >> To: > "The IESG" > >> Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, > "Al Morton" > >> , > "Bill Cerveny" , > ippm- > >> chairs@ietf.org, > acmorton@att.com, > ippm@ietf.org > >> Date: Saturday, April 8, 2017, 10:01 > AM > >> > >> > Warren Kumari has entered the following > >> ballot position for > >> > draft-ietf-ippm-6man-pdm-option-09: > >> Discuss > >> > >> When responding, please keep the > >> subject line intact and reply to > all > >> email addresses included in > the To and > >> CC lines. (Feel free > to cut this > >> introductory > paragraph, however.) > >> > >> > >> Please > refer to https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > >> > 3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=3DDwIFaQ&c=3DL= FYZ- > >> > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DDe_5hrtDljLJ3VK66tjLHiA= NTN9 > >> > K7XMPe5kXd0FjUcU&s=3Dd8aytJtECiLj4P1KOB1q5ORq2jEapXFca8_c6YatAnw&e=3D > >> for more information about IESG > DISCUSS > >> and COMMENT positions. > >> > >> > >> The document, along with other > ballot > >> positions, can be found > here: > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > >> > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2D6man-2Dpdm- > >> 2Doption_&d=3DDwIFaQ&c=3DLFYZ- > >> > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DDe_5hrtDljLJ3VK66tjLHiA= NTN9 > >> > K7XMPe5kXd0FjUcU&s=3D4Wpy1AmRHeyuVk_zDbqENoerkIYf2AxQTHqp1eTejcI&e=3D > >> > >> > >> > >> > ---------------------------------------------------------------------- > >> DISCUSS: > >> > ---------------------------------------------------------------------- > >> > >> The > document says that packet sequence > >> number are optional > ("measurements > >> based on > optional sequence numbers and > >> > timing may be embedded in each > >> > packet"), but doesn't say what should > >> be put in the PSNTP field if > I'm > >> not using them. It also > doesn't say > >> what I should put > in the PSNLR field > >> if I > haven't received any PDM packets > >> (the exmaple just has a dash). > This > >> means that I cannot create > an > >> interoperable implementation > from this > >> document alone. > >> > >> > >> > ---------------------------------------------------------------------- > >> COMMENT: > >> > ---------------------------------------------------------------------- > >> > >> This > document defines a new IPv6 > >> > Destination Option. Adding this to a > >> packet pushes the L4 information > >> further out, potentially making > it > >> unavailable to the forwarding > engine / > >> ACLs. This is not just > a > >> theoretical issue - see RFC7872 > for > >> real world examples. This > means that > >> if I connect to a > remote machine and > >> enable this, I > may lock myself out > >> of the > machine (return packets may not > >> > make it back to me); this should > >> > be noted (perhaps by expanding on > >> > section 1.6). In addition, enabling PDM > >> will (almost definitely) add some > >> processing / transmit time, and so > will > >> perturb the very thing being > measured - > >> I believe that the > document > >> should note this. > Appendix C mentions > >> overhead from > larger packets, but > >> nothing about > the additional processing > >> > time. > >> > >> In > addition, much of the security > >> > advice feels like sops, simply to > >> > appease security people. For example, > >> in "PDM as a Covert > Channel" we > >> find: > "Having said that, an > >> > implementation SHOULD stop using PDM if it > >> gets some number of > "nonsensical" > >> sequence > numbers." -- seeing as it > >> > would be the attacker using PDM as a > >> convert channel, this is like > saying > >> attackers must set the > evil bit on all > >> attack > traffic. > >> > >> > Another example is section 4.4 Timing > >> Attacks: > >> > "Even so, if using PDM, we introduce > >> the concept of user "Consent to > be > >> Measured" as a > pre-requisite for using > >> PDM. > Consent is common in > >> enterprises > and with some subscription > >> > services. So, if with PDM, we > >> > recommend that the user SHOULD consent > >> to its use." - this has nothing > to > >> do with timing attacks. In > addition a > >> concept is introduced, > but not > >> really explained - it is > then claimed > >> that this is common > in enterprises > >> (true), and that > users SHOULD consent > >> (or should > have already consented) > >> to being > monitored. This feels like it > >> was > sprinkled on like security > >> fairy > dust to make security people > >> > happy, and (for me) does the > >> > opposite. > >> > >> > >> I don't > understand Section 3.6 Dynamic > >> > Configuration Options. > >> "If > implemented, each operating system > >> MUST have a default configuration > >> parameter, e.g. > >> > diag_header_sys_default_value=3Dyes/no. The operating > >> system MAY also have a dynamic > >> configuration option to change > the > >> configuration setting as > needed." > >> I don't > understand how an implementing > >> OS > could not have a default > >> (unless > this were random). If the > >> default > were no, presumably it would > >> > *have* to have a dynamic option to > >> change the config (or it could > never > >> be enabled). > >> Section 3.5.1 says: "The PDM > >> destination options extension header > MUST be > >> explicitly turned on by > each > >> stack on a host node by > administrative > >> action. The > default value of PDM > >> is > off.", so I'm very confused what 3.6 > >> is trying to say... > >> > >> > >> > > > > -- > I > don't think the execution is relevant when it was > obviously a bad > idea in the first place. > This is like putting rabid weasels in your > pants, and later expressing > regret at having > chosen those particular rabid weasels and that pair > of pants. > ---maf > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Apr 12 14:29:02 2017 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 633F412EB4F; Wed, 12 Apr 2017 14:28:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Deborah Brungard To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, Al Morton , Bill Cerveny , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149203253030.15674.9991389611454681263.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 14:28:50 -0700 Archived-At: Subject: [ippm] Deborah Brungard's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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: Wed, 12 Apr 2017 21:28:51 -0000 Deborah Brungard has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Agree with the many comments by the other ADs. Especially, Mirja's and Ben's comments, the document reads like a white paper vs. an IETF specification. The "Consent to be Measured" by a user (section 4.4) seems contra to the use case described in the document (estimate QoS as experienced by an end user device). It should be the network provider who should be giving "consent to be measured" and the associated risks. Warren also noted these sentences as inappropriate. The document discusses the security aspects relative to the user but is missing discussion with respect to the network provider. From nobody Wed Apr 12 17:04:36 2017 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 BB8F612786A; Wed, 12 Apr 2017 17:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, MISSING_MIMEOLE=1.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 Gm2EKuLcl-OM; Wed, 12 Apr 2017 17:04:32 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id A1A2B127599; Wed, 12 Apr 2017 17:04:32 -0700 (PDT) Received: from [192.168.1.8] (pool-70-106-204-94.clppva.fios.verizon.net [70.106.204.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 072D1540570; Wed, 12 Apr 2017 20:04:30 -0400 (EDT) Date: Wed, 12 Apr 2017 20:04:28 -0400 Message-ID: X-Android-Message-ID: In-Reply-To: From: Jon Mitchell To: Greg Mirsky Cc: " ietf@ietf.org" , draft-ietf-ippm-twamp-time-format.all@ietf.org, ops-dir@ietf.org, ippm@ietf.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [ippm] Review of draft-ietf-ippm-twamp-time-format-05 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, 13 Apr 2017 00:04:34 -0000 PGRpdiBkaXI9J2F1dG8nPjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8i PlNHVE08L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBBcHIgMTAsIDIwMTcgMTI6MzEsIEdyZWcgTWlyc2t5ICZsdDtncmVn aW1pcnNreUBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+PGJsb2Nr cXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBkaXI9Imx0ciI+SGkgSm9uLDxk aXY+YXBvbG9naWVzIGZvciB0aGUgZXh0ZW5kZWQgZGVsYXkgdG8gYWRkcmVzcyB5b3VyIGNvbW1l bnQuIEkmIzM5O2QgbGlrZSB0byBhZGQgdGhlIGZvbGxvd2luZyBqdXN0IGJlZm9yZSB0aGUgU2Vj dGlvbiAyLjE6PC9kaXY+PGRpdj48cHJlIHN0eWxlPSJjb2xvcjpyZ2IoIDAgLCAwICwgMCApO3dv cmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj4gICBJbXBsZW1lbnRhdGlv bnMgb2YgT1dBTVAgYW5kL29yIFRXQU1QIE1BWSBwcm92aWRlIGEgY29uZmlndXJhdGlvbg0KICAg a25vYiB0byBieXBhc3MgdGhlIHRpbWVzdGFtcCBmb3JtYXQgbmVnb3RpYXRpb24gcHJvY2VzcyBh bmQgdG8gdXNlDQogICB0aGUgbG9jYWxseSBjb25maWd1cmVkIHZhbHVlcyBpbnN0ZWFkLg0KPC9w cmU+PC9kaXY+PGRpdj5Ib3BlIGl0IGNhcHR1cmVzIHRoZSBpZGVhIG9mIGFuZCBhZGRyZXNzZXMg eW91ciBjb21tZW50LjwvZGl2PjxkaXY+PGJyIC8+PC9kaXY+PGRpdj5SZWdhcmRzLDwvZGl2Pjxk aXY+R3JlZzwvZGl2PjxkaXY+PGJyIC8+PC9kaXY+PC9kaXY+PGRpdj48YnIgLz48ZGl2IGNsYXNz PSJlbGlkZWQtdGV4dCI+T24gTW9uLCBNYXIgMjAsIDIwMTcgYXQgMTA6MzQgQU0sIEdyZWcgTWly c2t5IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5JiM2NDtn bWFpbC5jb20iPmdyZWdpbWlyc2t5JiM2NDtnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6 PGJyIC8+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCAwLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0ibHRyIj5IaSBKb24sPGRp dj50aGFuayB5b3UgZm9yIGtpbmQgY29uc2lkZXJhdGlvbiBvZiB0aGUgZHJhZnQgYW5kIHRob3Vn aHRmdWwgY29tbWVudC4gSW5kZWVkLCBUV0FNUCBUZXN0LCBhbmQgdGhlIHRpbWUgc3RhbXAgZm9y bWF0IHRvIGJlIHVzZWQsIG1heSBiZSBjb250cm9sbGVkIGJ5IG1lYW5zIG90aGVyIHRoYW4gVFdB TVAgQ29udHJvbCwgZS5nLiwgbG9jYWwgY29uZmlndXJhYmxlIGtub2IgZXhwb3NlZCB2aWEgZGF0 YSBtb2RlbCBvciBDTEkuIEkmIzM5O2xsIHdvcmsgb24gdGV4dCB1cGRhdGVzIGZvciB0aGUgbmV4 dCB2ZXJzaW9uLjwvZGl2PjxkaXY+PGJyIC8+PC9kaXY+PGRpdj5SZWdhcmRzLDwvZGl2PjxkaXY+ R3JlZzwvZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxiciAvPjxkaXYgY2xhc3M9ImVsaWRlZC10 ZXh0Ij5PbiBGcmksIE1hciAxNywgMjAxNyBhdCAyOjAxIFBNLCBKb24gTWl0Y2hlbGwgPHNwYW4g ZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86anJtaXRjaGUmIzY0O3B1Y2submV0aGVyLm5l dCI+anJtaXRjaGUmIzY0O3B1Y2submV0aGVyLm5ldDwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIg Lz48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAgMCAwIDAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPlJldmlld2VyOiBKb24gTWl0Y2hlbGw8YnIgLz4N ClJldmlldyByZXN1bHQ6IEhhcyBOaXRzPGJyIC8+DQo8YnIgLz4NCkkgaGF2ZSByZXZpZXdlZCB0 aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIE9wZXJhdGlvbmFsIGRpcmVjdG9yYXRlJiMzOTtz PGJyIC8+DQo8YnIgLz4NCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVu dHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZTxiciAvPg0KSUVTRy7CoCBUaGVzZTxiciAvPg0KY29t bWVudHMgd2VyZSB3cml0dGVuIHdpdGggdGhlIGludGVudCBvZiBpbXByb3ZpbmcgdGhlIG9wZXJh dGlvbmFsPGJyIC8+DQphc3BlY3RzIG9mIHRoZTxiciAvPg0KSUVURiBkcmFmdHMuIENvbW1lbnRz IHRoYXQgYXJlIG5vdCBhZGRyZXNzZWQgaW4gbGFzdCBjYWxsIG1heSBiZTxiciAvPg0KaW5jbHVk ZWQgaW4gQUQgcmV2aWV3czxiciAvPg0KZHVyaW5nIHRoZSBJRVNHIHJldmlldy7CoCBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0PGJyIC8+DQp0aGVzZSBjb21tZW50 czxiciAvPg0KanVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyIC8+DQo8 YnIgLz4NClJlYWR5IHdpdGggTml0cyAtIHRoaXMgZHJhZnQgYWRkcyB0aGUgYWJpbGl0eSB0byB1 c2UgUFRQIHRpbWVzdGFtcHMgYXM8YnIgLz4NCmFuIGFsdGVybmF0aXZlIHRvIE5UUCB0aW1lc3Rh bXBzIGZvciBhY3RpdmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQ8YnIgLz4NCnByb3RvY29scyBP V0FNUCBhbmQgVFdBTVAuwqAgQWx0aG91Z2ggdGhpcyBkcmFmdCBkb2VzIGEgZ29vZCBqb2Igb2Y8 YnIgLz4NCmRpc2N1c3NpbmcgaW50ZXJvcGVyYWJpbGl0eSBmb3IgYm90aCBzaWRlcyBvZiB0aGUg c2Vzc2lvbiBoYXZpbmcgb3I8YnIgLz4NCm5vdCBoYXZpbmcgc3VwcG9ydCBmb3IgdGhpcyBvcGVy YXRpb25hbCBjYXBhYmlsaXR5LCBpbiBzZXZlcmFsIHBsYWNlczxiciAvPg0KaXQgc3RhdGVzIHRo YXQgaWYgYSBzZW5kL3JlY2VpdmVyIHN1cHBvcnQgdGhpcyBjYXBhYmlsaXR5IGl0IG11c3QgYmU8 YnIgLz4NCnNldCB0byAxIGluIHRoZSBmbGFncy7CoCBIb3dldmVyLCBvbmx5IGZvciBUV0FNUCBM aWdodCBtb2RlLCB0aGlzIHNlZW1zPGJyIC8+DQpjb25maWd1cmFibGUuwqAgVGhpcyBtYXkganVz dCBiZSBteSBpbnRlcnByZXRhdGlvbiwgYnV0IGl0IHByb2JhYmx5PGJyIC8+DQpzaG91bGQgc3Rh dGUgdGhhdCBsb2NhbCBpbXBsZW1lbnRhdGlvbnMgTUFZIHByb3ZpZGUgYSBjb25maWd1cmFibGU8 YnIgLz4NCmtub2IgdG8gbm90IG5lZ290aWF0ZSBQVFB2MiB0aW1lc3RhbXBzIGluIHNlY3Rpb24g Mi4xIGFuZCAyLjIgZXZlbiBpZjxiciAvPg0KdGhlIGNhcGFiaWxpdHkgaXMgc3VwcG9ydGVkIGJ5 IHRoZSBpbXBsZW1lbnRhdGlvbi48YnIgLz4NCjxiciAvPg0KPGJyIC8+DQo8L2Jsb2NrcXVvdGU+ PC9kaXY+PGJyIC8+PC9kaXY+DQo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyIC8+ PC9kaXY+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg== From nobody Thu Apr 13 09:54:11 2017 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 14EF0129520 for ; Thu, 13 Apr 2017 09:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 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, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, 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 sq5-4RPcoTqR for ; Thu, 13 Apr 2017 09:54:05 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 66DA8129B19 for ; Thu, 13 Apr 2017 09:54:00 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id f22so71703204oib.2 for ; Thu, 13 Apr 2017 09:54:00 -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=b7WCBkCIF133QTqe+cNPUzGQvhc0ElxCqFkARv8aFI0=; b=rKmra3Kn9st2m4i+aMTPzSqkD98VTTMMD0aM2r6Pq2ddfyy6qvbY9sfIPFWdIkmzEf VTIyCPykaHvi1+ZVYVSSqbnYMlbyLezmFQv09gc2gegAu5Pmi4wQkuTcWA2RsLJrH8g7 PnRq/1sQuhOtDamrQpk2ZCjjxRwLjdcx9mfoP5dwxpEA8fNun8RNS2726Sb3AUbvLamj 8eLYTcH+xse4A5Lr2kTV8LOSlnEeHPgM4lO6yoWezakSX8qvjwzvaV/clEeFXB49eSQY tURplqjVDk7SbwanG9FoQ2/C0uXO1M6GQlG52x70hx5Y+8eSunsPRKnCqo30AzzIK00O B9MQ== 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=b7WCBkCIF133QTqe+cNPUzGQvhc0ElxCqFkARv8aFI0=; b=KPOXi83uhnN2uE05X4bXS1v8BeAkigLASca65PU32mdmy5qP9Sy5J0vXAoOTsDuLIF KoUXcuHZxFlAsyxQ2nzrCUZCJKgbhHzEhTIIzK3C2sB1B9pkOjFzrr3ui1X8+KbTajII wurCCjZT0gO3QLvqac9II0MSAJz2YSj1nYP92VrebpuC4bqF4CbtBZKLBdfHN6moW2zl coxLUhLuWq0u5h7YcQymeyQFJ+fs0iexTU/l4yAbqkQ6AybUy/KOvHTtZhuQi0fUiUCq XljaPnVY8K4gvoI5my8t7rpVJpmIlVxX02+cEu4F1EihUZam47pluLH2+a2HrJj5JBlh wl3Q== X-Gm-Message-State: AN3rC/6W4TdXAkBeaIxsKkZjke0eTVjeKLvpiOiOLhPWnTyEx3Hda+Hn s8ZtIXn1ZmZrbLV/Xe1G5we89USNGw== X-Received: by 10.157.39.161 with SMTP id c30mr2754648otb.118.1492102439711; Thu, 13 Apr 2017 09:53:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.165 with HTTP; Thu, 13 Apr 2017 09:53:59 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Thu, 13 Apr 2017 09:53:59 -0700 Message-ID: To: Henrik Nydell Cc: Wei Luo S , "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c04f8e2e33734054d0f2bd4 Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 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, 13 Apr 2017 16:54:10 -0000 --94eb2c04f8e2e33734054d0f2bd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All, the new update of the TWAMP-Light YANG model has been published. It includes the following: - packet loss ratio as decimal64 type with fraction-size 5; - session-reflector state parameter in session-sender container; - defined continuous and periodic modes to execute a test session and how performance metrics are calculated in each of the modes; - reporting of one-way packet loss metrics, both near-end and far-end, has dependency of reflector's mode. Some questions still being discussed and we greatly appreciate suggestions, comments: - include percentile in delay and delay-variation containers? - default value for session-timeout in session-sender container is 900 seconds. Seems too big. What may be practical? Change units from seconds= to centiseconds or milliseconds? Regards, Greg On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell wrote= : > Some comments from the "field" as Accedian has several hundred thousand > TWAMP sessions running (continously) at numerous Tier one mobile/fixed > operators globally. > > On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S > wrote: > >> Hi Greg, >> >> >> >> Thanks a lot for your response. Please see my reply inline tagged [WEI>>= ]. >> >> >> >> Regards, >> >> Wei Luo >> >> >> >> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >> *Sent:* Tuesday, March 21, 2017 1:16 AM >> *To:* Wei Luo S >> *Cc:* ippm@ietf.org; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org >> *Subject:* Re: Some though on draft-mirsky-ippm-twamp-light-yang-07 >> >> >> >> Hi Wei Luo, >> >> many thanks for your thorough review and the most helpful comments to th= e >> TWAMP Light(Test) model. Please find my answers, notes in-line tagged GI= M>>. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S >> wrote: >> >> Hi Greg & Adrian, >> >> >> >> This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. >> The current TWAMP Light YANG model is well defined. Thanks for your grea= t >> job. >> >> But by working closely with our customers, we got some new user cases on >> TWAMP light. I believe these user cases are valuable and popular enough = to >> be modeled in TWAMP Light YANG. I hope I can be a contributor and co-wo= rk >> with you move this draft forward. >> >> I drafted a new version of the TWAMP light YANG model based on version >> ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any >> discussion is welcome. >> >> The draft yang model and tree is attached. To make you find the updates >> quickly, I highlighted all the updates in file >> ietf-twamp-light-weiluo.pdf. >> >> >> >> The following are the list of main updates: >> >> *1. Add a new typedef: percent. This is a new type defined for packet >> loss ratio.* >> >> Consideration: >> >> 1). From the customer perspective, packet loss ratio is a more meaningfu= l >> data. In most of the time, the absolute number is meaningless to user, >> especially they do the TWAMP test continuously. They are more care about >> the ratio than the absolute number. So adding it makes this model more >> friendly to customer; >> >> 2). From the service layer assurance(SLA) perspective, the packet loss >> ratio is a major measures. So with adding packet loss ratio in model, th= e >> TWAMP can work in SLA framework more smoothly. >> >> 3). It seems some similar protocol=E2=80=99s YANG model has the same def= inition, >> e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99, >> https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf. >> >> Agreed packet loss is important, however another important loss metric i= s > loss burst size (max/min) and number of loss bursts. A loss burst of 10 > consecutive TWAMP-test packets can be deemed more serious than 10 lost > packets spread evenly over the report interval. > >> GIM>> Indeed, packet loss more often expressed as packet loss ratio >> rather than as the absolute number. It would be most helpful to hear fro= m >> network operators if they see introduction of Packet Loss Ratio into the >> TWAMP model helpful. >> >> *2. Add a new typedef: state-mode. It defines a common type for >> stateful/stateless reflector. This type will be used in both sender sess= ion >> and reflector session.* >> >> Consideration: >> >> If the reflector is stateful, the TWAMP light can measure more items, >> e.g. one way packet loss. So for sender, the stats calculation and show = is >> different. When the reflector is stateless, it doesn=E2=80=99t need to c= alculate >> the one way packet loss. The one way packet loss is invalid and shouldn= =E2=80=99t >> be presented to customer. When the reflector is stateless, the sender ne= eds >> to calculate the one way packet loss. And the data should be present to >> customer. So this is used as a =E2=80=98when=E2=80=99 condition in the m= odel=E2=80=99s RO tree. >> >> GIM>> Yes, if Session-Sender is aware of the mode corresponding >> Session-Reflector operates, the sender may avoid calculation of some >> performance metrics, e.g., one-way packet loss. On the other hand, the >> orchestrator is aware of the state-mode and should be capable to properl= y >> use metrics reported by the Session-Sender. >> >> [WEI>>] Yes, the orchestrator could know that. But from the model side, >> this is not correct. The model should represent the right behavior and >> shouldn=E2=80=99t do assumption on orchestrator. >> > I agree the model should describe both one-way loss metrics and roundtrip > loss metrics, and the sender should be able to use either mode when > calculating, potentially also populating the roundtrip delay values with > proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that > would indicate buffer load/CPU load in the TWAMP responders processing ti= me. > >> *3. Add a new typedef: send-mode. This is a new type for sender session. >> It makes the sender session can send packet continuously and monitor the >> network all the time.* >> >> Consideration: >> >> The user case is that: the user runs TWAMP light sessions to watch links >> quality continuously. The session number could be very big. These TWAMP >> sessions are managed by SLA framework or similar. SLA retrieves the stat= s >> from TWAMP periodically, e.g. 15mins. In other words, all the performanc= e >> metrics are calculated based on the packets sent/received within 15mins. >> This makes the calculation become possible. With the periodical stats da= ta, >> the Network Management software can do further actions if some abnormal >> stats observed. This is a more general user case in customer site. Whil= e >> the non-continuous TWAMP sender session is generally used for debugging >> purpose on a link. >> >> GIM>> I think that support of continuous measurement is in LMAP domain, >> not for TWAMP Test data model. To conduct continuous measurement he LMAP >> Controller, in my opinion, programs the Measurement Agent to perform TWA= MP >> Test session with certain set of parameters and repeat it without any >> interval (interval =3D 0). >> > > Many operators use TWAMP in continous mode, not only with Accedian test > points and report at fixed intervals, typically ranging from 5s to 5 or 1= 5 > minutes, with 1-minute being the most popular granularity currently. The > advantage is that the result calculation can be handled separately from t= he > TWAMP-test sending/recieving, so that there is no parallelism required to > monitor 24/7. If a start-stop-based methodology is used, the sender needs > to start up the new test session even before the previous one has ended, > since the previous session needs to wait X seconds (or at least Y 100s of > milliseconds) before it stops waiting for packets to come back. And this > new session needs to have a different signature in order for the sender t= o > discern which packets belong to the previous interval and which belong to > the current. > > In a continous test-model, the sender can just simply record the sequence > number of the last packet transmitted in the interval to be reported, wai= t > for it to come back, or a MAXTIME, then report that result, while > continuing to transmit for the next interval. > > If the "interval=3D=3D0" parameter is intended to be used for continous t= ype > tests, then what parameter should indicate to the sender at what interval= s > to produce results? > >> *4. Add a new group: packet-loss-statistics. It grouping two packet loss >> statistics: loss-count and loss-ratio. This group will be used in RO sta= ts >> tree.* >> >> GIM>> I'd like to continue discussion. >> >> [WEI>>] OK. >> >> *5. Move leaf dscp out from grouping session-light-parameters. The leaf >> dscp is only valid when the dscp-handling-mode is use-configured-value. = A >> when condition shall be added to it. So it can=E2=80=99t be in this grou= p.* >> >> GIM>> I'm concerned that then the model will not be able to support >> concurrent TWAMP Test sessions between the same pair of Test Points (IP >> address+port number) at different CoS markings. >> >> [WEI>>] Actually, I have concern on using five tuple(IP address+port >> number+dscp) to identify a TWAMP test session. The DSCP is not a constan= t >> value in packet. It could be modified by the routers in the path. For >> example, the sender has two sessions: session A=E2=80=99s five tuple is: >> Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2. = Session B=E2=80=99s >> five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D5000= 1, >> DSCP=3Dcs3. The only difference between session A and session B is DSCP.= If >> the test packet=E2=80=99s DSCP of session B is modified to cs2 by a rout= er in the >> path. The five tuples are exactly the same for reflector. It can=E2=80= =99t >> differentiate which packet is from session A, which packet is from sessi= on >> B. It could mess the reflector=E2=80=99s session sequence number. And al= so, the >> sender will be messed because the received reply packet=E2=80=99s five t= uple are >> exactly the same. >> >> So I think it=E2=80=99s more reasonable to use four tuple to identify a = session. >> > > Yes, this would be appreciated by users. Changes in DSCP is a reasonably > common network error that users can detect with continous TWAMP monitorin= g, > thus it is good to not include the DSCP value as part of the "session > identifiier" but instead use 4-tuple with UDP source port to identify > several parallel flows between the same sender and responder. > >> *6. Add leaf 'session-packet-send-mode' to >> /twamp-light/twamp-light-session-sender/test-session*. This leaf specifi= es >> the sender session's packet send mode: continuous or non-continuous.* >> >> GIM>> As discussed in #3, I think that it is already part of LMAP YANG >> model. >> >> *7. Add leaf 'reflector-light-mode-state' to >> /twamp-light/twamp-light-session-sender/test-session*. This leaf indicat= es >> the the reflector's mode: stateful or stateless. If the reflector's mode= is >> stateful. Two one way packet loss statistics can be got: >> one-way-packet-loss-far-end, one-way-packet-loss-near-end.* >> >> Consideration: >> >> Only valid data should be presented to user. Otherwise it could >> misleading user in some cases. >> >> GIM>> A in response to #2. >> >> *8. Modify leaf >> /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. >> Add a 'when' condition to this leaf. When send-mode is 'continuous', the >> leaf number-of-packets is meaningless. So add a 'when' condition to limi= t >> it. Besides, added a default value =E2=80=9810=E2=80=99 to it. When the= send-mode is >> 'non-continuous', the session can't work with an empty number-of-packets= .* >> >> GIM>> As I've noted in #3. Will add default. >> >> *9. Add leaf time out to >> /twamp-light/twamp-light-session-sender/test-session*. A timeout mechani= sm >> is needed when the sender session can't get all the reply packets for a >> long time.* >> >> GIM>> Thank you, will add in the next update. >> >> *10. Modify leaf >> /twamp-light/twamp-light-session-sender/test-session*/interval. Change t= he >> units from =E2=80=98microseconds=E2=80=99 to =E2=80=98milliseconds=E2=80= =99. Add a default value 1000. * >> >> Consideration: >> >> 1). The aim of TWAMP is to measure network quality, but not fast >> failure detection. So a millisecond packet interval is enough. >> >> 2). Interval is a necessary parameter for a session. A sender sessio= n >> can't work with an empty packet send interval. So added a default value = to >> it. >> >> GIM>> Thank you. We've made units of interval microseconds in the last >> update already. I think that changing to milliseconds may be too >> restrictive, limit use cases for TWAMP Test. Will add default value with >> the next update. >> >> [WEI>>] Sorry, I do not see the reason. Are there any user cases to use >> microseconds? >> >> *11. Add leaf 'dscp' to >> /twamp-light/twamp-light-session-sender/test-session*. This is the leaf >> moved out from grouping session-light-parameters.* >> >> GIM>> As noted in response #5, the change may limit ability to run >> concurrent TWAMP Test sessions per CoS. I consider that to be valuable m= ode >> but would like to hear from network operators if that is indeed useful >> information. >> > > See my comment above. I argue that it is useful to keep track of changing > DSCP values, and treating DSCP as a metric of the TWAMP Session just like > loss and delay > >> *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and >> 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to >> /twamp-light/twamp-light-session-reflector/test-session*. These three >> attributes should be session specific. Different session could have >> different values. They are not common attributes.* >> >> GIM>> Agree, will make it in the next update. >> >> *13. Add leaf 'dscp' to >> /twamp-light/twamp-light-session-reflector/test-session*. This is the le= af >> moved out from grouping session-light-parameters. Besides the movement, >> added a 'when' condition to the leaf 'dscp'. This leaf is only valid whe= n >> the dscp-handling-mode is 'use-configured-value'.* >> >> GIM>> As response to #5. >> >> *14. Modify leaf >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats/number-of-packets. >> Add a 'when' condition to this leaf. When send-mode is 'continuous', the >> leaf number-of-packets is meaningless.* >> >> GIM>> Similar to #3. >> >> *15. Modify leaf >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats/interval. >> Change the units from microseconds to milliseconds.* >> >> GIM>> I think that microseconds is reasonable. >> >> *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and >> 'one-way-packet-loss-near-end' to >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats/. >> These are the new statistics for stateful reflector.* >> >> GIM>> Thank you, will be coming in the next update. >> >> *17. Remove leaf loss-packet in >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats. >> The loss packeted is replaced with 'two-way-packet-loss' stated above.* >> >> GIM>> Agree. >> >> *18. Modify leaf to >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= history-stats*/interval. >> Change the units from microseconds to milliseconds.* >> >> GIM>> I think that will limit applicability of TWAMP Test. >> >> *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and >> 'one-way-packet-loss-near-end' to >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= history-stats*/. >> These are the new statistics for stateful reflector.* >> >> GIM>> Agree. >> >> >> >> Thanks, >> >> Wei Luo >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> > > > -- > > > [image: Accedian.com] > > Henrik Nydell > > Sr Manager Global Strategy & Solutions > > Cell > > Email > > Skype > > +46 709845992 <+46%2070%20984%2059%2092> > > hnydell@accedian.com > > h nydell > > > > > > > > > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --94eb2c04f8e2e33734054d0f2bd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
the new update of the TWAMP-Light YANG mo= del=C2=A0has been published. It includes the following:
    <= li>packet loss ratio as decimal64 type with fraction-size 5;
  • sessio= n-reflector state parameter in session-sender container;
  • defined co= ntinuous and periodic modes to execute a test session and how performance m= etrics are calculated in each of the modes;
  • reporting of one-way pa= cket loss metrics, both near-end and far-end, has dependency of reflector&#= 39;s mode.
Some questions still being discussed and we greatl= y appreciate suggestions, comments:
  • include percent= ile in delay and delay-variation containers?
  • default value for sess= ion-timeout in session-sender container is 900 seconds. Seems too big. What= may be practical? Change units from seconds to centiseconds or millisecond= s?
Regards,
Greg

On Tue, Mar 21, 2017 at 5:21 AM, H= enrik Nydell <hnydell@accedian.com> wrote:
Some comments from the "field&quo= t; as Accedian has several hundred thousand TWAMP sessions running (contino= usly) at numerous Tier one mobile/fixed operators globally.

On Tue, Ma= r 21, 2017 at 11:52 AM, Wei Luo S <wei.s.luo@ericsson.com> wrote:

Hi Greg,

=C2=A0

Thanks a lot for your response. Please see my reply= inline tagged [WEI>>].

=C2=A0

Regards,

Wei Luo

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, March 21, 2017 1:16 AM
To: Wei Luo S <wei.s.luo@ericsson.com>
Cc: ippm@ietf.org= ; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org
Subject: Re: Some though on draft-mirsky-ippm-twamp-light-yang-= 07

=C2=A0

Hi Wei Luo,

many thanks for your thorough review and the most he= lpful comments to the TWAMP Light(Test) model. Please find my answers, note= s in-line tagged GIM>>.

=C2=A0

Regards,

Greg

=C2=A0

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.c= om> wrote:

Hi Greg & Adrian,

=C2=A0

This is Wei Luo from Ericsson. I work on TWAMP light= area in Ericsson. The current TWAMP Light YANG model is well defined. Than= ks for your great job.

But by working closely with our customers, we got so= me new user cases on TWAMP light. I believe these user cases are valuable a= nd popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor =C2=A0and co-work with you move this draft f= orward.=C2=A0

I =C2=A0drafted a new version of the TWAMP light YAN= G model based on version ietf-= twamp-light@2017-02-13.yang. Could you please comments on it? Any = discussion is welcome.

The draft yang model and tree is attached. To make y= ou find the updates quickly, I highlighted all the updates in fil= e ietf-twamp-light-weiluo.pdf.

=C2=A0

The following are the list of main updates:

1. Add a new typedef: percent. This is a new type= defined for packet loss ratio.

Consideration:

1). From the customer perspective, packet loss ratio is a more meaningful d= ata. In most of the time, the absolute number is meaningless to user, espec= ially they do the TWAMP test continuously. They are more care about the rat= io than the absolute number. So adding it makes this model more friendly to customer;

2). From the service layer assurance(SLA) perspective, the packet loss rati= o is a major measures. So with adding packet loss ratio in model, the TWAMP= can work in SLA framework more smoothly.

3). It seems some similar protocol=E2=80=99s YANG model has the same defini= tion, e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99= , https://www.mef.net/Assets/Technical_= Specifications/PDF/MEF_39.pdf.

=
Agreed p= acket loss is important, however another important loss metric is loss burs= t size (max/min) and number of loss bursts. A loss burst of 10 consecutive = TWAMP-test packets can be deemed more serious than 10 lost packets spread e= venly over the report interval.

GIM>> Indeed, packet loss more often expressed= as packet loss ratio rather than as the absolute number. It would be most = helpful to hear from network operators if they see introduction of Packet L= oss Ratio into the TWAMP model helpful.

2. Add a new typedef: state-mode. It defines a co= mmon type for stateful/stateless reflector. This type will be used in both = sender session and reflector session.

Consideration:

If the reflector is stateful, the TWAMP light can me= asure more items, e.g. one way packet loss. So for sender, the stats calcul= ation and show is different. When the reflector is stateless, it doesn=E2=80=99t need to calculate the one way packet loss. T= he one way packet loss is invalid and shouldn=E2=80=99t be presented to cus= tomer. When the reflector is stateless, the sender needs to calculate the o= ne way packet loss. And the data should be present to customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree.

GIM>> Yes, if Session-Sender is aware of the m= ode corresponding Session-Reflector operates, the sender may avoid calculat= ion of some performance metrics, e.g., one-way packet loss. On the other ha= nd, the orchestrator is aware of the state-mode and should be capable to properly use metrics reported by the Session-Send= er.

[WEI>>] Yes, the orchestrator could know that. But from= the model side, this is not correct.=C2=A0 The model should represent the = right behavior and shouldn=E2=80=99t do assumption on orchestrator.<= /p>

I agree the= model should describe both one-way loss metrics and roundtrip loss metrics= , and the sender should be able to use either mode when calculating, potent= ially also populating the roundtrip delay values with proper t1-t0 + t3-t2 = values, as well as reporting the t2-t1 values that would indicate buffer lo= ad/CPU load in the TWAMP responders processing time.
=

3. Add a new typedef: send-mode. This is a new ty= pe for sender session. It makes the sender session can send packet continuo= usly and monitor the network all the time.

Consideration:

The user case is that: the user runs TWAMP light ses= sions to watch links quality continuously. The session number could be very= big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. = In other words, all the performance metrics are calculated based on the pac= kets sent/received within 15mins. This makes the calculation become possibl= e. With the periodical stats data, the Network Management software can do further actions if some abnormal st= ats observed.=C2=A0 This is a more general user case in customer site. Whil= e the non-continuous TWAMP sender session is generally used for debugging p= urpose on a link. =C2=A0

GIM>> I think that support of continuous measu= rement is in LMAP domain, not for TWAMP Test data model. To conduct continu= ous measurement he LMAP Controller, in my opinion, programs the Measurement= Agent to perform TWAMP Test session with certain set of parameters and repeat it without any interval (interval =3D= 0).


Many operators use TWAMP in continous mode, not only with A= ccedian test points and report at fixed intervals, typically ranging from 5= s to 5 or 15 minutes, with 1-minute being the most popular granularity curr= ently. The advantage is that the result calculation can be handled separate= ly from the TWAMP-test sending/recieving, so that there is no parallelism r= equired to monitor 24/7. If a start-stop-based methodology is used, the sen= der needs to start up the new test session even before the previous one has= ended, since the previous session needs to wait X seconds (or at least Y 1= 00s of milliseconds) before it stops waiting for packets to come back. And = this new session needs to have a different signature in order for the sende= r to discern which packets belong to the previous interval and which belong= to the current.

In a continous test-model, the se= nder can just simply record the sequence number of the last packet transmit= ted in the interval to be reported, wait for it to come back, or a MAXTIME,= then report that result, while continuing to transmit for the next interva= l.

If the "interval=3D=3D0" parameter is= intended to be used for continous type tests, then what parameter should i= ndicate to the sender at what intervals to produce results? =C2=A0

4. Add a new group: packet-loss-statistics. It gr= ouping two packet loss statistics: loss-count and loss-ratio. This group wi= ll be used in RO stats tree.

GIM>> I'd like to continue discussion.=C2= =A0

[WEI>>] OK.

5. Move leaf dscp out from grouping session-light= -parameters. The leaf dscp is only valid when the dscp-handling-mode is use= -configured-value. A when condition shall be added to it. So it can=E2=80=99t be in this group.

GIM>> I'm concerned that then the model wi= ll not be able to support concurrent TWAMP Test sessions between the same p= air of Test Points (IP address+port number) at different CoS markings.=C2= =A0

[WEI>>] Actually, I have concern on using five tuple(IP= address+port number+dscp) to identify a TWAMP test session. The DSCP is no= t a constant value in packet. It could be modified by the routers in the path. For example, the sender has two sessions: session A=E2=80=99s= five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001,= DSCP=3Dcs2. Session B=E2=80=99s five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.= 2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs3. The only difference between session A and session B is DSCP. If the test packet=E2=80=99s DSCP of sess= ion B is modified to cs2 by a router in the path. The five tuples are exact= ly the same for reflector. It can=E2=80=99t differentiate which packet is f= rom session A, which packet is from session B. It could mess the reflector=E2=80=99s session sequence number. And also, the = sender will be messed because the received reply packet=E2=80=99s five tupl= e are exactly the same.

So I think it=E2=80=99s more reasonable to use four tuple to identif= y a session.


Yes, this would be appreciated by users. Changes in= DSCP is a reasonably common network error that users can detect with conti= nous TWAMP monitoring, thus it is good to not include the DSCP value as par= t of the "session identifiier" but instead use 4-tuple with UDP s= ource port to identify several parallel flows between the same sender and r= esponder.=C2=A0

=

6. Add leaf 'session-packet-send-mode' to= /twamp-light/twamp-light-session-sender/test-session*. This leaf spec= ifies the sender session's packet send mode: continuous or non-continuo= us.

GIM>> As discussed in #3, I think that it is a= lready part of LMAP YANG model.=C2=A0

7. Add leaf 'reflector-light-mode-state' = to /twamp-light/twamp-light-session-sender/test-session*. This leaf in= dicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can b= e got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.

Consideration: =C2=A0

Only valid data should be presented to user. Otherwi= se it could misleading user in some cases.

GIM>> A in response to #2.=C2=A0=

8. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. Add a 'when' condi= tion to this leaf. When send-mode is 'continuous', the leaf number-= of-packets is meaningless. So add a 'when' condition to limit it.=C2=A0 Besid= es, added a default value =E2=80=9810=E2=80=99 to it. When the send-mode is= 'non-continuous', the session can't work with an empty number-= of-packets.

GIM>> As I've noted in #3. Will add defaul= t.=C2=A0

9. Add leaf time out to /twamp-light/twamp-light-= session-sender/test-session*. A timeout mechanism is needed when the s= ender session can't get all the reply packets for a long time.

GIM>> Thank you, will add in the next update.= =C2=A0

10. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/interval. Change the units from =E2=80=98mic= roseconds=E2=80=99 to =E2=80=98milliseconds=E2=80=99. Add a default value 1= 000.

Consideration:

=C2=A0=C2=A0=C2=A0 1). The aim of TWAMP is to measur= e network quality, but not fast failure detection. So a millisecond packet = interval is enough.

=C2=A0=C2=A0=C2=A0 2). Interval is a necessary param= eter for a session. A sender session can't work with an empty packet se= nd interval. So added a default value to it.

GIM>> Thank you. We've made units of inter= val microseconds in the last update already. I think that changing to milli= seconds may be too restrictive, limit use cases for TWAMP Test. Will add de= fault value with the next update.

[WEI>>] Sorry, I do not see the reason. Are there any u= ser cases to use microseconds?

11. Add leaf 'dscp' to /twamp-light/twamp= -light-session-sender/test-session*. This is the leaf moved out from g= rouping session-light-parameters.

GIM>> As noted in response #5, the change may = limit ability to run concurrent TWAMP Test sessions per CoS. I consider tha= t to be valuable mode but would like to hear from network operators if that= is indeed useful information.=C2=A0


See my comment above. I arg= ue that it is useful to keep track of changing DSCP values, and treating DS= CP as a metric of the TWAMP Session just like loss and delay=C2=A0

12. Move leaves 'ref-wait', 'reflecto= r-light-mode-state' and 'dscp-handling-mode' from /twamp-light/= twamp-light-session-reflector to /twamp-light/twamp-light-session= -reflector/test-session*. These three attributes should be session specific. Different session could= have different values. They are not common attributes.

GIM>> Agree, will make it in the next update.= =C2=A0

13. Add leaf 'dscp' to /twamp-light/twamp= -light-session-reflector/test-session*. This is the leaf moved out fro= m grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only v= alid when the dscp-handling-mode is 'use-configured-value'.<= /u>

GIM>> As response to #5.=C2=A0

14. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/number-= of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.

GIM>> Similar to #3.=C2=A0

15. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/interva= l. Change the units from microseconds to milliseconds.

GIM>> I think that microseconds is reasonable.= =C2=A0

16. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/current-stats/. These are the new statistics for stateful reflector.

GIM>> Thank you, will be coming in the next up= date.=C2=A0

17. Remove leaf loss-packet in /twamp-light-state= /twamp-light-session-sender-state/test-session-state*/current-sta= ts. The loss packeted is replaced with 'two-way-packet-loss' stated above.

GIM>> Agree.=C2=A0

18. Modify leaf to /twamp-light-state/twamp-light= -session-sender-state/test-session-state*/history-stats*/int= erval. Change the units from microseconds to milliseconds.

GIM>> I think that will limit applicability of= TWAMP Test.=C2=A0

19. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/history-stats*/. These are the new statistics for stateful reflector.

GIM>> Agree.

=C2=A0

Thanks,

Wei Luo

=C2=A0


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




--


3D"Acced=

Henrik N= ydell

Sr Manager Global Strategy & Solutions


Cell

Email

Skype=

+46 709845992

hnydell@accedian.com

hnydell

<= /table>


= =C2= =A0 =C2=A0 =C2=A0 =C2=A0



<= /div>

Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.


_____________________________= __________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm


--94eb2c04f8e2e33734054d0f2bd4-- From nobody Sat Apr 15 02:16:15 2017 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 BE4E712426E; Sat, 15 Apr 2017 02:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 PqV24UubfW3a; Sat, 15 Apr 2017 02:16:12 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8711205F0; Sat, 15 Apr 2017 02:16:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3F9FenS025278; Sat, 15 Apr 2017 10:15:40 +0100 Received: from 950129200 (251.129.113.87.dyn.plus.net [87.113.129.251]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3F9FZGP025220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Apr 2017 10:15:39 +0100 Reply-To: From: "Adrian Farrel" To: "'Frank Brockners \(fbrockne\)'" Cc: "'ALFRED MORTON'" , "'Brian Trammell \(IETF\)'" , "'IPPM Chairs'" , , "'Sarah B'" References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> In-Reply-To: <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> Date: Sat, 15 Apr 2017 10:15:39 +0100 Message-ID: <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3Ooq+i0V2uDTKsntzdbDryWnJDQIGbTuQAhzFMcMCAqiNpgJZUHRiAczg8HQCom8n2QGF54TAAb4MqMABFXUytwGaPkqGAuvO8TYDDF8SAQGwfxGGoCi7hgA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23006.006 X-TM-AS-Result: No--9.607-10.0-31-10 X-imss-scan-details: No--9.607-10.0-31-10 X-TMASE-MatchedRID: VPleTT1nwdSnykMun0J1wgRH1Nr7oERdofZV/2Xa0cJ9aRK7E1xmXtum fLXrQVDADZcIl/YT+Cfw4tCmqBF8q3AELY3VgLbxDB+ErBr0bAOAfODDLypXmv2dkkg+0fIUqdW hIZx2SSJlaA126RCPPCbjUl0Qr/WOrsq/7BhdGyAwmhCbeOj6aVAI6wCVrE3vHiIhsW/ea0TbtI JlNra3Svdy7GMadCXAkZOl7WKIImq0P2qkGU0XygtuKBGekqUpI/NGWt0UYPCi94flAwriz1/Jb 6MCIex9SxNZBp51BkJf5VBpy9gGOJh0MHTFa8de Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 15 Apr 2017 09:16:14 -0000 Hi Frank, all, Thanks for proposing some text. > How about: "The operator of such a domain MUST put provisions in place to > ensure that in-situ OAM data stays within the specific domain only (i.e., does not > leak beyond the edge) using for example packet filtering methods. The operator > SHOULD consider potential operational impact of IOAM to mechanisms such as > ECMP processing (e.g. load-balancing schemes based on packet length could be > impacted by the increased packet size due to IOAM), path MTU (i.e. ensure that > the MTU of all links within a domain is sufficiently large to support the increased > packet size due to IOAM) and ICMP message handling (i.e. in case of a native IPv6 > transport, IOAM support for ICMPv6 Echo Request/Reply could desired which > would translate into ICMPv6 extensions to enable IOAM data fields to be copied > from an Echo Request message to an Echo Reply message)." Like Sarah, I think this is a start. I remain disappointed that it is the operators' responsibility to ensure various things, and not a feature of the protocol or implementation. But perhaps this text serves as a warning to the operators about using implementations of iOAM and so will suffice. I think the use of 2119 capitalisation is meaningless in this paragraph, and that the "SHOULD" in the second sentence should in any case be a "must". Thanks, Adrian From nobody Tue Apr 18 04:58:49 2017 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 6106912EB37 for ; Tue, 18 Apr 2017 04:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 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, SPF_PASS=-0.001, TRACKER_ID=1.306, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian-com.20150623.gappssmtp.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 qVC9giGyUPaY for ; Tue, 18 Apr 2017 04:58:44 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE7C1242EA for ; Tue, 18 Apr 2017 04:58:44 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id x184so85913910oia.1 for ; Tue, 18 Apr 2017 04:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Og1iQ8kpaXsSPKyl1Hgf1zDSQMlEq1IRBkh/lLkAvVs=; b=P3uPh2Pd/JeGKfnpRZQhV76Sfje8Ee+WkQBe0+FW+t7Ef67/ilT9jp09jI8hCvTlMq /mTGZu+KLZY+lBqgTVLBuDvSyxsfY7nB0LnCnkF3hvcdjBIQRrMWyugjEfl2VeiYgroR 1WOAD1s5c4LoL51icJK1uGEQdfaW2KQZbmbyDHfIkCX3j5hsTRH+qfrUl4ane1gofaQ4 vmZvMLmiNByBwJlm4sbfivmwSp74zJ86Fc+ty21Qdaj3H17YCzSvIKT78eBPy8jyf7GU zvkWA2L/PLbCsuuv7ySATSwwycknT1nz2+pkGzOL38fPdNH/YWEQXkGy1L7fnMsCutSH r3ew== 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=Og1iQ8kpaXsSPKyl1Hgf1zDSQMlEq1IRBkh/lLkAvVs=; b=oU3Vrzaz8FPSjyQC6J+7u1TUEjMU0Q0xYg206lp6Cuw7FukpGcVLBsaDimPxNjum94 H/AP3lxFW/tI6fDVYAE3x1HffQZGioRH6pm2YPKVwwvddmCEmLvGeNRMIy21UoodM+3C vTQIxJRrGgbh20sf37pwRP+c9OpbniXrdurQLml4stkrEuPr1xfzzamP0Th7fDEpaeYg TfGTe0cox1VYG3Ig2IUtMGQEt3jsrt2rnRRE1uT2hsZgH7V+FrN+6HNbrMG6KXN/y0qn TxCzhLO+tQkAHGKj8KKb3RI9VO+RNHJ3ipEUXauieyG5bciarB6gmvLnU1lawtTA3HUC fRAA== X-Gm-Message-State: AN3rC/50+uo82sXZK4yL23aeK2EbBjUdGD7nolCCHlpY1EVfe3hER8TR lX/Z90vXjXLXZ0p1Y02TmOTR+OwDv09Wk0Tikle0Bl1ROBgEnnucj7giZMqIb6TaAT9eUHQUbGK V X-Received: by 10.157.7.69 with SMTP id 63mr6837648ote.170.1492516723191; Tue, 18 Apr 2017 04:58:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.9.151 with HTTP; Tue, 18 Apr 2017 04:58:42 -0700 (PDT) In-Reply-To: References: From: Henrik Nydell Date: Tue, 18 Apr 2017 13:58:42 +0200 Message-ID: To: Greg Mirsky Cc: Wei Luo S , "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113dd7ae1b7d66054d6fa106 Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 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, 18 Apr 2017 11:58:47 -0000 --001a113dd7ae1b7d66054d6fa106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would ask you to consider adding some more valuable metrics 1) Loss burst size max leaf loss-burst-max { type int32; description "Highest number of lost packets back-to-back during interva= l."; } 2) Loss burst count (tells how many instances there was of packet loss during an interval, one "instance" means one or more consecutive packets lost. leaf loss-burst-count { type int32; description "Number of occasions with packet loss during interval."; } To further explain the above metrics, consider 60-second interval below with 1 packet per second monitoring, where x means lost packet and o means recieved. 0 60s oooXooXooooXXXXooooooooooXXoooooXoooXooooooooXXXXXXXXXXXXooo This 60s-interval has 22 lost packets ( 22/60 =3D36.67% loss) Loss burst max is 12 packets, number of loss instances are 7 3) Percentiles are very useful and important. If they cannot be "configurable" in the Yang model I would suggest you to consider adding at least the 95th, 99th and 99.9th percentiles for all delay type metrics. On Thu, Apr 13, 2017 at 6:53 PM, Greg Mirsky wrote: > Dear All, > the new update of the TWAMP-Light YANG model > has > been published. It includes the following: > > - packet loss ratio as decimal64 type with fraction-size 5; > - session-reflector state parameter in session-sender container; > - defined continuous and periodic modes to execute a test session and > how performance metrics are calculated in each of the modes; > - reporting of one-way packet loss metrics, both near-end and far-end, > has dependency of reflector's mode. > > Some questions still being discussed and we greatly appreciate > suggestions, comments: > > - include percentile in delay and delay-variation containers? > - default value for session-timeout in session-sender container is 900 > seconds. Seems too big. What may be practical? Change units from secon= ds to > centiseconds or milliseconds? > > Regards, > Greg > > On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell > wrote: > >> Some comments from the "field" as Accedian has several hundred thousand >> TWAMP sessions running (continously) at numerous Tier one mobile/fixed >> operators globally. >> >> On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S >> wrote: >> >>> Hi Greg, >>> >>> >>> >>> Thanks a lot for your response. Please see my reply inline tagged >>> [WEI>>]. >>> >>> >>> >>> Regards, >>> >>> Wei Luo >>> >>> >>> >>> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >>> *Sent:* Tuesday, March 21, 2017 1:16 AM >>> *To:* Wei Luo S >>> *Cc:* ippm@ietf.org; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org >>> *Subject:* Re: Some though on draft-mirsky-ippm-twamp-light-yang-07 >>> >>> >>> >>> Hi Wei Luo, >>> >>> many thanks for your thorough review and the most helpful comments to >>> the TWAMP Light(Test) model. Please find my answers, notes in-line tagg= ed >>> GIM>>. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S >>> wrote: >>> >>> Hi Greg & Adrian, >>> >>> >>> >>> This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. >>> The current TWAMP Light YANG model is well defined. Thanks for your gre= at >>> job. >>> >>> But by working closely with our customers, we got some new user cases o= n >>> TWAMP light. I believe these user cases are valuable and popular enough= to >>> be modeled in TWAMP Light YANG. I hope I can be a contributor and co-w= ork >>> with you move this draft forward. >>> >>> I drafted a new version of the TWAMP light YANG model based on version >>> ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any >>> discussion is welcome. >>> >>> The draft yang model and tree is attached. To make you find the updates >>> quickly, I highlighted all the updates in file >>> ietf-twamp-light-weiluo.pdf. >>> >>> >>> >>> The following are the list of main updates: >>> >>> *1. Add a new typedef: percent. This is a new type defined for packet >>> loss ratio.* >>> >>> Consideration: >>> >>> 1). From the customer perspective, packet loss ratio is a more >>> meaningful data. In most of the time, the absolute number is meaningles= s to >>> user, especially they do the TWAMP test continuously. They are more car= e >>> about the ratio than the absolute number. So adding it makes this model >>> more friendly to customer; >>> >>> 2). From the service layer assurance(SLA) perspective, the packet loss >>> ratio is a major measures. So with adding packet loss ratio in model, t= he >>> TWAMP can work in SLA framework more smoothly. >>> >>> 3). It seems some similar protocol=E2=80=99s YANG model has the same de= finition, >>> e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99, >>> https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf. >>> >>> Agreed packet loss is important, however another important loss metric >> is loss burst size (max/min) and number of loss bursts. A loss burst of = 10 >> consecutive TWAMP-test packets can be deemed more serious than 10 lost >> packets spread evenly over the report interval. >> >>> GIM>> Indeed, packet loss more often expressed as packet loss ratio >>> rather than as the absolute number. It would be most helpful to hear fr= om >>> network operators if they see introduction of Packet Loss Ratio into th= e >>> TWAMP model helpful. >>> >>> *2. Add a new typedef: state-mode. It defines a common type for >>> stateful/stateless reflector. This type will be used in both sender ses= sion >>> and reflector session.* >>> >>> Consideration: >>> >>> If the reflector is stateful, the TWAMP light can measure more items, >>> e.g. one way packet loss. So for sender, the stats calculation and show= is >>> different. When the reflector is stateless, it doesn=E2=80=99t need to = calculate >>> the one way packet loss. The one way packet loss is invalid and shouldn= =E2=80=99t >>> be presented to customer. When the reflector is stateless, the sender n= eeds >>> to calculate the one way packet loss. And the data should be present to >>> customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree. >>> >>> GIM>> Yes, if Session-Sender is aware of the mode corresponding >>> Session-Reflector operates, the sender may avoid calculation of some >>> performance metrics, e.g., one-way packet loss. On the other hand, the >>> orchestrator is aware of the state-mode and should be capable to proper= ly >>> use metrics reported by the Session-Sender. >>> >>> [WEI>>] Yes, the orchestrator could know that. But from the model side, >>> this is not correct. The model should represent the right behavior and >>> shouldn=E2=80=99t do assumption on orchestrator. >>> >> I agree the model should describe both one-way loss metrics and roundtri= p >> loss metrics, and the sender should be able to use either mode when >> calculating, potentially also populating the roundtrip delay values with >> proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that >> would indicate buffer load/CPU load in the TWAMP responders processing t= ime. >> >>> *3. Add a new typedef: send-mode. This is a new type for sender session= . >>> It makes the sender session can send packet continuously and monitor th= e >>> network all the time.* >>> >>> Consideration: >>> >>> The user case is that: the user runs TWAMP light sessions to watch link= s >>> quality continuously. The session number could be very big. These TWAMP >>> sessions are managed by SLA framework or similar. SLA retrieves the sta= ts >>> from TWAMP periodically, e.g. 15mins. In other words, all the performan= ce >>> metrics are calculated based on the packets sent/received within 15mins= . >>> This makes the calculation become possible. With the periodical stats d= ata, >>> the Network Management software can do further actions if some abnormal >>> stats observed. This is a more general user case in customer site. Whi= le >>> the non-continuous TWAMP sender session is generally used for debugging >>> purpose on a link. >>> >>> GIM>> I think that support of continuous measurement is in LMAP domain, >>> not for TWAMP Test data model. To conduct continuous measurement he LMA= P >>> Controller, in my opinion, programs the Measurement Agent to perform TW= AMP >>> Test session with certain set of parameters and repeat it without any >>> interval (interval =3D 0). >>> >> >> Many operators use TWAMP in continous mode, not only with Accedian test >> points and report at fixed intervals, typically ranging from 5s to 5 or = 15 >> minutes, with 1-minute being the most popular granularity currently. The >> advantage is that the result calculation can be handled separately from = the >> TWAMP-test sending/recieving, so that there is no parallelism required t= o >> monitor 24/7. If a start-stop-based methodology is used, the sender need= s >> to start up the new test session even before the previous one has ended, >> since the previous session needs to wait X seconds (or at least Y 100s o= f >> milliseconds) before it stops waiting for packets to come back. And this >> new session needs to have a different signature in order for the sender = to >> discern which packets belong to the previous interval and which belong t= o >> the current. >> >> In a continous test-model, the sender can just simply record the sequenc= e >> number of the last packet transmitted in the interval to be reported, wa= it >> for it to come back, or a MAXTIME, then report that result, while >> continuing to transmit for the next interval. >> >> If the "interval=3D=3D0" parameter is intended to be used for continous = type >> tests, then what parameter should indicate to the sender at what interva= ls >> to produce results? >> >>> *4. Add a new group: packet-loss-statistics. It grouping two packet los= s >>> statistics: loss-count and loss-ratio. This group will be used in RO st= ats >>> tree.* >>> >>> GIM>> I'd like to continue discussion. >>> >>> [WEI>>] OK. >>> >>> *5. Move leaf dscp out from grouping session-light-parameters. The leaf >>> dscp is only valid when the dscp-handling-mode is use-configured-value.= A >>> when condition shall be added to it. So it can=E2=80=99t be in this gro= up.* >>> >>> GIM>> I'm concerned that then the model will not be able to support >>> concurrent TWAMP Test sessions between the same pair of Test Points (IP >>> address+port number) at different CoS markings. >>> >>> [WEI>>] Actually, I have concern on using five tuple(IP address+port >>> number+dscp) to identify a TWAMP test session. The DSCP is not a consta= nt >>> value in packet. It could be modified by the routers in the path. For >>> example, the sender has two sessions: session A=E2=80=99s five tuple is= : >>> Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2.= Session B=E2=80=99s >>> five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D500= 01, >>> DSCP=3Dcs3. The only difference between session A and session B is DSCP= . If >>> the test packet=E2=80=99s DSCP of session B is modified to cs2 by a rou= ter in the >>> path. The five tuples are exactly the same for reflector. It can=E2=80= =99t >>> differentiate which packet is from session A, which packet is from sess= ion >>> B. It could mess the reflector=E2=80=99s session sequence number. And a= lso, the >>> sender will be messed because the received reply packet=E2=80=99s five = tuple are >>> exactly the same. >>> >>> So I think it=E2=80=99s more reasonable to use four tuple to identify a= session. >>> >> >> Yes, this would be appreciated by users. Changes in DSCP is a reasonably >> common network error that users can detect with continous TWAMP monitori= ng, >> thus it is good to not include the DSCP value as part of the "session >> identifiier" but instead use 4-tuple with UDP source port to identify >> several parallel flows between the same sender and responder. >> >>> *6. Add leaf 'session-packet-send-mode' to >>> /twamp-light/twamp-light-session-sender/test-session*. This leaf specif= ies >>> the sender session's packet send mode: continuous or non-continuous.* >>> >>> GIM>> As discussed in #3, I think that it is already part of LMAP YANG >>> model. >>> >>> *7. Add leaf 'reflector-light-mode-state' to >>> /twamp-light/twamp-light-session-sender/test-session*. This leaf indica= tes >>> the the reflector's mode: stateful or stateless. If the reflector's mod= e is >>> stateful. Two one way packet loss statistics can be got: >>> one-way-packet-loss-far-end, one-way-packet-loss-near-end.* >>> >>> Consideration: >>> >>> Only valid data should be presented to user. Otherwise it could >>> misleading user in some cases. >>> >>> GIM>> A in response to #2. >>> >>> *8. Modify leaf >>> /twamp-light/twamp-light-session-sender/test-session*/number-of-packets= . >>> Add a 'when' condition to this leaf. When send-mode is 'continuous', th= e >>> leaf number-of-packets is meaningless. So add a 'when' condition to lim= it >>> it. Besides, added a default value =E2=80=9810=E2=80=99 to it. When th= e send-mode is >>> 'non-continuous', the session can't work with an empty number-of-packet= s.* >>> >>> GIM>> As I've noted in #3. Will add default. >>> >>> *9. Add leaf time out to >>> /twamp-light/twamp-light-session-sender/test-session*. A timeout mechan= ism >>> is needed when the sender session can't get all the reply packets for a >>> long time.* >>> >>> GIM>> Thank you, will add in the next update. >>> >>> *10. Modify leaf >>> /twamp-light/twamp-light-session-sender/test-session*/interval. Change = the >>> units from =E2=80=98microseconds=E2=80=99 to =E2=80=98milliseconds=E2= =80=99. Add a default value 1000. * >>> >>> Consideration: >>> >>> 1). The aim of TWAMP is to measure network quality, but not fast >>> failure detection. So a millisecond packet interval is enough. >>> >>> 2). Interval is a necessary parameter for a session. A sender >>> session can't work with an empty packet send interval. So added a defau= lt >>> value to it. >>> >>> GIM>> Thank you. We've made units of interval microseconds in the last >>> update already. I think that changing to milliseconds may be too >>> restrictive, limit use cases for TWAMP Test. Will add default value wit= h >>> the next update. >>> >>> [WEI>>] Sorry, I do not see the reason. Are there any user cases to use >>> microseconds? >>> >>> *11. Add leaf 'dscp' to >>> /twamp-light/twamp-light-session-sender/test-session*. This is the leaf >>> moved out from grouping session-light-parameters.* >>> >>> GIM>> As noted in response #5, the change may limit ability to run >>> concurrent TWAMP Test sessions per CoS. I consider that to be valuable = mode >>> but would like to hear from network operators if that is indeed useful >>> information. >>> >> >> See my comment above. I argue that it is useful to keep track of changin= g >> DSCP values, and treating DSCP as a metric of the TWAMP Session just lik= e >> loss and delay >> >>> *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and >>> 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to >>> /twamp-light/twamp-light-session-reflector/test-session*. These three >>> attributes should be session specific. Different session could have >>> different values. They are not common attributes.* >>> >>> GIM>> Agree, will make it in the next update. >>> >>> *13. Add leaf 'dscp' to >>> /twamp-light/twamp-light-session-reflector/test-session*. This is the l= eaf >>> moved out from grouping session-light-parameters. Besides the movement, >>> added a 'when' condition to the leaf 'dscp'. This leaf is only valid wh= en >>> the dscp-handling-mode is 'use-configured-value'.* >>> >>> GIM>> As response to #5. >>> >>> *14. Modify leaf >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /current-stats/number-of-packets. >>> Add a 'when' condition to this leaf. When send-mode is 'continuous', th= e >>> leaf number-of-packets is meaningless.* >>> >>> GIM>> Similar to #3. >>> >>> *15. Modify leaf >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /current-stats/interval. >>> Change the units from microseconds to milliseconds.* >>> >>> GIM>> I think that microseconds is reasonable. >>> >>> *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' an= d >>> 'one-way-packet-loss-near-end' to >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /current-stats/. >>> These are the new statistics for stateful reflector.* >>> >>> GIM>> Thank you, will be coming in the next update. >>> >>> *17. Remove leaf loss-packet in >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /current-stats. >>> The loss packeted is replaced with 'two-way-packet-loss' stated above.* >>> >>> GIM>> Agree. >>> >>> *18. Modify leaf to >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /history-stats*/interval. >>> Change the units from microseconds to milliseconds.* >>> >>> GIM>> I think that will limit applicability of TWAMP Test. >>> >>> *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' an= d >>> 'one-way-packet-loss-near-end' to >>> /twamp-light-state/twamp-light-session-sender-state/test-session-state*= /history-stats*/. >>> These are the new statistics for stateful reflector.* >>> >>> GIM>> Agree. >>> >>> >>> >>> Thanks, >>> >>> Wei Luo >>> >>> >>> >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >>> >>> >> >> >> -- >> >> >> [image: Accedian.com] >> >> Henrik Nydell >> >> Sr Manager Global Strategy & Solutions >> >> Cell >> >> Email >> >> Skype >> >> +46 709845992 <+46%2070%20984%2059%2092> >> >> hnydell@accedian.com >> >> h nydell >> >> >> >> >> >> >> >> >> >> Avis de confidentialit=C3=A9 >> >> Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce >> qui lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g= =C3=A9es par le >> secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclu= sif de son ou de >> ses destinataires. Si vous recevez ce message par erreur, veuillez s=E2= =80=99il >> vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur= et en d=C3=A9truire tout >> exemplaire. De plus, il vous est strictement interdit de le divulguer, d= e >> le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. >> Merci. >> >> Confidentiality notice >> >> This e-mail message and any attachment hereto contain confidential >> information which may be privileged and which is intended for the exclus= ive >> use of its addressee(s). If you receive this message in error, please >> inform sender immediately and destroy any copy thereof. Furthermore, any >> disclosure, distribution or copying of this message and/or any attachmen= t >> hereto without the consent of the sender is strictly prohibited. Thank y= ou. >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> > --=20 [image: Accedian.com] Henrik Nydell Sr Manager Global Strategy & Solutions Cell Email Skype +46 709845992 hnydell@accedian.com h nydell --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3= =A8ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le secret=20 professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de son= ou de ses=20 destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99il= vous=20 plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en d= =C3=A9truire tout=20 exemplaire. De plus, il vous est strictement interdit de le divulguer, de= =20 le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99= exp=C3=A9diteur.=20 Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the exclusive= =20 use of its addressee(s). If you receive this message in error, please=20 inform sender immediately and destroy any copy thereof. Furthermore, any=20 disclosure, distribution or copying of this message and/or any attachment= =20 hereto without the consent of the sender is strictly prohibited. Thank you. --001a113dd7ae1b7d66054d6fa106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would ask you to consider adding some more valuable metr= ics
1) Loss burst size max

        leaf loss-burst-max {
                type int32;
                description
                "Highest number of lost packets back-to-back during in=
terval.";
        }

2) Loss burst count (tells how many instanc= es there was of packet loss during an interval, one "instance" me= ans one or more consecutive packets lost.

        leaf loss-burst-count {
                type int32;
                description
                "Number of occasions with packet loss during interval.=
";
        }

To further explain the above metrics, = consider 60-second interval below with 1 packet per second monitoring, wher= e x means lost packet and o means recieved.

0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 60s
oooXooXooooXXXXooooooooooXXoooooXoooX= ooooooooXXXXXXXXXXXXooo

This 60s-interval h= as 22 lost packets ( 22/60 =3D36.67% loss)
Loss burst max is 12 p= ackets, number of loss instances are 7


<= /div>
3) Percentiles are very useful and important. If they cannot be &= quot;configurable" in the Yang model I would suggest you to consider a= dding at least the 95th, 99th and 99.9th percentiles for all delay type met= rics.=C2=A0



On Thu, Apr 13, 2017 at 6:53 PM, Greg M= irsky <gregimirsky@gmail.com> wrote:
Dear All,
the new = update of the TWAMP-Light YANG model=C2=A0has been published. It includ= es the following:
  • packet loss ratio as decimal64 type wit= h fraction-size 5;
  • session-reflector state parameter in session-sen= der container;
  • defined continuous and periodic modes to execute a t= est session and how performance metrics are calculated in each of the modes= ;
  • reporting of one-way packet loss metrics, both near-end and far-e= nd, has dependency of reflector's mode.
Some questions st= ill being discussed and we greatly appreciate suggestions, comments:
<= /div>
  • include percentile in delay and delay-variation container= s?
  • default value for session-timeout in session-sender container is= 900 seconds. Seems too big. What may be practical? Change units from secon= ds to centiseconds or milliseconds?
Regards,
= Greg

<= div>
On Tue, Mar 21, 2017 at 5:21 AM, Henrik Nydell <h= nydell@accedian.com> wrote:
Some comments from th= e "field" as Accedian has several hundred thousand TWAMP sessions= running (continously) at numerous Tier one mobile/fixed operators globally= .

On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S <wei.s.luo@ericsson.com> wrote:

Hi Greg,

=C2=A0

Thanks a lot for your response. Please see my reply= inline tagged [WEI>>].

=C2=A0

Regards,

Wei Luo

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, March 21, 2017 1:16 AM
To: Wei Luo S <wei.s.luo@ericsson.com>
Cc: ippm@ietf.org= ; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org
Subject: Re: Some though on draft-mirsky-ippm-twamp-light-yang-= 07

=C2=A0

Hi Wei Luo,

many thanks for your thorough review and the most he= lpful comments to the TWAMP Light(Test) model. Please find my answers, note= s in-line tagged GIM>>.

=C2=A0

Regards,

Greg

=C2=A0

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.c= om> wrote:

Hi Greg & Adrian,

=C2=A0

This is Wei Luo from Ericsson. I work on TWAMP light= area in Ericsson. The current TWAMP Light YANG model is well defined. Than= ks for your great job.

But by working closely with our customers, we got so= me new user cases on TWAMP light. I believe these user cases are valuable a= nd popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor =C2=A0and co-work with you move this draft f= orward.=C2=A0

I =C2=A0drafted a new version of the TWAMP light YAN= G model based on version ietf-= twamp-light@2017-02-13.yang. Could you please comments on it? Any = discussion is welcome.

The draft yang model and tree is attached. To make y= ou find the updates quickly, I highlighted all the updates in fil= e ietf-twamp-light-weiluo.pdf.

=C2=A0

The following are the list of main updates:

1. Add a new typedef: percent. This is a new type= defined for packet loss ratio.

Consideration:

1). From the customer perspective, packet loss ratio is a more meaningful d= ata. In most of the time, the absolute number is meaningless to user, espec= ially they do the TWAMP test continuously. They are more care about the rat= io than the absolute number. So adding it makes this model more friendly to customer;

2). From the service layer assurance(SLA) perspective, the packet loss rati= o is a major measures. So with adding packet loss ratio in model, the TWAMP= can work in SLA framework more smoothly.

3). It seems some similar protocol=E2=80=99s YANG model has the same defini= tion, e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99= , https://www.mef.net/Assets/Technical_= Specifications/PDF/MEF_39.pdf.

=
Agreed p= acket loss is important, however another important loss metric is loss burs= t size (max/min) and number of loss bursts. A loss burst of 10 consecutive = TWAMP-test packets can be deemed more serious than 10 lost packets spread e= venly over the report interval.
<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
=

GIM>> Indeed, packet loss more often expressed= as packet loss ratio rather than as the absolute number. It would be most = helpful to hear from network operators if they see introduction of Packet L= oss Ratio into the TWAMP model helpful.

2. Add a new typedef: state-mode. It defines a co= mmon type for stateful/stateless reflector. This type will be used in both = sender session and reflector session.

Consideration:

If the reflector is stateful, the TWAMP light can me= asure more items, e.g. one way packet loss. So for sender, the stats calcul= ation and show is different. When the reflector is stateless, it doesn=E2=80=99t need to calculate the one way packet loss. T= he one way packet loss is invalid and shouldn=E2=80=99t be presented to cus= tomer. When the reflector is stateless, the sender needs to calculate the o= ne way packet loss. And the data should be present to customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree.

GIM>> Yes, if Session-Sender is aware of the m= ode corresponding Session-Reflector operates, the sender may avoid calculat= ion of some performance metrics, e.g., one-way packet loss. On the other ha= nd, the orchestrator is aware of the state-mode and should be capable to properly use metrics reported by the Session-Send= er.

[WEI>>] Yes, the orchestrator could know that. But from= the model side, this is not correct.=C2=A0 The model should represent the = right behavior and shouldn=E2=80=99t do assumption on orchestrator.<= /p>

I agree the= model should describe both one-way loss metrics and roundtrip loss metrics= , and the sender should be able to use either mode when calculating, potent= ially also populating the roundtrip delay values with proper t1-t0 + t3-t2 = values, as well as reporting the t2-t1 values that would indicate buffer lo= ad/CPU load in the TWAMP responders processing time.

3. Add a new typedef: send-mode. This is a new ty= pe for sender session. It makes the sender session can send packet continuo= usly and monitor the network all the time.

Consideration:

The user case is that: the user runs TWAMP light ses= sions to watch links quality continuously. The session number could be very= big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. = In other words, all the performance metrics are calculated based on the pac= kets sent/received within 15mins. This makes the calculation become possibl= e. With the periodical stats data, the Network Management software can do further actions if some abnormal st= ats observed.=C2=A0 This is a more general user case in customer site. Whil= e the non-continuous TWAMP sender session is generally used for debugging p= urpose on a link. =C2=A0

GIM>> I think that support of continuous measu= rement is in LMAP domain, not for TWAMP Test data model. To conduct continu= ous measurement he LMAP Controller, in my opinion, programs the Measurement= Agent to perform TWAMP Test session with certain set of parameters and repeat it without any interval (interval =3D= 0).


Many operators use TWAMP in continous mode, not only with A= ccedian test points and report at fixed intervals, typically ranging from 5= s to 5 or 15 minutes, with 1-minute being the most popular granularity curr= ently. The advantage is that the result calculation can be handled separate= ly from the TWAMP-test sending/recieving, so that there is no parallelism r= equired to monitor 24/7. If a start-stop-based methodology is used, the sen= der needs to start up the new test session even before the previous one has= ended, since the previous session needs to wait X seconds (or at least Y 1= 00s of milliseconds) before it stops waiting for packets to come back. And = this new session needs to have a different signature in order for the sende= r to discern which packets belong to the previous interval and which belong= to the current.

In a continous test-model, the se= nder can just simply record the sequence number of the last packet transmit= ted in the interval to be reported, wait for it to come back, or a MAXTIME,= then report that result, while continuing to transmit for the next interva= l.

If the "interval=3D=3D0" parameter is= intended to be used for continous type tests, then what parameter should i= ndicate to the sender at what intervals to produce results? =C2=A0

4. Add a new group: packet-loss-statistics. It gr= ouping two packet loss statistics: loss-count and loss-ratio. This group wi= ll be used in RO stats tree.

GIM>> I'd like to continue discussion.=C2= =A0

[WEI>>] OK.

5. Move leaf dscp out from grouping session-light= -parameters. The leaf dscp is only valid when the dscp-handling-mode is use= -configured-value. A when condition shall be added to it. So it can=E2=80=99t be in this group.

GIM>> I'm concerned that then the model wi= ll not be able to support concurrent TWAMP Test sessions between the same p= air of Test Points (IP address+port number) at different CoS markings.=C2= =A0

[WEI>>] Actually, I have concern on using five tuple(IP= address+port number+dscp) to identify a TWAMP test session. The DSCP is no= t a constant value in packet. It could be modified by the routers in the path. For example, the sender has two sessions: session A=E2=80=99s= five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001,= DSCP=3Dcs2. Session B=E2=80=99s five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.= 2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs3. The only difference between session A and session B is DSCP. If the test packet=E2=80=99s DSCP of sess= ion B is modified to cs2 by a router in the path. The five tuples are exact= ly the same for reflector. It can=E2=80=99t differentiate which packet is f= rom session A, which packet is from session B. It could mess the reflector=E2=80=99s session sequence number. And also, the = sender will be messed because the received reply packet=E2=80=99s five tupl= e are exactly the same.

So I think it=E2=80=99s more reasonable to use four tuple to identif= y a session.


Yes, this would be appreciated by users. Changes in= DSCP is a reasonably common network error that users can detect with conti= nous TWAMP monitoring, thus it is good to not include the DSCP value as par= t of the "session identifiier" but instead use 4-tuple with UDP s= ource port to identify several parallel flows between the same sender and r= esponder.=C2=A0

6. Add leaf 'session-packet-send-mode' to= /twamp-light/twamp-light-session-sender/test-session*. This leaf spec= ifies the sender session's packet send mode: continuous or non-continuo= us.

GIM>> As discussed in #3, I think that it is a= lready part of LMAP YANG model.=C2=A0

7. Add leaf 'reflector-light-mode-state' = to /twamp-light/twamp-light-session-sender/test-session*. This leaf in= dicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can b= e got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.

Consideration: =C2=A0

Only valid data should be presented to user. Otherwi= se it could misleading user in some cases.

GIM>> A in response to #2.=C2=A0=

8. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. Add a 'when' condi= tion to this leaf. When send-mode is 'continuous', the leaf number-= of-packets is meaningless. So add a 'when' condition to limit it.=C2=A0 Besid= es, added a default value =E2=80=9810=E2=80=99 to it. When the send-mode is= 'non-continuous', the session can't work with an empty number-= of-packets.

GIM>> As I've noted in #3. Will add defaul= t.=C2=A0

9. Add leaf time out to /twamp-light/twamp-light-= session-sender/test-session*. A timeout mechanism is needed when the s= ender session can't get all the reply packets for a long time.

GIM>> Thank you, will add in the next update.= =C2=A0

10. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/interval. Change the units from =E2=80=98mic= roseconds=E2=80=99 to =E2=80=98milliseconds=E2=80=99. Add a default value 1= 000.

Consideration:

=C2=A0=C2=A0=C2=A0 1). The aim of TWAMP is to measur= e network quality, but not fast failure detection. So a millisecond packet = interval is enough.

=C2=A0=C2=A0=C2=A0 2). Interval is a necessary param= eter for a session. A sender session can't work with an empty packet se= nd interval. So added a default value to it.

GIM>> Thank you. We've made units of inter= val microseconds in the last update already. I think that changing to milli= seconds may be too restrictive, limit use cases for TWAMP Test. Will add de= fault value with the next update.

[WEI>>] Sorry, I do not see the reason. Are there any u= ser cases to use microseconds?

11. Add leaf 'dscp' to /twamp-light/twamp= -light-session-sender/test-session*. This is the leaf moved out from g= rouping session-light-parameters.

GIM>> As noted in response #5, the change may = limit ability to run concurrent TWAMP Test sessions per CoS. I consider tha= t to be valuable mode but would like to hear from network operators if that= is indeed useful information.=C2=A0


See my comment above. I arg= ue that it is useful to keep track of changing DSCP values, and treating DS= CP as a metric of the TWAMP Session just like loss and delay=C2=A0

12. Move leaves 'ref-wait', 'reflecto= r-light-mode-state' and 'dscp-handling-mode' from /twamp-light/= twamp-light-session-reflector to /twamp-light/twamp-light-session= -reflector/test-session*. These three attributes should be session specific. Different session could= have different values. They are not common attributes.

GIM>> Agree, will make it in the next update.= =C2=A0

13. Add leaf 'dscp' to /twamp-light/twamp= -light-session-reflector/test-session*. This is the leaf moved out fro= m grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only v= alid when the dscp-handling-mode is 'use-configured-value'.<= /u>

GIM>> As response to #5.=C2=A0

14. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/number-= of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.

GIM>> Similar to #3.=C2=A0

15. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/interva= l. Change the units from microseconds to milliseconds.

GIM>> I think that microseconds is reasonable.= =C2=A0

16. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/. These are the new statistics for stateful reflector.

GIM>> Thank you, will be coming in the next up= date.=C2=A0

17. Remove leaf loss-packet in /twamp-light-state= /twamp-light-session-sender-state/test-session-state*/current-sta= ts. The loss packeted is replaced with 'two-way-packet-loss' stated above.

GIM>> Agree.=C2=A0

18. Modify leaf to /twamp-light-state/twamp-light= -session-sender-state/test-session-state*/history-stats*/int= erval. Change the units from microseconds to milliseconds.

GIM>> I think that will limit applicability of= TWAMP Test.=C2=A0

19. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-session-state*/history-stats*/. These are the new statistics for stateful reflector.

GIM>> Agree.

=C2=A0

Thanks,

Wei Luo

=C2=A0


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




--
<= div dir=3D"ltr">


3D"Accedian.com"

Henrik Nydell

Sr Manager Global Strategy & Solutio= ns


Cell

Email<= /p>

Skype

+46 709845992=

hnydell@accedian.com=

hnydell



= = =C2=A0= =C2= =A0 =C2=A0 =C2=A0=



<= /div>

Dear Carlos,
thank you for the referenc= e to the discussion in opsawg after the meeting in Seoul. After reading thr= ough I was left with expectation of the followup but I couldn't find an= y update since last January. I believe it will be beneficial for all intere= sted to have joint discussion thread.

Regards,
Greg

= On Wed, Apr 26, 2017 at 7:21 AM, Carlos Pignataro (cpignata) <cpignata@ci= sco.com> wrote:
Greg,

I agree that a shared understanding and alignment on the problem space= is critically important. My understanding is that we have already been doi= ng that extensively, including the work on potential charter text discussed= in Opsawg. That was, for example, a discussion solely about the problem to be solved.

What concerns me is the strict serialization and waterfall you seem to= be advocating for.

=E2=80=94 Carlos.

On Apr 26, 2017, at 9:22 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Carlos,
thank you for the reference.=C2=A0
I've never called for perfecting but for rough consensus on what p= roblem we need to address. How, IMHO, is secondary. And that is what may be= not working in this discussion - we've been presented answer to how do= measurement before we have reached an agreement that there's a problem to be solved.

Regards,
Greg

On Wed, Apr 26, 2017 at 6:13 AM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:

Dear Greg,

=C2=A0

Something like https://tools.ietf.org/html/draft-brockners-inband-oam-requiremen= ts-03?

=C2=A0

For the record, my opinion: perfecting requirements is perhaps not the bes= t use of WG cycles. However, placing requirements as a serialized requisite= before progressing protocol work is certainly harmful in this case.

=C2=A0

Thanks,

=C2=A0

-- Carlos.

=C2=A0

From: ippm <ippm-bounces@ietf.org> on be= half of Greg Mirsky <gregimirsky@gmail.com>
Date: Wednesday, April 26, 2017 at 5:22 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: IPPM Chairs <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Subject: Re: [ippm] Vote at IPPM session=

=C2=A0

Hi Adrian, et. al,

I strongly believe that having agreed upon list of r= equirements that answer questions What? and Where? rather than How? is the = most beneficial and not only for the discussion of applicability of in-situ= OAM. What needs to be solved, measured that is not ameasureable by already existing OAM methods? I think that if = we can compile such list, then it will be more clear what value may be adde= d by developing new hybrid OAM method.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Mar 29, 2017 at 2:32 PM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

> > There were several questions related to sc= ope and applicability in the WG
> discussion =E2=80=93 and even more recently on the list. Those can eas= ily be addressed by
> adding paragraph on applicability to draft-brockners-inband-oam-data =E2=80=93 there
> isn=E2=80=99t a need for a dedicated requirements document.
>
> I tend to agree with this, although "a paragraph" seems a li= ttle thin to me. I think
> there were some valid points made in that discussion about the scope o= f the
> proposal that should be addressed: is IOAM meant for use tunnel-end-to= -tunnel-
> end environment,=C2=A0 end-host-to-end-host, within a single network a= nd/or across
> the Internet.=C2=A0 What I would suggest is adding a section to the da= ta model draft on
> applicability and assumptions about the environment -- both about the = devices
> adding IOAM signals to traffic as well as those consuming these signal= s from the
> wire and analyzing them (possibly with the cooperation of devices not = on the
> wire) -- submitting a new revision, and we can run a more formal adopt= ion call on
> that.

Although I was one of the people raising the "need" for the scope= and requirements, I don't have a strong leading on whether this needs = to be in a separate document on folded into the data format document. So Br= ian's proposal would work for me.

Thus, I'd love to see this scoping text drafted and floated to the list= as an email or in a revision of the data format document.

Cheers,
Adrian

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

=C2=A0




--001a113d45f4406ed8054e12ed6a-- From nobody Wed Apr 26 09:46:13 2017 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 1FDB61293F8 for ; Wed, 26 Apr 2017 09:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 YQo120a7w1Uq for ; Wed, 26 Apr 2017 09:46:09 -0700 (PDT) Received: from nm35-vm2.bullet.mail.gq1.yahoo.com (nm35-vm2.bullet.mail.gq1.yahoo.com [98.136.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E2F1294D2 for ; Wed, 26 Apr 2017 09:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493224739; bh=j32MXy5USn3jCnXqIXkHB7j7Jbt+jN88kPNyu9QJ7UE=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=n2eRMBsI22YcQPE8Esof6YpYoG9XpIxX2uxeDg010iV5Qu7cko6thEUzvVq5SNa18QjJBD2qdyLbPG+3BE/B2BfwRyMSJW/ahyivL3/CIxOWXQ/u7wANzCKXs+WdOMXns+RMp3CMvnELxVFp1q//vQwdpYerVJUbsKo8uIU6gp6g9asPp2BJAiqHdSQIducW+PoUU3C3fWlix0zso1eJQNL4x0yODB1vcEyU8xUN4+JPYFNNt5p184JxFCmaU84Rt4tP2y9acRJdj3XPnCqnkvcqPBoLPZRGhOu2DE0bn768bdzWKnVTU73JLe5kx2Kri1mDUFJJqwInqtniV6LV6Q== Received: from [127.0.0.1] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 26 Apr 2017 16:38:59 -0000 Received: from [98.137.12.174] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 26 Apr 2017 16:36:02 -0000 Received: from [98.137.12.244] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 26 Apr 2017 16:36:02 -0000 Received: from [127.0.0.1] by omp1052.mail.gq1.yahoo.com with NNFMP; 26 Apr 2017 16:36:02 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 86646.85116.bm@omp1052.mail.gq1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws300028.mail.gq1.yahoo.com by sendmailws138.mail.gq1.yahoo.com; Wed, 26 Apr 2017 16:36:01 +0000; 1493224561.670 Date: Wed, 26 Apr 2017 16:36:01 +0000 (UTC) From: Reply-To: To: The IESG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: , , Bill Cerveny , , Message-ID: <1387097432.303756.1493224561374@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1387097432.303756.1493224561374.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9408 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ippm-6man-pdm-option-09=3A_=28with_COMMENT=29?= 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, 26 Apr 2017 16:46:12 -0000 Mirja, Thanks for your comments. Please find my responses inline. Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Wed, 4/12/17, Mirja K=C3=BChlewind wrote: Subject: Mirja K=C3=BChlewind's No Objection on draft-ietf-ippm-6man-pdm-o= ption-09: (with COMMENT) To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att= .com, ippm@ietf.org Date: Wednesday, April 12, 2017, 10:53 AM =20 Mirja K=C3=BChlewind has entered the following ballot position for draft-i= etf-ippm-6man-pdm-option-09: No Objection =20 Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html = for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https= ://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 > My main concern is that part of this document read like an advertisement = (e.g. "In our experience, valuable time is often lost.." whose > experience? The IETF? This is an IETF RFC!). I think most of this text is= not needed to understand the option and therefore should simply be > removed. More concretely, I propose to remove sections 1.2, 1.3., and 1.5= as well as paragraphs 4-8 of section 1.4 (starting with "In our > experience, valuable time is often lost..." to the end).=20 I think that RFCs are often lacking context which makes them difficult for = new people or even people not intimately involved in the creation of the draft to understand why they are being written.=C2=A0=C2=A0 I am OK = with moving the information to an appendix.=C2=A0 What do you think? One question though, I believe you mean "paragraphs 4-8 of section 1.4 (END= ING with "In our experience, valuable time is often lost...").=20 The=C2=A0 phrase "In our experience, valuable time is often lost..." is the= very last sentence of section 1.4.=20 > I would also recommend these two changes to shorten the RFC:=20 > - section 3.2.3. could just be moved into the appendix. Fine. I will move: "3.2.3 Considerations of this time-differential representation= " into an appendix > - the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed OK. >In general I think another editing pass could help to bring the document > more to the point in a couple of cases. But that's not really an issue. >Further comments: > 1) This text in 3.4.2 is a bit confusing: > "As a completely new IP packet will be made, it means that PDM informatio= n for that packet does not contain any information from the inner packet, i= .e. the PDM information will NOT be based on the > transport layer (TCP, UDP, etc) ports etc in the inner header, but will b= e specific to the ESP flow.=20 >=C2=A0 If PDM information for the inner packet is desired, the original ho= st sending the inner packet needs to put PDM header in the tunneled packet,= and then the PDM information will be specific for that > stream." > I think what you want to say is something like > "A tunnel endpoint that creates a new packet may decide to use PDM indepe= ndent of the use of PDM of the original packet to enable delay measurements= between the two tunnel endpoints." > Correct? Yes, I think your wording represents what I wanted to convey and does it be= tter. > 2) I'm not sure this is really useful to specify normatively in an RFC as= this is really implementation specific: > "The PDM destination options extension header MUST be explicitly turned o= n by each stack on a host node by administrative action. The default value = of PDM is off." > I would recommend the following text instead (without normative language)= : > "An implementation should provide an interface to enable or disable the u= se of PDM.=C2=A0 This specification recommends to turn PDM off by default." I believe you are speaking of section 3.5.1 The reason for this was because an implementation could be created which au= tomatically and dynamically turned on PDM when a packet containing a PDM he= ader was received.=C2=A0 Then, PDM would be used without the host being explicitly aware of it.=C2=A0=C2=A0 And a number of = unfortunate things such as information leakage, DOS attacks, etc might happ= en.=C2=A0=C2=A0 So, we added language to say that administrative action is = required.=C2=A0=C2=A0 This issue was brought up by the security area review= of this document. The issue mentioned above is dealt with explicitly in section 3.5.1.=C2=A0= =C2=A0 The entire text is below: Current text ---------------- 3.5.1 PDM Activation =C2=A0=C2=A0 The PDM destination options extension header MUST be explicitl= y turned on by each stack on a host node by administrative action. The defa= ult value of PDM is off. =C2=A0=C2=A0 PDM MUST NOT be turned on merely if a packet is received with = a PDM header. The received packet could be spoofed by another device. > 3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or wh= at's meant by 'dynamic configuration option'? In any case, I don't > think the use of normative language is appropriate here. This was also brought up by Warren.=C2=A0=C2=A0 He accepted the change belo= w.=C2=A0 Please let me know if that also works for you. Current text ---------------- 3.6 Dynamic Configuration Options If implemented, each operating system MUST have a default configuration par= ameter, e.g. diag_header_sys_default_value=3Dyes/no. The operating system M= AY also have a dynamic configuration option to change the configuration setting as needed. If the PDM destination options extension header is used, then it MAY be tur= ned on for all packets flowing through the host, applied to an upper-layer = protocol (TCP, UDP, SCTP, etc), a local port, or IP address only.=C2=A0 These are at the discretion of the implementation. New text ----------- 3.6 Filtering of PDM If the PDM destination options extension header is used, then it MAY be tur= ned on for all packets flowing through the host, applied to an upper-layer = protocol (TCP, UDP, SCTP, etc), a local port, or IP address only.=C2=A0 These are at the discretion of the implementation. > 4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6. = exists twice) Thanks will fix the 3.6 twice. >OLD > "3.6 5-tuple Aging > Within the operating system, metrics must be kept on a 5-tuple basis. > The question comes of when to stop keeping data or restarting the numberi= ng for a 5-tuple.=C2=A0 For example, in the case of TCP, at some >=C2=A0 point, the connection will terminate.=C2=A0 Keeping data in control= blocks forever, will have unfortunate consequences for the operating > system. >=C2=A0 So, the recommendation is to use a known aging parameter such as Ma= x Segment Lifetime (MSL) as defined in Transmission Control Protocol >=C2=A0 [RFC0793] to reuse or drop the control block.=C2=A0 The choice of a= ging parameter is left up to the implementation." >NEW > "3.6 Information Access and Storage > Measurement information provided by PDM must be made accessible for highe= r layers or the user itself. Similar as activating the use of > PDM, the implementation may also provide an interface to indicate if rece= ived > PDM information should be stored or not. If a packet with PDM information= is received and the information should be stored, the upper layers may be > notified. Further it is recommend to define a configurable maximum lifeti= me after which the information can be removed as well as > a configurable maximum amount of memory that should be allocated for PDM = information." > This text also addresses some of the "SYN flood attack" concerns as descr= ibed in the security considerations section. I would recommend to rewrite t= his > section as well and I would also recommend to not use the term SYN flood = as that is clearly associated with TCP only. As far as: "Measurement information provided by PDM must be made accessible for higher= layers or the user itself." The information in PDM is in the extension header.=C2=A0 What we had envis= ioned is that diagnostics would be done by capturing a packet trace.=C2=A0 = But, certainly what=20 you suggest is very interesting.=C2=A0 Higher layers as well as the user c= ould make very good use of PDM information.=C2=A0 =C2=A0 =20 Are you OK with a minor change to that sentence to say: "Measurement information provided by PDM may be made accessible for higher = layers or the user itself." As far as the rest of the text in that paragraph, I am fine with it.=C2=A0 = In fact, in working on implementation, we are doing exactly that:=C2=A0 a c= onfigurable amount of memory / lifetime. Actually, only memory is needed as then it controls everything else quite w= ell. This is why we said "limit on control blocks" in the security secti= on. I will make it more explicit that what is meant by control blocks is memory. Current Security section -------------------------------- 4.1. SYN Flood and Resource Consumption Attacks PDM needs to calculate the deltas for time and keep track of the sequence numbers. This means that control blocks must be kept at the end hosts per 5-tuple. Any time a control block is kept, an attacker can try to mis-use the control blocks such that there is a compromise of the end host. PDM is used only at the end hosts and the control blocks are only kept at the end host and not at routers or middle boxes. Remember, PDM is an implementation of the Destination Option extension header. =20 A "SYN flood" type of attack succeeds because a TCP SYN packet is small but it causes the end host to start creating a place holder for the session such that quite a bit of control block and other storage is used. This is an asynchronous type of attack in that a small amount of work by the attacker creates a large amount of work by the resource attacked. For PDM, the amount of data to be kept is quite small. That is, the control block is quite lightweight. Concerns about SYN Flood and other type of resource consumption attacks (memory, processing power, etc) can be alleviated by having a limit on the number of control block entries. We recommend that implementation of PDM SHOULD have a limit on the number of control block entries. =20 NEW ------- 4.1. Resource Consumption and Resource Consumption Attacks PDM needs to calculate the deltas for time and keep track of the sequence numbers. This means that control blocks which reside in memory may be kept at the end hosts per 5-tuple. =20 A limit on how much memory is being used SHOULD be=20 implemented. Additionally, any time a control block is kept in memory, an attacker can try to mis-use the control blocks to cause excessive resource consumption. This may create compromise of the end host. PDM is used only at the end hosts and the control blocks are only kept at the end host and not at routers or middle boxes. PDM is an=20 implementation of the Destination Option extension header. =20 > 5) Also section 4.1 (security consideration): I don't think this sentence= is true: > " For PDM, the amount of data to be kept is quite small. That is, the con= trol block is quite lightweight." > Because you eventually have to hold this data per packet, so it can grow = quickly. However, this is also really an implementation question only. You= could > also just store the delay calculation and not the whole control block, or= even an moving average of the delay which only needs a fixed amount of mem= ory for a few > values. I really depends what your use case is for the information provi= ded by PDM. Please let me know if the above changes to section 4.1 addresses your conce= rns. From nobody Thu Apr 27 03:26:57 2017 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 A9FCF1200DF; Thu, 27 Apr 2017 03:26:48 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ZT5jQBruXTNI; Thu, 27 Apr 2017 03:26:46 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 515C51200C1; Thu, 27 Apr 2017 03:26:44 -0700 (PDT) X-AuditID: d9a9790a-bddff7000000439d-14-5901c76274e1 Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id 15.4B.17309.267C1095; Thu, 27 Apr 2017 12:26:42 +0200 (CEST) From: Fioccola Giuseppe To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" CC: "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "ippm@ietf.org" , "ippm-chairs@ietf.org" Thread-Topic: IPR poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSvwbYCEwbUKb/E0u0OLm/OkrHyqHY8mLQ Date: Thu, 27 Apr 2017 10:26:42 +0000 Message-ID: <2d27868ab59943cc964a1c715b58521e@TELMBXB02RM001.telecomitalia.local> References: <8b495d71-1291-cd59-9faa-fff371c9535f@pi.nu> In-Reply-To: <8b495d71-1291-cd59-9faa-fff371c9535f@pi.nu> 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.233] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsXCxfdHSjfpOGOkway7hhYNk20sVu/oZrPo efCO2eLf3DnMFusun2KzuLV0JasDm8eSJT+ZPGZNb2MLYIpqYLRJzMvLL0ksSVVISS1OtlVy ySxOzknMzE0tUghJzUlNzs9VUshMsVUyVlIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5 Cql5yfkpmXnptkqewf66FhamlrqGSnaBpanFJfkKuanFxYnp6Zn5CqkJ6wUzXs+fy1awQaLi zZxTLA2MD8S7GDk4JARMJF42snQxcnEICUxlkjj0czOQw8nBJmAjcfDVCTaQGhGBfIlNdyNB apgFVjJKHF+3D6xGWMBU4uu6T6wgtoiAucSpFfuZIWwjievTDzOB2CwCqhJNB3+xgdi8AoES U5ddZQexhQQsJM4v2gpmcwpYSvRs2wXWyyggKzFh9yJGEJtZQFzixfQTYDUSAgISS/acZ4aw RSVePv7HCmEbSGxdCnGPhICixKPmbjYIW0Zi4ZHJrCD3MwtoSqzfpQ8xUlFiSvdDdohzBCVO znzCMoFRbBaSbbMQOmYh6ZiFpGMBI8sqRtHcCgNDvRJI5GWWJOZkJupllmxiBKaTmysruXYw vl7lfIhRgINRiYc37iBjpBBrYllxZe4hRgkOZiURXsmdQCHelMTKqtSi/Pii0pzU4kOMPsDw msgsJZqcD0x1eSXxhiYWlobGFhZGhhZmpjiElcR5E7cDzRJIB6au7NTUgtQimHFMHJxSDYwn J+raz3S2vcvd8KSHPyrPv31vJEvR8xfNm+7sXhbAO6HxuzWH8d6dcjOWTivVvOH4TM7RN/jA Jq/T7Flf3r3Tu7vbY9OqjGX7Px9gmMt/3PvRx1PSmzvLZj6dqGcZsXSl9UG9H7LHyo6ujs9e qD9PKvhL4Ikzd2Wz8+v9ubxbp29zv2IlLc+uxFKckWioxVxUnAgAMmAla1QDAAA= Archived-At: Subject: [ippm] R: IPR poll on draft-bryant-mpls-rfc6374-sfl 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, 27 Apr 2017 10:26:49 -0000 SGkgQWxsLA0KSSdtIG9uZSBvZiB0aGUgY28tYXV0aG9ycyBvZiB0aGlzIGRyYWZ0Lg0KDQpU aGUgSVBSIGRpc2Nsb3N1cmUsIGFscmVhZHkgbGlua2VkIHRvIHRoaXMgZG9jdW1lbnQsIGlz IHRoZSBmdW5kYW1lbnRhbCBvbmUuDQpUaGVyZSBhcmUgb3RoZXIgSVBScyBiZWxvbmdpbmcg dG8gdGhlIHNhbWUgdG9waWM6IHRoZSBhbHRlcm5hdGUgbWFya2luZyB0ZWNobm9sb2d5IChv d25lZCBieSBUZWxlY29tIEl0YWxpYSkuDQoNClRoZXNlIGFyZSBhbHJlYWR5IGRlY2xhcmVk IG9uIGRyYWZ0LWlldGYtaXBwbS1hbHQtbWFyaywgdGhhdCBpcyBhIHJlZmVyZW5jZSBmb3Ig ZHJhZnQtYnJ5YW50LW1wbHMtcmZjNjM3NC1zZmwuDQpPdXIgZHJhZnQgbWVudGlvbnMgZHJh ZnQtaWV0Zi1pcHBtLWFsdC1tYXJrIGluIHNvbWUgcG9pbnRzIGFuZCBleHBsYWlucyBob3cg dG8gdXNlIHRoZSBhbHRlcm5hdGUgbWFya2luZyB0ZWNobm9sb2d5LCBzbyBhbGwgdGhlIElQ UnMgc2hvdWxkIGJlIGluaGVyaXRlZCBpbiBhZGRpdGlvbiB0byB0aGUgSVBSIGFscmVhZHkg ZGVjbGFyZWQuDQoNCkRvIHlvdSB0aGluayB3ZSBzaG91bGQgZGVjbGFyZSBhbHNvIHRoZSBv dGhlciBJUFJzIG9uIG91ciBkcmFmdCBvciBhcmUgdGhlc2UgYWxyZWFkeSBpbmhlcml0ZWQg ZnJvbSBkcmFmdC1pZXRmLWlwcG0tYWx0LW1hcms/DQoNClRoYW5rcywNCg0KR2l1c2VwcGUN Cg0KDQotLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6IExvYSBBbmRlcnNzb24g W21haWx0bzpsb2FAcGkubnVdIA0KSW52aWF0bzogZ2lvdmVkw6wgMjcgYXByaWxlIDIwMTcg MDU6MzINCkE6IG1wbHNAaWV0Zi5vcmcNCkNjOiBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgZHJh ZnQtYnJ5YW50LW1wbHMtcmZjNjM3NC1zZmxAaWV0Zi5vcmcNCk9nZ2V0dG86IElQUiBwb2xs IG9uIGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQtc2ZsDQoNCldvcmtpbmcgR3JvdXAsDQoN ClRoZSBhdXRob3Igb2YgZHJhZnQtYnJ5YW50LW1wbHMtcmZjNjM3NC1zZmwgaGFzIHRvbGQg dXMgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgY29uc2lkZXJlZCBmb3Igd29y a2luZyBhZG9wdGlvbi4NCg0KVGhlIGRvY3VtZW50IGJlZW4gdGhyb3VnaCBNUExTLVJUIHJl dmlldy4gV2Ugd2lsbCBkbyBhbiBJUFIgcG9sbCBwYXJhbGxlbCB0byB0aGUgc3RhcnQgb2Yg dGhlIGFkb3B0aW9uIHBvbGwuDQoNClRoaXMgbWFpbCBzdGFydHMgdGhlIElQUiBwb2xsLg0K DQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWJyeWFu dC1tcGxzLXJmYzYzNzQtc2ZsPw0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xv c2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwg NDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KVGhlcmUgaXMgb25l IElQUiBkaXNjbG9zdXJlIGZpbGVkIGRpcmVjdGx5IGFnYWluc3QgdGhpcyBkb2N1bWVudC4N Cg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0 b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIg b3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gKlRoZSByZXNwb25z ZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdC4qIFRoZSBk b2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVz cG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0 b3IuDQoNCklmIHlvdSBhcmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5v dCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBs aWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBo YXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVs ZXMuDQoNCg0KL0xvYQ0KbXBscyB3ZyBjby1jaGFpcg0KLS0gDQoNCg0KTG9hIEFuZGVyc3Nv biAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20N ClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51 DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3Mzkg ODEgMjEgNjQNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGlu ZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlm ZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxs YSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRl IHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBl ciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRh IGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRp c3RydXppb25lLCBHcmF6aWUuIA0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlv biBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBj b3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5k ZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLiANCg0KUmlzcGV0dGEgbCdhbWJpZW50ZS4g Tm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLg0K From nobody Thu Apr 27 04:05:30 2017 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 40C141289B5; Thu, 27 Apr 2017 04:05:29 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xaJFOwoGqa9v; Thu, 27 Apr 2017 04:05:26 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA61D126C7A; Thu, 27 Apr 2017 04:05:25 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3RB5J7k022048; Thu, 27 Apr 2017 12:05:19 +0100 Received: from 950129200 (xeams.riffcube.co.uk [188.246.205.89]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3RB52wt021887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Apr 2017 12:05:13 +0100 Reply-To: From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" , "'Greg Mirsky'" Cc: "'IPPM Chairs'" , References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <1FCCBA3C-4553-4310-974B-3002A983BE7A@cisco.com> In-Reply-To: Date: Thu, 27 Apr 2017 12:05:00 +0100 Message-ID: <055001d2bf46$25747210$705d5630$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0551_01D2BF4E.87400600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3Ooq+i0V2uDTKsntzdbDryWnJDQIGbTuQAhzFMcMCAqiNpgJZUHRiAczg8HQCom8n2QGF54TAAb4MqMABZ6aajQIXJiqWAYMjGPoBK9B69KBc+ZPg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23034.006 X-TM-AS-Result: No--21.198-10.0-31-10 X-imss-scan-details: No--21.198-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO0/FLJq3yHG9YUAruWRrFsFQKuv8uQBDjoOU/uP6vRQHBHE Wt1zOSXkv+z/Cp/l5Anfs/iKYqqdz6RcnmyiScEKM0pZiLPQITrSL+EVfOJR0zASEdbkpUDPvL4 BuAuBsSnxEHxEGftd4hSupmb2RsqAkg6GA5mI8yy4jAucHcCqnZRy1HDTPOXau/jTz8Y/keq9LA P3BmK8uknBr3+qfSYg6e8O3e79YnPbCs3q6Ctuzk0IfQOJvRLR4lzqEpaPQLVUqATC7QW6p5wZE SERYY0skE4SFWFFa6kXIJWO/t2WjgxFU+TNBx+F+nWmWoRu6rEBk1BLx9Z1nSJ8zskw0dbrwhld 5aALkfhn1dtB0I0GA6ZRiuuvu4o9QjDhdr0sC0ysDodw9yUkxmWuy5Lm0L4/df6tui+/W0yM823 SqBkeEiUimlgta6MC/Byc/04iPni5HsA8a/n6iLMjW/sniEQK+OxgjmSeIa6ynk7TnYzMuuKclO 5YMBg/PdZCmk00PRU3KhLsGCPGMlJP/hSKiq44+NCQDut0K4UrvS9y1NIABwlbhF7ZTanLN+D0r Q2h0wJgJzASb2XBkDeT288mssTUPHPm0OGEPQajFYHTfcPkwhOySJ0+MHXaDYbe/PyX8gSM2EkI FQImiHlmrkHUz6dkp9iJdiBQ1fdcG2eGMs0H+ru9iqQJLR0vHznaOB9+eYiwThPQD7RhKUiMB4C WhnR4DV7LrgNoGacs+oi/YHgoTQe1vNu551eNY6Gjtu6/t32xxFti5/cl+kmDyxNPdHMXDjZwjr Q6CQWahMqmNXa3RRw58L6+gfo0RF8J0whn5t2eAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCsinemPj/cphyft0H93HE3oSTBF1Gl4i+CjYJEzU/c55SHIV02d1rpG8= Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 27 Apr 2017 11:05:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0551_01D2BF4E.87400600 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Carlos is right, but we got to this discussion because after Frank spoke = in Chicago there were a number of scoping questions that remained = unclear with possible misunderstandings and assumptions. =20 It should be clear from the email exchanges on this list so far that the = type of solution we develop will be considerably dependent on the scope = of the problem. =20 I don't believe we (well, not me anyway) are calling for a detailed = requirements document. Not even a problem statement document. But we do = need a clear scoping statement. =20 As it happens, Frank has done some good work to address this with his = new text, and I think we are close to done. =20 The only issue might be one of language. Saying "requirements" conveys = different meanings to different people. =20 Probably the best way to ensure Greg's concerns are answered is for Greg = to ask specific targeted questions (such as, but not specifically, "Do = you intend this technology to be used in kitchen appliances?"). Then = Frank can suggest answers, others can chime in for consensus, and the = result can be briefly captured in the document. =20 Ciao, Adrian =20 From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: 26 April 2017 15:21 To: Greg Mirsky Cc: Adrian Farrel; IPPM Chairs; ippm@ietf.org Subject: Re: [ippm] Vote at IPPM session =20 Greg,=20 =20 I agree that a shared understanding and alignment on the problem space = is critically important. My understanding is that we have already been = doing that extensively, including the work on potential charter text = discussed in Opsawg. That was, for example, a discussion solely about = the problem to be solved. =20 What concerns me is the strict serialization and waterfall you seem to = be advocating for. =20 =E2=80=94 Carlos. =20 On Apr 26, 2017, at 9:22 AM, Greg Mirsky wrote: =20 Dear Carlos,=20 thank you for the reference.=20 I've never called for perfecting but for rough consensus on what problem = we need to address. How, IMHO, is secondary. And that is what may be not = working in this discussion - we've been presented answer to how do = measurement before we have reached an agreement that there's a problem = to be solved. =20 Regards, Greg =20 On Wed, Apr 26, 2017 at 6:13 AM, Carlos Pignataro (cpignata) = wrote: Dear Greg, =20 Something like = https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-03?=20 =20 For the record, my opinion: perfecting requirements is perhaps not the = best use of WG cycles. However, placing requirements as a serialized = requisite before progressing protocol work is certainly harmful in this = case. =20 Thanks, =20 -- Carlos. =20 From: ippm on behalf of Greg Mirsky = Date: Wednesday, April 26, 2017 at 5:22 AM To: Adrian Farrel Cc: IPPM Chairs , "ippm@ietf.org" Subject: Re: [ippm] Vote at IPPM session =20 Hi Adrian, et. al,=20 I strongly believe that having agreed upon list of requirements that = answer questions What? and Where? rather than How? is the most = beneficial and not only for the discussion of applicability of in-situ = OAM. What needs to be solved, measured that is not ameasureable by = already existing OAM methods? I think that if we can compile such list, = then it will be more clear what value may be added by developing new = hybrid OAM method. =20 Regards, Greg =20 On Wed, Mar 29, 2017 at 2:32 PM, Adrian Farrel = wrote: > > There were several questions related to scope and applicability in = the WG > discussion =E2=80=93 and even more recently on the list. Those can = easily be addressed by > adding paragraph on applicability to draft-brockners-inband-oam-data = =E2=80=93 there > isn=E2=80=99t a need for a dedicated requirements document. > > I tend to agree with this, although "a paragraph" seems a little thin = to me. I think > there were some valid points made in that discussion about the scope = of the > proposal that should be addressed: is IOAM meant for use = tunnel-end-to-tunnel- > end environment, end-host-to-end-host, within a single network and/or = across > the Internet. What I would suggest is adding a section to the data = model draft on > applicability and assumptions about the environment -- both about the = devices > adding IOAM signals to traffic as well as those consuming these = signals from the > wire and analyzing them (possibly with the cooperation of devices not = on the > wire) -- submitting a new revision, and we can run a more formal = adoption call on > that. Although I was one of the people raising the "need" for the scope and = requirements, I don't have a strong leading on whether this needs to be = in a separate document on folded into the data format document. So = Brian's proposal would work for me. Thus, I'd love to see this scoping text drafted and floated to the list = as an email or in a revision of the data format document. Cheers, Adrian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm =20 =20 =20 ------=_NextPart_000_0551_01D2BF4E.87400600 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Carlos is right, but we got to = this discussion because after Frank spoke in Chicago there were a number = of scoping questions that remained unclear with possible = misunderstandings and assumptions.

 

It should be clear from the = email exchanges on this list so far that the type of solution we develop = will be considerably dependent on the scope of the = problem.

 

I don't believe we (well, not = me anyway) are calling for a detailed requirements document. Not even a = problem statement document. But we do need a clear scoping = statement.

 

As it happens, Frank has done = some good work to address this with his new text, and I think we are = close to done.

 

The only issue might be one of = language. Saying "requirements" conveys different meanings to = different people.

 

Probably the best way to = ensure Greg's concerns are answered is for Greg to ask specific targeted = questions (such as, but not specifically, "Do you intend this = technology to be used in kitchen appliances?"). Then Frank can = suggest answers, others can chime in for consensus, and the result can = be briefly captured in the document.

 

Ciao,

Adrian

 

From: Carlos Pignataro = (cpignata) [mailto:cpignata@cisco.com]
Sent: 26 April 2017 = 15:21
To: Greg Mirsky
Cc: Adrian Farrel; IPPM = Chairs; ippm@ietf.org
Subject: Re: [ippm] Vote at IPPM = session

 

Greg, =

 

I agree that a shared understanding and alignment on the problem = space is critically important. My understanding is that we have already = been doing that extensively, including the work on potential charter = text discussed in Opsawg. That was, for example, a discussion solely = about the problem to be solved.

 

What concerns me is the strict serialization and waterfall you = seem to be advocating for.

 

=E2=80=94 Carlos.

 

On Apr 26, 2017, at 9:22 AM, Greg Mirsky <gregimirsky@gmail.com> = wrote:

 

Dear Carlos, =

thank you for the = reference. 

I've never called for perfecting but for rough consensus on what = problem we need to address. How, IMHO, is secondary. And that is what = may be not working in this discussion - we've been presented answer to = how do measurement before we have reached an agreement that there's a = problem to be solved.

 

Regards,

Greg

 

On Wed, Apr 26, 2017 = at 6:13 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Dear Greg,

 

Something like https://tools.ietf.org/html/draft-brockners-inband-oam-= requirements-03?

 

For the record, my opinion: perfecting requirements is = perhaps not the best use of WG cycles. However, placing requirements as = a serialized requisite before progressing protocol work is certainly = harmful in this case.

 

Thanks,

 

-- Carlos.

 

From= : ippm= <ippm-bounces@ietf.org> on behalf of Greg Mirsky = <gregimirsky@gmail.com>
Date: = Wednesday, April 26, 2017 at 5:22 AM
To: Adrian Farrel = <adrian@olddog.co.uk>
Cc: IPPM Chairs = <ippm-chairs@ietf.org>, "ippm@ietf.org" = <ippm@ietf.org>
Subject: Re: [ippm] = Vote at IPPM session

 

=

Hi Adrian, et. al, =

I strongly believe that = having agreed upon list of requirements that answer questions What? and = Where? rather than How? is the most beneficial and not only for the = discussion of applicability of in-situ OAM. What needs to be solved, = measured that is not ameasureable by already existing OAM methods? I = think that if we can compile such list, then it will be more clear what = value may be added by developing new hybrid OAM = method.

 

=

Regards,

Greg

<= /div>

 

On Wed, Mar 29, 2017 at = 2:32 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

> > There were = several questions related to scope and applicability in the WG
> = discussion =E2=80=93 and even more recently on the list. Those can = easily be addressed by
> adding paragraph on applicability to = draft-brockners-inband-oam-data =E2=80=93 there
> isn=E2=80=99t a = need for a dedicated requirements document.
>
> I tend to = agree with this, although "a paragraph" seems a little thin to = me. I think
> there were some valid points made in that discussion = about the scope of the
> proposal that should be addressed: is = IOAM meant for use tunnel-end-to-tunnel-
> end environment,  = end-host-to-end-host, within a single network and/or across
> the = Internet.  What I would suggest is adding a section to the data = model draft on
> applicability and assumptions about the = environment -- both about the devices
> adding IOAM signals to = traffic as well as those consuming these signals from the
> wire = and analyzing them (possibly with the cooperation of devices not on = the
> wire) -- submitting a new revision, and we can run a more = formal adoption call on
> that.

Although I was one of the = people raising the "need" for the scope and requirements, I = don't have a strong leading on whether this needs to be in a separate = document on folded into the data format document. So Brian's proposal = would work for me.

Thus, I'd love to see this scoping text = drafted and floated to the list as an email or in a revision of the data = format = document.

Cheers,
Adrian

_______________________________= ________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

 

 

 

------=_NextPart_000_0551_01D2BF4E.87400600-- From nobody Thu Apr 27 05:01:00 2017 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 5E416129445; Thu, 27 Apr 2017 05:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 4xcQFAEq8krt; Thu, 27 Apr 2017 05:00:48 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048E0129444; Thu, 27 Apr 2017 05:00:48 -0700 (PDT) Received: from [192.168.1.10] (unknown [49.150.112.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 164DF18014F3; Thu, 27 Apr 2017 14:00:41 +0200 (CEST) To: Fioccola Giuseppe , "mpls@ietf.org" , "mpls-chairs@ietf.org" References: <8b495d71-1291-cd59-9faa-fff371c9535f@pi.nu> <2d27868ab59943cc964a1c715b58521e@TELMBXB02RM001.telecomitalia.local> Cc: "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "ippm@ietf.org" , "ippm-chairs@ietf.org" From: Loa Andersson Message-ID: <82bbc067-3526-8999-ad84-80654cccea55@pi.nu> Date: Thu, 27 Apr 2017 20:00:15 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2d27868ab59943cc964a1c715b58521e@TELMBXB02RM001.telecomitalia.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ippm] R: IPR poll on draft-bryant-mpls-rfc6374-sfl 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, 27 Apr 2017 12:00:50 -0000 Giuseppe, I can't give advice on validity of one IPR or another. If you have knowledge about IPRs that you think are relevant for one IETF document or another you have to disclose. The fact that it has been disclosed against another document is not relevant, a disclosure is necessary for each document you think it applies to. /Loa On 2017-04-27 18:26, Fioccola Giuseppe wrote: > Hi All, > I'm one of the co-authors of this draft. > > The IPR disclosure, already linked to this document, is the fundamental one. > There are other IPRs belonging to the same topic: the alternate marking technology (owned by Telecom Italia). > > These are already declared on draft-ietf-ippm-alt-mark, that is a reference for draft-bryant-mpls-rfc6374-sfl. > Our draft mentions draft-ietf-ippm-alt-mark in some points and explains how to use the alternate marking technology, so all the IPRs should be inherited in addition to the IPR already declared. > > Do you think we should declare also the other IPRs on our draft or are these already inherited from draft-ietf-ippm-alt-mark? > > Thanks, > > Giuseppe > > > -----Messaggio originale----- > Da: Loa Andersson [mailto:loa@pi.nu] > Inviato: giovedì 27 aprile 2017 05:32 > A: mpls@ietf.org > Cc: mpls-chairs@ietf.org; draft-bryant-mpls-rfc6374-sfl@ietf.org > Oggetto: IPR poll on draft-bryant-mpls-rfc6374-sfl > > Working Group, > > The author of draft-bryant-mpls-rfc6374-sfl has told us that the document is ready to be considered for working adoption. > > The document been through MPLS-RT review. We will do an IPR poll parallel to the start of the adoption poll. > > This mail starts the IPR poll. > > Are you aware of any IPR that applies to draft-bryant-mpls-rfc6374-sfl? > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > There is one IPR disclosure filed directly against this document. > > If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. > > > /Loa > mpls wg co-chair > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 27 05:13:47 2017 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 AAB5412944B; Thu, 27 Apr 2017 05:13:45 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 PACRePYagNnu; Thu, 27 Apr 2017 05:13:44 -0700 (PDT) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 E0D5B129435; Thu, 27 Apr 2017 05:13:38 -0700 (PDT) X-AuditID: d9a9790a-bddff7000000439d-2f-5901e070d15e Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id A7.25.17309.070E1095; Thu, 27 Apr 2017 14:13:36 +0200 (CEST) From: Fioccola Giuseppe To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" CC: "draft-bryant-mpls-rfc6374-sfl@ietf.org" , "ippm@ietf.org" , "ippm-chairs@ietf.org" Thread-Topic: R: IPR poll on draft-bryant-mpls-rfc6374-sfl Thread-Index: AQHSvwbYCEwbUKb/E0u0OLm/OkrHyqHY8mLQgAAJsoCAACNF4A== Date: Thu, 27 Apr 2017 12:13:36 +0000 Message-ID: <8a36b471f3c24e848a3cc05278d16003@TELMBXB02RM001.telecomitalia.local> References: <8b495d71-1291-cd59-9faa-fff371c9535f@pi.nu> <2d27868ab59943cc964a1c715b58521e@TELMBXB02RM001.telecomitalia.local> <82bbc067-3526-8999-ad84-80654cccea55@pi.nu> In-Reply-To: <82bbc067-3526-8999-ad84-80654cccea55@pi.nu> 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.235] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEKsWRmVeSWpSXmKPExsXCxfdHSrfgAWOkwZczehYNk20sVu/oZrPo efCO2eLf3DnMFusun2KzuLV0JasDm8eSJT+ZPGZNb2MLYIpqYLRJzMvLL0ksSVVISS1OtlVy ySxOzknMzE0tUghJzUlNzs9VUshMsVUyVlIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5 Cql5yfkpmXnptkqewf66FhamlrqGSnaBpanFJfkKuanFxYnp6Zn5CqkJ6wUzrnacYik4plSx uG0fcwPjFcUuRk4OCQETiY6He5lAbCGBqUwSa9apg9hsAjYSB1+dYOti5OAQEciX2HQ3souR i4NZYCWjxPF1+1hAaoQFLCTOdSwB6xURsJJYt+QCG4TtJNH0dBYriM0ioCoxecVuMJtXIFDi 3dnzzCCDhATWM0psffuWESTBKWApcfz1NbBmRgFZiQm7F4HFmQXEJV5MP8EOcaiAxJI9IM0g tqjEy8f/WCFsA4mtSyEOkhBQlPjTvYUJwpaRWHhkMivIA8wCmhLrd+lDjFSUmNL9kB3iHkGJ kzOfsExgFJuFZNsshI5ZSDpmIelYwMiyilE0t8LAUK8EEnuZJYk5mYl6mSWbGIEJ5ebKSq4d jK9XOR9iFOBgVOLhnXKXMVKINbGsuDL3EKMEB7OSCG/mFaAQb0piZVVqUX58UWlOavEhRh9g gE1klhJNzgcmu7ySeEMTC0tDYwsLI0MLM1McwkrivJvuAM0SSAcmr+zU1ILUIphxTBycUg2M KY0HWN9qv2lbvf5vhY7YBKu0QkfRA5u6zypsP2OerBG27ct1JeOZLu+Zey7uk7k6ydrTZsWU doV+ZTunxusaK6p/P9k8t/PCPrnyV38ZV9/Zd/Vja8Uf0bNCjHr18yuYZdoKAit707hP/Iq9 cG/z8/l/3QSFTi3hs1soc59F5NcM3151hsx6JZbijERDLeai4kQAWmYRDVUDAAA= Archived-At: Subject: [ippm] R: R: IPR poll on draft-bryant-mpls-rfc6374-sfl 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, 27 Apr 2017 12:13:46 -0000 T2sgTG9hLCANCk1hbnkgVGhhbmtzIGZvciB5b3VyIGNsYXJpZmljYXRpb24uDQpJIHdpbGwg aW5mb3JtIFRJIElQUiBkZXBhcnRtZW50IHNvIHRoZXkgY2FuIHVwZGF0ZSB0aGUgZGlzY2xv c3VyZSBvbiBkcmFmdC1icnlhbnQtbXBscy1yZmM2Mzc0LXNmbC4NCg0KQmVzdCBSZWdhcmRz LA0KDQpHaXVzZXBwZQ0KDQotLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6IExv YSBBbmRlcnNzb24gW21haWx0bzpsb2FAcGkubnVdIA0KSW52aWF0bzogZ2lvdmVkw6wgMjcg YXByaWxlIDIwMTcgMTQ6MDANCkE6IEZpb2Njb2xhIEdpdXNlcHBlOyBtcGxzQGlldGYub3Jn OyBtcGxzLWNoYWlyc0BpZXRmLm9yZw0KQ2M6IGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQt c2ZsQGlldGYub3JnOyBpcHBtQGlldGYub3JnOyBpcHBtLWNoYWlyc0BpZXRmLm9yZw0KT2dn ZXR0bzogUmU6IFI6IElQUiBwb2xsIG9uIGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQtc2Zs DQoNCkdpdXNlcHBlLA0KDQpJIGNhbid0IGdpdmUgYWR2aWNlIG9uIHZhbGlkaXR5IG9mIG9u ZSBJUFIgb3IgYW5vdGhlci4gSWYgeW91IGhhdmUga25vd2xlZGdlIGFib3V0IElQUnMgdGhh dCB5b3UgdGhpbmsgYXJlIHJlbGV2YW50IGZvciBvbmUgSUVURiBkb2N1bWVudCBvciBhbm90 aGVyIHlvdSBoYXZlIHRvIGRpc2Nsb3NlLiBUaGUgZmFjdCB0aGF0IGl0IGhhcyBiZWVuIGRp c2Nsb3NlZCBhZ2FpbnN0IGFub3RoZXIgZG9jdW1lbnQgaXMgbm90IHJlbGV2YW50LCBhIGRp c2Nsb3N1cmUgaXMgbmVjZXNzYXJ5IGZvciBlYWNoIGRvY3VtZW50IHlvdSB0aGluayBpdCBh cHBsaWVzIHRvLg0KDQovTG9hDQoNCk9uIDIwMTctMDQtMjcgMTg6MjYsIEZpb2Njb2xhIEdp dXNlcHBlIHdyb3RlOg0KPiBIaSBBbGwsDQo+IEknbSBvbmUgb2YgdGhlIGNvLWF1dGhvcnMg b2YgdGhpcyBkcmFmdC4NCj4NCj4gVGhlIElQUiBkaXNjbG9zdXJlLCBhbHJlYWR5IGxpbmtl ZCB0byB0aGlzIGRvY3VtZW50LCBpcyB0aGUgZnVuZGFtZW50YWwgb25lLg0KPiBUaGVyZSBh cmUgb3RoZXIgSVBScyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgdG9waWM6IHRoZSBhbHRlcm5h dGUgbWFya2luZyB0ZWNobm9sb2d5IChvd25lZCBieSBUZWxlY29tIEl0YWxpYSkuDQo+DQo+ IFRoZXNlIGFyZSBhbHJlYWR5IGRlY2xhcmVkIG9uIGRyYWZ0LWlldGYtaXBwbS1hbHQtbWFy aywgdGhhdCBpcyBhIHJlZmVyZW5jZSBmb3IgZHJhZnQtYnJ5YW50LW1wbHMtcmZjNjM3NC1z ZmwuDQo+IE91ciBkcmFmdCBtZW50aW9ucyBkcmFmdC1pZXRmLWlwcG0tYWx0LW1hcmsgaW4g c29tZSBwb2ludHMgYW5kIGV4cGxhaW5zIGhvdyB0byB1c2UgdGhlIGFsdGVybmF0ZSBtYXJr aW5nIHRlY2hub2xvZ3ksIHNvIGFsbCB0aGUgSVBScyBzaG91bGQgYmUgaW5oZXJpdGVkIGlu IGFkZGl0aW9uIHRvIHRoZSBJUFIgYWxyZWFkeSBkZWNsYXJlZC4NCj4NCj4gRG8geW91IHRo aW5rIHdlIHNob3VsZCBkZWNsYXJlIGFsc28gdGhlIG90aGVyIElQUnMgb24gb3VyIGRyYWZ0 IG9yIGFyZSB0aGVzZSBhbHJlYWR5IGluaGVyaXRlZCBmcm9tIGRyYWZ0LWlldGYtaXBwbS1h bHQtbWFyaz8NCj4NCj4gVGhhbmtzLA0KPg0KPiBHaXVzZXBwZQ0KPg0KPg0KPiAtLS0tLU1l c3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KPiBEYTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxv YUBwaS5udV0NCj4gSW52aWF0bzogZ2lvdmVkw6wgMjcgYXByaWxlIDIwMTcgMDU6MzINCj4g QTogbXBsc0BpZXRmLm9yZw0KPiBDYzogbXBscy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWJy eWFudC1tcGxzLXJmYzYzNzQtc2ZsQGlldGYub3JnDQo+IE9nZ2V0dG86IElQUiBwb2xsIG9u IGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQtc2ZsDQo+DQo+IFdvcmtpbmcgR3JvdXAsDQo+ DQo+IFRoZSBhdXRob3Igb2YgZHJhZnQtYnJ5YW50LW1wbHMtcmZjNjM3NC1zZmwgaGFzIHRv bGQgdXMgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgY29uc2lkZXJlZCBmb3Ig d29ya2luZyBhZG9wdGlvbi4NCj4NCj4gVGhlIGRvY3VtZW50IGJlZW4gdGhyb3VnaCBNUExT LVJUIHJldmlldy4gV2Ugd2lsbCBkbyBhbiBJUFIgcG9sbCBwYXJhbGxlbCB0byB0aGUgc3Rh cnQgb2YgdGhlIGFkb3B0aW9uIHBvbGwuDQo+DQo+IFRoaXMgbWFpbCBzdGFydHMgdGhlIElQ UiBwb2xsLg0KPg0KPiBBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRv IGRyYWZ0LWJyeWFudC1tcGxzLXJmYzYzNzQtc2ZsPw0KPg0KPiBJZiBzbywgaGFzIHRoaXMg SVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAo c2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4N Cj4NCj4gVGhlcmUgaXMgb25lIElQUiBkaXNjbG9zdXJlIGZpbGVkIGRpcmVjdGx5IGFnYWlu c3QgdGhpcyBkb2N1bWVudC4NCj4NCj4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVu dCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBy ZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2 YW50IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIHdn IG1haWxpbmcgbGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBu ZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNo IGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQo+DQo+IElmIHlvdSBhcmUgb24gdGhlIE1QTFMg V0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRy aWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJl IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBj b25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQo+DQo+DQo+IC9Mb2ENCj4gbXBscyB3ZyBj by1jaGFpcg0KPg0KDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAg ICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9yIE1QTFMgRXhwZXJ0 ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCkh1YXdlaSBUZWNobm9sb2dp ZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KDQpRdWVzdG8g bWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZh bWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1 YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVl c3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBh YmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0 ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBt aXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4g DQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFu ZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUg YWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9y IHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg YW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWls LCBUaGFua3MuIA0KDQpSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3Rh IG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQo= From nobody Thu Apr 27 06:56:17 2017 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 71916129522; Thu, 27 Apr 2017 06:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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=telekom.de 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 PzYlbbqKiU4e; Thu, 27 Apr 2017 06:56:13 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (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 1D50D1294F7; Thu, 27 Apr 2017 06:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1493301373; x=1524837373; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=F+GgYkl4Cw1yxn4LQBllXlJa5LEd2iablUf6FkLyiyA=; b=bMTiaJZOgNOFHjjHFeN6Eix+kgrcbAFYEc872zqTIK1ia+0o2yYrFYkj 4u66rJubRyPY+euMDeKgaw5N1vVsWfsO6uoPHiSBAIC8LUqVMxp6ifjh9 aGLGaHHijEiw0ygLd3sbqRk+kVMgwBJhDRzC3zL4o4BG9XJwx4NUk1/nI SmEkwW7BG/YXg3di1NtCjihyqIb9teCUuynC+7Y1hZlSO16hk4t0f2fiZ bcWk0sXx93JNVtqi36Rb9hORGJ6DZcWEepx3LSlGMTt9lM6M2jyXNUN79 8P48VVC6ypKZSgPTuQMvWah+C5bbgXo/SVlmkm58Za0E6Va7GpoIci1Wd w==; Received: from q4de8ssaz61.gppng.telekom.de ([10.206.166.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2017 15:56:09 +0200 X-IronPort-AV: E=Sophos;i="5.37,384,1488841200"; d="scan'208";a="1172753296" Received: from he101655.emea1.cds.t-internal.com ([10.134.226.17]) by q4de8ssazdv.gppng.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2017 15:56:08 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101655.emea1.cds.t-internal.com (10.134.226.17) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Apr 2017 15:56:08 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Thu, 27 Apr 2017 15:56:08 +0200 From: To: CC: , , Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ANPZAWv+5YD0yHKUp0Ir+32KGqudOAgAAD3QCAAAfSAIAAIx6AgAA2hgCAAPdoAIAAaFWAgAAcNwD//8lsgIAC5LeAgAt5d4CABF/eAIADEXMAgARQ+4CABTbyAIAAKoCA///CZvCAAQO0gIAAkNsggAWfLACAAXzNAA== Date: Thu, 27 Apr 2017 13:56:08 +0000 Message-ID: <39f70adc5ad34581bf83b0e9c48dd50a@HE101653.emea1.cds.t-internal.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF25F71AE7@njmtexg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> <9C575ED7-E248-4D6D-855A-2F20926709DF@cisco.com> In-Reply-To: <9C575ED7-E248-4D6D-855A-2F20926709DF@cisco.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.166.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 27 Apr 2017 13:56:16 -0000 SGkgQ2FybG9zLA0KDQpMZXQgbWUgcGljayB1cCBGcmFuaydzIHByb3Bvc2FsOg0KDQpPTEQNCiJE ZXNpZ25lcnMgb2YgY2FycmllciBwcm90b2NvbHMgZm9yIElPQU0gZGVzaWduZXJzIG11c3QgY29u c2lkZXIgdG8gcHV0IG1lY2hhbmlzbXMgaW4gcGxhY2UgdG8gZW5zdXJlIHRoYXQgaW4tc2l0dSBP QU0gZGF0YSBzdGF5cyB3aXRoaW4gYW4gSU9BTSBkb21haW4uLiINCg0KTkVXDQoiRGVzaWduZXJz IG9mIGNhcnJpZXIgcHJvdG9jb2xzIGZvciBJT0FNIGRlc2lnbmVycyBtdXN0IHNwZWNpZnkgbWVj aGFuaXNtcyB0byBlbnN1cmUgdGhhdCBpbi1zaXR1IE9BTSBkYXRhIHN0YXlzIHdpdGhpbiBhbiBJ T0FNIGRvbWFpbi4uIg0KDQpJIGRvbid0IG9iamVjdCB0aGF0IHRoZSBvcGVyYXRvciBpcyBpbnZv bHZlZC4gQnV0IHRoZSBvcGVyYXRvcnMgdGFzayB0byBtZSBzaG91bGQgYmUgdG8gdHVybiBhbiAi aW4tc2l0dSBPQU0gY29uZmlndXJhdGlvbiBrbm9iIiB0byBzb2x2ZSB0aGUgcHJvYmxlbS4gVGhp cyBrbm9iIG11c3QgYmUgZGVsaXZlcmVkIGJ5IHRoZSBwcm90b2NvbCBkZXZlbG9wZXJzLiAiQ29u c2lkZXIiIHRvIG1lIGFzIGEgbm9uLW5hdGl2ZSBzcGVha2VyIHNvdW5kcyBsaWtlICJ0aGluayBh Ym91dCBhbmQgaWYgaXQncyBnZXR0aW5nIGNvbXBsZXgsIGRvaW5nIG5vdGhpbmcgaXMgYSB2YWxp ZCBvcHRpb24iLiANCg0KQXMgbWVudGlvbmVkIGVhcmxpZXIsIHJlbHlpbmcgb24gYSBmaXJld2Fs bCB0byBtZSBpcyBhbiBvcHRpb24gSSdkIGxpa2UgdG8gYXZvaWQuIA0KDQpSZWdhcmRzLA0KDQpS dWVkaWdlcg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0gDQpHZXNl bmRldDogU29ubnRhZywgMjMuIEFwcmlsIDIwMTcgMTM6NDQNCkFuOiBBbCBNb3J0b24NCkNjOiBH ZWliLCBSw7xkaWdlcjsgaXBwbS1jaGFpcnNAaWV0Zi5vcmc7IGlwcG1AaWV0Zi5vcmcNCkJldHJl ZmY6IFJlOiBbaXBwbV0gVm90ZSBhdCBJUFBNIHNlc3Npb24NCg0KSGksDQoNClRoaXMgaXMgYSB2 ZXJ5IHVzZWZ1bCBkaXNjdXNzaW9uIOKAlCBhbHRob3VnaCBvbiB0aGUgdGFpbC1lbmQgc2VlbXMg dG8gYmUgZGl2ZXJnaW5nIGZyb20gdGhlIG9yaWdpbmFsIGdvYWwuIEkgc3VnZ2VzdCB0aGF0IHdl IHNob3VsZCBwcm9iYWJseSBub3QgdGFrZSB0aGlzIGRpc2N1c3Npb24gaW50byBhbGwgaW50ZXIt ZG9tYWluIHBlcm11dGF0aW9ucy4NCg0KSW4gb3RoZXIgd29yZHMsIGlzIHRoZXJlIHNvbWUgY2Fz ZSB0aGF0IHRoZSBvcmlnaW5hbCB0ZXh0IGRvZXMgbm90IGNvdmVyPyBUaGUgdGV4dCBpbmNsdWRl cyDigJxtZWNoYW5pc21zIGluIHBsYWNlIHRvIGVuc3VyZSB0aGF0IGluLXNpdHUgT0FNIGRhdGEg c3RheXMgd2l0aGluIGFuIElPQU0gZG9tYWlu4oCdIGFuZCDigJxwcm92aXNpb25zIGluIHBsYWNl IHRvIGVuc3VyZSB0aGF0IElPQU0gZGF0YSBkb2VzIG5vdCBsZWFrIGJleW9uZCB0aGUgZWRnZSBv ZiBhbiBJT0FNIGRvbWFpbuKAnS4NCg0KVGhlIGlkZWEgaXMgdGhhdCBhbiBJT0FNIERvbWFpbiBz aG91bGQgdGFrZSBjYXJlIG9mIGNvbnNpZGVyYXRpb25zIGJlY2F1c2Ugb2YgZS5nLiwgaW5jcmVh c2VkIHBhY2tldCBzaXplcyB3aXRoaW4gaXRzIGRvbWFpbiwgYW5kIHByZXZlbnQgbGVha2FnZS4N Cg0KSW4gbWFueSBkZXBsb3ltZW50cywgdGhlIGxhdHRlciAoaS5lLiwgImVuc3VyaW5nIHRoYXQg aU9BTSBkYXRhIHN0YXlzIHdpdGhpbiB0aGUgZG9tYWluLCBhbmQgZG9lcyBub3QgbGVhayBiZXlv bmQgdGhlIGV4aXQgZWRnZeKAnSkgd291bGQgYmUgYSBuYXR1cmFsIGNoYXJhY3RlcmlzdGljIG9m IHRoZSBlbmNhcHN1bGF0aW9uLiBGb3IgZXhhbXBsZSwgd2hlbiB1c2luZyBJT0FNIHdpdGggTlNI LCBhbiBJT0FNIGRvbWFpbiB3b3VsZCBiZSBhbiBTRkMgZG9tYWluLCBhbmQgdGh1cyByZW1vdmlu ZyBOU0ggZW5jYXAgd2lsbCBhbHNvIGVuc3VyZSBJT0FNIGRvZXMgbm90IGxlYWsuIFNhbWUgd2l0 aCBWeExBTi1HUEUsIGV0Yy4NCg0KQnV0IG5ldC1uZXQsIEnigJlkIHJlY29tbWVuZCB3ZSBkZWZp bmUgdGhlIElPQU0gZG9tYWluIGJlaGF2aW9yIGFuZCBub3QgYWxsIG90aGVyIHBvc3NpYmxlIHZp ZXdzLg0KDQpUaGFua3MhDQoNCuKAlCBDYXJsb3MuDQoNCj4gT24gQXByIDE5LCAyMDE3LCBhdCA0 OjAyIFBNLCBNT1JUT04sIEFMRlJFRCBDIChBTCkgPGFjbW9ydG9uQGF0dC5jb20+IHdyb3RlOg0K PiANCj4gSGkgUsO8ZGlnZXIsDQo+IHNob3J0IHJlcGx5IGluLWxpbmUsDQo+IEFsDQo+IA0KPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFJ1ZWRpZ2VyLkdlaWJAdGVsZWtv bS5kZSBbbWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZV0NCj4+IFNlbnQ6IFdlZG5lc2Rh eSwgQXByaWwgMTksIDIwMTcgMzoxNSBBTQ0KPj4gVG86IE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0K Pj4gQ2M6IGlwcG0tY2hhaXJzQGlldGYub3JnOyBpcHBtQGlldGYub3JnOyBpZXRmQHRyYW1tZWxs LmNoOyANCj4+IGZicm9ja25lQGNpc2NvLmNvbQ0KPj4gU3ViamVjdDogQVc6IFtpcHBtXSBWb3Rl IGF0IElQUE0gc2Vzc2lvbg0KPj4gDQo+PiBIaSBBbCwNCj4+IA0KPj4gaXMgYSBub24taU9BTSBu ZXR3b3JrIG9wZXJhdG9yIGFibGUgdG8gZGV0ZWN0IHN0YW5kYXJkIGlwdjYgcGFja2V0cyANCj4+ IHdpdGggaU9BTSBleHRlbnNpb25zLCBpZiB0aGUgcmVjZWl2aW5nIG9wZXJhdG9ycyBlcXVpcG1l bnQgaXMgDQo+PiBjb25maWd1cmVkIHRvIHN1cHBvcnQgc3RhbmRhcmQgaXB2NiBwcm90b2NvbCBv bmx5PyBUaGUgcHJlLWNvbmRpdGlvbiANCj4+IGhlcmUgaXMgIm5vbi1pT0FNIGRvbWFpbiIgYXQg dGhlIHJlY2VpdmluZyBzaWRlLiBNeSBwb2ludCBpcywgaWYgYSANCj4+IGRvbWFpbiBpc24ndCBp bnRlcmVzdGVkIGluIHN1cHBvcnRpbmcgdGhlIGlPQU0gZXh0ZW5zaW9ucywgaXMgaXQgDQo+PiBv YmxpZ2VkIHRvIG9wZXJhdGUgaU9BTSBhd2FyZSBlcXVpcG1lbnQgdG8gZGV0ZWN0IHVuZGVzaXJl ZCB0cmFmZmljIGF0IG5ldHdvcmsgYm91bmRhcmllcz8NCj4gW0FDTV0NCj4gTm8sIGFuIG9wZXJh dG9yIGNhbiBsZXQgdGhlIHRyYWZmaWMgZmxvdyBpZiB0aGV5IHdhbnQuDQo+IEhvd2V2ZXIsIGlm IG9wZXJhdG9ycyBmaW5kIHRoYXQgdGhlaXIgbmV0d29yayBpcyBhZmZlY3RlZCBieSB0cmFmZmlj IA0KPiB3aXRoIGlPQU0gZGF0YSBmcm9tIGFub3RoZXIgZG9tYWluLCB0aGV5IHdvdWxkIGJlIGp1 c3RpZmllZCB0byBkaXNjYXJkIA0KPiB0aGF0IHRyYWZmaWMgKGFzIGxvbmcgYXMgdGhlcmUgaXMg YSBjbGVhciBkb21haW4gbGltaXQgZXhwcmVzc2VkIHRvIA0KPiBpT0FNIHByb3RvY29sIGRlc2ln bmVycyBvZiB0aGUgZnV0dXJlLCBhcyBGcmFuayBoYXMgc3VnZ2VzdGVkKS4NCj4gDQo+IFRoaXMg aXMgdGhlIHNhbWUgYWJpbGl0eSBhZmZvcmRlZCBvcGVyYXRvcnMgYnkgZGVjbGFyaW5nIEJNV0cg YWRkcmVzcyANCj4gc3BhY2UgZm9yIGlzb2xhdGVkIHRlc3Rpbmctb25seSwgb3IgdGhlIHZhcmlv dXMgcHJpdmF0ZSBuZXR3b3JrIA0KPiBhZGRyZXNzIHNwYWNlcy4gUGxlbnR5IG9mIE5ldDEwIHRy YWZmaWMgZXNjYXBlcywgYW5kIG9wZXJhdG9ycyBhcmUgbm90IA0KPiBvYmxpZ2VkIHRvIGRyb3Ag aXQsIGJ1dCB0aGV5IGNlcnRhaW5seSBjYW4uDQo+IA0KPj4gDQo+PiBJJ20gbm90IHN1cmUsIHdo ZXRoZXIgdGhpcyBpcyBhbiBJUFBNIGRpc2N1c3Npb24uIElzIHRoZXJlIGFueSBvdGhlciANCj4+ IElQUE0gcHJvdG9jb2wgb3IgcGFja2V0IGNvbnRlbnQgcmVxdWlyaW5nIGEgZGlzY2FyZCBvZiB0 cmFmZmljIGF0IGEgDQo+PiBkb21haW4gYm91bmRhcnk/DQo+PiANCj4+IFJlZ2FyZHMsDQo+PiAN Cj4+IFJ1ZWRpZ2VyDQo+PiANCj4+IA0KPj4gW0FDTV0NCj4+IA0KPj4gSU9NLCB0aGVyZSBpcyBh IGdlbmVyYWwgbWVzc2FnZSB0byBjb252ZXkgZm9yIGFsbCBmdXR1cmUgcHJvdG9jb2wgDQo+PiBk ZXZlbG9wbWVudC4gU29tZXRoaW5nIGxpa2UgInN1ZmZpY2llbnQgcHJvdmlzaW9ucyBzaG91bGQg YmUgbWFkZSB0byANCj4+IHJlc3RyaWN0IHRoZSBpT0FNIHRyYWZmaWMgdG8gdGhlIGludGVuZGVk IGRvbWFpbi4iDQo+PiANCj4+IFdlIGNvdWxkIHByb3ZpZGUgZ3VpZGFuY2UgdG8gaW50ZXJjb25u ZWN0aW5nIG5ldHdvcmsgb3BlcmF0b3JzLCBhcyANCj4+IHdlbGwsIGVmZmVjdGl2ZWx5IGFsbG93 aW5nIHRoZW0gdG8gZGlzY2FyZCB0cmFmZmljIGNvbnRhaW5pbmcgDQo+PiB1bmV4cGVjdGVkIGlP QU0gZGF0YS4gVGhpcyB3b3VsZCBiZSBhcHBsaWNhYmxlIHRvIG5vbi1pT0FNIG5ldHdvcmsgDQo+ PiBvcGVyYXRvcnMsIGJ1dCBtaWdodCBiZSBtb3JlIGltcG9ydGFudCBmb3IgaW50ZXJjb25uZWN0 aW5nIG9wZXJhdG9ycyANCj4+IHdobyBoYXZlIGVzdGFibGlzaGVkIHRoZWlyIG93biBpT0FNIGRv bWFpbi4NCj4+IA0KPj4gVGhpcyBpcyBzaW1pbGFyIHRvIHRoZSBhcHByb2FjaCB3ZSB1c2VkIGZv ciBCTVdHIHRlc3QgdHJhZmZpYzoNCj4+IHRoZXJlIGFyZSB2NCBhbmQgdjYgYWRkcmVzcyBzcGFj ZXMgZGVkaWNhdGVkIGZvciBpc29sYXRlZCB0ZXN0IA0KPj4gZW52aXJvbm1lbnRzLCBhbmQgYW55 IHBhY2tldCB3aXRoIHRlc3RpbmcgYWRkcmVzc2VzIG9ic2VydmVkIG9uIHRoZSANCj4+IEludGVy bmV0IG1heSBiZSBkaXNjYXJkZWQuDQo+PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlwcG1AaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoNCg== From nobody Thu Apr 27 08:45:47 2017 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 A7AD5126C7B; Thu, 27 Apr 2017 08:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 tCU2jlOlR6Gu; Thu, 27 Apr 2017 08:45:44 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79B81293D6; Thu, 27 Apr 2017 08:44:12 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3RFi4B2011359; Thu, 27 Apr 2017 16:44:04 +0100 Received: from 950129200 ([218.94.158.242]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3RFhrNS011217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Apr 2017 16:44:00 +0100 Reply-To: From: "Adrian Farrel" To: , Cc: , , References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B! 309F97543CF25F71AE7@njm texg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> <9C575ED7-E248-4D6D-855A-2F20926709DF@cisco.com> <39f70adc5ad34581bf83b0e9c48dd50a@HE101653.emea1.cds.t-internal.com> In-Reply-To: <39f70adc5ad34581bf83b0e9c48dd50a@HE101653.emea1.cds.t-internal.com> Date: Thu, 27 Apr 2017 16:43:52 +0100 Message-ID: <00b001d2bf6d$18351c40$489f54c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3Ooq+i0V2uDTKsntzdbDryWnJDQIGbTuQAhzFMcMCAqiNpgJZUHRiAczg8HQCom8n2QGF54TAAb4MqMABFXUytwGaPkqGAuvO8TYDDF8SAQGwfxGGArM0lpYBJhUk1wHmYm5WAY6WDkABuHd+WwEMCmhDAoFTES0Bw8dCN5/JT1Jg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23034.007 X-TM-AS-Result: No--30.724-10.0-31-10 X-imss-scan-details: No--30.724-10.0-31-10 X-TMASE-MatchedRID: z5DqD3Ob670Qaipp+dGzb37siEtWY367t3aeg7g/usAUsxngDoycC8Wg mIw8xvFeht1c+QVuyJmx8nm8pl676AHYCNT1xjfzLi5PDX0qWHoLTBRg82kMWt9RlPzeVuQQDnr wC+Ypv2rRDY8q4BVKbjRy0OKJ/UfsdLTHjoswkhrkubfAiR2pY5J4wTGO4igS2e73tJcoE9hLOU ja9PDjm9pPbWtTekK0zgkbICeA85ESk0DRfI0qvkNdLGoEdvhBH181YDtIVaoNht78/JfyBMvSO FlVWsCb5RlEVaicFdu0Bgm0CXGm5qz2iVjIPqfDE0Q83A2vD+u+JGWINXafLGtfrDMzRAX0NSLa tMg7EYYA0rZU8f2W+Lfhr7mD6KG8GBntNyPrRBuaVoAi2I40/fa/bRHEsPI3tWFMPVR2CrxMAHV bmze1TtzoKZ50+DkssVF8oHsRlBoXwXUmM6vIafSG/+sPtZVk0Wobj8GkNVrI9BHsOEzeNnO2Er lYRgFIq+c3NkYTYQUszsjWloLR+E6XZTso/wr5nbUZkYTzXIb66wd4gAR1X1vo8FSqar5S7JUz5 4b1aJ+56iSfTQ85B2JgDPyg9qz4YWo9dIuk10BCvapcIkxJX3WT6A/Vdqa0myiLZetSf8my5/tF Zu9S3Ku6xVHLhqfxvECLuM+h4RB+3BndfXUhXQ== Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 27 Apr 2017 15:45:47 -0000 That's nice R=C3=BCdiger, Although too many "designers" in the text. Adrian > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of > Ruediger.Geib@telekom.de > Sent: 27 April 2017 14:56 > To: cpignata@cisco.com > Cc: ippm-chairs@ietf.org; acmorton@att.com; ippm@ietf.org > Subject: Re: [ippm] Vote at IPPM session >=20 > Hi Carlos, >=20 > Let me pick up Frank's proposal: >=20 > OLD > "Designers of carrier protocols for IOAM designers must consider to = put > mechanisms in place to ensure that in-situ OAM data stays within an = IOAM > domain.." >=20 > NEW > "Designers of carrier protocols for IOAM designers must specify = mechanisms to > ensure that in-situ OAM data stays within an IOAM domain.." >=20 > I don't object that the operator is involved. But the operators task = to me should > be to turn an "in-situ OAM configuration knob" to solve the problem. = This knob > must be delivered by the protocol developers. "Consider" to me as a = non-native > speaker sounds like "think about and if it's getting complex, doing = nothing is a > valid option". >=20 > As mentioned earlier, relying on a firewall to me is an option I'd = like to avoid. >=20 > Regards, >=20 > Ruediger >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Gesendet: Sonntag, 23. April 2017 13:44 > An: Al Morton > Cc: Geib, R=C3=BCdiger; ippm-chairs@ietf.org; ippm@ietf.org > Betreff: Re: [ippm] Vote at IPPM session >=20 > Hi, >=20 > This is a very useful discussion =E2=80=94 although on the tail-end = seems to be diverging > from the original goal. I suggest that we should probably not take = this discussion > into all inter-domain permutations. >=20 > In other words, is there some case that the original text does not = cover? The text > includes =E2=80=9Cmechanisms in place to ensure that in-situ OAM data = stays within an > IOAM domain=E2=80=9D and =E2=80=9Cprovisions in place to ensure that = IOAM data does not leak > beyond the edge of an IOAM domain=E2=80=9D. >=20 > The idea is that an IOAM Domain should take care of considerations = because of > e.g., increased packet sizes within its domain, and prevent leakage. >=20 > In many deployments, the latter (i.e., "ensuring that iOAM data stays = within the > domain, and does not leak beyond the exit edge=E2=80=9D) would be a = natural > characteristic of the encapsulation. For example, when using IOAM with = NSH, an > IOAM domain would be an SFC domain, and thus removing NSH encap will = also > ensure IOAM does not leak. Same with VxLAN-GPE, etc. >=20 > But net-net, I=E2=80=99d recommend we define the IOAM domain behavior = and not all > other possible views. >=20 > Thanks! >=20 > =E2=80=94 Carlos. >=20 > > On Apr 19, 2017, at 4:02 PM, MORTON, ALFRED C (AL) = > wrote: > > > > Hi R=C3=BCdiger, > > short reply in-line, > > Al > > > >> -----Original Message----- > >> From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > >> Sent: Wednesday, April 19, 2017 3:15 AM > >> To: MORTON, ALFRED C (AL) > >> Cc: ippm-chairs@ietf.org; ippm@ietf.org; ietf@trammell.ch; > >> fbrockne@cisco.com > >> Subject: AW: [ippm] Vote at IPPM session > >> > >> Hi Al, > >> > >> is a non-iOAM network operator able to detect standard ipv6 packets > >> with iOAM extensions, if the receiving operators equipment is > >> configured to support standard ipv6 protocol only? The = pre-condition > >> here is "non-iOAM domain" at the receiving side. My point is, if a > >> domain isn't interested in supporting the iOAM extensions, is it > >> obliged to operate iOAM aware equipment to detect undesired traffic = at > network boundaries? > > [ACM] > > No, an operator can let the traffic flow if they want. > > However, if operators find that their network is affected by traffic > > with iOAM data from another domain, they would be justified to = discard > > that traffic (as long as there is a clear domain limit expressed to > > iOAM protocol designers of the future, as Frank has suggested). > > > > This is the same ability afforded operators by declaring BMWG = address > > space for isolated testing-only, or the various private network > > address spaces. Plenty of Net10 traffic escapes, and operators are = not > > obliged to drop it, but they certainly can. > > > >> > >> I'm not sure, whether this is an IPPM discussion. Is there any = other > >> IPPM protocol or packet content requiring a discard of traffic at a > >> domain boundary? > >> > >> Regards, > >> > >> Ruediger > >> > >> > >> [ACM] > >> > >> IOM, there is a general message to convey for all future protocol > >> development. Something like "sufficient provisions should be made = to > >> restrict the iOAM traffic to the intended domain." > >> > >> We could provide guidance to interconnecting network operators, as > >> well, effectively allowing them to discard traffic containing > >> unexpected iOAM data. This would be applicable to non-iOAM network > >> operators, but might be more important for interconnecting = operators > >> who have established their own iOAM domain. > >> > >> This is similar to the approach we used for BMWG test traffic: > >> there are v4 and v6 address spaces dedicated for isolated test > >> environments, and any packet with testing addresses observed on the > >> Internet may be discarded. > >> > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Thu Apr 27 10:02:15 2017 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 BEECE129687; Thu, 27 Apr 2017 10:02:13 -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 ns7JqKUTe1fL; Thu, 27 Apr 2017 10:02:09 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F06126DEE; Thu, 27 Apr 2017 09:59:40 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id k87so28303815ioi.0; Thu, 27 Apr 2017 09:59:40 -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=uN0K45chGWr9EG/F7OojOQxD1edWTts3Ql6CBSVUxd4=; b=Ul319sD9kJTU1+xnNK2Hh58gV1JlPFmpoCM7nBOehhJJBSgIPzlnRQ+pVT9TBkNX8u P4pAhzYdjlvW8rk7CgC+pBPoOROyH37L4TJtXpnJzldGyJewqlCnQidOhCpA6WZGB62h QIka1gnx7xEnFFTMGy6SrVj9nsO0vxmGw7cQsMAE/CtyA/idzXBgjQIpvY0NE1AHoHCK nLI9x9Y/Jr29nFiOoFhPFXb00RfBTa3rpoR+0dIIBh/SL64FiIGe9wDW/iA/UWGjjypT sLKt2ipzVsaHfSqHPaiF7pEZw7CblA5MCQA1lZ5UYKYkqdZA3FoSEzrZaZKUiH7rM51D QqRg== 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=uN0K45chGWr9EG/F7OojOQxD1edWTts3Ql6CBSVUxd4=; b=X1G2Bhez7M6p0LkJLChyQBLeZlmuBg4PkzHGDWv0CDogxa9gEDOqcQj47nFjt9YlMZ HGOCSRpOIvSJhC3eNfL03kGOA2RJqddRe4eVhcnWvJ/D06gJC08vK3GPGTTh6SGi5E6l ZOjcL13uuPSxvBMh48iVk/pF3FGWj6TJOVngbJ3ENQU5pxOuFOPnOsRu7fIbcVu2FSO4 alF+4MRO5oY6ZEGklAjiTiJxsugixddZMuzjWqHh/yETitpeJlHRAx5Fk5AVeoJuBfHN 0l4ZhpFsW4Bo50aVVwwcrxJLFNYrF38Fi1EAyTW4sq5DQkr6FzSQ0m/gIXN+6n/EA/RC rkjg== X-Gm-Message-State: AN3rC/5lo6E1+7q3aDt4I0I/EEIczrqTW1kO7gsNHVYS9KJ+kruHXaRD IbkEbJgQ7abtdc5zxMBKNQWkq+Wvyg== X-Received: by 10.157.47.70 with SMTP id h64mr2775086otb.23.1493312379048; Thu, 27 Apr 2017 09:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.118 with HTTP; Thu, 27 Apr 2017 09:59:38 -0700 (PDT) In-Reply-To: <055001d2bf46$25747210$705d5630$@olddog.co.uk> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <1FCCBA3C-4553-4310-974B-3002A983BE7A@cisco.com> <055001d2bf46$25747210$705d5630$@olddog.co.uk> From: Greg Mirsky Date: Thu, 27 Apr 2017 09:59:38 -0700 Message-ID: To: Adrian Farrel Cc: "Carlos Pignataro (cpignata)" , IPPM Chairs , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c047138e45aed054e28e170 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 27 Apr 2017 17:02:14 -0000 --94eb2c047138e45aed054e28e170 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian, per my understanding WG adoption call is to answer three basic questions: - is the document reasonably readable; - does it solve outstanding operational problem, i.e. yet unaddressed or operationally burdensome scenario; - is the document technically sound. I certainly say 'yes' to #1. I cannot say 'yes' neither on # 2, nor on #3: - On #2. It appears to me that we're discussing what iOAM does and what it should not do even though the stated scope of the document is the dat= a types, not the mechanism of the protocol itself. Does that indicate that the scope is not yet clearly defined? And if the mechanism of in-situ OA= M is in scope of the document, then I cannot find clear statement of the problem(s) it solves or was intended to solve. If anyone can help me wit= h the answer, would be much obliged. - On #3. References to non-existent "out-of-band OAM" don't make the document technically sound, rather contrary to that. As the allusion tha= t active OAM is inherently out-of-band and thus active OAM methods are not suitable to address needs of network operators. Regards, Greg On Thu, Apr 27, 2017 at 4:05 AM, Adrian Farrel wrote: > Carlos is right, but we got to this discussion because after Frank spoke > in Chicago there were a number of scoping questions that remained unclear > with possible misunderstandings and assumptions. > > > > It should be clear from the email exchanges on this list so far that the > type of solution we develop will be considerably dependent on the scope o= f > the problem. > > > > I don't believe we (well, not me anyway) are calling for a detailed > requirements document. Not even a problem statement document. But we do > need a clear scoping statement. > > > > As it happens, Frank has done some good work to address this with his new > text, and I think we are close to done. > > > > The only issue might be one of language. Saying "requirements" conveys > different meanings to different people. > > > > Probably the best way to ensure Greg's concerns are answered is for Greg > to ask specific targeted questions (such as, but not specifically, "Do yo= u > intend this technology to be used in kitchen appliances?"). Then Frank ca= n > suggest answers, others can chime in for consensus, and the result can be > briefly captured in the document. > > > > Ciao, > > Adrian > > > > *From:* Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > *Sent:* 26 April 2017 15:21 > *To:* Greg Mirsky > *Cc:* Adrian Farrel; IPPM Chairs; ippm@ietf.org > > *Subject:* Re: [ippm] Vote at IPPM session > > > > Greg, > > > > I agree that a shared understanding and alignment on the problem space is > critically important. My understanding is that we have already been doing > that extensively, including the work on potential charter text discussed = in > Opsawg. That was, for example, a discussion solely about the problem to b= e > solved. > > > > What concerns me is the strict serialization and waterfall you seem to be > advocating for. > > > > =E2=80=94 Carlos. > > > > On Apr 26, 2017, at 9:22 AM, Greg Mirsky wrote: > > > > Dear Carlos, > > thank you for the reference. > > I've never called for perfecting but for rough consensus on what problem > we need to address. How, IMHO, is secondary. And that is what may be not > working in this discussion - we've been presented answer to how do > measurement before we have reached an agreement that there's a problem to > be solved. > > > > Regards, > > Greg > > > > On Wed, Apr 26, 2017 at 6:13 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > > Dear Greg, > > > > Something like https://tools.ietf.org/html/dr > aft-brockners-inband-oam-requirements-03? > > > > For the record, my opinion: perfecting requirements is perhaps not the > best use of WG cycles. However, placing requirements as a serialized > requisite before progressing protocol work is certainly harmful in this > case. > > > > Thanks, > > > > -- Carlos. > > > > *From: *ippm on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Wednesday, April 26, 2017 at 5:22 AM > *To: *Adrian Farrel > *Cc: *IPPM Chairs , "ippm@ietf.org" > *Subject: *Re: [ippm] Vote at IPPM session > > > > Hi Adrian, et. al, > > I strongly believe that having agreed upon list of requirements that > answer questions What? and Where? rather than How? is the most beneficial > and not only for the discussion of applicability of in-situ OAM. What nee= ds > to be solved, measured that is not ameasureable by already existing OAM > methods? I think that if we can compile such list, then it will be more > clear what value may be added by developing new hybrid OAM method. > > > > Regards, > > Greg > > > > On Wed, Mar 29, 2017 at 2:32 PM, Adrian Farrel > wrote: > > > > There were several questions related to scope and applicability in th= e > WG > > discussion =E2=80=93 and even more recently on the list. Those can easi= ly be > addressed by > > adding paragraph on applicability to draft-brockners-inband-oam-data = =E2=80=93 > there > > isn=E2=80=99t a need for a dedicated requirements document. > > > > I tend to agree with this, although "a paragraph" seems a little thin t= o > me. I think > > there were some valid points made in that discussion about the scope of > the > > proposal that should be addressed: is IOAM meant for use > tunnel-end-to-tunnel- > > end environment, end-host-to-end-host, within a single network and/or > across > > the Internet. What I would suggest is adding a section to the data > model draft on > > applicability and assumptions about the environment -- both about the > devices > > adding IOAM signals to traffic as well as those consuming these signals > from the > > wire and analyzing them (possibly with the cooperation of devices not o= n > the > > wire) -- submitting a new revision, and we can run a more formal > adoption call on > > that. > > Although I was one of the people raising the "need" for the scope and > requirements, I don't have a strong leading on whether this needs to be i= n > a separate document on folded into the data format document. So Brian's > proposal would work for me. > > Thus, I'd love to see this scoping text drafted and floated to the list a= s > an email or in a revision of the data format document. > > Cheers, > Adrian > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > --94eb2c047138e45aed054e28e170 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Adrian,
per my understanding WG adop= tion call is to answer three basic questions:
  • is the docu= ment reasonably readable;
  • does it solve outstanding operational pro= blem, i.e. yet unaddressed or operationally burdensome scenario;
  • is= the document technically sound.
I certainly say 'yes' to = #1. I cannot say 'yes' neither on # 2, nor on #3:
    On #2. It appears to me that we're discussing what iOAM does and what = it should not do even though the stated scope of the document is the data t= ypes, not the mechanism of the protocol itself. Does that indicate that the= scope is not yet clearly defined? And if the mechanism of in-situ OAM is i= n scope of the document, then I cannot find clear statement of the problem(= s) it solves or was intended to solve. If anyone can help me with the answe= r, would be much obliged.
  • On #3. References to non-existent "o= ut-of-band OAM" don't make the document technically sound, rather = contrary to that. As the allusion that active OAM is inherently out-of-band= and thus active OAM methods are not suitable to address needs of network o= perators.

Regards,
Greg

On = Thu, Apr 27, 2017 at 4:05 AM, Adrian Farrel <adrian@olddog.co.uk&g= t; wrote:

Carlos is right, but we got = to this discussion because after Frank spoke in Chicago there were a number= of scoping questions that remained unclear with possible misunderstandings= and assumptions.

=C2=A0

It should be cl= ear from the email exchanges on this list so far that the type of solution = we develop will be considerably dependent on the scope of the problem.

=C2=A0

I don't believe we (well, not me = anyway) are calling for a detailed requirements document. Not even a proble= m statement document. But we do need a clear scoping statement.

=C2=A0

=

As it happens, Frank has done some good work= to address this with his new text, and I think we are close to done.

=C2=A0

The only issue might be one of languag= e. Saying "requirements" conveys different meanings to different = people.

=C2= =A0

Probably the best way t= o ensure Greg's concerns are answered is for Greg to ask specific targe= ted questions (such as, but not specifically, "Do you intend this tech= nology to be used in kitchen appliances?"). Then Frank can suggest ans= wers, others can chime in for consensus, and the result can be briefly capt= ured in the document.

=C2=A0

Ciao,

Adrian

=C2=A0

From: Carlos = Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: 26 April 2017 15:21To: Greg Mirsky
Cc: Adrian Farrel; IPPM Chairs; ippm@ietf.org


Subject: Re: [ippm] Vote at IPPM session

=C2=A0

Greg, =

=C2=A0

I agree that a shared understandin= g and alignment on the problem space is critically important. My understand= ing is that we have already been doing that extensively, including the work= on potential charter text discussed in Opsawg. That was, for example, a di= scussion solely about the problem to be solved.

=C2=A0

<= div>

What concerns me is the strict serializati= on and waterfall you seem to be advocating for.

=C2=A0

<= div>

=E2=80=94 Carlos.

=

=C2=A0

On Apr 26, 2017, at 9:22 AM, Greg Mirsky <gregimirsky@gmail.com> w= rote:

=C2= =A0

Dear Carlos,

thank you for the = reference.=C2=A0

= I've never called for perfecting but for rough consensus on what = problem we need to address. How, IMHO, is secondary. And that is what may b= e not working in this discussion - we've been presented answer to how d= o measurement before we have reached an agreement that there's a proble= m to be solved.

<= span>=C2=A0

Regards,

G= reg

<= u>=C2=A0

On Wed, Apr= 26, 2017 at 6:13 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:=

Dear Greg,

=C2=A0

<= span lang=3D"EN-US" style=3D"font-size:11pt;font-family:calibri,sans-serif"= >Something like https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-03?

=C2=A0

For the = record, my opinion: perfecting requirements is perhaps not the best use of = WG cycles. However, placing requirements as a serialized requisite before p= rogressing protocol work is certainly harmful in this case.

=C2=A0=

Than= ks,

=C2=A0

-- Carlos.

=C2=A0<= /u>

From: ippm <ippm-bounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com><= br>Date: Wednesday, April 26, 2017 at 5:22 AM
To: Adrian F= arrel <adrian@o= lddog.co.uk>
Cc: IPPM Chairs <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
<= b>Subject: Re: [ippm] Vote at IPPM session<= u>

=C2=A0

Hi Adrian, et. al,

<= p class=3D"MsoNormal">I strongly believe that having a= greed upon list of requirements that answer questions What? and Where? rath= er than How? is the most beneficial and not only for the discussion of appl= icability of in-situ OAM. What needs to be solved, measured that is not ame= asureable by already existing OAM methods? I think that if we can compile s= uch list, then it will be more clear what value may be added by developing = new hybrid OAM method.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Mar 29, 2017 at 2:32 PM, Adrian Farrel <adrian@olddog.co.uk&= gt; wrote:

> > There were several questions related to scope an= d applicability in the WG
> discussion =E2=80=93 and even more recent= ly on the list. Those can easily be addressed by
> adding paragraph o= n applicability to draft-brockners-inband-oam-data =E2=80=93 there
= > isn=E2=80=99t a need for a dedicated requirements document.
>> I tend to agree with this, although "a paragraph" seems a l= ittle thin to me. I think
> there were some valid points made in that= discussion about the scope of the
> proposal that should be addresse= d: is IOAM meant for use tunnel-end-to-tunnel-
> end environment,=C2= =A0 end-host-to-end-host, within a single network and/or across
> the= Internet.=C2=A0 What I would suggest is adding a section to the data model= draft on
> applicability and assumptions about the environment -- bo= th about the devices
> adding IOAM signals to traffic as well as thos= e consuming these signals from the
> wire and analyzing them (possibl= y with the cooperation of devices not on the
> wire) -- submitting a = new revision, and we can run a more formal adoption call on
> that.
Although I was one of the people raising the "need" for the= scope and requirements, I don't have a strong leading on whether this = needs to be in a separate document on folded into the data format document.= So Brian's proposal would work for me.

Thus, I'd love to se= e this scoping text drafted and floated to the list as an email or in a rev= ision of the data format document.

Cheers,
Adrian

________= _______________________________________
ippm mailing list
ippm@ietf.org
https://w= ww.ietf.org/mailman/listinfo/ippm

=C2=A0=

=C2=A0

=C2=A0


--94eb2c047138e45aed054e28e170-- From nobody Thu Apr 27 10:23:13 2017 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 C1252129B84; Thu, 27 Apr 2017 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 U0CzjSZSOfj0; Thu, 27 Apr 2017 10:23:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D26129B8D; Thu, 27 Apr 2017 10:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49182; q=dns/txt; s=iport; t=1493313622; x=1494523222; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ty3v4kLzJcyiRkT9+1ZVZMvyXHxAP9kkUsJPGe+yWWc=; b=RFkZiZ2yky9hn0cIt5oSF2joBZ2gWDqN2Dt6O6JDihXXayYFdA8/LAv4 5+5Tz0VmvLr1ajOZACBXBmu7xY8+YxxIrv1gUacDh7TZOUMyw6jxSoBu9 caS/ApgtJsKXJxNmfGXvsLrKTBQdcjOECM7S8cmF0QTOfFJ7+BTPMyeL7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAQCrJwJZ/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYYEMB4NhihiRKSGIIo1KggwDIQEKhXgCGoQJPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUVAQEBAQIBAQEbBksLEAIBBgIRAwEBAQEgAQYDAgICHwYLFAkIAgQBD?= =?us-ascii?q?QUbiWoDDQgOj1ydYYImK4cFDYNHAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGVIF?= =?us-ascii?q?eKwuBWYELglOBXhEBPBaCUC6CMQWJQo0QhkM7AYcYhyeETIIChTeDZYZAixmJD?= =?us-ascii?q?QEfOH8LbxVEEgGGXXWGX4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,384,1488844800"; d="scan'208,217";a="238498596" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2017 17:20:21 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3RHKK61001889 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2017 17:20:21 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Apr 2017 13:20:20 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Thu, 27 Apr 2017 13:20:20 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky , Adrian Farrel CC: IPPM Chairs , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSqBXsR2UglBUivky7lwWMt8jJvaGsFiIAgABoVYCAABw3AIArNV0A///9mQCAAEV4AIAAEImAgAFbdwCAAGMVAP//wrmA Date: Thu, 27 Apr 2017 17:20:20 +0000 Message-ID: <9D3214A2-F6F6-4594-B656-A10B78AABC62@cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <1FCCBA3C-4553-4310-974B-3002A983BE7A@cisco.com> <055001d2bf46$25747210$705d5630$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.251.5] Content-Type: multipart/alternative; boundary="_000_9D3214A2F6F64594B656A10B78AABC62ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 27 Apr 2017 17:23:11 -0000 --_000_9D3214A2F6F64594B656A10B78AABC62ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KWW91IHNlZW0gdG8gYmUgcHJlc2VudGluZyBhIHBvc2l0aW9uIGFraW4g4oCcaGFs Zi1nbGFzcyBpcyBjb21wbGV0ZWx5IGVtcHR5IGFuZCBoYXMgYWJzb2x1dGVseSBub3RoaW5nIGlu IGl04oCdLCBvciDigJxpdCBpcyBlbXB0eSwgdGhhdCBnbGFzcywgb24gb25lIGhhZuKAnSDigJMg d2hpY2ggaXMgbW9yZSBwb2xhcml6ZWQgdGhhbiDigJx0aGUgZ2xhc3MgaXMgaGFsZiBlbXB0eeKA nS4NCg0KRm9yICMyLCBwbGVhc2UgcmVhZCB0aGUgdGhyZWFkcy4gQW5kIHRoZSBuZXcgdGV4dCBk aXNjdXNzZWQgb24gdGhpcyBsaXN0LCB3aGljaCBpcyBmb3J0aGNvbWluZyAoc28gYWxsb3cgZm9y IG1vcmUgKmNvbmNyZXRlKiBjb21tZW50cyBvbiB0aGUgdGV4dCBpdHNlbGYpLg0KSW4gdGhpcywg QWRyaWFuIGhhcyBhIGdyZWF0IHN1Z2dlc3Rpb246IHBvaW50ZWQsIHRhcmdldGVkLCBuYXJyb3ct c2NvcGVkIGFuZCBleHBsaWNpdCBxdWVzdGlvbnMgYXJlIG1vcmUgdXNlZnVsLg0KDQpGb3IgIzMs IGlmIHlvdXIgY29uY2VybiB0aGF0IGFtb3VudHMgdG8gdGVjaG5pY2FsIHVuc291bmRuZXNzIGlz IHRoZSA0IGluc3RhbmNlcyBvZiDigJxvdXQtb2YtYmFuZOKAnSwgc2VlbXMgbGlrZSBhbiBlYXN5 IHRoaW5nIHRvIHJlc29sdmUuDQoNClRoYW5rcyENCg0KLS0gQ2FybG9zLg0KDQpGcm9tOiBHcmVn IE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0KRGF0ZTogVGh1cnNkYXksIEFwcmlsIDI3 LCAyMDE3IGF0IDEyOjU5IFBNDQpUbzogQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51 az4NCkNjOiBDYXJsb3MgUGlnbmF0YXJvIDxjcGlnbmF0YUBjaXNjby5jb20+LCBJUFBNIENoYWly cyA8aXBwbS1jaGFpcnNAaWV0Zi5vcmc+LCAiaXBwbUBpZXRmLm9yZyIgPGlwcG1AaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uDQoNCg0KSGkgQWRyaWFu LA0KcGVyIG15IHVuZGVyc3RhbmRpbmcgV0cgYWRvcHRpb24gY2FsbCBpcyB0byBhbnN3ZXIgdGhy ZWUgYmFzaWMgcXVlc3Rpb25zOg0KDQogICogICBpcyB0aGUgZG9jdW1lbnQgcmVhc29uYWJseSBy ZWFkYWJsZTsNCiAgKiAgIGRvZXMgaXQgc29sdmUgb3V0c3RhbmRpbmcgb3BlcmF0aW9uYWwgcHJv YmxlbSwgaS5lLiB5ZXQgdW5hZGRyZXNzZWQgb3Igb3BlcmF0aW9uYWxseSBidXJkZW5zb21lIHNj ZW5hcmlvOw0KICAqICAgaXMgdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5kLg0KSSBjZXJ0 YWlubHkgc2F5ICd5ZXMnIHRvICMxLiBJIGNhbm5vdCBzYXkgJ3llcycgbmVpdGhlciBvbiAjIDIs IG5vciBvbiAjMzoNCg0KICAqICAgT24gIzIuIEl0IGFwcGVhcnMgdG8gbWUgdGhhdCB3ZSdyZSBk aXNjdXNzaW5nIHdoYXQgaU9BTSBkb2VzIGFuZCB3aGF0IGl0IHNob3VsZCBub3QgZG8gZXZlbiB0 aG91Z2ggdGhlIHN0YXRlZCBzY29wZSBvZiB0aGUgZG9jdW1lbnQgaXMgdGhlIGRhdGEgdHlwZXMs IG5vdCB0aGUgbWVjaGFuaXNtIG9mIHRoZSBwcm90b2NvbCBpdHNlbGYuIERvZXMgdGhhdCBpbmRp Y2F0ZSB0aGF0IHRoZSBzY29wZSBpcyBub3QgeWV0IGNsZWFybHkgZGVmaW5lZD8gQW5kIGlmIHRo ZSBtZWNoYW5pc20gb2YgaW4tc2l0dSBPQU0gaXMgaW4gc2NvcGUgb2YgdGhlIGRvY3VtZW50LCB0 aGVuIEkgY2Fubm90IGZpbmQgY2xlYXIgc3RhdGVtZW50IG9mIHRoZSBwcm9ibGVtKHMpIGl0IHNv bHZlcyBvciB3YXMgaW50ZW5kZWQgdG8gc29sdmUuIElmIGFueW9uZSBjYW4gaGVscCBtZSB3aXRo IHRoZSBhbnN3ZXIsIHdvdWxkIGJlIG11Y2ggb2JsaWdlZC4NCiAgKiAgIE9uICMzLiBSZWZlcmVu Y2VzIHRvIG5vbi1leGlzdGVudCAib3V0LW9mLWJhbmQgT0FNIiBkb24ndCBtYWtlIHRoZSBkb2N1 bWVudCB0ZWNobmljYWxseSBzb3VuZCwgcmF0aGVyIGNvbnRyYXJ5IHRvIHRoYXQuIEFzIHRoZSBh bGx1c2lvbiB0aGF0IGFjdGl2ZSBPQU0gaXMgaW5oZXJlbnRseSBvdXQtb2YtYmFuZCBhbmQgdGh1 cyBhY3RpdmUgT0FNIG1ldGhvZHMgYXJlIG5vdCBzdWl0YWJsZSB0byBhZGRyZXNzIG5lZWRzIG9m IG5ldHdvcmsgb3BlcmF0b3JzLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBUaHUsIEFwciAyNywg MjAxNyBhdCA0OjA1IEFNLCBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0 bzphZHJpYW5Ab2xkZG9nLmNvLnVrPj4gd3JvdGU6DQpDYXJsb3MgaXMgcmlnaHQsIGJ1dCB3ZSBn b3QgdG8gdGhpcyBkaXNjdXNzaW9uIGJlY2F1c2UgYWZ0ZXIgRnJhbmsgc3Bva2UgaW4gQ2hpY2Fn byB0aGVyZSB3ZXJlIGEgbnVtYmVyIG9mIHNjb3BpbmcgcXVlc3Rpb25zIHRoYXQgcmVtYWluZWQg dW5jbGVhciB3aXRoIHBvc3NpYmxlIG1pc3VuZGVyc3RhbmRpbmdzIGFuZCBhc3N1bXB0aW9ucy4N Cg0KSXQgc2hvdWxkIGJlIGNsZWFyIGZyb20gdGhlIGVtYWlsIGV4Y2hhbmdlcyBvbiB0aGlzIGxp c3Qgc28gZmFyIHRoYXQgdGhlIHR5cGUgb2Ygc29sdXRpb24gd2UgZGV2ZWxvcCB3aWxsIGJlIGNv bnNpZGVyYWJseSBkZXBlbmRlbnQgb24gdGhlIHNjb3BlIG9mIHRoZSBwcm9ibGVtLg0KDQpJIGRv bid0IGJlbGlldmUgd2UgKHdlbGwsIG5vdCBtZSBhbnl3YXkpIGFyZSBjYWxsaW5nIGZvciBhIGRl dGFpbGVkIHJlcXVpcmVtZW50cyBkb2N1bWVudC4gTm90IGV2ZW4gYSBwcm9ibGVtIHN0YXRlbWVu dCBkb2N1bWVudC4gQnV0IHdlIGRvIG5lZWQgYSBjbGVhciBzY29waW5nIHN0YXRlbWVudC4NCg0K QXMgaXQgaGFwcGVucywgRnJhbmsgaGFzIGRvbmUgc29tZSBnb29kIHdvcmsgdG8gYWRkcmVzcyB0 aGlzIHdpdGggaGlzIG5ldyB0ZXh0LCBhbmQgSSB0aGluayB3ZSBhcmUgY2xvc2UgdG8gZG9uZS4N Cg0KVGhlIG9ubHkgaXNzdWUgbWlnaHQgYmUgb25lIG9mIGxhbmd1YWdlLiBTYXlpbmcgInJlcXVp cmVtZW50cyIgY29udmV5cyBkaWZmZXJlbnQgbWVhbmluZ3MgdG8gZGlmZmVyZW50IHBlb3BsZS4N Cg0KUHJvYmFibHkgdGhlIGJlc3Qgd2F5IHRvIGVuc3VyZSBHcmVnJ3MgY29uY2VybnMgYXJlIGFu c3dlcmVkIGlzIGZvciBHcmVnIHRvIGFzayBzcGVjaWZpYyB0YXJnZXRlZCBxdWVzdGlvbnMgKHN1 Y2ggYXMsIGJ1dCBub3Qgc3BlY2lmaWNhbGx5LCAiRG8geW91IGludGVuZCB0aGlzIHRlY2hub2xv Z3kgdG8gYmUgdXNlZCBpbiBraXRjaGVuIGFwcGxpYW5jZXM/IikuIFRoZW4gRnJhbmsgY2FuIHN1 Z2dlc3QgYW5zd2Vycywgb3RoZXJzIGNhbiBjaGltZSBpbiBmb3IgY29uc2Vuc3VzLCBhbmQgdGhl IHJlc3VsdCBjYW4gYmUgYnJpZWZseSBjYXB0dXJlZCBpbiB0aGUgZG9jdW1lbnQuDQoNCkNpYW8s DQpBZHJpYW4NCg0KRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3Bp Z25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+XQ0KU2VudDogMjYgQXBy aWwgMjAxNyAxNToyMQ0KVG86IEdyZWcgTWlyc2t5DQpDYzogQWRyaWFuIEZhcnJlbDsgSVBQTSBD aGFpcnM7IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJl OiBbaXBwbV0gVm90ZSBhdCBJUFBNIHNlc3Npb24NCg0KR3JlZywNCg0KSSBhZ3JlZSB0aGF0IGEg c2hhcmVkIHVuZGVyc3RhbmRpbmcgYW5kIGFsaWdubWVudCBvbiB0aGUgcHJvYmxlbSBzcGFjZSBp cyBjcml0aWNhbGx5IGltcG9ydGFudC4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHdlIGhhdmUg YWxyZWFkeSBiZWVuIGRvaW5nIHRoYXQgZXh0ZW5zaXZlbHksIGluY2x1ZGluZyB0aGUgd29yayBv biBwb3RlbnRpYWwgY2hhcnRlciB0ZXh0IGRpc2N1c3NlZCBpbiBPcHNhd2cuIFRoYXQgd2FzLCBm b3IgZXhhbXBsZSwgYSBkaXNjdXNzaW9uIHNvbGVseSBhYm91dCB0aGUgcHJvYmxlbSB0byBiZSBz b2x2ZWQuDQoNCldoYXQgY29uY2VybnMgbWUgaXMgdGhlIHN0cmljdCBzZXJpYWxpemF0aW9uIGFu ZCB3YXRlcmZhbGwgeW91IHNlZW0gdG8gYmUgYWR2b2NhdGluZyBmb3IuDQoNCuKAlCBDYXJsb3Mu DQoNCk9uIEFwciAyNiwgMjAxNywgYXQgOToyMiBBTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5 QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkRlYXIg Q2FybG9zLA0KdGhhbmsgeW91IGZvciB0aGUgcmVmZXJlbmNlLg0KSSd2ZSBuZXZlciBjYWxsZWQg Zm9yIHBlcmZlY3RpbmcgYnV0IGZvciByb3VnaCBjb25zZW5zdXMgb24gd2hhdCBwcm9ibGVtIHdl IG5lZWQgdG8gYWRkcmVzcy4gSG93LCBJTUhPLCBpcyBzZWNvbmRhcnkuIEFuZCB0aGF0IGlzIHdo YXQgbWF5IGJlIG5vdCB3b3JraW5nIGluIHRoaXMgZGlzY3Vzc2lvbiAtIHdlJ3ZlIGJlZW4gcHJl c2VudGVkIGFuc3dlciB0byBob3cgZG8gbWVhc3VyZW1lbnQgYmVmb3JlIHdlIGhhdmUgcmVhY2hl ZCBhbiBhZ3JlZW1lbnQgdGhhdCB0aGVyZSdzIGEgcHJvYmxlbSB0byBiZSBzb2x2ZWQuDQoNClJl Z2FyZHMsDQpHcmVnDQoNCk9uIFdlZCwgQXByIDI2LCAyMDE3IGF0IDY6MTMgQU0sIENhcmxvcyBQ aWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBj aXNjby5jb20+PiB3cm90ZToNCkRlYXIgR3JlZywNCg0KU29tZXRoaW5nIGxpa2UgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLXJlcXVpcmVtZW50 cy0wMz8NCg0KRm9yIHRoZSByZWNvcmQsIG15IG9waW5pb246IHBlcmZlY3RpbmcgcmVxdWlyZW1l bnRzIGlzIHBlcmhhcHMgbm90IHRoZSBiZXN0IHVzZSBvZiBXRyBjeWNsZXMuIEhvd2V2ZXIsIHBs YWNpbmcgcmVxdWlyZW1lbnRzIGFzIGEgc2VyaWFsaXplZCByZXF1aXNpdGUgYmVmb3JlIHByb2dy ZXNzaW5nIHByb3RvY29sIHdvcmsgaXMgY2VydGFpbmx5IGhhcm1mdWwgaW4gdGhpcyBjYXNlLg0K DQpUaGFua3MsDQoNCi0tIENhcmxvcy4NCg0KRnJvbTogaXBwbSA8aXBwbS1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgR3JlZyBNaXJz a3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4N CkRhdGU6IFdlZG5lc2RheSwgQXByaWwgMjYsIDIwMTcgYXQgNToyMiBBTQ0KVG86IEFkcmlhbiBG YXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+Pg0K Q2M6IElQUE0gQ2hhaXJzIDxpcHBtLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aXBwbS1jaGFpcnNA aWV0Zi5vcmc+PiwgImlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+IiA8aXBwbUBp ZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2lwcG1dIFZvdGUg YXQgSVBQTSBzZXNzaW9uDQoNCkhpIEFkcmlhbiwgZXQuIGFsLA0KSSBzdHJvbmdseSBiZWxpZXZl IHRoYXQgaGF2aW5nIGFncmVlZCB1cG9uIGxpc3Qgb2YgcmVxdWlyZW1lbnRzIHRoYXQgYW5zd2Vy IHF1ZXN0aW9ucyBXaGF0PyBhbmQgV2hlcmU/IHJhdGhlciB0aGFuIEhvdz8gaXMgdGhlIG1vc3Qg YmVuZWZpY2lhbCBhbmQgbm90IG9ubHkgZm9yIHRoZSBkaXNjdXNzaW9uIG9mIGFwcGxpY2FiaWxp dHkgb2YgaW4tc2l0dSBPQU0uIFdoYXQgbmVlZHMgdG8gYmUgc29sdmVkLCBtZWFzdXJlZCB0aGF0 IGlzIG5vdCBhbWVhc3VyZWFibGUgYnkgYWxyZWFkeSBleGlzdGluZyBPQU0gbWV0aG9kcz8gSSB0 aGluayB0aGF0IGlmIHdlIGNhbiBjb21waWxlIHN1Y2ggbGlzdCwgdGhlbiBpdCB3aWxsIGJlIG1v cmUgY2xlYXIgd2hhdCB2YWx1ZSBtYXkgYmUgYWRkZWQgYnkgZGV2ZWxvcGluZyBuZXcgaHlicmlk IE9BTSBtZXRob2QuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFdlZCwgTWFyIDI5LCAyMDE3IGF0 IDI6MzIgUE0sIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlh bkBvbGRkb2cuY28udWs+PiB3cm90ZToNCj4gPiBUaGVyZSB3ZXJlIHNldmVyYWwgcXVlc3Rpb25z IHJlbGF0ZWQgdG8gc2NvcGUgYW5kIGFwcGxpY2FiaWxpdHkgaW4gdGhlIFdHDQo+IGRpc2N1c3Np b24g4oCTIGFuZCBldmVuIG1vcmUgcmVjZW50bHkgb24gdGhlIGxpc3QuIFRob3NlIGNhbiBlYXNp bHkgYmUgYWRkcmVzc2VkIGJ5DQo+IGFkZGluZyBwYXJhZ3JhcGggb24gYXBwbGljYWJpbGl0eSB0 byBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhIOKAkyB0aGVyZQ0KPiBpc27igJl0IGEg bmVlZCBmb3IgYSBkZWRpY2F0ZWQgcmVxdWlyZW1lbnRzIGRvY3VtZW50Lg0KPg0KPiBJIHRlbmQg dG8gYWdyZWUgd2l0aCB0aGlzLCBhbHRob3VnaCAiYSBwYXJhZ3JhcGgiIHNlZW1zIGEgbGl0dGxl IHRoaW4gdG8gbWUuIEkgdGhpbmsNCj4gdGhlcmUgd2VyZSBzb21lIHZhbGlkIHBvaW50cyBtYWRl IGluIHRoYXQgZGlzY3Vzc2lvbiBhYm91dCB0aGUgc2NvcGUgb2YgdGhlDQo+IHByb3Bvc2FsIHRo YXQgc2hvdWxkIGJlIGFkZHJlc3NlZDogaXMgSU9BTSBtZWFudCBmb3IgdXNlIHR1bm5lbC1lbmQt dG8tdHVubmVsLQ0KPiBlbmQgZW52aXJvbm1lbnQsICBlbmQtaG9zdC10by1lbmQtaG9zdCwgd2l0 aGluIGEgc2luZ2xlIG5ldHdvcmsgYW5kL29yIGFjcm9zcw0KPiB0aGUgSW50ZXJuZXQuICBXaGF0 IEkgd291bGQgc3VnZ2VzdCBpcyBhZGRpbmcgYSBzZWN0aW9uIHRvIHRoZSBkYXRhIG1vZGVsIGRy YWZ0IG9uDQo+IGFwcGxpY2FiaWxpdHkgYW5kIGFzc3VtcHRpb25zIGFib3V0IHRoZSBlbnZpcm9u bWVudCAtLSBib3RoIGFib3V0IHRoZSBkZXZpY2VzDQo+IGFkZGluZyBJT0FNIHNpZ25hbHMgdG8g dHJhZmZpYyBhcyB3ZWxsIGFzIHRob3NlIGNvbnN1bWluZyB0aGVzZSBzaWduYWxzIGZyb20gdGhl DQo+IHdpcmUgYW5kIGFuYWx5emluZyB0aGVtIChwb3NzaWJseSB3aXRoIHRoZSBjb29wZXJhdGlv biBvZiBkZXZpY2VzIG5vdCBvbiB0aGUNCj4gd2lyZSkgLS0gc3VibWl0dGluZyBhIG5ldyByZXZp c2lvbiwgYW5kIHdlIGNhbiBydW4gYSBtb3JlIGZvcm1hbCBhZG9wdGlvbiBjYWxsIG9uDQo+IHRo YXQuDQoNCkFsdGhvdWdoIEkgd2FzIG9uZSBvZiB0aGUgcGVvcGxlIHJhaXNpbmcgdGhlICJuZWVk IiBmb3IgdGhlIHNjb3BlIGFuZCByZXF1aXJlbWVudHMsIEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBs ZWFkaW5nIG9uIHdoZXRoZXIgdGhpcyBuZWVkcyB0byBiZSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50 IG9uIGZvbGRlZCBpbnRvIHRoZSBkYXRhIGZvcm1hdCBkb2N1bWVudC4gU28gQnJpYW4ncyBwcm9w b3NhbCB3b3VsZCB3b3JrIGZvciBtZS4NCg0KVGh1cywgSSdkIGxvdmUgdG8gc2VlIHRoaXMgc2Nv cGluZyB0ZXh0IGRyYWZ0ZWQgYW5kIGZsb2F0ZWQgdG8gdGhlIGxpc3QgYXMgYW4gZW1haWwgb3Ig aW4gYSByZXZpc2lvbiBvZiB0aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQuDQoNCkNoZWVycywNCkFk cmlhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K aXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0KDQoNCg0K --_000_9D3214A2F6F64594B656A10B78AABC62ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <51473E4621CED54EB3514965752AA782@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ill1IE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDQgMCAwIDAg MCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xv cjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjUxMDIxNzY5NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTgwNjQ5 NDU0O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMDU1Mzk3 MTc3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODYwMDQ1MTU2O30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5HcmVnLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPllvdSBzZWVt IHRvIGJlIHByZXNlbnRpbmcgYSBwb3NpdGlvbiBha2luIOKAnGhhbGYtZ2xhc3MgaXMgY29tcGxl dGVseSBlbXB0eSBhbmQgaGFzIGFic29sdXRlbHkgbm90aGluZyBpbiBpdOKAnSwgb3Ig4oCcaXQg aXMgZW1wdHksIHRoYXQgZ2xhc3MsIG9uIG9uZSBoYWbigJ0g4oCTIHdoaWNoIGlzIG1vcmUgcG9s YXJpemVkIHRoYW4g4oCcdGhlDQogZ2xhc3MgaXMgaGFsZiBlbXB0eeKAnS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5Gb3IgIzIsIHBsZWFzZSByZWFkIHRoZSB0aHJlYWRzLiBBbmQgdGhlIG5l dyB0ZXh0IGRpc2N1c3NlZCBvbiB0aGlzIGxpc3QsIHdoaWNoIGlzIGZvcnRoY29taW5nIChzbyBh bGxvdyBmb3IgbW9yZSAqPGI+Y29uY3JldGU8L2I+KiBjb21tZW50cyBvbiB0aGUgdGV4dCBpdHNl bGYpLg0KPGJyPg0KSW4gdGhpcywgQWRyaWFuIGhhcyBhIGdyZWF0IHN1Z2dlc3Rpb246IHBvaW50 ZWQsIHRhcmdldGVkLCBuYXJyb3ctc2NvcGVkIGFuZCBleHBsaWNpdCBxdWVzdGlvbnMgYXJlIG1v cmUgdXNlZnVsLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPkZvciAjMywgaWYgeW91ciBjb25jZXJuIHRoYXQgYW1vdW50cyB0byB0ZWNobmljYWwgdW5z b3VuZG5lc3MgaXMgdGhlIDQgaW5zdGFuY2VzIG9mIOKAnG91dC1vZi1iYW5k4oCdLCBzZWVtcyBs aWtlIGFuIGVhc3kgdGhpbmcgdG8gcmVzb2x2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5U aGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+LS0gQ2FybG9zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkdyZWcgTWlyc2t5 ICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5 LCBBcHJpbCAyNywgMjAxNyBhdCAxMjo1OSBQTTxicj4NCjxiPlRvOiA8L2I+QWRyaWFuIEZhcnJl bCAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDs8YnI+DQo8Yj5DYzogPC9iPkNhcmxvcyBQaWdu YXRhcm8gJmx0O2NwaWduYXRhQGNpc2NvLmNvbSZndDssIElQUE0gQ2hhaXJzICZsdDtpcHBtLWNo YWlyc0BpZXRmLm9yZyZndDssICZxdW90O2lwcG1AaWV0Zi5vcmcmcXVvdDsgJmx0O2lwcG1AaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbaXBwbV0gVm90ZSBhdCBJUFBNIHNl c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgQWRyaWFuLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5wZXIgbXkgdW5kZXJzdGFuZGluZyBXRyBhZG9wdGlvbiBjYWxsIGlzIHRvIGFu c3dlciB0aHJlZSBiYXNpYyBxdWVzdGlvbnM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxl dmVsMSBsZm8xIj4NCmlzIHRoZSBkb2N1bWVudCByZWFzb25hYmx5IHJlYWRhYmxlOzxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4N CmRvZXMgaXQgc29sdmUgb3V0c3RhbmRpbmcgb3BlcmF0aW9uYWwgcHJvYmxlbSwgaS5lLiB5ZXQg dW5hZGRyZXNzZWQgb3Igb3BlcmF0aW9uYWxseSBidXJkZW5zb21lIHNjZW5hcmlvOzxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4N CmlzIHRoZSBkb2N1bWVudCB0ZWNobmljYWxseSBzb3VuZC48bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2VydGFpbmx5IHNheSAneWVzJyB0byAjMS4gSSBjYW5u b3Qgc2F5ICd5ZXMnIG5laXRoZXIgb24gIyAyLCBub3Igb24gIzM6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj4NCk9uICMyLiBJdCBhcHBlYXJzIHRvIG1lIHRoYXQgd2Un cmUgZGlzY3Vzc2luZyB3aGF0IGlPQU0gZG9lcyBhbmQgd2hhdCBpdCBzaG91bGQgbm90IGRvIGV2 ZW4gdGhvdWdoIHRoZSBzdGF0ZWQgc2NvcGUgb2YgdGhlIGRvY3VtZW50IGlzIHRoZSBkYXRhIHR5 cGVzLCBub3QgdGhlIG1lY2hhbmlzbSBvZiB0aGUgcHJvdG9jb2wgaXRzZWxmLiBEb2VzIHRoYXQg aW5kaWNhdGUgdGhhdCB0aGUgc2NvcGUgaXMgbm90IHlldCBjbGVhcmx5IGRlZmluZWQ/IEFuZA0K IGlmIHRoZSBtZWNoYW5pc20gb2YgaW4tc2l0dSBPQU0gaXMgaW4gc2NvcGUgb2YgdGhlIGRvY3Vt ZW50LCB0aGVuIEkgY2Fubm90IGZpbmQgY2xlYXIgc3RhdGVtZW50IG9mIHRoZSBwcm9ibGVtKHMp IGl0IHNvbHZlcyBvciB3YXMgaW50ZW5kZWQgdG8gc29sdmUuIElmIGFueW9uZSBjYW4gaGVscCBt ZSB3aXRoIHRoZSBhbnN3ZXIsIHdvdWxkIGJlIG11Y2ggb2JsaWdlZC48bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpPbiAjMy4g UmVmZXJlbmNlcyB0byBub24tZXhpc3RlbnQgJnF1b3Q7b3V0LW9mLWJhbmQgT0FNJnF1b3Q7IGRv bid0IG1ha2UgdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5kLCByYXRoZXIgY29udHJhcnkg dG8gdGhhdC4gQXMgdGhlIGFsbHVzaW9uIHRoYXQgYWN0aXZlIE9BTSBpcyBpbmhlcmVudGx5IG91 dC1vZi1iYW5kIGFuZCB0aHVzIGFjdGl2ZSBPQU0gbWV0aG9kcyBhcmUgbm90IHN1aXRhYmxlIHRv IGFkZHJlc3MgbmVlZHMgb2YgbmV0d29yayBvcGVyYXRvcnMuPG86cD48L286cD48L2xpPjwvdWw+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIEFwciAyNywgMjAxNyBhdCA0OjA1IEFNLCBBZHJpYW4gRmFycmVsICZsdDs8YSBocmVmPSJt YWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPmFkcmlhbkBvbGRkb2cu Y28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+Q2FybG9z IGlzIHJpZ2h0LCBidXQgd2UgZ290IHRvIHRoaXMgZGlzY3Vzc2lvbiBiZWNhdXNlIGFmdGVyIEZy YW5rIHNwb2tlIGluIENoaWNhZ28gdGhlcmUgd2VyZSBhIG51bWJlcg0KIG9mIHNjb3BpbmcgcXVl c3Rpb25zIHRoYXQgcmVtYWluZWQgdW5jbGVhciB3aXRoIHBvc3NpYmxlIG1pc3VuZGVyc3RhbmRp bmdzIGFuZCBhc3N1bXB0aW9ucy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPkl0IHNob3VsZCBiZSBj bGVhciBmcm9tIHRoZSBlbWFpbCBleGNoYW5nZXMgb24gdGhpcyBsaXN0IHNvIGZhciB0aGF0IHRo ZSB0eXBlIG9mIHNvbHV0aW9uIHdlIGRldmVsb3ANCiB3aWxsIGJlIGNvbnNpZGVyYWJseSBkZXBl bmRlbnQgb24gdGhlIHNjb3BlIG9mIHRoZSBwcm9ibGVtLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+ SSBkb24ndCBiZWxpZXZlIHdlICh3ZWxsLCBub3QgbWUgYW55d2F5KSBhcmUgY2FsbGluZyBmb3Ig YSBkZXRhaWxlZCByZXF1aXJlbWVudHMgZG9jdW1lbnQuIE5vdCBldmVuDQogYSBwcm9ibGVtIHN0 YXRlbWVudCBkb2N1bWVudC4gQnV0IHdlIGRvIG5lZWQgYSBjbGVhciBzY29waW5nIHN0YXRlbWVu dC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPkFzIGl0IGhhcHBlbnMsIEZyYW5rIGhhcyBkb25lIHNv bWUgZ29vZCB3b3JrIHRvIGFkZHJlc3MgdGhpcyB3aXRoIGhpcyBuZXcgdGV4dCwgYW5kIEkgdGhp bmsgd2UgYXJlDQogY2xvc2UgdG8gZG9uZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPlRoZSBvbmx5 IGlzc3VlIG1pZ2h0IGJlIG9uZSBvZiBsYW5ndWFnZS4gU2F5aW5nICZxdW90O3JlcXVpcmVtZW50 cyZxdW90OyBjb252ZXlzIGRpZmZlcmVudCBtZWFuaW5ncyB0byBkaWZmZXJlbnQNCiBwZW9wbGUu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5Qcm9iYWJseSB0aGUgYmVzdCB3YXkgdG8gZW5zdXJlIEdy ZWcncyBjb25jZXJucyBhcmUgYW5zd2VyZWQgaXMgZm9yIEdyZWcgdG8gYXNrIHNwZWNpZmljIHRh cmdldGVkIHF1ZXN0aW9ucw0KIChzdWNoIGFzLCBidXQgbm90IHNwZWNpZmljYWxseSwgJnF1b3Q7 RG8geW91IGludGVuZCB0aGlzIHRlY2hub2xvZ3kgdG8gYmUgdXNlZCBpbiBraXRjaGVuIGFwcGxp YW5jZXM/JnF1b3Q7KS4gVGhlbiBGcmFuayBjYW4gc3VnZ2VzdCBhbnN3ZXJzLCBvdGhlcnMgY2Fu IGNoaW1lIGluIGZvciBjb25zZW5zdXMsIGFuZCB0aGUgcmVzdWx0IGNhbiBiZSBicmllZmx5IGNh cHR1cmVkIGluIHRoZSBkb2N1bWVudC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPkNpYW8sPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPkFkcmlhbjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aTtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEiPiBDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+Y3BpZ25hdGFAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNl bnQ6PC9iPiAyNiBBcHJpbCAyMDE3IDE1OjIxPGJyPg0KPGI+VG86PC9iPiBHcmVnIE1pcnNreTxi cj4NCjxiPkNjOjwvYj4gQWRyaWFuIEZhcnJlbDsgSVBQTSBDaGFpcnM7IDxhIGhyZWY9Im1haWx0 bzppcHBtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQppcHBtQGlldGYub3JnPC9hPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbaXBwbV0gVm90ZSBhdCBJUFBNIHNlc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+R3JlZywN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGFncmVlIHRo YXQgYSBzaGFyZWQgdW5kZXJzdGFuZGluZyBhbmQgYWxpZ25tZW50IG9uIHRoZSBwcm9ibGVtIHNw YWNlIGlzIGNyaXRpY2FsbHkgaW1wb3J0YW50LiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgd2Ug aGF2ZSBhbHJlYWR5IGJlZW4gZG9pbmcgdGhhdCBleHRlbnNpdmVseSwNCiBpbmNsdWRpbmcgdGhl IHdvcmsgb24gcG90ZW50aWFsIGNoYXJ0ZXIgdGV4dCBkaXNjdXNzZWQgaW4gT3BzYXdnLiBUaGF0 IHdhcywgZm9yIGV4YW1wbGUsIGEgZGlzY3Vzc2lvbiBzb2xlbHkgYWJvdXQgdGhlIHByb2JsZW0g dG8gYmUgc29sdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiPldoYXQgY29uY2VybnMgbWUgaXMgdGhlIHN0cmljdCBzZXJpYWxpemF0aW9uIGFu ZCB3YXRlcmZhbGwgeW91IHNlZW0gdG8gYmUgYWR2b2NhdGluZyBmb3IuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+4oCUIENhcmxvcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gQXByIDI2 LCAyMDE3LCBhdCA5OjIyIEFNLCBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdp bWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC Ij5EZWFyIENhcmxvcywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj50aGFuayB5b3UgZm9yIHRoZSByZWZlcmVu Y2UuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+SSd2ZSBuZXZlciBjYWxsZWQgZm9yIHBl cmZlY3RpbmcgYnV0IGZvciByb3VnaCBjb25zZW5zdXMgb24gd2hhdCBwcm9ibGVtIHdlIG5lZWQg dG8gYWRkcmVzcy4gSG93LCBJTUhPLCBpcyBzZWNvbmRhcnkuIEFuZCB0aGF0IGlzIHdoYXQgbWF5 IGJlIG5vdCB3b3JraW5nIGluIHRoaXMNCiBkaXNjdXNzaW9uIC0gd2UndmUgYmVlbiBwcmVzZW50 ZWQgYW5zd2VyIHRvIGhvdyBkbyBtZWFzdXJlbWVudCBiZWZvcmUgd2UgaGF2ZSByZWFjaGVkIGFu IGFncmVlbWVudCB0aGF0IHRoZXJlJ3MgYSBwcm9ibGVtIHRvIGJlIHNvbHZlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiPkdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBXZWQsIEFwciAyNiwgMjAxNyBhdCA2OjEzIEFNLCBDYXJs b3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RGVh ciBHcmVnLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+U29tZXRoaW5nIGxpa2UNCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1y ZXF1aXJlbWVudHMtMDMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1yZXF1aXJlbWVudHMtMDM8L2E+PyA8L3Nw YW4+DQo8c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Rm9yIHRoZSByZWNvcmQsIG15IG9waW5pb246IHBlcmZl Y3RpbmcgcmVxdWlyZW1lbnRzIGlzIHBlcmhhcHMgbm90IHRoZSBiZXN0IHVzZSBvZiBXRyBjeWNs ZXMuIEhvd2V2ZXIsIHBsYWNpbmcgcmVxdWlyZW1lbnRzIGFzDQogYSBzZXJpYWxpemVkIHJlcXVp c2l0ZSBiZWZvcmUgcHJvZ3Jlc3NpbmcgcHJvdG9jb2wgd29yayBpcyBjZXJ0YWlubHkgaGFybWZ1 bCBpbiB0aGlzIGNhc2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MsPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4tLSBDYXJsb3MuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmkiPmlwcG0gJmx0OzxhIGhyZWY9Im1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pcHBtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgR3Jl ZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5XZWRuZXNkYXksIEFwcmlsIDI2LCAyMDE3IGF0IDU6MjIgQU08YnI+DQo8Yj5UbzogPC9iPkFk cmlhbiBGYXJyZWwgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0YXJn ZXQ9Il9ibGFuayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5J UFBNIENoYWlycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG0tY2hhaXJzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+aXBwbS1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHBtQGlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p cHBtQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtpcHBtXSBWb3Rl IGF0IElQUE0gc2Vzc2lvbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3Bh biBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5IaSBBZHJpYW4sIGV0LiBhbCwNCjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkkgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IGhhdmluZyBhZ3JlZWQgdXBvbiBs aXN0IG9mIHJlcXVpcmVtZW50cyB0aGF0IGFuc3dlciBxdWVzdGlvbnMgV2hhdD8gYW5kIFdoZXJl PyByYXRoZXIgdGhhbiBIb3c/IGlzIHRoZSBtb3N0IGJlbmVmaWNpYWwgYW5kIG5vdCBvbmx5IGZv ciB0aGUgZGlzY3Vzc2lvbiBvZg0KIGFwcGxpY2FiaWxpdHkgb2YgaW4tc2l0dSBPQU0uIFdoYXQg bmVlZHMgdG8gYmUgc29sdmVkLCBtZWFzdXJlZCB0aGF0IGlzIG5vdCBhbWVhc3VyZWFibGUgYnkg YWxyZWFkeSBleGlzdGluZyBPQU0gbWV0aG9kcz8gSSB0aGluayB0aGF0IGlmIHdlIGNhbiBjb21w aWxlIHN1Y2ggbGlzdCwgdGhlbiBpdCB3aWxsIGJlIG1vcmUgY2xlYXIgd2hhdCB2YWx1ZSBtYXkg YmUgYWRkZWQgYnkgZGV2ZWxvcGluZyBuZXcgaHlicmlkIE9BTSBtZXRob2QuPHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5HcmVnPHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBN YXIgMjksIDIwMTcgYXQgMjozMiBQTSwgQWRyaWFuIEZhcnJlbCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFkcmlhbkBvbGRkb2cuY28udWsiIHRhcmdldD0iX2JsYW5rIj5hZHJpYW5Ab2xkZG9nLmNvLnVr PC9hPiZndDsgd3JvdGU6PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mZ3Q7ICZndDsgVGhlcmUgd2VyZSBzZXZlcmFsIHF1ZXN0aW9ucyBy ZWxhdGVkIHRvIHNjb3BlIGFuZCBhcHBsaWNhYmlsaXR5IGluIHRoZSBXRzxicj4NCiZndDsgZGlz Y3Vzc2lvbiDigJMgYW5kIGV2ZW4gbW9yZSByZWNlbnRseSBvbiB0aGUgbGlzdC4gVGhvc2UgY2Fu IGVhc2lseSBiZSBhZGRyZXNzZWQgYnk8YnI+DQomZ3Q7IGFkZGluZyBwYXJhZ3JhcGggb24gYXBw bGljYWJpbGl0eSB0byBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhIOKAkyB0aGVyZTxi cj4NCiZndDsgaXNu4oCZdCBhIG5lZWQgZm9yIGEgZGVkaWNhdGVkIHJlcXVpcmVtZW50cyBkb2N1 bWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRlbmQgdG8gYWdyZWUgd2l0aCB0aGlzLCBhbHRo b3VnaCAmcXVvdDthIHBhcmFncmFwaCZxdW90OyBzZWVtcyBhIGxpdHRsZSB0aGluIHRvIG1lLiBJ IHRoaW5rPGJyPg0KJmd0OyB0aGVyZSB3ZXJlIHNvbWUgdmFsaWQgcG9pbnRzIG1hZGUgaW4gdGhh dCBkaXNjdXNzaW9uIGFib3V0IHRoZSBzY29wZSBvZiB0aGU8YnI+DQomZ3Q7IHByb3Bvc2FsIHRo YXQgc2hvdWxkIGJlIGFkZHJlc3NlZDogaXMgSU9BTSBtZWFudCBmb3IgdXNlIHR1bm5lbC1lbmQt dG8tdHVubmVsLTxicj4NCiZndDsgZW5kIGVudmlyb25tZW50LCZuYnNwOyBlbmQtaG9zdC10by1l bmQtaG9zdCwgd2l0aGluIGEgc2luZ2xlIG5ldHdvcmsgYW5kL29yIGFjcm9zczxicj4NCiZndDsg dGhlIEludGVybmV0LiZuYnNwOyBXaGF0IEkgd291bGQgc3VnZ2VzdCBpcyBhZGRpbmcgYSBzZWN0 aW9uIHRvIHRoZSBkYXRhIG1vZGVsIGRyYWZ0IG9uPGJyPg0KJmd0OyBhcHBsaWNhYmlsaXR5IGFu ZCBhc3N1bXB0aW9ucyBhYm91dCB0aGUgZW52aXJvbm1lbnQgLS0gYm90aCBhYm91dCB0aGUgZGV2 aWNlczxicj4NCiZndDsgYWRkaW5nIElPQU0gc2lnbmFscyB0byB0cmFmZmljIGFzIHdlbGwgYXMg dGhvc2UgY29uc3VtaW5nIHRoZXNlIHNpZ25hbHMgZnJvbSB0aGU8YnI+DQomZ3Q7IHdpcmUgYW5k IGFuYWx5emluZyB0aGVtIChwb3NzaWJseSB3aXRoIHRoZSBjb29wZXJhdGlvbiBvZiBkZXZpY2Vz IG5vdCBvbiB0aGU8YnI+DQomZ3Q7IHdpcmUpIC0tIHN1Ym1pdHRpbmcgYSBuZXcgcmV2aXNpb24s IGFuZCB3ZSBjYW4gcnVuIGEgbW9yZSBmb3JtYWwgYWRvcHRpb24gY2FsbCBvbjxicj4NCiZndDsg dGhhdC48YnI+DQo8YnI+DQpBbHRob3VnaCBJIHdhcyBvbmUgb2YgdGhlIHBlb3BsZSByYWlzaW5n IHRoZSAmcXVvdDtuZWVkJnF1b3Q7IGZvciB0aGUgc2NvcGUgYW5kIHJlcXVpcmVtZW50cywgSSBk b24ndCBoYXZlIGEgc3Ryb25nIGxlYWRpbmcgb24gd2hldGhlciB0aGlzIG5lZWRzIHRvIGJlIGlu IGEgc2VwYXJhdGUgZG9jdW1lbnQgb24gZm9sZGVkIGludG8gdGhlIGRhdGEgZm9ybWF0IGRvY3Vt ZW50LiBTbyBCcmlhbidzIHByb3Bvc2FsIHdvdWxkIHdvcmsgZm9yIG1lLjxicj4NCjxicj4NClRo dXMsIEknZCBsb3ZlIHRvIHNlZSB0aGlzIHNjb3BpbmcgdGV4dCBkcmFmdGVkIGFuZCBmbG9hdGVk IHRvIHRoZSBsaXN0IGFzIGFuIGVtYWlsIG9yIGluIGEgcmV2aXNpb24gb2YgdGhlIGRhdGEgZm9y bWF0IGRvY3VtZW50Ljxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpBZHJpYW48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmlwcG0g bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5pcHBtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwvYT48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9D3214A2F6F64594B656A10B78AABC62ciscocom_-- From nobody Thu Apr 27 21:04:20 2017 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 A975E129BC6 for ; Thu, 27 Apr 2017 21:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 002bCimsqULC for ; Thu, 27 Apr 2017 21:04:08 -0700 (PDT) Received: from nm30-vm1.bullet.mail.gq1.yahoo.com (nm30-vm1.bullet.mail.gq1.yahoo.com [98.136.216.192]) (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 87B03129BC7 for ; Thu, 27 Apr 2017 21:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493352100; bh=p0TdsH1TjFRnAYbHUufS2y3PUsKRn+YAFUZj5WfChlU=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=MqAZ+8EgpVumNGXs6kcdBgS5/x+WNJKYxaHZdqhM0QQjXn8DvUbhS3v6Rl6TrCYLsWofswjuJSG7cujzYD0i5UX9Xe+4kKJaLMhnH4y9oDix9Gfrzki3VCKpLG3y5ERMKBjAkyk0D1zAW6kTF9C2Majw/X9JNp71iBk40YvYH6wPhIRtqprUtamjThQiXJoLyLdU2c3FyGfW6xmHqmIpiWOBWQBFP1Fll95/eJ2nHQ5evRyHYeJmYCmTSw4+tLvOtB0RAd5v4kKemJgjAk4+3GEq/vXM1ZmfmiYDD1ACCZFgf8Yf0OfGkUJRyd+2yy9ZNf45nnyPXmXtIPnxXxxF1g== Received: from [216.39.60.180] by nm30.bullet.mail.gq1.yahoo.com with NNFMP; 28 Apr 2017 04:01:40 -0000 Received: from [98.137.12.197] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 28 Apr 2017 04:01:40 -0000 Received: from [127.0.0.1] by omp1005.mail.gq1.yahoo.com with NNFMP; 28 Apr 2017 04:01:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 891091.27031.bm@omp1005.mail.gq1.yahoo.com X-YMail-OSG: siJSFL8VM1mD8A_Iscu2q17FYKP6LBIEPJCOG7xzTCrkuWKO9o_z5QeMlrnUDM_ 3xhS3C5PaY5LMbyL_R_qIE6fImqTpwuQlGgLcQrZ9xtn82znxwjUGLD6ff3b67HW33ruGswUQ7tA qvBgfcOD0muI8j96GmDg3gEnsv1YqCN3HQydmQyXS7nlg9nV9FNuELbQr2cMNXhrRt29DglEoUvO dpSG.1u1q38hGlqC9Q2.CvLfc.M5RZ4RCspxuFYGByR1OF9hDoj..0DYBdOG3iVlvJbaP.xDNW0p iopIe4IFpdSajLn0tKVlB6V1xnlY501L6v.CtUP8nmVtbQ72.2k24EPHFmEMZkRNzVuk3YAMEw1z Z34a0yPdX8Sp1eJex0ll8mx34gLnEdWWQV7TINjE7.w232xIr59Zc0R7CaHrWS9JInrf2lHr45hx wU0aThWIZ3bwUuTtPvrQOwKYFN9VumKQZa5pL_rNWWYiJ3HnyuxYG2WrMOeLuPMqY1OiO9Zck3HQ amz1_Ma6pOD061zTZiUjVTM0MkEng_xCe4Q-- Received: from jws300008.mail.gq1.yahoo.com by sendmailws137.mail.gq1.yahoo.com; Fri, 28 Apr 2017 04:01:39 +0000; 1493352099.734 Date: Fri, 28 Apr 2017 04:01:39 +0000 (UTC) From: Reply-To: To: The IESG , Benoit Claise Cc: , , Bill Cerveny , , , Message-ID: <554038332.13283997.1493352099497@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <554038332.13283997.1493352099497.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9408 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [ippm] Benoit Claise's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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, 28 Apr 2017 04:04:09 -0000 On Wed, 4/12/17, Benoit Claise wrote: Subject: Benoit Claise's No Objection on draft-ietf-ippm-6man-pdm-option-0= 9: (with COMMENT) To: "The IESG" Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att= .com, ippm@ietf.org, jiangsheng@huawei.com Date: Wednesday, April 12, 2017, 11:30 AM =20 > Benoit Claise has entered the following ballot position for draft-ietf-ip= pm-6man-pdm-option-09: No Objection =20 >=C2=A0 Please refer to https://www.ietf.org/iesg/statement/discuss-criteri= a.html for more information about IESG DISCUSS and COMMENT positions. =20 > The document, along with other ballot positions, can be found here: https= ://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ =20 =20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- =20 > No objection to the publication of this document, but it's important to g= et Warren's COMMENT addressed: > This document defines a new IPv6 Destination Option. Adding this to a pac= ket pushes the L4 information further out, potentially making it unavailabl= e to the forwarding engine / > ACLs. This is not just a theoretical issue - see RFC7872 for real world e= xamples. This means that if I connect to a remote machine and enable this, = I may lock myself out > of the machine (return packets may not make it back to me); this should b= e noted (perhaps by expanding on section 1.6). =20 This was the text that was agreed on with Warren.=C2=A0 Please let me know= if you agree. Current Text ---------------- 1.6 IPv6 Transition Technologies In the path to full implementation of IPv6, transition technologies such as= translation or tunneling may be employed.=C2=A0 The PDM header is not expe= cted to work in such scenarios.=C2=A0 It is likely that an IPv6 packet containing PDM will be dropped if using IPv6 transition techno= logies. New Text ------------ 1.6 Full Support of IPv6 Functionality In the path to full implementation of native IPv6, transition technologies = such as translation or tunneling may be employed.=C2=A0 The PDM header may = not work in such scenarios.=C2=A0 It is likely that an IPv6 packet containing PDM will be dropped if using IPv6 transition technol= ogies. It is also possible that some devices in the network may not correctly hand= le multiple IPv6 Extension Headers, including the IPv6 Destination Option.= =C2=A0 For example, adding the PDM header to a packet may push the layer 4 information to a point in the packet where it is not v= isible to filtering logic, and may be dropped.=C2=A0 This kind of situation= is expected to become rare over time. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 =20 =20 From nobody Fri Apr 28 01:46:36 2017 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 209D2129C6F; Fri, 28 Apr 2017 01:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 AdB-D2x2U2gf; Fri, 28 Apr 2017 01:46:24 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9F9126BF0; Fri, 28 Apr 2017 01:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3073; q=dns/txt; s=iport; t=1493369002; x=1494578602; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=OHkWsZi1V5Lx7iPgmibINPNOonquT+X+UeEO+/hxmhI=; b=I5oSY6dajze3ndZC8smfZJ9o3RsMUjvYkrMUxifo025CcfGnBXsCXGfl CuShwLG/I0Za4sNjDTW1JUntO8SDTnQixSQIr94a0iMVokduLayjer0Mh cUYgK4GTNUxj+0HopygLMJ4orFci3GlZszhafK/iGvyACoGHHufXWwKwB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAQBRAANZ/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ2gQyDaIoYc5BblWyCDyyFeAKEbBgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMjFREwEAsUAwECAiYCAk8IBgEMBgIBAYobDqthgiaLBgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BC4VUgV4rgm+FACaCP4JfAQSJPZQThxmCaIkLggKFN4NChmO?= =?us-ascii?q?MAIgnHziBCi4gCBkVhWqBTD41AYdrAQEB?= X-IronPort-AV: E=Sophos;i="5.37,387,1488844800"; d="scan'208";a="652500493" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2017 08:42:55 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3S8gtHH002119; Fri, 28 Apr 2017 08:42:55 GMT To: nalini.elkins@insidethestack.com, The IESG References: <554038332.13283997.1493352099497.ref@mail.yahoo.com> <554038332.13283997.1493352099497@mail.yahoo.com> Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, acmorton@att.com, Bill Cerveny , ippm-chairs@ietf.org, ippm@ietf.org, jiangsheng@huawei.com From: Benoit Claise Message-ID: Date: Fri, 28 Apr 2017 10:42:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <554038332.13283997.1493352099497@mail.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ippm] Benoit Claise's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) 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, 28 Apr 2017 08:46:28 -0000 On 4/28/2017 6:01 AM, nalini.elkins@insidethestack.com wrote: > On Wed, 4/12/17, Benoit Claise wrote: > > Subject: Benoit Claise's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT) > To: "The IESG" > Cc: draft-ietf-ippm-6man-pdm-option@ietf.org, "Al Morton" , "Bill Cerveny" , ippm-chairs@ietf.org, acmorton@att.com, ippm@ietf.org, jiangsheng@huawei.com > Date: Wednesday, April 12, 2017, 11:30 AM > >> Benoit Claise has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. > >> The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- > >> No objection to the publication of this document, but it's important to get Warren's COMMENT addressed: >> This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / >> ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out >> of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). > > > This was the text that was agreed on with Warren. Please let me know if you agree. Sure. Thanks, B. > > Current Text > ---------------- > > 1.6 IPv6 Transition Technologies > > In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed. The PDM header is not expected to work in such scenarios. It is likely that an > IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. > > New Text > ------------ > > 1.6 Full Support of IPv6 Functionality > > In the path to full implementation of native IPv6, transition technologies such as translation or tunneling may be employed. The PDM header may not work in such scenarios. It is likely that an > IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. > > It is also possible that some devices in the network may not correctly handle multiple IPv6 Extension Headers, including the IPv6 Destination Option. For example, adding the PDM header to a packet > may push the layer 4 information to a point in the packet where it is not visible to filtering logic, and may be dropped. This kind of situation is expected to become rare over time. > > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > . > From nobody Fri Apr 28 15:24:00 2017 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 CE0D6129548; Fri, 28 Apr 2017 15:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Y5IH76kBruiJ; Fri, 28 Apr 2017 15:23:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D355E129AE0; Fri, 28 Apr 2017 15:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8676; q=dns/txt; s=iport; t=1493418067; x=1494627667; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7tF9TsyfQCaf/mAHEnrbcR1jppckr5hq2QTF0ffuXiY=; b=ZJerPMPD2bHZYCbn5W1K0t0YW/tsDqsgnB/WUNbEreZu3S94akJYN508 FlaiSs23IIKfx5gbw+KQY078Dp+qE8m0wmg/wRdzKwvbfeEBwdMK7Wntb axg19kqSn0qqsW2CYol049whgxxEm1bx5io7229MAeNIwGnkYXFCoQKZB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAQDcvwNZ/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQwHg2GKGJFNlW2CDyELhXgCGoQdPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQEhETMHCwUHBAIBCBEEAQEBAgIjAwICAiULFAEICAIEDgUbiXwID?= =?us-ascii?q?q9wgiaLGwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuDLoImgV4rgm+EPIMpLoI?= =?us-ascii?q?xBZZThn4Bkw2RXpQoAR84gQpvFUQSAYReHIFjdYUwgS+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,389,1488844800"; d="scan'208";a="242731511" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2017 22:21:06 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3SML6ul019258 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Apr 2017 22:21:06 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Apr 2017 18:21:05 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Fri, 28 Apr 2017 18:21:05 -0400 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel CC: "Ruediger.Geib@telekom.de" , IPPM Chairs , Al Morton , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSqBXsR2UglBUivky7lwWMt8jJvaGsFiIAgABoVYCAABw3AIAAG56AgAKShYCAC3l4gIAEX90AgAMRcwCABFD7gIAFNvIAgAAqgICAAArNAIAAu02AgADWd4CABb4lAIAGbjAAgAAeGgCAAgFOAA== Date: Fri, 28 Apr 2017 22:21:05 +0000 Message-ID: <3C354A6A-7E00-4B27-9BA2-8965F9E0E877@cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> <2BCD950B-DEBF-4FCD-92DD-89BE50270006@encrypted.net> <45679B2A-EE96-4980-BAED-B39994C73CFE@encrypted.net> <070501d2b5c8$dc264d30$9472e790$@olddog.co.uk> <58b68d6d47614281846807b6353b46f3@XCH-RCD-008.cisco.com> <38C60635-D7B8-4AA9-843D-ABBA65AC3D62@trammell.ch> <4D7F4AD313D3FC43A053B! 309F97543CF25F71AE7@njm texg5.research.att.com> <17864478fa3b4b58894f8b3c701505f4@HE101653.emea1.cds.t-internal.com> <4D7F4AD313D3FC43A053B309F97543CF25F72473@njmtexg5.research.att.com> <9C575ED7-E248-4D6D-855A-2F20926709DF@cisco.com> <39f70adc5ad34581bf83b0e9c48dd50a@HE101653.emea1.cds.t-internal.com> <00b001d2bf6d$18351c40$489f54c0$@olddog.co.uk> In-Reply-To: <00b001d2bf6d$18351c40$489f54c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.214.201] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session 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, 28 Apr 2017 22:23:59 -0000 VGhhbmtzLCBSw7xkaWdlciDigJQgSSBsaWtlIGl0IHRvbywgYW5kIHNpbmNlIHRoaXMgaXMgdGFy Z2V0aW5nIGEgd2lkZSByYW5nZSBvZiBkZXZlbG9wbWVudHMgKGkuZS4sIOKAnERlc2lnbmVycyBv ZiBjYXJyaWVyIHByb3RvY29scyBmb3IgSU9BTeKAnSBpbmNsdWRlcyBkaXNwYXJhdGUgZW5jYXBz KSwgd2UgbWlnaHQgd2FudCB0byBhbGxvdyBmb3Igc29tZSByb29tIGFuZCBub3QgYmUgdG8gcHJl c2NyaXB0aXZlIHNpbmNlIHRoZXJl4oCZcyBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzIGF2YWlsYWJs ZS4NCg0KVGhhdCBzYWlkLCBhcyB3ZSBhcmUgdGFsa2luZyBhYm91dCBlZGdlLXRvLWVkZ2UgcGF0 aCBjb25zdHJ1Y3RzLCB0aGVyZSBvdWdodCB0byB0aGluayBiZXlvbmQg4oCcY29uZmlnIGtub2Li gJ0gYW5kIGFsc28gaW5jbHVkZSBvcGVyYXRvciBjb2xsYWJvcmF0aW9uIGluIHRoZSBzb2x1dGlv bi4NCg0KSSBmdWxseSBhZ3JlZSB3aXRoIHlvdSBvbiByb2xlcy4NCg0KVGhhbmtzLA0KDQpDYXJs b3MuDQoNCj4gT24gQXByIDI3LCAyMDE3LCBhdCAxMTo0MyBBTSwgQWRyaWFuIEZhcnJlbCA8YWRy aWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQo+IA0KPiBUaGF0J3MgbmljZSBSw7xkaWdlciwNCj4g DQo+IEFsdGhvdWdoIHRvbyBtYW55ICJkZXNpZ25lcnMiIGluIHRoZSB0ZXh0Lg0KPiANCj4gQWRy aWFuDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGlwcG0gW21h aWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gUnVlZGlnZXIuR2Vp YkB0ZWxla29tLmRlDQo+PiBTZW50OiAyNyBBcHJpbCAyMDE3IDE0OjU2DQo+PiBUbzogY3BpZ25h dGFAY2lzY28uY29tDQo+PiBDYzogaXBwbS1jaGFpcnNAaWV0Zi5vcmc7IGFjbW9ydG9uQGF0dC5j b207IGlwcG1AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbaXBwbV0gVm90ZSBhdCBJUFBNIHNl c3Npb24NCj4+IA0KPj4gSGkgQ2FybG9zLA0KPj4gDQo+PiBMZXQgbWUgcGljayB1cCBGcmFuaydz IHByb3Bvc2FsOg0KPj4gDQo+PiBPTEQNCj4+ICJEZXNpZ25lcnMgb2YgY2FycmllciBwcm90b2Nv bHMgZm9yIElPQU0gZGVzaWduZXJzIG11c3QgY29uc2lkZXIgdG8gcHV0DQo+PiBtZWNoYW5pc21z IGluIHBsYWNlIHRvIGVuc3VyZSB0aGF0IGluLXNpdHUgT0FNIGRhdGEgc3RheXMgd2l0aGluIGFu IElPQU0NCj4+IGRvbWFpbi4uIg0KPj4gDQo+PiBORVcNCj4+ICJEZXNpZ25lcnMgb2YgY2Fycmll ciBwcm90b2NvbHMgZm9yIElPQU0gZGVzaWduZXJzIG11c3Qgc3BlY2lmeSBtZWNoYW5pc21zIHRv DQo+PiBlbnN1cmUgdGhhdCBpbi1zaXR1IE9BTSBkYXRhIHN0YXlzIHdpdGhpbiBhbiBJT0FNIGRv bWFpbi4uIg0KPj4gDQo+PiBJIGRvbid0IG9iamVjdCB0aGF0IHRoZSBvcGVyYXRvciBpcyBpbnZv bHZlZC4gQnV0IHRoZSBvcGVyYXRvcnMgdGFzayB0byBtZSBzaG91bGQNCj4+IGJlIHRvIHR1cm4g YW4gImluLXNpdHUgT0FNIGNvbmZpZ3VyYXRpb24ga25vYiIgdG8gc29sdmUgdGhlIHByb2JsZW0u IFRoaXMga25vYg0KPj4gbXVzdCBiZSBkZWxpdmVyZWQgYnkgdGhlIHByb3RvY29sIGRldmVsb3Bl cnMuICJDb25zaWRlciIgdG8gbWUgYXMgYSBub24tbmF0aXZlDQo+PiBzcGVha2VyIHNvdW5kcyBs aWtlICJ0aGluayBhYm91dCBhbmQgaWYgaXQncyBnZXR0aW5nIGNvbXBsZXgsIGRvaW5nIG5vdGhp bmcgaXMgYQ0KPj4gdmFsaWQgb3B0aW9uIi4NCj4+IA0KPj4gQXMgbWVudGlvbmVkIGVhcmxpZXIs IHJlbHlpbmcgb24gYSBmaXJld2FsbCB0byBtZSBpcyBhbiBvcHRpb24gSSdkIGxpa2UgdG8gYXZv aWQuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiANCj4+IFJ1ZWRpZ2VyDQo+PiANCj4+IC0tLS0tVXJz cHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4+IFZvbjogQ2FybG9zIFBpZ25hdGFybyAoY3Bp Z25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KPj4gR2VzZW5kZXQ6IFNvbm50YWcs IDIzLiBBcHJpbCAyMDE3IDEzOjQ0DQo+PiBBbjogQWwgTW9ydG9uDQo+PiBDYzogR2VpYiwgUsO8 ZGlnZXI7IGlwcG0tY2hhaXJzQGlldGYub3JnOyBpcHBtQGlldGYub3JnDQo+PiBCZXRyZWZmOiBS ZTogW2lwcG1dIFZvdGUgYXQgSVBQTSBzZXNzaW9uDQo+PiANCj4+IEhpLA0KPj4gDQo+PiBUaGlz IGlzIGEgdmVyeSB1c2VmdWwgZGlzY3Vzc2lvbiDigJQgYWx0aG91Z2ggb24gdGhlIHRhaWwtZW5k IHNlZW1zIHRvIGJlIGRpdmVyZ2luZw0KPj4gZnJvbSB0aGUgb3JpZ2luYWwgZ29hbC4gSSBzdWdn ZXN0IHRoYXQgd2Ugc2hvdWxkIHByb2JhYmx5IG5vdCB0YWtlIHRoaXMgZGlzY3Vzc2lvbg0KPj4g aW50byBhbGwgaW50ZXItZG9tYWluIHBlcm11dGF0aW9ucy4NCj4+IA0KPj4gSW4gb3RoZXIgd29y ZHMsIGlzIHRoZXJlIHNvbWUgY2FzZSB0aGF0IHRoZSBvcmlnaW5hbCB0ZXh0IGRvZXMgbm90IGNv dmVyPyBUaGUgdGV4dA0KPj4gaW5jbHVkZXMg4oCcbWVjaGFuaXNtcyBpbiBwbGFjZSB0byBlbnN1 cmUgdGhhdCBpbi1zaXR1IE9BTSBkYXRhIHN0YXlzIHdpdGhpbiBhbg0KPj4gSU9BTSBkb21haW7i gJ0gYW5kIOKAnHByb3Zpc2lvbnMgaW4gcGxhY2UgdG8gZW5zdXJlIHRoYXQgSU9BTSBkYXRhIGRv ZXMgbm90IGxlYWsNCj4+IGJleW9uZCB0aGUgZWRnZSBvZiBhbiBJT0FNIGRvbWFpbuKAnS4NCj4+ IA0KPj4gVGhlIGlkZWEgaXMgdGhhdCBhbiBJT0FNIERvbWFpbiBzaG91bGQgdGFrZSBjYXJlIG9m IGNvbnNpZGVyYXRpb25zIGJlY2F1c2Ugb2YNCj4+IGUuZy4sIGluY3JlYXNlZCBwYWNrZXQgc2l6 ZXMgd2l0aGluIGl0cyBkb21haW4sIGFuZCBwcmV2ZW50IGxlYWthZ2UuDQo+PiANCj4+IEluIG1h bnkgZGVwbG95bWVudHMsIHRoZSBsYXR0ZXIgKGkuZS4sICJlbnN1cmluZyB0aGF0IGlPQU0gZGF0 YSBzdGF5cyB3aXRoaW4gdGhlDQo+PiBkb21haW4sIGFuZCBkb2VzIG5vdCBsZWFrIGJleW9uZCB0 aGUgZXhpdCBlZGdl4oCdKSB3b3VsZCBiZSBhIG5hdHVyYWwNCj4+IGNoYXJhY3RlcmlzdGljIG9m IHRoZSBlbmNhcHN1bGF0aW9uLiBGb3IgZXhhbXBsZSwgd2hlbiB1c2luZyBJT0FNIHdpdGggTlNI LCBhbg0KPj4gSU9BTSBkb21haW4gd291bGQgYmUgYW4gU0ZDIGRvbWFpbiwgYW5kIHRodXMgcmVt b3ZpbmcgTlNIIGVuY2FwIHdpbGwgYWxzbw0KPj4gZW5zdXJlIElPQU0gZG9lcyBub3QgbGVhay4g U2FtZSB3aXRoIFZ4TEFOLUdQRSwgZXRjLg0KPj4gDQo+PiBCdXQgbmV0LW5ldCwgSeKAmWQgcmVj b21tZW5kIHdlIGRlZmluZSB0aGUgSU9BTSBkb21haW4gYmVoYXZpb3IgYW5kIG5vdCBhbGwNCj4+ IG90aGVyIHBvc3NpYmxlIHZpZXdzLg0KPj4gDQo+PiBUaGFua3MhDQo+PiANCj4+IOKAlCBDYXJs b3MuDQo+PiANCj4+PiBPbiBBcHIgMTksIDIwMTcsIGF0IDQ6MDIgUE0sIE1PUlRPTiwgQUxGUkVE IEMgKEFMKSA8YWNtb3J0b25AYXR0LmNvbT4NCj4+IHdyb3RlOg0KPj4+IA0KPj4+IEhpIFLDvGRp Z2VyLA0KPj4+IHNob3J0IHJlcGx5IGluLWxpbmUsDQo+Pj4gQWwNCj4+PiANCj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRl IFttYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlXQ0KPj4+PiBTZW50OiBXZWRuZXNkYXks IEFwcmlsIDE5LCAyMDE3IDM6MTUgQU0NCj4+Pj4gVG86IE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0K Pj4+PiBDYzogaXBwbS1jaGFpcnNAaWV0Zi5vcmc7IGlwcG1AaWV0Zi5vcmc7IGlldGZAdHJhbW1l bGwuY2g7DQo+Pj4+IGZicm9ja25lQGNpc2NvLmNvbQ0KPj4+PiBTdWJqZWN0OiBBVzogW2lwcG1d IFZvdGUgYXQgSVBQTSBzZXNzaW9uDQo+Pj4+IA0KPj4+PiBIaSBBbCwNCj4+Pj4gDQo+Pj4+IGlz IGEgbm9uLWlPQU0gbmV0d29yayBvcGVyYXRvciBhYmxlIHRvIGRldGVjdCBzdGFuZGFyZCBpcHY2 IHBhY2tldHMNCj4+Pj4gd2l0aCBpT0FNIGV4dGVuc2lvbnMsIGlmIHRoZSByZWNlaXZpbmcgb3Bl cmF0b3JzIGVxdWlwbWVudCBpcw0KPj4+PiBjb25maWd1cmVkIHRvIHN1cHBvcnQgc3RhbmRhcmQg aXB2NiBwcm90b2NvbCBvbmx5PyBUaGUgcHJlLWNvbmRpdGlvbg0KPj4+PiBoZXJlIGlzICJub24t aU9BTSBkb21haW4iIGF0IHRoZSByZWNlaXZpbmcgc2lkZS4gTXkgcG9pbnQgaXMsIGlmIGENCj4+ Pj4gZG9tYWluIGlzbid0IGludGVyZXN0ZWQgaW4gc3VwcG9ydGluZyB0aGUgaU9BTSBleHRlbnNp b25zLCBpcyBpdA0KPj4+PiBvYmxpZ2VkIHRvIG9wZXJhdGUgaU9BTSBhd2FyZSBlcXVpcG1lbnQg dG8gZGV0ZWN0IHVuZGVzaXJlZCB0cmFmZmljIGF0DQo+PiBuZXR3b3JrIGJvdW5kYXJpZXM/DQo+ Pj4gW0FDTV0NCj4+PiBObywgYW4gb3BlcmF0b3IgY2FuIGxldCB0aGUgdHJhZmZpYyBmbG93IGlm IHRoZXkgd2FudC4NCj4+PiBIb3dldmVyLCBpZiBvcGVyYXRvcnMgZmluZCB0aGF0IHRoZWlyIG5l dHdvcmsgaXMgYWZmZWN0ZWQgYnkgdHJhZmZpYw0KPj4+IHdpdGggaU9BTSBkYXRhIGZyb20gYW5v dGhlciBkb21haW4sIHRoZXkgd291bGQgYmUganVzdGlmaWVkIHRvIGRpc2NhcmQNCj4+PiB0aGF0 IHRyYWZmaWMgKGFzIGxvbmcgYXMgdGhlcmUgaXMgYSBjbGVhciBkb21haW4gbGltaXQgZXhwcmVz c2VkIHRvDQo+Pj4gaU9BTSBwcm90b2NvbCBkZXNpZ25lcnMgb2YgdGhlIGZ1dHVyZSwgYXMgRnJh bmsgaGFzIHN1Z2dlc3RlZCkuDQo+Pj4gDQo+Pj4gVGhpcyBpcyB0aGUgc2FtZSBhYmlsaXR5IGFm Zm9yZGVkIG9wZXJhdG9ycyBieSBkZWNsYXJpbmcgQk1XRyBhZGRyZXNzDQo+Pj4gc3BhY2UgZm9y IGlzb2xhdGVkIHRlc3Rpbmctb25seSwgb3IgdGhlIHZhcmlvdXMgcHJpdmF0ZSBuZXR3b3JrDQo+ Pj4gYWRkcmVzcyBzcGFjZXMuIFBsZW50eSBvZiBOZXQxMCB0cmFmZmljIGVzY2FwZXMsIGFuZCBv cGVyYXRvcnMgYXJlIG5vdA0KPj4+IG9ibGlnZWQgdG8gZHJvcCBpdCwgYnV0IHRoZXkgY2VydGFp bmx5IGNhbi4NCj4+PiANCj4+Pj4gDQo+Pj4+IEknbSBub3Qgc3VyZSwgd2hldGhlciB0aGlzIGlz IGFuIElQUE0gZGlzY3Vzc2lvbi4gSXMgdGhlcmUgYW55IG90aGVyDQo+Pj4+IElQUE0gcHJvdG9j b2wgb3IgcGFja2V0IGNvbnRlbnQgcmVxdWlyaW5nIGEgZGlzY2FyZCBvZiB0cmFmZmljIGF0IGEN Cj4+Pj4gZG9tYWluIGJvdW5kYXJ5Pw0KPj4+PiANCj4+Pj4gUmVnYXJkcywNCj4+Pj4gDQo+Pj4+ IFJ1ZWRpZ2VyDQo+Pj4+IA0KPj4+PiANCj4+Pj4gW0FDTV0NCj4+Pj4gDQo+Pj4+IElPTSwgdGhl cmUgaXMgYSBnZW5lcmFsIG1lc3NhZ2UgdG8gY29udmV5IGZvciBhbGwgZnV0dXJlIHByb3RvY29s DQo+Pj4+IGRldmVsb3BtZW50LiBTb21ldGhpbmcgbGlrZSAic3VmZmljaWVudCBwcm92aXNpb25z IHNob3VsZCBiZSBtYWRlIHRvDQo+Pj4+IHJlc3RyaWN0IHRoZSBpT0FNIHRyYWZmaWMgdG8gdGhl IGludGVuZGVkIGRvbWFpbi4iDQo+Pj4+IA0KPj4+PiBXZSBjb3VsZCBwcm92aWRlIGd1aWRhbmNl IHRvIGludGVyY29ubmVjdGluZyBuZXR3b3JrIG9wZXJhdG9ycywgYXMNCj4+Pj4gd2VsbCwgZWZm ZWN0aXZlbHkgYWxsb3dpbmcgdGhlbSB0byBkaXNjYXJkIHRyYWZmaWMgY29udGFpbmluZw0KPj4+ PiB1bmV4cGVjdGVkIGlPQU0gZGF0YS4gVGhpcyB3b3VsZCBiZSBhcHBsaWNhYmxlIHRvIG5vbi1p T0FNIG5ldHdvcmsNCj4+Pj4gb3BlcmF0b3JzLCBidXQgbWlnaHQgYmUgbW9yZSBpbXBvcnRhbnQg Zm9yIGludGVyY29ubmVjdGluZyBvcGVyYXRvcnMNCj4+Pj4gd2hvIGhhdmUgZXN0YWJsaXNoZWQg dGhlaXIgb3duIGlPQU0gZG9tYWluLg0KPj4+PiANCj4+Pj4gVGhpcyBpcyBzaW1pbGFyIHRvIHRo ZSBhcHByb2FjaCB3ZSB1c2VkIGZvciBCTVdHIHRlc3QgdHJhZmZpYzoNCj4+Pj4gdGhlcmUgYXJl IHY0IGFuZCB2NiBhZGRyZXNzIHNwYWNlcyBkZWRpY2F0ZWQgZm9yIGlzb2xhdGVkIHRlc3QNCj4+ Pj4gZW52aXJvbm1lbnRzLCBhbmQgYW55IHBhY2tldCB3aXRoIHRlc3RpbmcgYWRkcmVzc2VzIG9i c2VydmVkIG9uIHRoZQ0KPj4+PiBJbnRlcm5ldCBtYXkgYmUgZGlzY2FyZGVkLg0KPj4+PiANCj4+ PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+IGlwcG0gbWFpbGluZyBsaXN0DQo+Pj4gaXBwbUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KPj4gDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gaXBwbSBtYWlsaW5nIGxpc3QNCj4+ IGlwcG1AaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBwbQ0KPiANCg0K

On Apr 7, 2017, at 2:15 PM, = Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Mahesh,
I think that there could be two = models - TWAMP-Control and TWAMP-Test. I don't see any good reason to = have TWAMP-Test configuration model as part of TWAMP-Control. In fact, = having it there makes control of a test session ambiguous as only one of = them must be used to configure a test session. TWAMP-Control model only = needs test session operational state model and it should use the one = defined in TWAMP-Test model.

Regards,
Greg 

On Fri, Apr 7, 2017 at 10:57 AM, = Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Besides, from a YANG modeling = perspective, the model has to model both the Control and Test part. = Implementations that choose not to use Control can choose not to do = so. 

On Mar 27, 2017, at 4:07 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:

I=E2=80=99m = sorry Roni, but that=E2=80=99s exactly what this phrase,
=E2=80=9C...an incremental path to = adopting TWAMP=E2=80=A6=E2=80=9D =  means,
suggesting a multi-step process to achieve a full TWAMP
implementation.
 
The = sentence in the body sets the context for Appendix I.
It says the Appendix describes building TWAMP-Test *first*.
Clearly, TWAMP-Test is not the final step!
 
Al
 
From: Ron = Even [mailto:ron.even.tlv@gmail.com] 
Sent: Monday,= March 27, 2017 6:54 PM
To: MORTON,= ALFRED C (AL)
Cc: Mahesh = Jethanandani; ippm@ietf.org
Subject: Re: = [ippm] RFC 4656 on use of OWAMP-Control and relationship with = OWAMP-Test
 
Al,
The last part of your response  " then = implementing the rest of TWAMP (TWAMP-Control)." is not there. This is = why I said that it does not say that you SHOULD implement the control = protocol, you can stop after implmenting the test protocol.
Roni
 
On= Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:
Roni, = in-line:
 
From: Ron = Even [mailto:ron.even.tlv@gmail.com] 
Sent: Monday,= March 27, 2017 5:54 PM
To: Mahesh = Jethanandani
Cc: MORTON,= ALFRED C (AL); ippm@ietf.org
Subject: Re: = [ippm] RFC 4656 on use of OWAMP-Control and relationship with = OWAMP-Test
 
Hi,
I = read both RFC5357 and RFC 4656 and even though they say that TWAMP = consist of two protocol it never says that  both MUST be used = anywhere in the document. The document does not have a lot of normative = text.
 
Section 5 of RFC5357 is an example and not a requirement and = even the text that was mentioned in the IPPM session
 
"Appendix = I provide= s an example for purely informational purposes. It
   suggests an incremental path to adopting TWAMP, =
by implementing the
   TWAMP-Test protocol =
first."
 
Does not say that using TWAMP-Test without the control =
protocol SHOULD NOT be used.
[ACM] =

Of course it doesn=E2=80=99t! It says Appendix I describes a =

the first step of one process of standards-track TWAMP =

implementation, by starting with TWAMP-light, then =

implementing the rest of TWAMP (TWAMP-Control).
 
Al
 
 
 
 
Roni Even
 
 
 
 
 
On= Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Greg,
 
And the part that you forgot to quote that followed in = Section 1.1 is:
 
TWAMP-
  =
 Control is used to initiate, start, and stop test sessions, whereas
  =
 TWAMP-Test is used to exchange test packets between two TWAMP
  =
 entities.
 
There is clearly a precedence for TWAMP-Control to be a = entity by itself and very much part of the TWAMP protocol.
 
If= this is this rational for your comments on the YANG model, then I fail = to see RFC 5357 backing your claim that TWAMP-control is optional.
 
Cheers.
 
On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C = (AL) <acmorton@att.com> wrote:
 
Greg,
 
All ambiguity falls away in the context of
the = complete TWAMP document, which says:
 
   This example eliminates the need for the = TWAMP-Control protocol, and
   assumes that the Session-Reflector is configured = and communicates its
   configuration with the Server through = non-standard means.
 
The example referred to above is not TWAMP;
it is the = option you describe, but it is
called *TWAMP light*.
 
Al
 
From: ippm = [mailto:ippm-bounces@ietf.org] On Behalf = Of Greg Mirsky
Sent: Monday, March 27, 2017 3:16 PM
To: MORTON, ALFRED C (AL)
Cc: ippm@ietf.org
Subject: Re: [ippm] RFC 4656 on use of = OWAMP-Control and relationship with OWAMP-Test
 
Hi Al,
then, in my opinion, there's certain ambiguity = in the text of RFC 4656 and in RFC 5357 as well because of the following = statement in the very first sentence of section 1.1 RFC 5357:
   Similar to OWAMP [RFC4656], =
TWAMP consists of two inter-related
  =
 protocols: TWAMP-Control and TWAMP-Test.  The relationship of =
these
   protocols is as defined in Section =
1.1 of OWAMP [RFC4656]. =

 
Regards,
Greg
 
On= Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:
Greg,
 
If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or = =E2=80=9COPTIONAL=E2=80=9D (the term
you used today when presenting) we would have used = the
RFC 2119 term in the text.
 
There are plenty of other examples where both = Control
and Test protocols are taken as =E2=80=9Cthe full = TWAMP=E2=80=9D.
 
Al
 
 
From: ippm = [mailto:ippm-bounces@ietf.org] On Behalf = Of Greg Mirsky
Sent: Monday, March 27, 2017 12:29 PM
To: ippm@ietf.org
Subject: [ippm] RFC 4656 on use of OWAMP-Control = and relationship with OWAMP-Test
 
Dear All,
the second paragraph in section 1.1 of RFC 4656 states the = following:
  =
 Although OWAMP-Test may be used in conjunction with a control
 =
  protocol other than OWAMP-Control, the authors have =
deliberately
   chosen to include both protocols in the =
same RFC to encourage the
   implementation and deployment of =
OWAMP-Control as a common
   denominator control protocol for one-way =
active measurements.
 
I interpret "may be used" as MAY per RFC 2119. Please =
let me know if this should not be the case.
 
Regards,
Greg
 
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
 
Mahesh = Jethanandani
 
 
 


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